웹사이트 백업은 무엇을 복구해야 할까요?

백업 작업이 성공적으로 끝나도 복구를 시험해 보지 않았을 수 있습니다. 성공 보고서만으로는 백업본에서 업무에 필요한 웹사이트 구성 요소를 되살릴 수 있는지 알 수 없습니다. 홈페이지를 복구했다고 해도 직원이 로그인할 수 있는지, 고객 기록을 찾을 수 있는지, 업로드한 문서를 열 수 있는지는 알 수 없습니다.

실제 업무부터 생각해 보세요. 웹사이트를 잃은 뒤 무엇을 해야 하나요? 그 업무를 하려면 어떤 요소를 복구해야 하는지 서비스 제공업체에 물어보세요.

예약과 첨부 문서는 함께 복구해야 합니다

예약은 데이터베이스에 저장하고 고객 문서는 업로드 파일로 보관하는 예약 웹사이트를 떠올려 보세요. 가상의 사례지만 상황은 쉽게 상상할 수 있습니다. 예약은 복구됐는데 첨부 파일을 눌러 보니 문서가 없습니다.

예약 정보는 찾았지만, 문서가 필요한 업무는 여전히 할 수 없습니다.

일반적인 WordPress 웹사이트의 경우, WordPress 백업 안내는 데이터베이스와 파일이 모두 중요하며 일관된 한 세트로 보관해야 한다고 설명합니다. 다른 웹사이트는 구성이 다를 수 있습니다. 폴더 하나만 백업하면 모두 포함된다고 여기지 말고 기록과 업로드 파일이 실제로 어디에 저장되는지 확인하세요.

웹사이트 소프트웨어와 설정, 복구해서 사용하는 데 필요한 접근 권한도 중요합니다. 연결된 서비스도 마찬가지입니다. 호주 신호정보국의 시스템 관리 지침은 데이터, 애플리케이션, 설정을 같은 시점으로 복구하고 사전에 의존 항목을 파악하도록 안내합니다. 사업자라면 각 요소가 함께 작동할지, 복구에 필요한 접근 권한은 누가 갖고 있는지 확인하면 됩니다.

최근 업무가 얼마나 빠질 수 있을까요?

복구한 사본에는 웹사이트의 과거 한 시점 상태가 담겨 있습니다. 그 이후에 등록한 예약은 복구가 계획대로 이뤄져도 빠져 있을 수 있습니다.

어느 시점까지 복구할 수 있는지, 필요한 때 복구 정보가 얼마나 오래된 상태일지 서비스 제공업체에 물어보세요. 빠진 업무가 어떤 영향을 줄지도 생각해 보세요. 직원이 다른 기록으로 다시 만들 수 있나요? 고객에게 연락해야 하나요? 허용할 수 있는 기준은 웹사이트의 역할에 따라 달라집니다.

업무를 다시 시작하기까지 걸리는 시간도 있습니다. 데이터를 복사하는 것만으로 끝나지 않습니다. 다른 요소를 다른 요소도 복구한 뒤 중요한 업무를 실제로 처리할 수 있는지 확인해야 합니다. AWS 복구 테스트 지침은 별도로 복구를 시험하고, 복구한 데이터에 접근해 사용할 수 있는지 확인하며, 사업의 필요에 비춰 복구한 정보가 얼마나 오래됐는지, 복구와 검증에 얼마나 걸리는지 측정하도록 권합니다.

테스트에서 각 단계에 얼마나 걸렸는지 물어보세요. 구체적으로 논의할 기준이 생깁니다. 다만 문제를 찾고 대응을 결정하는 시간까지 포함한 향후 전체 사고의 복구 시간을 보장하지는 않습니다.

결제는 이미 처리됐을 수 있습니다

예약 사례로 돌아가 보겠습니다. 고객이 외부 결제 서비스로 예약금을 냈다고 가정해 보세요. 이전 웹사이트 백업본을 복구해도 결제가 취소되지는 않으며, 웹사이트 기록과 결제 서비스의 기록이 일치한다는 뜻도 아닙니다.

예약 정보 자체가 외부 예약 서비스에 있다면 웹사이트 백업에는 포함되지 않을 수 있습니다. 직원이 기준으로 삼아야 할 기록을 어느 시스템이 보관하는지, 해당 서비스에서 무엇을 복구할 수 있는지, 누가 기록을 대조할지 확인하세요. 웹사이트를 복구해도 연결된 모든 항목을 과거로 되돌릴 수는 없습니다.

안전한 복구 테스트를 요청하세요

다음으로 할 일은 권한이 있는 담당자가 격리된 환경에서 계획에 따라 복구하는 것입니다. 누가 무엇을 확인할지 미리 정하세요. 복구본은 개인정보와 사업 정보를 보호하고 외부에 공개되지 않도록 하며 운영 중인 기록을 건드리지 않아야 합니다.

실제 이메일 전송, 결제, 다른 서비스에 대한 자동 요청, 실제 예약 생성도 차단해야 합니다. 사용할 수 있다면 관리되는 테스트 계정과 테스트 연결을 활용할 수 있습니다. 어떤 서비스를 안전하게 테스트할 수 없다면 그 제한을 기록하고 해당 서비스의 역할을 별도로 확인하세요.

이 가상의 사례에서는 서비스 제공업체가 일관된 백업본을 복구하고, 제한된 접근 권한으로 로그인해 선택한 예약과 첨부 파일을 연 다음 복구 시점에 있어야 할 내용과 대조합니다. 홈페이지 스크린샷만 보는 것보다 훨씬 유용합니다.

이런 확인이 필요한 이유를 보여 주는 과거 사례로 GitLab의 2017년 1월 데이터베이스 장애 보고서가 있습니다. 당시 예상했던 데이터베이스 백업을 사용할 수 없었고 장애 알림 이메일도 반송돼 다른 스냅샷으로 복구했습니다. 영향을 받은 것은 GitLab.com의 데이터베이스 정보였으며 저장소 데이터와 GitLab을 직접 운영하는 고객은 영향을 받지 않았습니다. 이 사례는 백업 계획이 있다는 것과 실제로 쓸 수 있는 복구 방법이 있다는 것 사이에 차이가 생길 수 있음을 보여 줍니다.

결과를 보고 필요한 변경을 결정하세요

무엇을 어느 시점에서 복구했는지, 어떤 업무를 확인했고 결과가 어땠는지 간단한 기록을 요청하세요. 복구한 정보가 얼마나 오래됐는지, 복구와 확인에 걸린 시간, 필요한 접근 권한과 연결 서비스, 실패했거나 아직 시험하지 않은 항목도 기록해야 합니다.

예약 확인에 성공했다면 해당 테스트 조건에서 그 업무가 가능했다는 뜻입니다. 모든 기록이 온전하다거나 모든 기능이 작동한다거나 앞으로 복구할 때도 같은 시간이 걸린다는 증거는 아닙니다. 격리된 백업본만으로 복구한 웹사이트가 안전하거나 공격에서 벗어났다고 판단할 수도 없습니다.

그 결과를 사업에 필요한 조건과 비교해 보세요. 합의한 서비스 범위가 충분하다고 판단할 수도 있습니다. 업로드 파일이 없거나 계정에 접근할 수 없는 구체적인 공백을 발견할 수도 있습니다. 중요한 업무가 가능한지 확인되지 않아 추가 테스트가 필요할 수도 있습니다.

LINK-V와 웹사이트 유지보수를 논의한다면 복구 후 직원과 고객이 해야 할 업무를 알려 주세요. 웹사이트에 맞춰 유지보수 범위와 복구 테스트 여부를 정할 수 있습니다.