백업은 간단하지 않다 — 스냅샷에서 3-2-1 규칙까지 쌓이는 복잡성

본문

저자는 '데이터의 치명적 손실을 겪어본 사람과 앞으로 겪을 사람, 두 부류가 있다'는 시스템 관리자들 사이의 격언으로 글을 시작합니다. 어린 시절 가족 사진을 외장 하드 한 곳에 모아두었다가, 아버지가 TV 셋톱박스의 포맷 안내를 따라 디스크를 초기화하면서 전부 날릴 뻔한 경험을 소개합니다. 다행히 복구에는 성공했지만 '중요한 것을 한 곳에만 두지 않는다'는 값싼 교훈을 얻었고, 비기술자에게 포맷이 데이터 삭제를 의미한다는 사실까지 알도록 요구하는 소프트웨어 측의 문제도 있었다고 지적합니다.

미러가 아니라 스냅샷이어야 하는 이유

백업의 첫 원칙은 파일의 사본을 다른 곳에 두는 것이지만, 상시 연결된 드라이브는 랜섬웨어 암호화, 실수로 인한 삭제, 모든 것을 0으로 덮어쓰는 스크립트 같은 위험에 그대로 노출됩니다. 따라서 RAID 1처럼 디스크를 실시간 미러링하는 방식은 백업이 될 수 없고, 과거 시점으로 되돌아갈 수 있는 스냅샷 방식이 필요합니다. 얼마나 자주 스냅샷을 찍을지는 RPO(Recovery Point Objective)로 표현되는데, 실제 현장에서는 데이터 손실을 감당할 수 없는 금융 기관의 30초 미만부터, 재해 복구 전략이 있다면 감사한 수준인 소기업의 24시간 이상까지 다양합니다.

로테이션과 GFS — 점점 길어지는 형용사 목록

스냅샷은 저장 공간 부담을 키우므로 로테이션이 필요합니다. 최근 14일치만 유지하는 단순한 방식은 '2주 전에 무언가가 조용히 손상되었을 수 있다'는 문제를 남기고, 1년치 일별 스냅샷을 전부 보관하는 것도 비현실적입니다. 364일째 되는 날에 2일차와 3일차 사이의 변화는 거의 의미가 없기 때문입니다. 그래서 최근일수록 촘촘하고 과거일수록 성긴 세분도가 필요해지고, 일별 14일·주별 7주·월별 12개월 로테이션이라는 GFS(Grandfather-Father-Son) 방식에 도달합니다.

중복 제거와 증분 백업

MPEG이 프레임 간 유사성을 이용해 영상을 압축하는 것에서 영감을 얻으면, 파일 변경 역시 fat-tailed 분포를 따라 대부분의 파일은 변하지 않고 소수만 계속 바뀐다는 사실에 도달합니다. 동일한 파일을 중복 저장하는 대신 하드 링크로 참조하는 중복 제거(deduplication)가 답이며, 디렉토리 항목만 지우기 때문에 로테이션과도 양립합니다. 이것이 rsnapshot이 쓰는 증분(incremental) 백업 방식이고, 네트워크 전송량과 클라우드 비용까지 줄여줍니다. 여기까지 오면 '증분·중복 제거·GFS 로테이션·스냅샷 기반' 백업이 완성되며, rsync와 cronjob으로 구현할 수 있고 파일 메타데이터도 보존됩니다.

현실이 던지는 문제들

이 솔루션을 Docker 컨테이너 10개가 도는 홈랩에 적용하면 곧바로 실패가 시작됩니다. 컨테이너가 root 소유 파일을 만들어 일반 사용자 cronjob이 읽지 못하고, 데이터베이스는 성능을 위해 메모리에 데이터를 들고 있다가 배치로 디스크에 쓰기 때문에 운 나쁘게 찍힌 백업은 복원 시 손상됩니다. 그래서 데이터베이스 덤프와 볼륨 전체 권한이 추가됩니다. 특정 하드드라이브 모델의 높은 고장률 사례를 접하면 서로 다른 매체에 나눠 저장하고 싶어지고, 정전·화재·침수까지 대비하면 유명한 3-2-1 규칙 — 사본 3개, 서로 다른 매체 2종, 오프사이트 1개 — 에 도달합니다.

S3, 그리고 포기와 감사

오프사이트로 Amazon S3 같은 오브젝트 스토리지를 고르면 새로운 벽이 나타납니다. 업로드 시 파일 메타데이터가 사라지고, 작은 파일 다수 업로드는 fat-tailed 분포 때문에 비용이 처벌적 수준으로 비쌉니다. 그래서 tarball로 묶어야 하는데, 거대한 단일 tar는 하드 링크 기반 증분 백업을 무의미하게 만들고, 50MB 청크로 나누면 '검증 가능하게 안전한' 분할을 직접 구현해야 합니다. 저자는 오후 한 나절이면 될 줄 알았던 자작 백업이 여기서 한계에 이른다고 고백하며, 암호화·청크 단위 중복 제거·체크섬까지 처리하는 Borg나 Restic 같은 검증된 도구와 이를 만들어온 오픈소스 커뮤니티에 감사를 표합니다. 마지막으로 복원 테스트 없이는 이 모든 것이 무의미하다며, 6개월마다 복원을 실행하는 디지털 위생 습관을 당부합니다.

Hacker News 반응

• @readthenotes1 — "복원을 실제로 테스트하지 않으면 이 모든 것이 무의미하다." 제 선생님 중 한 분은 일반적인 통념과 달리 실제로 백업에 가치를 두는 사람은 없으며, 돈을 낼 가치가 있는 것은 복원이라고 주장하셨습니다.
• @TheCondor — 직접 만든 백업 '솔루션'에서 간단한 복구를 하려다 문제를 발견하기 시작할 때의 느낌은 특별합니다. 두려움이라기보다 혐오감, 속이 메스꺼움, 자기 분노, 상실감이 뒤섞인 복잡한 감정입니다. 아이들의 아기 사진 전부가 사라진 물질이라면 어떨지 상상만 해봅니다. Borg와 restic은 훌륭하지만, 온갖 기능에도 불구하고 검증을 포함한 합리적인 정책 같은 '바보 방지 모드'가 있으면 좋겠습니다.
• @innocent_name — NAS에서 20TB를 임시로 옮겨야 해서 Hetzner 스토리지 박스를 샀고, 전송 전 암호화를 위해 borg ssh 마운트를 썼습니다. borg가 이슈 #7672 때문에 몇 번 실패했고, 문서대로 재개했더니 2GB가 조용히 손상되었습니다. 끊긴 파이프 때문에 데이터 무결성 검사도 불가능했고 이전 지점부터 재개하는 옵션도 없었습니다.
• @gerdesj — 그런 기준으로 사업을 운영한다고 생각해 보세요, 복원은 어디서 나오겠습니까? 저희는 고객에게 백업 스토리지를 용량으로 과금하는데, 여기에는 연간 복구 시연이 포함됩니다. 고객 시스템 일부 또는 전부를 저희 장비에서 격리된 상태로 띄워서 제대로 작동함을 보여줍니다. 선생님의 말씀은 '높이가 사람을 죽이는 게 아니라 깊이가 죽인다'는 잘 알려진 말을 변주한 겁니다.
• @bitwize — "사람을 죽이는 건 추락이 아니라 끝에 오는 갑작스러운 정지다."

원문: filipovski.net / 번역·요약: Trawling