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

14년간 서버를 운영하면서 백업 작업은 성공으로 찍혔는데 사이트는 살리지 못한 경우를 여러 번 봤다. 웹 파일만 남고 데이터베이스가 빠졌거나, 백업 파일은 있는데 내려받는 데 하루가 걸리는 식이었다. 데이터 백업 업체를 고를 때 저장 공간의 크기보다 먼저 확인할 것은 실제로 어디까지, 얼마나 빨리 복구할 수 있느냐다.

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

백업 주기는 사이트의 성격에 따라 달라진다. 하루에 글 한두 개 올라오는 회사 소개 사이트라면 전날 상태로 돌아가도 감당할 수 있다. 반면 주문이 들어오는 쇼핑몰에서 하루치 주문이 사라지면 손실이 크다. 장애 직전부터 얼마나 과거까지의 데이터 손실을 허용할지 정하는 값이 RPO, 서비스를 다시 열 때까지 허용할 시간이 RTO다.

예를 들어 새벽 2시에 하루 한 번 백업한다면 다음 백업 직전에 장애가 날 때 거의 24시간의 변경분을 잃을 수 있다. ‘매일 백업’이라는 문구만 보고 충분하다고 판단하기 어려운 이유다. 주문 데이터의 허용 손실이 1시간이라면 그에 맞는 데이터베이스 백업이나 로그 보관 방식이 필요하다. 이때 비용도 함께 올라간다.

복구 시간도 따져야 한다. 120GB를 초당 10Mb로 내려받으면 전송에만 이론상 약 27시간이 걸린다. 초당 100Mb여도 약 2.7시간이다. 실제로는 전송 지연과 파일 확인, 데이터베이스 재구동 시간이 더해진다. 업체가 ‘즉시 복구’를 말한다면 어느 크기의 데이터를 어떤 회선과 절차로 복구했을 때의 시간인지 물어야 한다.

저장 용량보다 총비용을 계산한다

백업 비용은 원본 데이터 크기만으로 결정되지 않는다. 저장 기간, 변경량, 백업 방식, 복구 때 나가는 데이터 양을 함께 봐야 한다. 원본이 120GB이고 하루 변경분이 4GB이며 30일치를 보관한다고 해보자. 변경분만 효율적으로 쌓인다는 가정에서 첫 사본 120GB에 변경분 약 120GB가 더해져 보관량은 대략 240GB다. 실제 용량은 중복 제거 방식과 파일 변경 패턴에 따라 달라진다.

견적에서는 240GB 보관료만 보지 말고 백업 작업 횟수, 저장소 간 복사, 복구 시 전송료, 장기 보관료까지 확인한다. 일부 서비스는 넣을 때 저렴해도 꺼낼 때 비용이나 대기 시간이 붙는다. 장애 때 전체 파일을 한 번 복구하는 상황을 가정해 월 비용과 별도로 계산해 두면 요금표를 읽기 쉬워진다.

작은 개인 사이트라면 호스팅의 기본 백업과 별도 저장소 한 곳만으로도 요구 수준을 맞출 수 있다. 반대로 같은 서버의 다른 디스크에만 복사해 두면 서버 계정 침해나 장비 장애에 함께 영향을 받을 수 있다. 비싼 요금제가 안전을 보장하는 것은 아니다. 필요한 복구 목표와 보관 구조를 충족하는 가장 단순한 구성이 대개 운영하기도 쉽다.

무엇을 백업하고 누가 지울 수 있는지 확인한다

웹사이트 복구에는 웹 파일과 데이터베이스만 필요한 게 아니다. 사용자가 올린 이미지, 서버 설정, 예약 작업, 도메인 DNS 설정, 인증서 갱신 방법도 확인해야 한다. 환경 변수와 비밀키는 백업 접근 권한을 제한한 별도 경로에 보관하는 편이 낫다. 한 번에 모든 것을 되살릴 수 있다는 광고보다 빠진 항목이 없는 목록이 실무에서는 더 유용하다.

백업 계정이 원본 서버와 같은 관리자 권한을 쓰는지도 본다. 서버가 침해됐을 때 공격자가 백업까지 삭제할 수 있다면 사본을 둔 의미가 줄어든다. 원본 서버에는 백업을 쓰는 데 필요한 최소 권한만 주고, 백업 삭제 권한은 분리하는 구성이 좋다. 삭제 후 일정 기간 되돌릴 수 있는 보관 잠금 기능과 관리자 계정의 다중 인증 여부도 확인할 항목이다.

동기화와 백업도 구분해야 한다. 원본에서 파일을 실수로 지웠을 때 그 삭제가 보관소에 곧바로 반영되면 복구할 이전 시점이 없다. 파일을 여러 시점으로 보관하는지, 특정 날짜의 데이터베이스와 파일을 함께 꺼낼 수 있는지 확인해야 한다. 백업 실패 알림의 수신자가 누구인지도 계약서나 운영 화면에서 분명히 해둔다.

계약 전에 작은 복구를 직접 해본다

업체 비교표에는 저장 공간, 주기, 보관 기간과 함께 복구 시험 결과를 적는 게 좋다. 시험용 환경에 최근 백업을 내려받아 사이트를 띄우고 로그인, 게시물, 첨부 파일, 주문 조회처럼 중요한 동작을 확인한다. 복구 작업 시작부터 서비스 확인까지 걸린 시간을 재면 광고 문구보다 정확한 RTO가 나온다. AWS의 백업 운영 지침에서도 백업 파일의 존재만 확인하는 대신 실제 복구와 데이터 검사를 권한다.

처음 맡길 때는 업체에 복구 요청 접수 방법, 야간 대응 범위, 계정 해지 후 데이터 반출 형식도 물어본다. 특정 업체의 전용 형식으로만 받을 수 있다면 이전이 어려울 수 있다. 반출한 파일을 다른 서버에서 읽을 수 있는지 미리 시험하면 업체를 바꿀 때도 덜 불안하다.

나는 작은 사이트일수록 한 달에 한 번 정도 복구 시험을 일정에 넣는다. 자동 백업 알림은 매일 오지만, 실제로 사이트가 살아나는지는 직접 확인해야 알 수 있다. 데이터 백업 업체의 값어치는 저장한 용량보다 장애가 난 날 되돌릴 수 있는 데이터와 시간에서 드러난다.