되돌려 보지 않은 백업은 아직 백업이 아닙니다
혼자서 프로덕션을 돌리는 개발자를 위한 글입니다. 읽고 나면 지금의 백업이 ‘있음’ 상태인지 ‘되돌림’ 상태인지 판별하는 기준, 그리고 그 증명을 유지하는 주기를 갖게 됩니다. 기준 자체는 두 줄이고 주기는 달력에 한 칸이면 됩니다.
결론부터 말하겠습니다. 백업 파일이 존재한다는 사실, 크기가 정상처럼 보인다는 사실, 목록에 나타난다는 사실은 모두 ‘백업이 있다’는 것만 증명합니다. ‘되돌릴 수 있다’는 말은 실제로 되돌려 본 순간에만 참입니다. 따라서 백업의 유효성은 만드는 작업이 아니라, 사고가 오기 전에 복원을 반복하고 그것을 기록하는 유지의 문제입니다.
목요일 새벽 2시, 결제 데이터베이스가 응답을 멈췄다는 알림이 옵니다. 서버에 접속해 보면 디스크가 죽어 있었고 데이터가 있던 볼륨은 통째로 읽히지 않습니다. 마음은 객체 스토리지에 쌓아 둔 백업으로 향합니다. 그런데 마지막 성공한 파일은 3개월 전 것이었고 그 사이 스크립트는 디스크가 차서 매일 조용히 실패하고 있었습니다. 매일 아침 초록으로 보여준 대시보드가 실제로 확인한 것은 ‘한 번 성공한 파일이 아직 있다’는 사실뿐이었기 때문입니다.
글의 핵심 개념을 형상화했습니다.
초록이 말하지 않는 것
백업 스크립트는 실패를 알리지 않는 방식으로 죽는 경우가 많습니다. 디스크가 차서 쓸 곳이 없어지고 백업 대상 경로가 바뀌어 빈 폴더를 복사하고 자격 증명이 만료되어 로그인을 실패합니다. 이 실패들은 모두 조용합니다. 새벽 4시에 돌아가는 스크립트에는 청중이 없으니까요.
팀이 있으면 백업이 죽어도 누군가의 화면이 빨갛게 변하고 그 빨간 것을 보는 사람이 따로 있습니다. 혼자 시스템이면 대시보드를 봐야 할 사람과 다른 일을 하고 있는 사람이 같은 사람입니다. 그래서 조용한 실패는 이 구조에서는 우연이 아니라 필연입니다. 실패가 쌓이는 동안 아무에게도 알려지지 않고, 다음 사고에서 한꺼번에 터져 나오게 마련입니다.
매일 아침 확인하는 초록은 ‘오늘 백업이 성공했다’는 뜻이 아닙니다. 대개는 ‘마지막 성공한 파일이 여전히 있다’는 뜻입니다. 그것은 과거의 사실입니다. 어제에도, 한 달 전에도, 3개월 전에도 같은 초록을 볼 수 있는 사실입니다. 색은 변하지 않으면서 색 뒤에 있는 시간이 계속 밀려 나가는 상태가 아무도 모르게 이어지는 것입니다.
그래서 ‘백업을 하고 있다’는 상태와 ‘되돌릴 수 있다’는 상태는 다른 두 개의 상태입니다. 파일이 있는가, 크기가 들어 보이는가, 목록이 나오는가. 이 세 가지 확인은 전부 ‘있음’만 증명합니다. ‘되돌림’은 증명하지 않습니다. 이 둘을 같은 서랍에 넣는 순간, 새벽 2시의 식은땀이 시작됩니다. 초록을 증명처럼 읽는 습관이, 3개월 뒤에 사고를 만드는 것입니다.
첫 번째 질문은 단순합니다. 마지막에 백업이 성공한 시각이 언제인가, 그리고 마지막에 복원이 성공한 시각이 언제인가. 두 시각을 나란히 적어 두면, 초록이 말하지 않는 것이 숫자로 드러납니다. 두 시각이 비슷하게 최신이라면 백업은 실제로 작동하고 있고, 백업 시각만 최신이라면 그것은 희망입니다.
백업은 네 가지 얼굴로 죽습니다
파일의 존재를 확인했다 해도, 백업이 무너지는 방식은 네 갈래입니다. 이 네 가지를 구분해야 하는 이유는, 각각이 요구하는 방어책이 다르기 때문입니다. 하나를 막았다고 나머지가 막히는 것은 아닙니다.
첫 번째 얼굴은 사라짐입니다. 스크립트가 조용히 죽거나, 디스크가 차서 쓰지 못하거나, 대상 경로가 바뀌어 빈 폴더의 복사물을 만들고 있습니다. 사라짐은 목록에서 발견할 수 있어야 합니다. 파일이 목록에 없다는 사실 자체가 알림이 되어야지, 복원을 시도하는 날 알게 되는 사실이여서는 안 됩니다.
두 번째 얼굴은 손상입니다. 전원이 나가면서 쓰다 만 파일, 압축 도구가 만든 깨진 아카이브, 디스크의 오래된 오류입니다. 파일은 있는데 열리지 않습니다. 그리고 확인하는 시점은 열려야 하는 바로 그 순간, 즉 사고의 한복판입니다.
세 번째 얼굴은 오래됨입니다. 백업은 멀쩡하고 복원도 잘 됩니다. 하지만 돌아간 시점이 3개월 전이라면, 그 사이 쌓인 데이터는 통째로 날아갑니다. ‘되돌릴 수 있다’는 말이 참이되, 돌아간 시점이 쓸모없다면 거짓과 거의 차이가 없습니다.
네 번째 얼굴은 못 읽음입니다. 파일은 멀쩡한데, 그것을 열 수 있는 도구가 사라집니다. 폐기된 소프트웨어 버전, 더 이상 구할 수 없는 형식, 열쇠를 잃어버린 암호화 아카이브입니다. 백업은 있는데, 그것을 읽을 수 있는 손이 사라진 상태입니다.
| 실패의 얼굴 | 흔한 징후 | 막는 방법 |
|---|---|---|
| 사라짐 | 목록에서 파일이 안 보인다 | 실패 알림 |
| 손상 | 열려야 할 순간에 안 열림 | 무결성 검사 |
| 오래됨 | 날짜가 몇 달 전 | 보관 주기 정책 |
| 못 읽음 | 파일은 있는데 열 도구가 없음 | 형식과 키 관리 |
방어책도 얼굴별로 다릅니다. 사라짐은 알림으로, 손상은 무결성 검사로, 오래됨은 보관 정책으로, 못 읽음은 도구의 지속 가능성과 키 관리로 막습니다. 대시보드가 초록인 것과 복원이 성공한 것은 다른 검증입니다.
복제는 백업이 아닙니다
‘데이터를 지킨다’는 말에는 세 가지 도구가 섞여 있습니다. 복제, 미러, 백업입니다. 셋 다 데이터를 지킬 수 있지만 실패하는 방식이 다릅니다. 이 차이를 모르면 데이터는 지켰는데 잃어버린 일만 생깁니다.
복제와 미러는 원본이 바뀔 때마다 따라가는 실시간 사본입니다. 원본과 같은 운명을 공유합니다. 같은 디스크가 죽으면 둘 다 사라지고 같은 지역에서 장애가 나면 둘 다 멈춥니다.
가장 무서운 경우는 사람의 실수입니다. 잘못된 마이그레이션이나 실수로 지운 테이블은, 따라가는 사본까지 실시간으로 오염시킵니다. 복제가 막는 실패는 하드웨어 장애 같은 가용성 문제입니다. 복제가 막지 못하는 실패는, 원본 자체가 오염되거나 지워지는 경우입니다.
백업은 그 반대입니다. 특정 시점의 데이터를 독립적으로 복사해 두는 것이기 때문에, 원본에 지금 이 순간에 무슨 일이 일어나도 과거의 깨끗한 시점을 유지합니다. 데이터 손실에서 진정으로 구해 주는 것은 백업이고 멈추지 않는 것을 위한 도구는 복제입니다.
그래서 가용성과 손실은 같은 서랍에 넣지 않습니다. 복제로 가용성을 사고 백업으로 손실을 막습니다. 그리고 백업은 원본과 다른 실패 영역에 놓여야 합니다. 같은 호스트, 같은 지역, 같은 계정에 있으면 원본과 함께 죽기 때문입니다. 막고 싶은 실패의 종류를 먼저 정하고 그 다음에 백업의 자리를 정하는 것입니다.
유일한 증거는 성공한 복원입니다
핵심 명제를 다시 쓰면 한 줄입니다. 백업이 동작한다는 증거는 오직 하나, 성공한 복원뿐입니다. 파일을 만들어 두었다는 사실은 ‘있음’을 증명할 뿐입니다. 실제로 되돌려 보았을 때만 ‘되돌림’이 성립합니다.
그렇다면 복원을 언제 연습해야 하는가. 복원 연습은 백업과 같은 주기로, 백업만큼 당연하게 돌아야 합니다. 매일 백업을 만든다면, 매일 한 파일의 샘플 복원으로 무결성을 확인하고 주 1회 표 단위로 복원하고 월 1회 시스템 전체를 다시 세웁니다. 세 단계가 서로 다른 질문입니다. 열릴 수 있는가, 그 구간이 돌아오는가, 시스템이 다시 서는가.
전체 복원이 핵심입니다. 파일을 목록으로 확인하는 것은 있음만 증명할 뿐, 서기름은 증명하지 않습니다. 새 인스턴스를 만들고 백업을 올리고 앱을 그 위에 띄우고 로그인이 되고 핵심 조회가 원본과 같은 값을 반환하고 쓰기가 한 건 정상 저장되는 것을 확인하는 것. 앱이 뜨지 않는다면, 그것은 뜨지 않는 백업입니다.
복원은 항상 스크래치 환경, 즉 버려도 되는 곳에서 합니다. 원본을 덮어쓰는 복원은 실패하면 원래 상태마저 잃습니다. 복원 전용 인스턴스를 필요할 때만 만들고 끝나면 지우는 방식이 가장 싸고, 항상 떠 있는 소형 인스턴스를 하나 두는 방식이 가장 편합니다. 중요한 것은 그 스크래치가 프로덕션과 다른 실패 영역에 있다는 것입니다. 프로덕션이 죽은 날, 스크래치까지 읽히지 못하면 연습은 무의미합니다.
비용은 생각보다 작습니다. 월 1회, 한두 시간의 전체 복원 연습은 작은 시스템이면 몇 천 원의 인스턴스 비용으로 끝나고 [추정], 그 대가로 가장 나쁜 순간이 사라집니다. 손이 떨리고 시간이 부족하고 문서도 기억도 없는 상태에서의 첫 복원은, 연습해 둔 복원보다 몇 배나 더 비쌉니다.
사람이 매번 확인하는 것은 지치므로, 확인의 일부를 기계에게 맡기는 구간이 있습니다. 각 백업 직후, 복원 가능 여부를 스스로 검사하는 옵션으로 무결성을 확인하게 하고 주 1회의 표 복원과 무결성 검사를 스크래치 환경에서 자동으로 돌립니다. 월 1회의 전체 복원은 사람이 직접 하지만, 그 사이까지의 점검은 기계가 합니다. 사람이 남는 부분은 한 달에 한 번의 전체 복원과, 그 결과를 기록하는 일입니다.
연습은 기록이 되어야 증명입니다
복원 연습은 해 본 것만으로는 충분하지 않습니다. 언제, 어떤 시점의 백업으로, 얼마나 걸렸고 무엇을 확인했으며 무엇이 실패했는지 기록으로 남겨 두어야 합니다. 기록이 없으면 다음 달의 연습은 다시 처음부터 시작하는 것입니다.
복원이 성공했다는 말을 쓰기 전에 네 가지를 확인합니다. 무결성, 체크섬이 맞고 조회가 기대한 값을 반환하는가. 시간, 실측한 복원 시간이 RTO 이내인가. 신선도, 복원된 데이터가 RPO가 약속한 시점까지 최신인가. 기능, 복원된 데이터로 서비스가 실제로 동작하는가. 하나라도 빠지면 그것은 성공이 아니라 시도입니다.
RPO와 RTO는 숫자로 미리 세웁니다. RPO는 잃어도 되는 데이터의 양을 시간으로 쓴 것이라, 백업 간격 그대로입니다. 매일 밤 백업이라면 RPO는 최대 24시간입니다. RTO는 사고를 알아차린 뒤 서비스를 다시 세우는 데 걸리는 시간이며, 복원 연습에서 실측하는 값입니다. 온라인으로 예약을 받는 작은 서비스라면, 하루치 예약을 잃을 수 있는지부터 결정해야 합니다. 하루 예약이 10건이라고 하면 [추정], 최악의 경우 하루가 통째로 사라지는 것을 받아들일 수 있는지, 아니면 백업 간격을 줄일 것인지의 문제입니다.
기록이 잡아 주는 것은 아무도 몰랐던 변화입니다. 한 달의 기록을 펴 보면, 월초의 전체 복원은 40분 만에 통과했고 [추정], 같은 달 마지막 주의 표 복원이 실패한 것이 보입니다. 이유는 백업 파일의 경로가 바뀌어 찾을 수 없었기 때문입니다. 이 변화는 대시보드 어디에도 빨간 것으로 나타나지 않았습니다. 복원 연습에서만 드러났습니다. 사고 전에 실패하는 것은, 사고 중에 실패하는 것보다 훨씬 쌉니다.
복원 연습에서 실패를 만나는 것은 나쁜 일이 아닙니다. 실패는 네 갈래로 분류됩니다. 도구, 복원 도구가 없거나 버전이 다른 경우. 경로, 백업 파일이 옮겨져 찾을 수 없는 경우. 데이터, 파일이 손상되어 열리지 않는 경우. 시간, 복원이 목표보다 너무 늦은 경우. 각 갈래의 대응을 런북에 미리 써 두면, 사고 당일 처음부터 생각하는 일이 사라집니다. 백업 스크립트는 매일 돌아가며 스스로의 오류를 드러내지만, 런북은 쓰지 않으면 아무도 그 오류를 모릅니다. 그래서 복원 런북은 백업 스크립트만큼, 어쩌면 그보다 더 중요합니다.
매달 10분만 내서 다섯 질문에 답해 보십시오. 마지막 백업 성공 시점은 언제인가. 마지막 복원 성공 시점은 언제인가. 지금 복원하면 어느 시점의 데이터를 되찾을 수 있는가. 그 백업을 열 수 있는 도구가 지금 내 손에 있는가. 암호화되어 있다면 그 열쇠를 지금 꺼낼 수 있는가. 하나라도 ‘잘 모르겠다’가 나오면, 아직 희망인 것입니다.
오늘 밤, 두 줄이면 충분합니다
시스템 전체를 오늘 밤에 다시 설계할 필요는 없습니다. 두 줄이면 됩니다. 가장 마지막에 백업이 성공한 시각을, 가장 마지막에 복원이 성공한 시각을, 각각 적어 보십시오.
복원의 시각이 빈 칸이라면, 그 백업은 아직 희망입니다. 달력에 월 1회 전체 복원의 다음 일자를 적어 두십시오. 그리고 복원 절차의 첫 세 줄, 새 인스턴스를 만들고 백업을 옮겨 복원 명령을 실행하는 줄을 문서 한 장에 적어 두면, 다음 달에 따라갈 것이 생기는 것입니다.
신호의 경로도 하나 만들어 두십시오. 백업 실패, 백업이 너무 오래됨, 검증 실패, 복원 연습 기한 초과. 이 네 가지를 알림으로 만들면, 조용히 실패한 백업은 더 이상 존재하지 않게 됩니다.
되돌릴 수 있다는 것은 상태가 아니라 유지입니다. 매일의 백업 한 번, 매일의 샘플 복원 한 번, 주 1회의 표 복원, 월 1회의 전체 복원. 이 작은 반복의 비용은 작고 건너뛴 대가는 잃어버린 데이터 그 자체입니다. 무엇을 백업할지, 각 계층을 어디에 놓을지, 오래된 사본을 어떻게 살릴지에 이르기까지 이 규율의 전체를 한 페이지 도면으로 정리한 전자책도 함께 준비했습니다.