데이터백업 회사 고를 때 복구부터 확인하는 방법

얼마 전 서버를 옮기던 운영자가 백업은 매일 성공했다고 했는데, 막상 새 서버에서는 사이트가 뜨지 않았다. 파일은 있었지만 데이터베이스 덤프가 오래됐고, 복구에 필요한 암호화 키도 이전 서버에만 남아 있었다. 운영하면서 이런 일을 몇 번 겪고 나니 데이터백업 회사를 볼 때 저장 용량보다 먼저 묻게 되는 게 있다. 장애가 나면 어느 시점으로, 몇 시간 안에 되돌릴 수 있느냐는 것이다.

허용할 데이터 손실과 중단 시간을 먼저 적는다

업체에 문의하기 전에 두 숫자를 정해야 한다. 복구 시점 목표인 RPO는 장애가 났을 때 잃어도 되는 데이터의 시간이다. 복구 시간 목표인 RTO는 서비스를 다시 열 때까지 허용할 시간이다. AWS의 재해 복구 안내도 이 두 값을 복구 전략의 출발점으로 둔다.

하루에 글 한두 편 올리는 블로그라면 전날 밤 백업으로 돌아가도 직접 다시 올릴 수 있다. 이 경우 RPO 24시간, RTO 하루 정도를 목표로 잡을 수 있다. 반면 주문이 계속 들어오는 쇼핑몰은 하루치 주문 손실을 받아들이기 어렵다. 백업 주기를 짧게 하고 데이터베이스의 변경 기록까지 보관해야 할 수 있다. 필요한 수준이 다르니 같은 요금제를 놓고 싸다, 비싸다를 말하기도 어렵다.

여기서 RTO는 업체의 파일 전달 시간만 뜻하지 않는다. 새 서버 준비, 데이터베이스 복원, 설정 확인, 접속 전환까지 포함해 사이트가 실제로 열리는 시간이다. 업체가 ‘즉시 복구’를 말하면 어떤 작업이 포함된 시간인지 확인해야 한다.

백업 범위와 삭제 방어를 확인한다

웹사이트 백업은 화면에 보이는 파일만 복사해서 끝나지 않는다. 운영 형태에 따라 데이터베이스, 업로드 파일, 환경 설정, 인증서, 예약 작업 설정이 필요하다. VPS라면 서버 이미지 하나에 기대기보다 애플리케이션 파일과 데이터베이스를 따로 복구할 수 있는지도 본다. 이미지가 통째로 손상되거나 다른 환경에서 부팅되지 않을 때 선택지가 생긴다.

특히 데이터베이스는 복사 시점의 일관성이 중요하다. 쓰기가 진행되는 중에 파일만 가져가면 백업 작업은 성공으로 표시돼도 복원 후 데이터가 맞지 않을 수 있다. 업체에 데이터베이스를 어떤 방식으로 백업하는지, 복원 시 어느 시점의 거래까지 보장하는지 물어볼 만하다.

• 백업 대상: 파일, 데이터베이스, 설정 중 무엇이 포함되는가
• 보관 기간: 어제 버전뿐 아니라 며칠 전 버전도 꺼낼 수 있는가
• 접근 권한: 운영 서버 계정이 탈취돼도 백업을 지우기 어려운가
• 반출 방법: 계약을 끝낼 때 데이터를 일반적인 형식으로 받을 수 있는가

운영 서버와 같은 계정으로 백업까지 모두 삭제할 수 있다면 랜섬웨어나 계정 탈취에 취약하다. CISA는 중요한 데이터의 오프라인·암호화 백업과 정기적인 복구 시험을 권고한다. 소규모 사이트라도 별도 계정이나 삭제 제한이 있는 저장소에 한 벌을 두면 사고 범위를 줄일 수 있다. 동기화 폴더 하나만 믿는 방식은 원본에서 잘못 지운 파일까지 함께 사라질 수 있어 주의가 필요하다.

월 요금은 저장량과 복구 비용까지 계산한다

데이터백업 회사의 요금표에서 ‘월 저장 공간’만 비교하면 실제 청구액을 놓치기 쉽다. 최초 데이터량, 하루 변경량, 보관 기간, 복구할 때 내려받는 양을 함께 봐야 한다. 예를 들어 최초 백업이 200GB이고 매일 20GB씩 변경되며 30일치를 보관한다면, 중복 제거와 압축을 제외한 단순 계산으로는 200GB에 29일치 변경분 580GB를 더한 780GB가 된다. 실제 사용량은 백업 방식에 따라 달라지므로 이 숫자로 견적 구조를 확인하면 된다.

복구 때의 비용도 따로 묻는다. 백업 200GB를 다른 서버로 내려받을 때 전송료가 붙는지, 긴급 복원을 요청하면 작업비가 있는지, 보관 기간을 늘릴 때 단가가 어떻게 바뀌는지 확인한다. 반대로 백업량이 작고 하루치 손실을 감당할 수 있는 개인 블로그라면 호스팅에 포함된 백업과 별도 저가 저장 공간으로도 충분할 수 있다. 처음부터 비싼 상시 대기 서버를 둘 이유는 없다.

같은 가격이라면 복구 지원의 범위를 비교한다. ‘백업 파일 제공’과 ‘새 서버에서 사이트가 열릴 때까지 복원’은 다른 서비스다. 장애 접수 시간, 담당자 응답 시간, 복원 작업의 책임 구간을 계약 문구로 확인해야 한다.

계약 전에 작은 복구를 한 번 실행한다

백업 성공 알림은 복구 가능성을 증명하지 않는다. 미국 국립표준기술연구소의 저장 인프라 지침도 주기적인 복구 시험으로 목표 시간을 충족하는지 확인하도록 한다. 내가 업체를 비교할 때 가장 신뢰하는 자료도 기능 목록보다 시험 복구 기록이다.

가능하면 운영 서버와 분리된 임시 환경에 최근 백업을 복원한다. 화면이 뜨는지만 보지 말고 관리자 로그인, 게시물 조회, 이미지 표시, 새 글 저장까지 확인한다. 쇼핑몰이라면 주문과 결제 기록의 건수도 원본과 대조한다. 시작 시각과 완료 시각을 적어 두면 약속한 RTO가 현실적인지 알 수 있다.

시험 중에는 백업 파일을 어디서 찾았는지, 암호화 키는 누가 보관하는지, 담당자가 없을 때도 절차를 따라 할 수 있는지 기록한다. 이전 작업을 앞뒀다면 기존 서버를 바로 지우지 말고 새 환경의 데이터와 기능을 확인한 뒤 접속을 전환하는 편이 안전하다. 백업 계약의 값어치는 저장해 둔 용량보다 그날 실제로 되살릴 수 있는 사이트에 있다.