← 블로그 목록

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

백업이 있다는 사실과 복구할 수 있다는 사실 사이에는 생각보다 큰 간격이 있다. 파일이 손상됐거나 절차가 없거나 시간이 너무 오래 걸리면 위기 때 백업은 무용지물이 된다. 3-2-1 원칙과 함께 어떤 순서로 무엇을 되살릴지, 누가 검증할지 시나리오를 평소에 점검해야 백업이 진짜 운영 자산이 된다.

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

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

사이트나 서비스를 운영하다 보면 백업은 하고 있다는 말에 안심하기 쉽다. 하지만 사고가 나면 금방 알게 된다. 진짜 중요한 것은 백업 파일의 존재가 아니라, 그 파일로 서비스와 데이터를 실제로 되살릴 수 있는가다.

미국 사이버보안국(CISA)도 백업을 권하면서 동시에 복구 절차를 정기적으로 시험하라고 강조한다. 이유는 단순하다. 복구를 한 번도 해 보지 않은 백업은, 필요할 때 쓸 수 없는 가능성을 항상 안고 있기 때문이다.

백업은 저장이고 복구는 운영이다

백업은 파일을 남기는 일이다. 복구는 그 파일로 시스템을 다시 서비스 가능한 상태로 만드는 일이다. 둘은 비슷해 보여도 완전히 다르다. 백업에는 성공했지만 복구에 실패하는 이유는 대개 다음과 같다.

백업이 있다복구할 수 있다 사이에는 생각보다 큰 간격이 있다.

복구 연습이 필요한 이유는 위기 때 처음 배우면 너무 늦기 때문이다

랜섬웨어나 실수 삭제, 호스팅 장애가 생기면 사람은 급해진다. 이때 처음으로 복구 매뉴얼을 찾기 시작하면 거의 항상 놓치는 것이 생긴다. 그래서 백업 전략에는 평소의 연습이 포함되어야 한다.

CISA가 권하는 방향도 비슷하다.

실제로는 얼마나 자주 저장하나만큼 얼마나 빨리 되살릴 수 있나가 중요하다.

운영자에게 필요한 것은 3-2-1 원칙과 복구 시나리오다

가장 널리 알려진 기본 원칙은 3-2-1이다. 원본을 포함해 최소 세 개의 사본을 두고, 두 가지 다른 매체에 보관하며, 한 개는 외부에 둔다는 뜻이다. 하지만 이 원칙도 복구 시나리오가 없으면 반쪽짜리다.

운영자는 최소한 다음을 문서로 갖고 있는 편이 좋다.

이 정도가 정리돼 있어야 백업이 실제 운영 자산이 된다.

마치며

웹사이트 운영에서 백업은 보험과 비슷하다. 가입했다는 사실만으로 충분하지 않고, 필요할 때 실제로 작동해야 의미가 있다. 그래서 운영자는 백업을 하고 있는가보다 최근에 복구를 시험해 봤는가를 더 자주 물어야 한다.

안전은 파일을 쌓는 데서 끝나지 않는다. 그 파일로 서비스를 다시 살릴 수 있을 때 비로소 안전이라고 부를 수 있다.

참고 자료

← 목록으로
Related

함께 읽으면 좋은 글

게임 개발반복 개발플레이테스트
게임 개발의 품질은 한 번의 완성보다 테스트와 수정이 반복되는 루프에서 나온다

게임의 품질은 처음부터 잘 짠 설계가 아니라 빨리 만들고 시험하고 고치는 루프의 건강함에서 나온다. 테스트는 버그 잡기보다 이 선택이 맞는가를 확인하는 질문 검증에 가깝고, 좋은 팀은 가설과 빌드, 플레이테스트, 수정, 재검증을 짧게 반복한다. 결국 좋은 게임은 정답을 처음부터 아는 팀이 아니라 더 빨리 배우는 팀이 만든다.

소프트웨어 개발생산성회의 문화
개발자와 매니저의 시간표가 충돌하는 이유는 일의 단위가 다르기 때문이다

개발자에게 30분 회의가 하루를 깨뜨리는 이유는 예민함이 아니라 작업 단위의 차이다. 폴 그레이엄이 정리한 메이커의 시간표는 긴 몰입을, 매니저의 시간표는 짧은 조정 블록을 전제로 한다. 회의를 없애는 대신 두 시간표를 구분하고 회복 시간까지 함께 설계할 때 팀 생산성이 달라진다.

커뮤니티 디자인온라인 플랫폼사용자 경험
커뮤니티 기능 아이디어보다 먼저 필요한 것은 신뢰, 검색, 수정 권한의 설계다

좋은 커뮤니티는 기능의 화려함이 아니라 운영 구조에서 갈린다. 누가 무엇을 할 수 있는가에 대한 신뢰 기반 권한, 정보를 다시 찾게 만드는 검색과 태그, 수정 이력과 책임 추적, 모더레이션 도구가 먼저 설계돼야 한다. 좋은 정보가 남고 나쁜 상황이 정리되는 공간은 기능 목록이 아니라 뼈대에서 시작된다.