백업 성공 메시지는 파일이 저장됐다는 뜻이지 서비스가 복구된다는 뜻은 아닙니다. 데이터 시점, 환경 설정과 복구 순서가 맞지 않으면 백업 파일이 있어도 운영을 재개할 수 없습니다.

복구가 실패하는 대표 원인

데이터베이스와 파일의 백업 시점이 다르거나 필요한 PHP 확장과 환경변수가 누락되는 경우가 많습니다. 백업 저장소가 운영 서버와 같은 장애 영역에 있는 것도 위험합니다.

RPO와 RTO

RPO는 허용 가능한 데이터 손실 시점, RTO는 허용 가능한 서비스 중단 시간을 뜻합니다. 주문이나 문의가 중요한 서비스라면 하루 1회 백업이 목표에 맞는지 계산해야 합니다.

데이터 사본을 3개 이상, 서로 다른 매체 2곳에, 그중 1개는 다른 위치에 보관합니다. 스냅샷 외에 별도 계정과 리전의 암호화된 복사본을 두세요.

테스트 서버에 복원한 뒤 DB 연결, 이미지, 관리자 로그인, 문의 메일, 예약 작업과 외부 API를 순서대로 확인합니다. 실제 소요 시간을 기록해야 현실적인 RTO를 알 수 있습니다.

장애 범위와 마지막 정상 시점을 확인하고 증거를 보존한 뒤 복구 지점을 선택합니다. DNS 전환과 인증서 상태를 확인하고 복구 후 사용자 기능과 로그를 검증합니다.

백업 위치, 암호화 키, 담당자, 연락망, 복원 명령과 검증 항목을 한 문서에 정리합니다. 담당자가 부재해도 다른 사람이 실행할 수 있어야 합니다.

백업 정책은 저장 공간보다 복구 가능성을 중심으로 설계해야 합니다. 정기적인 복원 훈련이 가장 확실한 검증 방법입니다.