사이트가 잘 돌아갈 때는 아무도 백업을 신경 쓰지 않습니다. 문제는 늘 예고 없이 찾아옵니다. 호스팅 업체의 장애, 잘못 누른 삭제 버튼, 업데이트 중 꼬인 데이터베이스, 혹은 해킹 한 번이면 몇 년간 쌓아 올린 사이트가 하루아침에 빈 화면이 됩니다. 그리고 그 순간 가장 먼저 떠오르는 질문은 단 하나입니다. "백업, 있나요?"
안타깝게도 많은 작은 회사가 이 질문 앞에서 무너집니다. 백업은 사이트가 멀쩡할 때 준비해야 의미가 있고, 장애가 터진 뒤에는 이미 늦습니다. 오늘은 작은 회사가 비용을 크게 들이지 않고도 갖출 수 있는 백업과 장애 복구의 5가지 원칙을 정리합니다.
1. 백업은 '있다'가 아니라 '복구된다'로 증명한다
가장 흔한 착각은 "호스팅 업체가 알아서 백업하겠지"라는 믿음입니다. 실제로 많은 공유 호스팅은 백업을 보장하지 않거나, 보장하더라도 복구 시 추가 비용을 받습니다. 더 위험한 건 백업 파일은 있는데 막상 복구가 안 되는 경우입니다.
백업의 진짜 목적은 파일을 보관하는 것이 아니라 실제로 사이트를 되살리는 것입니다. 그러니 분기에 한 번이라도 테스트 서버에 백업을 복원해 보고, 사이트가 정상적으로 뜨는지 직접 확인하세요. 복구 연습을 한 번도 해본 적 없는 백업은 백업이 아니라 그저 압축 파일일 뿐입니다.
2. 3-2-1 규칙으로 단일 실패 지점을 없앤다
업계에서 검증된 백업의 기본 공식은 3-2-1 규칙입니다.
- 3개의 복사본: 원본을 포함해 최소 3개의 데이터 사본을 유지합니다.
- 2개의 다른 매체: 서버 디스크와 클라우드 스토리지처럼 서로 다른 저장 매체에 둡니다.
- 1개의 오프사이트: 최소 한 부는 물리적으로 떨어진 외부(클라우드 등)에 보관합니다.
같은 서버 안에만 백업이 있다면 그 서버가 통째로 날아가는 순간 백업도 함께 사라집니다. AWS S3나 Cloudflare R2 같은 외부 오브젝트 스토리지에 자동으로 백업을 올려두면, 호스팅이 어떤 사고를 겪어도 데이터는 살아남습니다.
3. 자동화하지 않은 백업은 결국 멈춘다
"매주 수요일에 직접 백업받아야지"라는 다짐은 두세 번이면 흐지부지됩니다. 사람의 습관에 의존하는 백업은 가장 바쁘고 정신없을 때, 즉 가장 백업이 필요한 시점에 가장 먼저 빠집니다.
해법은 스케줄러를 통한 자동화입니다. 리눅스 서버라면 cron, 프레임워크라면 내장 스케줄러를 이용해 매일 정해진 시각에 데이터베이스 덤프와 업로드 파일을 묶어 외부 스토리지로 전송하도록 설정하세요. 그리고 백업이 성공했는지 실패했는지를 알림(메일·메신저)으로 받도록 해두는 것이 핵심입니다. 조용히 멈춰버린 백업만큼 위험한 것이 없기 때문입니다.
4. 복구 목표 시간(RTO)과 복구 시점(RPO)을 정해둔다
장애 복구를 막연히 "최대한 빨리"로 두면 막상 사고가 났을 때 우왕좌왕하게 됩니다. 두 가지 숫자를 미리 정해두면 대응이 명확해집니다.
- RTO(복구 목표 시간): 사이트가 멈춘 뒤 몇 시간 안에 되살릴 것인가. 쇼핑몰이라면 1시간, 단순 소개 사이트라면 하루처럼 사업 성격에 맞춰 정합니다.
- RPO(복구 시점 목표): 데이터를 몇 시간 전 상태까지 되돌릴 수 있어야 하는가. 주문 데이터가 매시간 쌓인다면 백업 주기도 그만큼 촘촘해야 합니다.
이 두 숫자가 정해지면 백업 주기와 보관 방식이 자연스럽게 결정됩니다. 하루에 한 번 백업으로는 RPO가 24시간이라는 뜻이고, 그 사이의 데이터는 포기해야 한다는 의미입니다.
5. 복구 절차를 문서로 남기고 담당자를 정한다
장애는 보통 담당 개발자가 자리에 없을 때, 새벽이나 주말에 터집니다. 그때 "어디에 백업이 있고, 어떻게 복원하는지"가 한 사람의 머릿속에만 있다면 사이트는 그 사람이 연락될 때까지 멈춰 있습니다.
그래서 복구 절차를 짧게라도 문서로 남기는 것이 중요합니다. 호스팅·도메인·DB 접속 정보가 어디에 있는지, 백업 파일은 어느 스토리지에 있는지, 복원 명령은 무엇인지를 단계별로 적어두세요. 그리고 1차·2차 담당자를 정해 비상 연락 체계를 만들어 두면, 사고가 나도 패닉 대신 절차가 작동합니다.
멈췄을 때를 위해 준비하는 것
백업과 장애 복구는 매출을 직접 늘려주지 않습니다. 그래서 늘 뒤로 밀립니다. 하지만 사이트가 곧 매출이고 신뢰인 작은 회사에게, 단 한 번의 장애는 그동안 쌓아온 모든 것을 무너뜨릴 수 있습니다. 보험처럼, 쓸 일이 없기를 바라지만 없으면 안 되는 것이 바로 백업입니다.
CYAN은 작은 회사의 웹사이트를 만들 때 백업 자동화와 장애 복구 체계를 처음부터 함께 설계합니다. 화려한 화면 뒤에서 보이지 않게 사이트를 지키는 일까지가 진짜 웹 제작이라고 믿기 때문입니다. 지금 운영 중인 사이트의 백업이 정말 '복구되는' 백업인지 한 번쯤 점검이 필요하다면, 편하게 문의해 주세요.