작은 서비스에서 백업보다 복구 리허설이 먼저인 이유

문제 정의

백업을 설정했다는 말과 복구할 수 있다는 말은 다릅니다. 많은 서비스가 백업 파일은 만들지만, 실제로 어느 시점까지 되돌릴 수 있는지, 누가 복구할 수 있는지, 복구 중 사용자는 무엇을 보게 되는지 확인하지 않습니다.

장애가 난 뒤 처음 복구 절차를 읽는다면 백업은 아직 운영 장치가 아닙니다.

상황과 배경

작은 서비스는 데이터베이스, 업로드 파일, 환경변수, DNS 설정이 모두 흩어져 있을 수 있습니다. DB만 백업해도 이미지 파일이 빠지거나, 환경변수 복원이 빠지면 서비스는 정상으로 돌아오지 않습니다. 복구는 데이터뿐 아니라 서비스 상태를 되살리는 과정입니다.

장애 대응 순서를 문서화하는 방법은 기능보다 먼저 운영 런북을 만드는 이유와 함께 준비하면 좋습니다.

복구 리허설에서 확인할 것

• 복구 시간: 실제로 몇 분 안에 서비스를 열 수 있는지 측정합니다.
• 복구 지점: 마지막 백업 이후 잃을 수 있는 데이터 범위를 확인합니다.
• 권한: 백업 위치, DB 접속, 서버 접근 권한을 누가 갖는지 확인합니다.
• 검증 경로: 복구 후 홈, 로그인, 글 목록, 관리자 기능을 확인합니다.

실제 적용 방법

운영 DB를 직접 건드리지 말고 별도 환경에서 백업을 복원해 봅니다. 복원한 뒤에는 단순히 DB가 뜨는지만 보지 말고 애플리케이션이 실제 데이터를 읽는지 확인합니다. 업로드 파일, migration 상태, 관리자 계정, API health도 함께 봐야 합니다.

리허설 결과는 숫자로 남겨야 합니다. 복구 시작부터 첫 정상 응답까지 걸린 시간, 수동으로 입력한 명령, 막힌 권한, 누락된 파일을 기록하면 다음 리허설의 목표가 분명해집니다.

DB 변경을 동반한 배포 전에는 DB 마이그레이션 체크리스트를 같이 확인하면 복구 리허설의 범위가 더 분명해집니다.

운영 체크리스트

• 백업 파일 생성 시간과 보관 위치를 문서화합니다.
• 월 1회 이상 별도 환경에서 복구를 실행해 봅니다.
• 복구 후 확인할 공개 URL과 관리자 기능을 정합니다.
• 복구 중 사용자 안내 문구와 임시 점검 화면을 준비합니다.
• 복구 실패 시 다음 의사결정자를 명확히 둡니다.

결론

백업은 파일이고 복구 리허설은 능력입니다. 최소 관측성과 복구 리허설을 함께 갖추면 작은 서비스도 장애 상황에서 훨씬 침착하게 움직일 수 있습니다.