백업보다 중요한 것은 실제로 복구해 본 적이 있는가다

사이트나 서비스를 운영하다 보면 백업은 하고 있다는 말에 안심하기 쉽다. 하지만 사고가 나면 금방 알게 된다. 진짜 중요한 것은 백업 파일의 존재가 아니라, 그 파일로 서비스와 데이터를 실제로 되살릴 수 있는가다.
미국 사이버보안국(CISA)도 백업을 권하면서 동시에 복구 절차를 정기적으로 시험하라고 강조한다. 이유는 단순하다. 복구를 한 번도 해 보지 않은 백업은, 필요할 때 쓸 수 없는 가능성을 항상 안고 있기 때문이다.
백업은 저장이고 복구는 운영이다
백업은 파일을 남기는 일이다. 복구는 그 파일로 시스템을 다시 서비스 가능한 상태로 만드는 일이다. 둘은 비슷해 보여도 완전히 다르다. 백업에는 성공했지만 복구에 실패하는 이유는 대개 다음과 같다.
- 백업 파일이 손상되어 있음
- 어떤 순서로 되살려야 하는지 문서가 없음
- 데이터는 있지만 애플리케이션 버전이나 설정이 맞지 않음
- 복구 시간이 너무 오래 걸려 실제 운영 기준을 못 맞춤
즉 백업이 있다와 복구할 수 있다 사이에는 생각보다 큰 간격이 있다.
복구 연습이 필요한 이유는 위기 때 처음 배우면 너무 늦기 때문이다
랜섬웨어나 실수 삭제, 호스팅 장애가 생기면 사람은 급해진다. 이때 처음으로 복구 매뉴얼을 찾기 시작하면 거의 항상 놓치는 것이 생긴다. 그래서 백업 전략에는 평소의 연습이 포함되어야 한다.
CISA가 권하는 방향도 비슷하다.
- 오프라인 또는 격리된 백업 유지
- 정기적 백업
- 복구 테스트
- 최소 어느 시점까지 되돌릴 수 있는지 확인
실제로는 얼마나 자주 저장하나만큼 얼마나 빨리 되살릴 수 있나가 중요하다.
운영자에게 필요한 것은 3-2-1 원칙과 복구 시나리오다
가장 널리 알려진 기본 원칙은 3-2-1이다. 원본을 포함해 최소 세 개의 사본을 두고, 두 가지 다른 매체에 보관하며, 한 개는 외부에 둔다는 뜻이다. 하지만 이 원칙도 복구 시나리오가 없으면 반쪽짜리다.
운영자는 최소한 다음을 문서로 갖고 있는 편이 좋다.
- 무엇을 백업하는가: DB, 업로드 파일, 환경 설정, 코드, 인증서
- 얼마나 자주 백업하는가
- 어디에 저장하는가
- 누가 복구 권한을 갖는가
- 장애 시 어떤 순서로 되살리는가
- 복구 후 무엇을 검증하는가
이 정도가 정리돼 있어야 백업이 실제 운영 자산이 된다.
마치며
웹사이트 운영에서 백업은 보험과 비슷하다. 가입했다는 사실만으로 충분하지 않고, 필요할 때 실제로 작동해야 의미가 있다. 그래서 운영자는 백업을 하고 있는가보다 최근에 복구를 시험해 봤는가를 더 자주 물어야 한다.
안전은 파일을 쌓는 데서 끝나지 않는다. 그 파일로 서비스를 다시 살릴 수 있을 때 비로소 안전이라고 부를 수 있다.