사장님, 마지막으로 우리 사이트를 백업한 게 언제인가요? 이 질문에 즉시 대답할 수 없다면 사이트는 이미 위험에 노출되어 있는 셈입니다. 호스팅이 잘 돌아가고 있을 때는 백업의 존재 자체를 의식하지 않게 됩니다. 그러다 한 번의 해킹, 한 번의 실수로 데이터베이스가 날아가거나, 한 번의 서버 장애로 사이트가 통째로 사라진 뒤에야 비로소 백업의 가치를 깨닫지요. 그때는 이미 늦습니다.
실무에서 마주친 사고들은 대부분 거창한 사이버 공격이 아니었습니다. 관리자가 잘못 누른 한 번의 삭제 버튼, 플러그인 업데이트 실패, 호스팅 결제 카드 만료로 인한 계정 정지 — 평범한 일상 안에서 데이터는 사라집니다. 작은 사업장의 웹사이트일수록 백업이 더 절실한 이유입니다. 오늘은 사장님이 직접 챙겨야 할 백업 전략 다섯 가지를 정리합니다.
1. 무엇을 백업할지부터 정확히 알아야 한다
흔히 '사이트 백업'이라고 하면 파일만 떠올리지만, 실제로 백업해야 할 대상은 세 가지입니다. 소스 코드, 데이터베이스, 그리고 사용자 업로드 파일입니다. 셋 중 하나라도 빠지면 복원해도 사이트는 정상 작동하지 않습니다.
- 소스 코드: 깃(Git) 저장소를 운영하고 있다면 코드 백업은 자동으로 해결됩니다. 그렇지 않다면 서버의 public_html 전체를 정기적으로 압축해 두어야 합니다.
- 데이터베이스: 게시글, 회원 정보, 주문 내역이 모두 들어 있는 핵심 자산입니다. mysqldump로 일 단위 덤프를 떠야 합니다.
- 업로드 파일: 상품 이미지, 첨부 파일, 영상은 데이터베이스에 들어 있지 않습니다. /uploads, /storage 폴더를 별도로 백업해야 합니다.
2. 변경 빈도가 백업 주기를 결정한다
매일 새 글이 올라오는 블로그라면 일 단위 백업이 기본입니다. 하루에 수십 건의 주문이 들어오는 쇼핑몰이라면 한 시간 단위로도 부족할 수 있습니다. 반면 거의 변동이 없는 회사 소개 사이트라면 주 단위 백업으로도 충분합니다. 백업 주기를 정할 때는 '얼마만큼의 데이터를 잃어도 비즈니스가 멈추지 않는가'라는 질문에서 출발하세요. 이 한도가 곧 RPO(Recovery Point Objective)이고, 그 시간이 백업 주기의 상한선입니다.
3. 같은 서버 안의 백업은 백업이 아니다
가장 흔한 실수가 같은 서버의 다른 폴더에 백업본을 두는 것입니다. 서버 자체가 죽으면 백업도 함께 죽습니다. 랜섬웨어를 당하면 백업 폴더도 함께 암호화됩니다. 백업의 핵심은 물리적으로 분리된 다른 저장소에 보관하는 것입니다.
현실적인 선택지는 셋입니다. AWS S3, Cloudflare R2, 백블레이즈 B2 같은 클라우드 오브젝트 스토리지에 자동 업로드하거나, 별도의 NAS에 동기화하거나, 최소한 사장님 PC와 외장하드에 주 1회라도 다운로드해 두는 것입니다. 3-2-1 원칙 — 데이터 사본 3개, 서로 다른 매체 2종류, 그중 1개는 외부에 보관 — 을 기억하시면 좋습니다.
4. 복원해보지 않은 백업은 백업이 아니다
실제로 사고를 당한 사장님들에게 가장 자주 듣는 말이 있습니다. "백업은 매일 돌고 있었는데, 막상 복원하려니 안 되더라." 백업 파일이 손상되어 있거나, 데이터베이스 덤프의 인코딩이 깨져 있거나, 압축 비밀번호를 아무도 모르는 경우가 정말 많습니다.
그래서 백업 못지않게 중요한 것이 정기적인 복원 훈련입니다. 분기에 한 번이라도 좋으니, 테스트 서버에 백업을 풀어 사이트를 띄워보세요. 실제로 화면이 뜨고, 로그인이 되고, 결제 모듈까지 정상 동작하는 것을 확인해야 비로소 그 백업은 '쓸 수 있는 백업'이 됩니다.
5. 자동화되지 않은 백업은 결국 잊힌다
"매주 금요일에 백업하기"를 손으로 하면 한 달은 지키지만, 석 달 뒤에는 까맣게 잊어버립니다. 사람의 습관은 백업을 지킬 만큼 견고하지 않습니다. cron + 셸 스크립트 + 클라우드 업로드 — 이 조합으로 한 번 자동화해두면 사장님이 잠들어 있어도 새벽 3시에 백업이 돌아가고 클라우드에 올라갑니다.
여기에 한 가지 더, 백업 실패 알림을 반드시 붙이세요. 슬랙이나 이메일로 "오늘 백업 성공/실패"가 매일 도착해야 합니다. 알림이 없는 자동화는 조용히 멈춰도 아무도 모릅니다. 6개월 뒤 사고가 났을 때 "아, 그 백업 사실 두 달 전부터 안 돌고 있었네"라고 깨닫는 것이 가장 무서운 시나리오입니다.
백업은 사이트의 보험입니다
백업은 매출을 늘려주지도, 트래픽을 끌어오지도 않습니다. 그래서 우선순위에서 늘 밀리지요. 하지만 한 번의 사고로 사이트가 사라졌을 때, 백업이 있는 사장님과 없는 사장님의 그날 저녁은 완전히 다릅니다. 한 분은 "한 시간 안에 복원되겠네"라며 잠을 청하고, 한 분은 "지난 5년의 콘텐츠가 다 사라졌다"는 사실 앞에서 밤을 새웁니다.
CYAN은 사이트를 만들 때부터 이 다섯 가지 원칙을 함께 설계합니다. 자동 백업 스크립트, 클라우드 스토리지 연동, 복원 매뉴얼까지 — 사장님이 새벽에 잠을 설치지 않으셔도 되도록 백업 체계를 갖춰드립니다. 백업이 걱정이라면 한 번 점검을 권해드립니다.