백업을 진지하게 생각하게 되는 순간
해킹, 업데이트 실패, 실수로 인한 파일 삭제, 호스팅 장애. 웹사이트를 한 번이라도 운영해 본 사람이라면 이 중 하나는 겪어봤을 가능성이 높습니다. 문제는 이런 사고가 터진 뒤에야 백업을 떠올린다는 점입니다. "그때 백업만 해뒀더라면"이라는 후회를 막는 가장 확실한 방법은, 평소에 체계적인 백업 전략을 만들어 두는 것뿐입니다.
무엇을 백업해야 하는가
웹사이트 백업이라고 하면 흔히 파일만 떠올리지만, 실제로는 여러 종류의 데이터가 함께 관리되어야 합니다.
- 데이터베이스: 게시글, 주문, 회원 정보 등 동적으로 쌓이는 데이터
- 업로드 파일: 이미지, PDF, 첨부파일 등 사용자가 올린 미디어
- 소스 코드와 테마: 커스터마이징된 템플릿, 플러그인, 설정 값
- 환경 설정: 서버 환경 파일, DNS 레코드, 웹서버 설정
- SSL 인증서와 API 키: 재발급 비용과 시간이 드는 자산
이 중 하나라도 빠지면 완전한 복구는 불가능합니다.
백업의 황금 법칙, 3-2-1 원칙
업계에서 오래도록 통용되는 공식이 있습니다. 3개의 복사본, 2가지 서로 다른 저장 매체, 1개는 반드시 오프사이트 보관. 원본에 더해 두 개의 백업본을 두되, 그중 하나는 물리적으로 다른 장소에 보관하라는 뜻입니다. 호스팅 서버 안에만 백업이 있다면, 서버가 통째로 사라질 때 백업도 함께 사라집니다.
주기와 보관 기간은 어떻게 정하나
주기는 사이트의 변경 빈도에 맞춥니다. 쇼핑몰처럼 매일 주문이 쌓이는 사이트는 데이터베이스를 최소 하루 한 번, 업로드가 잦다면 더 자주 백업해야 합니다. 반면 소개 사이트라면 주 1회 백업으로도 충분할 수 있습니다.
보관 기간은 일일 7일 + 주간 4주 + 월간 6개월 같은 계단식 구조를 추천합니다. 뒤늦게 발견되는 데이터 오염이나 악성 코드 잠복에 대비하려면, 최신 백업만 덮어쓰는 방식은 위험합니다. 시점별로 되돌아갈 수 있는 여러 지점을 확보해 두는 것이 핵심입니다.
자동화하지 않은 백업은 오래가지 않는다
수동 백업은 결국 잊히기 마련입니다. 규모와 기술 스택에 맞는 자동화 도구를 반드시 도입하세요.
- 워드프레스 기반: UpdraftPlus나 BlogVault 같은 플러그인으로 구글 드라이브·S3에 자동 업로드
- Laravel·커스텀 PHP: spatie 백업 패키지와 cron 스케줄러, 혹은 mysqldump와 rclone을 조합한 스크립트
- 호스팅사 제공 백업: Cafe24·가비아 등 기본 백업은 보조 수단으로만 활용하세요. 주 백업으로는 부족합니다
클라우드 스토리지 목적지는 AWS S3나 Backblaze B2처럼 원본 서버와 다른 리전을 선택할 수 있는 곳이 좋습니다.
복구 테스트하지 않은 백업은 백업이 아니다
가장 많이 놓치는 단계가 복구 리허설입니다. 백업 파일이 존재한다는 사실과 그 파일로 실제 사이트를 되살릴 수 있다는 사실은 전혀 다른 이야기입니다. 최소 분기에 한 번은 스테이징 환경에 복구해 보고, 소요 시간과 절차를 문서로 남겨 두세요. 사고가 터진 당일은 매뉴얼을 차근차근 읽을 여유가 없는 날입니다.
백업은 시간이 아니라 안심을 사는 일입니다
백업에 들어가는 스토리지 비용은 보통 월 몇천 원에서 몇만 원 수준입니다. 반면 사이트를 처음부터 재구축하는 비용과 시간, 그 사이에 발생하는 매출 손실은 그보다 수십 배 큽니다. CYAN은 새 사이트를 오픈할 때 자동 백업과 복구 매뉴얼 세팅을 기본 과정으로 포함하고 있습니다. 지금 운영 중인 사이트가 걱정된다면, "현재 백업이 어디에 있는가"와 "복구에 얼마나 걸리는가" 두 가지 질문에 먼저 답해 보세요. 그 답이 막연하다면, 오늘이 점검하기에 가장 좋은 날입니다.