홈페이지 백업 주기: 우리 사업에 맞는 복구 기준을 정하는 법
홈페이지 백업은 무조건 하루 한 번이 아니라, 장애가 났을 때 잃어도 되는 데이터 양과 허용 가능한 중단 시간을 먼저 정한 뒤 그 기준에 맞춰 설계해야 합니다.
읽기 전에 핵심만
- 백업 주기는 관행이 아니라 사업이 허용할 데이터 손실 시간인 RPO를 기준으로 정해야 합니다.
- 운영 서버와 분리된 사본을 두고 데이터베이스·업로드·설정까지 복구 대상에 포함하세요.
- 정기 복구 시험으로 실제 소요 시간과 누락 항목을 확인해야 RTO를 지킬 수 있습니다.
홈페이지 백업 주기는 ‘몇 시간마다’라는 숫자부터 정하면 안 됩니다. 주문·예약·문의처럼 장애 시 잃어도 되는 데이터의 범위와, 서비스가 멈춰도 버틸 수 있는 시간을 먼저 정하세요. 이 두 기준을 각각 복구 시점 목표(RPO)와 복구 시간 목표(RTO)라고 부릅니다. 사업 기준이 정해지면 백업 주기, 보관 위치, 복구 절차를 훨씬 현실적으로 결정할 수 있습니다.[2]
백업 주기는 '하루 한 번'보다 손실 허용량으로 정합니다
RPO(Recovery Point Objective)는 사고가 났을 때 어느 시점의 데이터까지 되돌릴 수 있어야 하는지를 뜻합니다. 쉽게 말해 ‘최대 몇 시간치 데이터를 잃어도 사업이 버틸 수 있는가’입니다. RTO(Recovery Time Objective)는 서비스 중단 후 복구까지 허용할 수 있는 최대 시간입니다.[2]
가령 하루에 문의가 한두 건 들어오는 소개형 홈페이지와, 결제가 계속 발생하는 쇼핑몰은 같은 백업 주기를 쓸 이유가 없습니다. 아래는 의사결정을 돕기 위한 예시이며 모든 사업에 그대로 적용하는 표준값은 아닙니다.
| 운영 상황 | 먼저 물을 질문 | 백업 설계 방향의 예시 |
|---|---|---|
| 회사 소개와 정적 콘텐츠 중심 | 최근 수정본을 다시 올릴 수 있는가 | 배포본과 설정을 별도로 보관하고 변경 때마다 백업 |
| 상담·예약 폼 운영 | 누락된 신청을 다른 기록으로 확인할 수 있는가 | 데이터가 쌓이는 간격보다 짧게 백업하고 외부 알림 기록도 보존 |
| 주문·회원 데이터 운영 | 어느 정도의 거래 손실부터 재처리가 어려운가 | 더 짧은 RPO와 복구 순서가 적힌 절차 필요 |
| 캠페인 기간의 집중 유입 | 특정 기간에 중단 비용이 커지는가 | 행사 기간에만 기준을 강화하고 종료 후 원래 정책으로 복귀 |
AWS의 복구 지침도 업무별 사업 영향에 따라 RPO와 RTO를 정하고, 지나치게 엄격한 목표가 불필요한 비용과 복잡성을 만들 수 있다고 설명합니다.[2] ‘최대한 자주’보다 ‘왜 이 주기여야 하는가’를 문서로 남기는 편이 낫습니다.
파일만 복사하면 홈페이지 전체가 돌아오지 않을 수 있습니다
홈페이지는 화면 파일 하나로만 구성되지 않습니다. 복구 대상부터 빠짐없이 적어야 합니다. 미국 사이버보안 및 인프라 보안국(CISA)은 중소기업이 웹사이트와 운영 데이터베이스뿐 아니라 설정 파일, 고객 기록, 이메일과 주요 커뮤니케이션도 백업 대상으로 확인하라고 안내합니다.[1]
확인할 항목은 다음과 같습니다.
- 소스 코드와 실제 배포 버전
- 상품, 게시물, 주문, 예약, 문의가 저장되는 데이터베이스
- 업로드 이미지와 첨부파일
- 도메인·DNS 설정을 다시 구성할 수 있는 기록
- 서버와 애플리케이션 설정
- 외부 서비스 연동 목록과 재연결 절차
- 백업을 복구할 담당자와 비상 연락 순서
비밀키나 비밀번호를 평문 문서에 모아 두라는 뜻은 아닙니다. 필요한 비밀값의 종류와 안전한 보관 위치, 접근 권한을 확인할 사람을 복구 문서에 적어 두면 됩니다.
한곳에만 둔 백업은 원본과 함께 사라질 수 있습니다
CISA는 중요한 파일을 원본 포함 여러 사본으로 유지하고, 서로 다른 저장 매체를 사용하며, 사업장 밖에도 사본을 두는 3-2-1 원칙을 안내합니다. 백업에는 암호화와 오프라인 사본 같은 보호 조치도 적용하라고 권고합니다.[1]
같은 서버 안의 다른 폴더에 복사한 파일은 서버 전체가 고장 나거나 침해되면 함께 잃을 수 있습니다. 운영 서버와 분리된 위치가 있어야 합니다.
실무에서는 운영 서버의 자동 스냅샷만 보고 안심하기 쉽습니다. 유지보수 업체나 개발팀에 ‘백업이 있나요?’라고 묻는 대신 아래처럼 구체적으로 확인하세요.
- 원본과 백업이 물리적·논리적으로 분리되어 있습니까?
- 데이터베이스, 업로드 파일, 설정을 각각 복원할 수 있습니까?
- 백업 접근 권한은 운영 계정과 분리되어 있습니까?
- 보관 기간이 RPO와 사고 발견 시점을 감당합니까?
- 최근 복구 테스트 날짜와 결과가 기록되어 있습니까?
복구 테스트를 해야 백업인지 알 수 있습니다
백업 작업이 ‘성공’으로 표시됐다는 사실과 실제 복구 가능 여부는 다릅니다. CISA는 정기적인 복구 시험으로 백업 무결성과 절차를 확인하고, 전체 및 일부 데이터를 빠르게 복원할 수 있는지 점검하라고 권고합니다.[1] AWS도 장애 유형, 의존 서비스, 시기별 사업 영향을 고려해 복구 목표를 조정하고 담당 부서와 기술팀이 함께 검토하도록 안내합니다.[2]
복구 테스트는 다음 순서로 작게 시작할 수 있습니다.
- 운영과 분리된 시험 환경을 준비합니다.
- 임의의 백업 시점을 골라 데이터베이스와 파일을 복원합니다.
- 로그인, 문의 접수, 주문 조회처럼 사업에 필요한 흐름을 직접 실행합니다.
- 소요 시간과 빠진 데이터, 수동 작업을 기록합니다.
- 실제 결과가 RPO와 RTO를 넘었다면 주기나 절차를 고칩니다.
운영 사이트 위에 덮어쓰는 방식으로 시험하면 새 장애를 만들 수 있습니다. 첫 복구 훈련은 반드시 격리된 환경에서 진행하고, 결과를 담당자가 읽을 수 있는 짧은 문서로 남기세요.
유지보수 계약에는 백업보다 복구 책임을 적으세요
계약서에 ‘정기 백업 제공’만 있으면 사고 때 필요한 답이 남지 않습니다. 무엇을, 얼마나 자주, 어디에, 얼마 동안 보관하는지와 누가 복구를 시작할 수 있는지를 명시해야 합니다.
계약 또는 운영 문서에 넣을 최소 항목은 아래와 같습니다.
- 대상: 코드, 데이터베이스, 업로드, 설정 가운데 포함되는 범위
- 목표: 업무별 RPO와 RTO
- 보관: 저장 위치, 보존 기간, 삭제 정책
- 보호: 암호화, 접근 권한, 운영 계정과의 분리
- 시험: 복구 테스트 주기, 성공 기준, 결과 공유 방식
- 사고 대응: 요청 채널, 담당자, 우선 복구 기능
- 종료 시 인계: 백업 파일 형식과 전달 방법
현재 홈페이지의 백업 범위나 유지보수 책임이 불분명하다면 웹사이트 제작·운영 범위를 기준으로 먼저 점검할 수 있습니다. 도구를 바꾸기 전에 사업이 허용할 손실과 중단 시간을 한 문장씩 합의해 두면 견적 비교도 쉬워집니다.
오늘 바로 정할 수 있는 최소 기준
회의를 길게 열 필요는 없습니다. 주문, 예약, 문의, 콘텐츠 가운데 멈추면 가장 곤란한 기능 하나를 고르세요. 그 기능에 대해 ‘마지막 몇 시간치 기록까지 반드시 살려야 하는가’와 ‘몇 시간 안에 다시 열려야 하는가’를 적습니다. 이 답이 첫 RPO와 RTO입니다.
그다음 현재 백업이 그 기준을 충족하는지 복구 시험으로 확인하세요. 충족하지 못하면 백업 빈도만 높이기보다 누락된 대상, 분리 보관, 권한, 복구 순서를 함께 손보는 편이 안전합니다.
자주 묻는 질문
홈페이지는 하루에 한 번만 백업하면 충분한가요?
사이트마다 다릅니다. 하루치 주문이나 예약을 잃어도 복구 가능한지부터 판단해야 합니다. 허용할 수 없는 손실 범위가 짧다면 백업 간격도 그보다 짧아야 하며, 실제 복구 시험으로 목표 충족 여부를 확인해야 합니다.
호스팅 업체의 자동 백업만 믿어도 되나요?
자동 백업의 대상, 저장 위치, 보존 기간, 접근 권한과 복구 방법을 확인해야 합니다. 운영 서버와 같은 장애 범위에만 저장되거나 데이터베이스·업로드 파일이 빠져 있다면 별도 백업이 필요할 수 있습니다.
RPO와 RTO의 차이는 무엇인가요?
RPO는 장애가 발생했을 때 허용할 수 있는 데이터 손실 시간 범위이고, RTO는 서비스가 중단된 뒤 복구까지 허용할 수 있는 시간입니다. 백업 주기는 주로 RPO에, 복구 인력과 절차는 RTO에 직접 연결됩니다.
복구 테스트는 운영 홈페이지에서 해도 되나요?
운영 환경에 바로 덮어쓰면 정상 데이터까지 손상시킬 수 있습니다. 먼저 격리된 시험 환경에 복원하고, 로그인·문의·주문 조회처럼 사업에 필요한 흐름을 실행한 뒤 소요 시간과 누락 항목을 기록하는 방식이 안전합니다.
