"데이터를 크게 잃어본 사람과, 앞으로 잃게 될 사람. 세상엔 이 두 부류만 있다." 시스템 관리자 사이에서 여러 변형으로 떠도는 이 말은 데이터 손실이 생각보다 흔하고, 대부분이 그 순간에 대비되어 있지 않다는 현실을 압축한다. 개발자 알렉산다르 필리포프스키는 자신의 어린 시절 경험에서 이야기를 시작한다. 가족 사진을 정리하려고 외장 하드에 몰아넣어 두었는데, 아버지가 그 드라이브를 셋톱박스 저장장치로 쓰려다 포맷 안내에 따라 그대로 밀어버렸다는 것이다. 다행히 복구했지만, 그는 이 사고가 한 사람의 실수가 아니라 여러 단계의 허점이 겹친 결과였다고 짚는다. 사진을 한 곳에만 두었고, 포맷이 곧 데이터 삭제라는 경고를 제대로 띄우지 않은 형편없는 UI가 있었으며, 애초에 비전문가에게 이런 지식을 기대하는 것 자체가 무리였다.
복사본 하나로는 부족한 이유
첫 번째 원칙은 단순하다. 파일의 사본을 다른 곳에 하나 더 둔다. 하지만 이 원칙만으로는 부족하다. 드라이브는 고장 나거나 도난당할 수 있고, 하드디스크의 자성 입자가 이동하거나 SSD의 NAND 소자가 전하를 누설하면서 시간이 지나 데이터가 조용히 썩어가는 '비트 부패'도 일어난다. 더 성가신 문제는 연결된 드라이브 자체가 위험원이 된다는 점이다. 랜섬웨어가 파일을 암호화할 수도 있고, 실수로 엉뚱한 파일을 지우거나 최악의 경우 전체를 0으로 덮어쓰는 스크립트를 돌릴 수도 있다. 그래서 백업은 원본을 그대로 비추는 거울이어서는 안 된다. 문제가 생겼을 때 과거로 되돌아갈 수 있어야 하며, 이는 RAID 1 같은 실시간 미러링이 백업이 될 수 없다는 뜻이다. 필요한 것은 시점을 저장하는 스냅샷 방식이다.
복잡성이 눈덩이처럼 불어난다
얼마나 자주 스냅샷을 찍을 것인가는 '얼마만큼의 데이터 손실을 감내할 수 있는가'의 문제, 즉 복구 시점 목표(RPO)로 정리된다. 금융권처럼 손실이 치명적인 곳은 30초 미만을 목표로 하지만, 소규모 조직은 24시간 이상이거나 아예 복구 전략이 없기도 하다. 스냅샷을 자주 찍으면 저장 부담이 커진다. RPO가 24시간이면 주 7개, 월 30개, 연 365개의 스냅샷이 쌓인다. 그래서 오래된 것부터 지우며 순환시켜야 하는데, 단순히 14일치만 유지하는 방식은 그 사이에 조용히 손상된 데이터를 놓칠 위험이 있다. 반대로 1년치를 다 보관하는 것도 무의미하다. 오늘에서 가까울수록 촘촘하게, 멀수록 성기게 남기는 것이 합리적이다. 여기서 GFS(할아버지-아버지-아들) 순환 방식이 나온다. 일 단위 백업은 14일, 주 단위는 7주, 월 단위는 12개월씩 순환하는 식이다.
필리포프스키는 여기에 영상 압축의 발상을 겹친다. MPEG이 배경이 거의 정지된 장면에서 프레임 간 차이만 벡터로 저장하듯, 스냅샷도 대부분 서로 비슷하다. 파일 변경은 두꺼운 꼬리 분포를 따라 절대다수는 전혀 바뀌지 않고 극소수만 자주 바뀐다. 그렇다면 동일한 파일을 매번 복사할 게 아니라 중복을 제거하고, 이미 존재하는 파일은 하드링크로 참조하면 된다. 실제 파일은 디스크에 하나만 두고 각 스냅샷이 이를 가리키므로, 디렉터리 항목만 지우는 순환에도 데이터가 살아남는다. rsnapshot이 쓰는 이 증분 백업 방식은 저장 공간뿐 아니라 네트워크 대역폭도 절약한다. 클라우드를 두 번째 저장소로 쓸 때 이는 곧 비용 절감으로 이어진다.
현실은 디테일이 넘쳐난다
이렇게 증분·중복제거·GFS 순환·스냅샷 기반 백업을 완성하고 rsync와 cron으로 자동화하면 그럴듯해 보인다. 하지만 홈랩의 도커 컨테이너 10개를 백업하려는 순간 문제가 터진다. 많은 컨테이너가 root 소유 파일을 만드는데 cron 작업이 일반 사용자로 돌면 백업이 실패한다. 데이터베이스는 성능을 위해 메모리에 데이터를 두었다가 나중에 디스크로 몰아 쓰는 탓에, 운이 나쁘면 복원 시 손상으로 실패한다. 그래서 DB 덤프를 별도로 뜨고 도커 볼륨에 대한 권한을 조정해야 한다. 특정 하드디스크 모델의 높은 불량률 같은 사건을 접하면, 서로 다른 매체 두 종류에 저장하고 하나는 클라우드나 지인의 집처럼 물리적으로 떨어진 곳에 두고 싶어진다. 이것이 사본 3개, 매체 2종, 오프사이트 1개로 요약되는 3-2-1 백업이다.
오프사이트로 S3 같은 객체 스토리지를 고르면 또 다른 벽에 부딪힌다. 업로드 시 파일 메타데이터가 사라지고, 작은 파일을 대량으로 올리면 비용이 가혹하게 붙는다(파일 크기 역시 두꺼운 꼬리 분포를 따른다). 결국 여러 파일을 tarball로 묶어야 메타데이터와 비용을 모두 지킬 수 있는데, 하나의 거대한 tarball로 묶으면 하드링크 기반 증분 백업의 의미가 사라진다. 50MB 단위로 깔끔하게 쪼개되 그것을 검증 가능하게 안전한 방식으로 해내야 한다. 저자는 바로 이 지점에서 직접 만드는 것을 포기하겠다고 말한다.
실무자를 위한 교훈
오후 한나절이면 짤 수 있을 것 같던 백업은, 실제로는 감당하기 어려운 정신적 부담을 요구한다. 그래서 결론은 Borg나 Restic 같은 검증된 도구를 쓰라는 것이다. 이들은 암호화, 청크 단위 중복제거, 체크섬까지 처리하며, 그 복잡성을 추상화하기까지 오픈소스 커뮤니티가 쌓아온 수많은 시행착오가 녹아 있다. 다만 백업을 갖추는 것만으로 끝이 아니다. 복원을 실제로 시험해보지 않으면 아무 의미가 없다. 최소 6개월에 한 번은 복원을 돌려보는 것이 디지털 위생의 일부다. 이 글이 한국의 실무자에게 주는 함의는 분명하다. 백업 요건을 스스로 재구현하려는 유혹을 참고, 성숙한 도구 위에서 RPO 설정·권한·DB 정합성·복원 검증에 집중하는 편이 훨씬 안전하다. 마지막으로 저자는 새벽 2~3시에 백업을 돌리지 말라는 농담 섞인 조언을 덧붙이는데, 서머타임 전환으로 시각이 겹치거나 사라지는 시간대의 스케줄링 함정을 떠올리게 하는 대목이다.