“사람은 치명적인 데이터 손실을 겪은 사람과 앞으로 겪을 사람으로 나뉜다”는 경험적 명제인데, 실제로 근거가 있는지 의문임.
99%의 사람은 백업하지 않으며, 위험이 낮고 스스로 복구 가능성을 크게 높이기도 어렵고 데이터 손실을 재앙으로 여길 만큼 애착도 없으니 그게 올바른 선택일 수도 있음. 일부 기술 애호가는 데이터를 절대 잃지 않는 데 열심이지만, 보편적인 태도는 아님. 대부분에게는 그리 중요한 일이 아니며, 그래도 괜찮음.

살면서 후회할 만한 데이터 손실을 네 번 겪었음. 첫 번째는 열 살 때 집 앞 전봇대에 벼락이 직접 떨어졌을 때임. 평생 들은 소리 중 가장 컸고, 전류가 전화선과 내장 팩스 모뎀을 타고 들어와 주변 부품을 모두 태워버렸음. 플로피 백업은 있었지만 모든 데이터를 담지는 못했음.
두 번째는 OneDrive의 “평생” 저장 공간 관련 약관 변경 때문임. 내려받기 속도가 사용하기 어려울 정도로 느린 클라이언트에 회수 기한까지 겹쳐 파일 대부분을 잃었음. 세 번째는 여행 중 디지털카메라의 SD 카드 컨트롤러가 고장 나 카드가 아예 인식되지 않았을 때임. Toshiba가 제조한 새 Sony 128GB 카드였고 흔한 고장처럼 보였기에, 이제는 카드 두 장에 동시에 촬영함.
네 번째는 백업 도중이었음. 잘못된 스크립트가 원본을 지웠는데, 새 백업 공간을 확보하려고 기존 백업도 지운 뒤였음. 이후 덮어쓸 수 있는 매체를 경계하게 됐고, 백업 작업 자체도 위험도가 높다고 봄.

1990년대 하드디스크 고장으로 BASIC 프로그램을 전부 잃었던 일이 떠오름. 풀이 죽어 앉아 있으니 어머니가 플로피 디스크 몇 장을 건네며 쓸 만한 게 있는지 확인해 보라고 하셨음.
거기에 프로그램이 전부 들어 있었음! 직접 백업해 놓고 잊어버렸던 것임. 백업은 무엇을 어디에 해뒀는지 추적하는 것도 어려운 과제임.

중국 클라우드 저장 업체에서 비슷한 일을 겪었음. 편리한 내보내기 기능도 없고 다운로드를 약 100KB/s로 제한했지만, 다행히 가상 머신 여러 대에서 클라이언트를 실행해 병렬로 내려받을 수 있었음.
원본과 기존 백업을 함께 잃는 과정은 백업 절차 자체에 근본적인 결함이 있어 보임. 나도 root 권한의 백업 프로그램이 폭주할까 걱정돼서, systemd로 제약을 건 restic 실행 정도로 작업을 단순하게 유지함.

이 얘기가 나온 김에, iCloud 사진을 따로 백업하는 분이 있는지, 있다면 어떻게 하는지 궁금함.

사진과 중요한 문서를 Blu-ray 디스크에 백업할까 잠깐 고민했지만, 생산이 대부분 축소되는 요즘에는 괜찮은 기록 장치를 구하기가 쉽지 않아 보임. 차선책으로는 일정 기간 객체 삭제를 막는 객체 저장 서비스의 “object lock” 기능이 좋아 보임.

Jim Salter의 sanoid/syncoid를 이용해 외부 백업 장치가 데이터를 가져가는 방식으로 동기화하는 ZFS 스냅샷 구성이 마음에 듦. 모든 운영체제와 파일시스템의 기반을 ZFS로 삼고, 데이터셋을 잘 정리해 임시 데이터와 영구 보존 데이터를 분리하면 백업 요구사항의 90%는 충족됨.
도구는 1, 데이터 분리 구성 예시는 2를 참고하면 됨.

호스트 세 대에 3-2-1에 가까운 백업을 구성 중이며, Restic + Backrest 쪽으로 마음이 기울고 있음. 모두 같은 CoreOS 구성을 사용하고, 컨테이너 볼륨을 volumes/ 한곳에 모아두므로 이 폴더만 백업하면 됨. https://github.com/ebrahim37/infra-template. vps1에서는 사용자 정의 sh 진입점이 있는 restic 컨테이너로 24시간마다 volumes/를 홈랩에 백업할 계획임. 홈랩에서는 backrest 컨테이너가 로컬 볼륨 백업, 정리·검사, 외부 저장소 복제를 맡고, rest-server 컨테이너가 세 호스트의 백업을 보관함. 외부 호스트도 24시간마다 볼륨을 홈랩에 백업하며, 별도의 rest-server로 홈랩 백업 사본을 보관하게 됨.
걸리는 부분은 데이터베이스임. 컨테이너를 중지하고 데이터 볼륨을 백업한 뒤 재시작하거나, pg_dump 같은 도구를 써야 함. 중복 제거 덕분에 지난 1년의 주간 스냅샷을 보관해도 저장 비용이 과도하게 늘지 않는 점이 좋음.

백업은 단순함. 문제는 기업이 이를 시험해야 할 QA 인력을 해고하기 좋아한다는 것임. Microsoft는 테스트 개발 엔지니어가 필요 없다며 결함투성이 제품을 출시해도, 인질이나 다름없는 고객이 뭘 할 수 있겠느냐는 식임.
데이터 손실을 겪는 대기업에는 동정심이 없지만, 할머니의 결혼사진을 잃은 개인은 안타까움. 내 복구 전략은 단순함. 사진을 스캔해 사촌 한 명에게 이메일로 보냈고, 그 사촌이 다른 사촌들에게 다시 보냈음. 클라우드 백업도 있지만 원본 파일이 어디 있는지는 모름. 결국 데이터는 공유하기 위한 것임.

rsync로 Synology NAS에 복사하고, 그곳에서 스냅샷을 만든 뒤 VPN으로 원격 Synology NAS에 동기화함. 다른 NAS는 부모님 댁에 있고, 부모님도 비슷한 구성으로 내 쪽에 동기화함.
가장 좋은 점은 독점 형식의 아카이브가 아니라 그냥 파일이라는 것임. 가장 기본적인 도구로도 복구할 수 있어 신뢰가 큼. Linux, Windows를 거쳐 지금의 Mac까지 잘 작동했고, 새 컴퓨터와 운영체제로 옮길 때도 대부분 백업 복원으로 해결함.

집 PC에서는 restic을 수동으로 실행함. 스크립트를 사용하며, 마지막 백업 후 24시간이 지나면 터미널 배너가 재촉하고, 백업을 했으면 스페인어 동사표를 보여줌. 평소의 동사표가 안 보이면 바로 알아차리도록 한 구성임.
예전에 백업 cron 작업이 사라져 낭패를 봤고, 이 용도에 Dead Man’s Snitch까지 쓰는 건 과하다고 느꼈음. 이전 설치에서 어떤 백업 체계를 썼는지 잊어버려, 복구가 필요할 때 구성을 파악하는 데 너무 오래 걸린 적도 있음.
운영 환경이라면 당연히 자동화와 모니터링이 맞지만, 개인 컴퓨터에서는 이 구성이 꽤 마음에 듦.