요약
1997년에 나온 '백업의 도'는 스승과 초보자의 선문답으로 백업의 일곱 원칙을 가르칩니다.
로스 윌리엄스가 1997년에 만든 웹사이트입니다. 초보자가 깨달음을 물으면 스승은 대답 대신 사고를 겪게 하는 짧은 우화 일곱 편과 에필로그로 이뤄져 있습니다.
왜 중요한가
- 백업은 복사해 두는 데서 끝나지 않고, 오래 보관하고 복원해 보고 원본까지 감시해야 완성된다는 점을 보여 줍니다.
- 원문은 눈에 띄는 디스크 고장보다, 모르는 사이 백업까지 번지는 파일 손상을 더 큰 위험으로 꼽습니다.
핵심 내용
- 일곱 원칙은 범위, 빈도, 분리, 이력, 시험, 보안, 무결성이고, 편마다 초보자가 무시한 원칙의 대가를 치릅니다.
- 시스템 파일은 재설치하면 된다던 초보자는 디스크가 고장 난 뒤 사흘째 소프트웨어를 다시 깔고 있었습니다.
- 반년 된 테이프를 재사용하자던 초보자는 넉 달 전 바이러스에 망가진 파일의 유일한 온전한 사본을 잃었습니다.
- 백업을 굳게 믿는 초보자 앞에서 스승은 도끼로 디스크를 부수고, 믿는 것과 실제로 써야 하는 것은 다르다고 말합니다.
- 에필로그는 이 모든 이야기가 Veracity(록소프트의 데이터 무결성 검사 도구) 판촉이기도 하다는 농담으로 끝납니다.
HN 반응
- 시스템 파일 재설치 대목을 두고 NixOS 설정 파일 하나면 된다는 의견과, 원본 패키지가 사라지거나 복구가 느릴 수 있다는 반론이 맞섰습니다.
- 1997년에나 맞는 이야기라는 의견에는 손으로 설정한 윈도 서버가 아직 곳곳에서 돌아간다는 반론이 나왔습니다.
이런 처지라면 애플리케이션까지 백업해 두는 편이 나을 수도 있습니다. 하지만 이 문제를 아예 무의미하게 만드는 더 나은 해법들이 있습니다. 예를 들어 NixOS를 쓰면 시스템 구성을 적은 텍스트 파일 하나만 백업해 두고, 그 파일로 몇 분 안에 시스템을 자동으로 다시 만들 수 있습니다. 그것도 비트 단위까지 똑같다고 보장됩니다.
제 경험으로는 그게 한 80% 정도만 됩니다. 그것만 해도 훌륭하죠! 하지만 백업은 그게 안 될 때를 위해 있는 겁니다.
"어떻게 그렇게 자주 실패하느냐"고 물으실 텐데, 저는 오래된 버전을 고정해 두고 쓰는 걸 좋아하고, 그런 버전은 이런저런 이유로 곧잘 못 쓰게 되거든요(예를 들면 파일을 구할 수 없게 됩니다).
배포판 파일을 미러나 프록시 미러로 백업해 두면 되지 않나요?
요점은 비트 단위 복제를 파일 하나로 해결한다는 거였다고 봅니다. 여기서 인프라를 따로 관리하는 건 투자 대비 효율이 안 좋고요.
파일 하나로 비트 단위 복제를 한다는 건 그 비트들이 아직 남아 있고, 그걸 보장할 수 있을 때나 가능한 이야기입니다. 미러를 두지 않으면 그 비트들은 숨은 의존성입니다. 미러가 없으면 복제가 대체로 잘 되는 것처럼 보이다가, 결국 가장 원치 않는 방식으로 실패하게 됩니다.
그럴 수도 있겠지만, 드라이브 전체를 백업해도 선별해서 백업하는 것보다 크기가 그렇게 많이 늘지 않더라고요. 게다가 드라이브 일부만 백업하려고 하면 꼭 필요한 부분을 빠뜨립니다.
비트 단위로 똑같다는 보장은 없습니다(그 이유를 파고들면 끝이 없습니다). 그래도 실용적인 목적으로는 충분히 똑같습니다.
한편으로는 하드웨어가 바뀌어도 훨씬 잘 버팁니다. 백업해 둔 설정 파일 그대로(특정 시스템에만 해당하는 몇 줄은 빼고요. 있을 수도 있고 없을 수도 있습니다), 전혀 다른 하드웨어에서도 기능상 똑같이 동작하는 시스템을 띄울 수 있으니까요.
제가 Gentoo에서 쓰는 전략은 대략 이렇습니다.
/etc/ - 수정한 설정 파일 전부
/etc/portage/ - make.conf, 패키지 설정(package.accept_keywords, package.use 등)
/var/lib/portage/ - world와 world sets. portage가 시스템을 다시 빌드하는 데 필요한 것 전부
/var/db/repos/ - 특히 로컬이나 직접 만든 패키지 저장소
/home/<username>/ - 설명이 필요 없음
/root/ - 설명이 필요 없음
이 정도면 깨끗한 Stage를 내려받은 데서부터 (크게 손대지 않고) Gentoo 시스템을 거의 그대로 다시 만들 수 있을 겁니다.
NixOS 구성이 hello-world 수준이 아니라면 대개 sops(또는 다른 시크릿 관리 도구)를 쓰고 있을 테고, 그러면 age 키도 백업해야 합니다. 이 키들은 누구나 읽을 수 있는 nix store로 새어 나가지 않도록 메인 구성 트리와 반드시 분리해 두는데, 가장 흔한 경우 git 저장소 밖에 있는 권한 600짜리 파일입니다. 이걸 백업하는 걸 잊는 건 NixOS에서 고전적인 함정이고, 이 공안(koan)을 일반화한 사례이기도 합니다.
새 호스트 키로 시크릿을 다시 암호화하면 되지 않나요? 저는 보통 그렇게 합니다(한 번 부팅해서 키를 만들고, 시크릿을 갱신한 다음, 원격으로 리빌드하고 스위치합니다).
베어메탈 복구가 재설치보다 시간이 덜 걸린다면 베어메탈 백업을 해야 합니다. 베어메탈이 업데이트되면 백업도 그래야 하고요.
가상 머신을 쓴다면 하이퍼바이저 설정과 구성도 꼭 백업하세요. 인프라의 어느 부분이 먼저 망가질지는 아무도 모르니까요.
이건 1997년에나 더 맞는 이야기 같아요. 특히 윈도 서버와 그 위에서 돌리던 것들을 생각하면요.
이게 옛날이야기라고 생각하신다면 현장의 프로덕션 서버에 대해 배울 게 아주 많으실 거예요! =)
세상의 적지 않은 부분이 아직도 몇 대 안 되는 구닥다리 AS/400 시스템에 의존하는 것처럼, 사회의 꽤 큰 부분이 손으로 구성한 윈도 서버가 별 탈 없이 돌아가 주는 데 기대고 있거든요.
요점을 놓치셨습니다. 시스템을 똑같이 다시 만들 수 있느냐는 중요하지 않습니다. 문제의 예시는 복원이 얼마나 정확한지가 아니라 재설치에 걸리는 시간에 관한 것이었습니다.
저도 새 시스템을 kickstart로 띄우고 ansible 플레이북을 적용하는 것만으로 많은 시스템을 완전히 다시 만들 수 있습니다. 그렇게 하고 싶을까요? 아닙니다. 너무 느리고, 이 작업을 수십 수백 대에 해야 할 수도 있으니까요.
저희는 백업을 여러 단계로 둡니다. VM과 물리 서버는 veeam으로 시스템 전체를 백업해 디스크 저장소에 두고, 그걸 오프사이트의 변경 불가(immutable) 저장소로도 보냅니다. 그와 별개로 rsync 기반의 오래된 시스템도 돌리는데, 이건 (일부 데이터 디렉터리를 뺀) 시스템을 서버의 디렉터리로 rsync하고 스냅샷으로 공간 사용량을 최소화합니다.
많은 경우 복원이 필요하면 그냥 호스트로 데이터를 rsync로 되돌리면 됩니다. 파일 한두 개든 시스템 대부분이든요.
저는 여러 유형의 장애를 몇 초, 길어야 한 자릿수 분 안에 복구할 수 있고, 그 시간도 대부분 사람이 손댈 필요 없는 시간입니다. 복구 시간은 중요한 지표인데도 흔히 간과됩니다. 한 번 호되게 당해 보고 나서야, 뭔가를 복원하는 데 사람이 한 시간 넘게 매달리는 방식은 어떤 상황에서는 규모를 감당하지 못한다는 걸 깨닫게 되죠. 그리고 그런 상황이 대개 가장 중요한 상황이고요.
하지만 실제로는 느리지 않습니다. NixOS는 로딩될 때 이전 상태 목록을 전부 보여 주고 고를 수 있게 해 줍니다. 그중 어느 것으로 부팅하든 가장 최근 것으로 부팅하는 것만큼 빠릅니다.
백업을 비트 복사로 복원하는 건 그 비트들이 복사되기를 기다려야 해서 훨씬 느립니다. 반면 이전 구성으로 부팅하는 건 이미 자리에 있는 비트들을 가리키는 참조만 바꿔 끼우는 일이라 아무 조작도 필요 없습니다.
불변성(immutability)이 여기서 얻게 해 주는 게 꽤 많습니다. 다만 그 이점을 누리려면 처음에 어느 정도 규율이 필요하고, 사람에 따라서는 그게 결정적인 걸림돌이 될 수도 있습니다.
시스템이 아직 살아 있고 상태 정보를 믿을 수 있을 때는 그게 유용합니다. 하지만 디스크가 고장 났거나 시스템 상태가 심하게 손상돼 그 상태 추적을 믿고 싶지 않을 때는 다른 수단이 필요합니다.
또 구성에서 패키지 버전을 고정해 두셨나요? 그 모든 경우에 원래 패키지가 아직 남아 있습니까? 이전 버전을 항상 보관해 주지 않는 원격 소스에서 받아 오던 건 아닌가요?
처음부터 직접 빌드한 게 있습니까? 설치에 쓴 소스나 바이너리 아카이브를 따로 제공했나요? 그 소스는 정확히 같은 버전으로 아직 구할 수 있습니까?
상태를 기록해 둔 것에서 복원하면 필요한 건 전부 기록된 데이터에 들어 있습니다. 반면 상태의 설명(임의의 동작이 포함될 수도 있습니다)을 바탕으로 있어야 할 상태를 다시 만들려면 신경 쓸 게 수없이 많습니다.
기록할 수 있는 건 많을수록 좋습니다. nix 구성 상태도 기록해 두고, 상황에 맞으면 그걸로 복원해야 할까요? 물론입니다! 간단하고 쉽고 공간도 엄청나게 쓰지 않는다면 안 할 이유가 없죠. 다만 백업 시스템이 충족해야 할 구체적인 요구사항과 목표에 비추어 있으면 좋은 것과 충분한 것을 혼동하지 마십시오.
저희는 시스템 이미지 전체를 변경 불가 원격 저장소에 두고 있지만, 가장 먼저 찾는 곳은 거기가 아닙니다. 더 빠르고 쉬운 수단으로 부족할 때 거기로 갑니다. NixOS를 쓴다면 지금 하는 건 전부 유지하고, 거기에 NixOS 상태를 별도로 바뀔 때마다 백업해 저장하도록 추가했을 겁니다(실제로 비슷한 맥락에서 모든 호스트에서 etckeeper도 돌리고 있습니다. 뭔가 바뀌면 매일 커밋하고, 호스트 구성을 적용하는 ansible을 실행할 때마다 시작과 끝에도 자동으로 커밋합니다).
많을수록 좋습니다. 구성 변경이 궁금하면 대개 그 장비의 etckeeper를 보면 되고, 어느 시점에 rsync로 만든 백업에 있던 정확한 상태로 트리를 복원하고 싶으면 그것도 쉽게 할 수 있습니다(그게 어땠는지 보기만 하려면 백업 서버의 디렉터리 트리를 돌아보거나, 시점별 상태를 diff하면 됩니다). 정상이던 백업에서 시스템 이미지 전체를 복원해야 하면 Veeam과 로컬 저장소를 씁니다. 로컬 저장소가 죽었으면 복제해 둔 오프사이트 저장소를 쓰고요. 공격자가 둘 다 파괴했다면 변경 불가 오프사이트 백업으로 가는데, 아마 백업 인프라를 맨땅에서 다시 구축한 뒤에 거기서 복원하게 될 겁니다. 이 수단들은 각기 조금씩 다른 시나리오를 막아 주고, 보안, 무결성, 사용 편의성 면에서 저마다 다른 절충을 제공합니다.
맞습니다. 입력과 출력 모두 로컬 캐시 대신 원격 캐시에서 받아 와야 하면 "빠르다"는 장점은 놓칠 수 있습니다. 그리고 커뮤니티가 관리하는 캐시를 무작정 믿는 게 맞지 않을 수도 있으니, 그러면 결국 캐시를 직접 관리하면서 전통적인 방법으로 백업해야 하는 처지가 됩니다. 만능 해결책은 아니고, 많은 용도에서는 아마 본전도 못 건질 겁니다.
하지만 이걸로 얻는 건 다른 방법으로는 얻기 힘든 검증 가능성입니다. 누구든 선언된 입력만으로 시스템의 어느 부분이든 빌드해서 "흠, 나는 해시가 다르게 나오네요. 뭔가 이상한데요"라고 말할 수 있습니다. 누군가 손댄 이미지에서 복원한다면 소스 코드가 아니라 이미지가 진실의 원천이 되는데, 그러면 그 타당성을 따져 보기가 훨씬 어려워집니다. 검증해 줄 사람이 그 특정 이미지에 관심 있는 사람들뿐이고, 이는 여러분이 의존하는 소스에 관심 있는 사람들의 집합보다 훨씬 작을 가능성이 높기 때문입니다.
이걸 Veracity로도 할 수 있나요? Veracity가 이미 지원하는데 굳이 Veracity 기반이 아닌 솔루션을 쓰고 싶지는 않거든요.
이건 1997년 글이에요. 2026년에는 이 일이 훨씬 쉽고요.
Nix는 옛날 버전을 무기한 보관하나요?
다른 배포판에서도 Puppet이나 Ansible 같은 걸로 똑같이 할 수 있긴 한데, 그 배포판의 패키지 범위 안에서만 됩니다. 배포판 밖의 서드파티 물건(그리고 요즘은 서드파티 물건을 점점 더 많이 씁니다)은 다운로드 링크가 죽어 있을 수도 있고요.
게다가 그냥 백업에서 복원하는 게 여전히 더 빠릅니다.
실은 보관합니다! 필요한 건 패키지 정의뿐이고, 그건 해당 nixpkgs 저장소 커밋의 tarball에서 얻을 수 있으니까요. 그리고 빌드+설치나 다운로드+설치나 Nix 명령은 똑같기 때문에, 바이너리 캐시에 옛 패키지가 남아 있느냐(캐시가 아직 살아 있느냐조차)는 빠른 다운로드냐 느린 빌드냐의 차이일 뿐입니다. 오래된 걸 설치하려면 복잡한 빌드 환경을 띄우고 새 도구를 잔뜩 익혀야 하는 대부분의 패키지 관리자와는 다르죠.
물론 원본 소스마저 없어졌다면 깨진 URL을 고쳐야 할 겁니다. 소스가 인터넷에서 어떻게든 싹 지워졌다면 방법이 없고요.
저는 개인 컴퓨터에서 백업으로 복원할 때, 보통 그걸 정리할 기회로 삼아요.
백업보다는 스냅샷으로 되돌리는 쪽이 더 낫습니다. 제 호스트 머신은 깨끗합니다. 작업을 전부 VM에서 하거든요.
그 얘기는 MinIO 사용자들한테 해 보시죠, ㅋㅋ
ㅋㅋ, 저 대목이 나오자마자 광고인가 싶었는데, 그래도 그걸 인정할 배짱은 있네요.
스승은 이러면 안 됐습니다. 설령 선편 우편으로 보냈더라도요. 백업의 첫 번째 법칙은 이렇기 때문입니다. 제대로 된 백업은 치명적인 데이터 손실을 겪고 나서야 배우게 된다는 것.
제자를 그 일에서 보호해 주는 건 유일하게 참된 앎을 빼앗는 일입니다. 머리에만 저장되는 게 아니라 살갗에 새겨지는 그 앎을요.
하지만 스승은 이미 그걸 DOOM 사본으로 덮어써 버린 뒤였습니다.
월드 와이드 웹이 그리워요, 정말...