백업은 다들 돌리고 있습니다. 문제는 정작 필요할 때 열어보니 복구가 안 되는 경우예요. 며칠째 백업이 실패하고 있었거나, 파일은 있는데 DB가 빠져 있거나, 압축은 풀리는데 데이터가 깨져 있거나. 사고가 난 뒤에 알게 되면 손쓸 방법이 없습니다.
스냅샷과 백업은 다릅니다
가장 흔한 오해입니다. 스냅샷은 같은 스토리지 안에 특정 시점을 표시해두는 것이에요. 실수로 파일을 지웠거나 업데이트가 잘못됐을 때 몇 분 만에 되돌릴 수 있어 아주 유용합니다.
하지만 스토리지 자체에 장애가 나면 원본과 스냅샷이 함께 사라집니다. 같은 곳에 있으니까요. 랜섬웨어도 마찬가지예요. 서버 권한을 잡은 공격자는 스냅샷부터 지웁니다. 그래서 다른 저장소에 따로 보관하는 백업이 반드시 별도로 있어야 합니다. 스냅샷은 빠른 되돌리기용, 백업은 최후의 보루로 역할이 다릅니다.
얼마나 잃어도 되는지부터 정하세요
백업 주기를 정할 때 기준이 되는 질문 두 가지가 있습니다. 하나는 데이터를 얼마나 잃어도 감당할 수 있는가이고, 다른 하나는 복구에 몇 시간까지 쓸 수 있는가입니다.
하루 한 번 백업한다면 최악의 경우 하루치가 날아갑니다. 쇼핑몰이라면 하루치 주문이 사라지는 셈이라 감당하기 어렵죠. 이런 경우 DB만이라도 훨씬 자주 백업하거나 실시간 복제를 함께 씁니다. 반대로 자료실 성격의 사이트라면 하루 한 번으로 충분할 수 있어요. 모든 데이터에 같은 기준을 적용할 필요는 없습니다.
보관 기간도 중요합니다. 최근 것만 며칠 갖고 있으면, 문제가 생긴 지 한참 뒤에 발견했을 때 이미 정상 시점 백업이 없습니다. 일별과 주별, 월별을 섞어 보관하면 이런 상황에 대응할 수 있어요.
복구 연습을 해두세요
이 글에서 딱 하나만 가져가신다면 이겁니다. 복구를 한 번도 해보지 않은 백업은 있다고 말할 수 없습니다.
실제로 해보면 예상 못한 것들이 나옵니다. 백업에 설정 파일이 빠져 있거나, DB 덤프는 있는데 사용자 권한 정보가 없거나, 복구에 생각보다 오래 걸려서 목표 시간을 못 맞추거나. 이런 건 미리 해봐야만 알 수 있어요.
분기에 한 번이라도 좋으니 테스트 서버에 복구해보시길 권합니다. 그러면서 복구 절차를 문서로 남겨두세요. 사고는 대개 담당자가 자리에 없을 때 납니다. 그때 다른 사람이 보고 따라 할 수 있는 문서가 있느냐가 복구 시간을 좌우합니다.
백업 실패를 알아채는 장치
백업 스크립트는 조용히 실패합니다. 디스크가 가득 차서, 권한이 바뀌어서, 원격 저장소 인증이 만료돼서. 로그를 매일 들여다보지 않는 이상 몇 달째 실패 중인 걸 모를 수 있어요.
그래서 성공했을 때가 아니라 실패했을 때 알림이 오도록 걸어두는 게 좋습니다. 여기에 백업 파일 크기를 함께 확인하면 더 확실해요. 평소 수 기가바이트이던 파일이 갑자기 몇 킬로바이트로 줄었다면 내용이 비었다는 뜻이니까요.
TIDC는 서버 요금제에 정기 백업 운영을 포함하고 있습니다. 어떤 주기와 보관 정책이 서비스에 맞을지 함께 잡아드리니 편하게 문의해주세요.
