백업은 파일 복사가 아니다: 가족사진부터 홈랩까지, 진짜 복구되는 백업 만들기
한 줄 요약
백업은 "파일을 다른 곳에 복사하는 일"이 아니라 과거의 특정 시점으로 돌아갈 수 있는 상태를 유지하는 일입니다. 장치 고장뿐 아니라 실수, 랜섬웨어, 조용히 진행되는 데이터 손상까지 막아야 하기 때문이죠. 그리고 무엇보다 — 복원해 보지 않은 백업은 백업이 아닙니다.
사본 하나에 의존하면 벌어지는 일
실제로 이런 사례가 있었습니다. 여러 노트북과 PC에 흩어져 있던 가족사진을 외장 하드 한 곳에 모아두었는데, 나중에 그 드라이브를 TV 셋톱박스용 저장장치로 쓰려고 포맷하면서 파일 인덱스가 날아간 겁니다. 다행히 사진은 복구했지만, 별도 백업은 없었고 셋톱박스 어디에도 "포맷하면 데이터가 사라집니다"라는 분명한 경고는 없었습니다.
비기술 사용자가 포맷의 결과를 당연히 알 거라고 기대할 수는 없습니다. 그리고 데이터가 한 곳에만 있으면 다음 위험에 그대로 노출됩니다.
- 고장과 도난 — 물리적으로 사라지면 끝입니다
- 장기 보관 중 데이터 손상 — HDD는 자성 입자의 변화로, SSD는 NAND 트랜지스터의 전하 누설로 시간이 지나며 데이터가 조용히 썩어갑니다
- 랜섬웨어 암호화, 실수로 인한 삭제, 모든 데이터를 0으로 덮어쓰는 스크립트 — 연결된 드라이브라면 백업도 함께 당합니다
RAID는 백업이 아닙니다
여기서 많이들 오해하는 지점입니다. RAID 1 같은 미러링은 현재 상태의 복제본일 뿐입니다. 실수로 파일을 지우면 미러에서도 똑같이 지워지죠. 우리에게 필요한 건 복제본이 아니라 과거 상태를 보존하는 스냅샷입니다.
얼마나 자주 백업할까: RPO와 보존 정책
복구 시점 목표(RPO, Recovery Point Objective) 는 "얼마만큼의 시간에 해당하는 데이터 손실을 감수할 수 있는가"입니다. 이 값이 백업 주기를 결정합니다.
| 대상 | 현실적인 RPO | |---|---| | 가족사진 | 주 1회 (6일 23시간 손실 감수) | | 중요 금융기관 | 30초 미만 | | 일부 소기업 | 24시간 이상 | | 재해 복구 전략이 없는 곳 | (사실상 무한대) |
그런데 스냅샷이 쌓이면?
RPO가 24시간이면 스냅샷은 주 7개, 월 30개, 연 365개씩 쌓입니다. 그래서 백업 순환(rotation) 이 필요합니다.
- 최근 14일치만 보존 → 단순하지만, 손상을 그 안에 발견하지 못하면 답이 없습니다
- 1년 전 모든 일별 상태를 동일한 밀도로 보관 → 그럴 필요까지는 없습니다
그래서 최근은 촘촘하게, 과거는 성기게 보관하는 방식이 효율적입니다. 대표적인 것이 GFS(Grandfather-Father-Son) 순환입니다.
- 일별 백업 14일치
- 주별 백업 7주치
- 월별 백업 12개월치
공간과 대역폭 아끼기: 증분 백업과 중복 제거
MPEG 영상 압축이 비슷한 프레임 사이의 움직임만 작은 정보로 표현하듯, 스냅샷도 대부분의 내용이 직전 상태와 동일합니다. 실제로 파일 변경은 꼬리가 두꺼운 분포(fat-tailed distribution) 를 따릅니다. 일정 기간 동안 대다수 파일은 전혀 바뀌지 않고, 극소수 파일만 빈번하게 바뀌죠.
중복 제거
동일한 파일을 반복 저장하는 대신, 이미 존재하는 파일을 하드 링크로 참조합니다. 파일 하나를 여러 스냅샷이 함께 참조하고, 백업 순환 시에도 파일 자체가 아니라 디렉터리 항목만 삭제하므로 이 구조가 유지됩니다. rsnapshot이 바로 이 접근법을 사용합니다.
증분 vs 차등
- 증분(incremental) 백업 — 인접한 두 스냅샷 사이의 변경만 저장. 공간 효율이 좋습니다
- 차등(differential) 백업 — 마지막 전체 백업 이후의 모든 변경을 저장. 공간은 더 쓰지만 복원할 때 더 견고합니다
중복 제거는 저장 공간뿐 아니라 네트워크 대역폭도 아껴줍니다. 백업은 결국 다른 머신으로 파일을 보내는 일이고, 클라우드를 쓴다면 전송량이 곧 비용이니까요.
💡 여기까지는
rsync+cron으로 충분히 구현할 수 있습니다. rsync로 주 머신의 파일을 가져오고, cron으로 백업 스크립트를 돌리면 증분·중복 제거·GFS 순환·스냅샷 백업이 갖춰집니다. rsync는 파일 메타데이터를 보존하므로 접근 권한과 소유권도 그대로 유지됩니다. 백업 머신을 추가하는 것도 어렵지 않고요.
홈랩에 적용하면 무너지는 지점
"이 정도면 됐다" 싶을 때, Docker 컨테이너 10개를 굴리는 홈랩에 똑같이 적용해 보면 곧바로 벽에 부딪힙니다.
1. 파일 권한
컨테이너는 root 소유 파일을 만드는데, cron 작업은 기본 사용자 권한으로 돌아갑니다. 해당 파일에 접근하지 못해 백업이 조용히 실패합니다.
2. 데이터베이스 일관성
데이터베이스 파일을 그대로 복사하는 것도 안전하지 않습니다. DB는 성능을 위해 데이터를 메모리에 두었다가 디스크에 일괄 기록하기도 하거든요. 그 중간 상태에서 뜬 백업은 운이 나쁘면 데이터가 손상되어 복원에 실패합니다.
해법은 두 가지입니다.
- 백업 과정에 데이터베이스 덤프를 추가할 것
- Docker 볼륨의 파일시스템에 충분한 접근 권한을 부여할 것
매체와 장소를 분산하는 3-2-1 백업
특정 하드디스크 모델이 유난히 높은 고장률을 보였던 Deskstar 사례처럼, 하드웨어 종류 자체가 원인이 되는 실패도 있습니다.
- 서로 다른 매체를 쓰는 두 머신에 백업을 두면, 특정 하드웨어 결함으로 모든 백업을 한꺼번에 잃을 확률이 낮아집니다
- 외부 장소 백업은 전력 서지, 홍수, 화재가 모든 사본을 동시에 파괴하는 상황을 막아줍니다. 클라우드도 좋고, 가족 집에 둔 머신도 훌륭한 선택지입니다
이것을 정리한 것이 3-2-1 백업 원칙입니다.
사본 3개를, 서로 다른 매체 2종에 보관하고, 그중 1개는 외부 장소에 둔다.
객체 스토리지가 더하는 복잡성
외부 백업지로 Amazon S3 같은 객체 스토리지를 고르는 순간, 기존 파일 기반 구성이 그대로 작동하지 않습니다.
- 메타데이터 손실 — 파일을 업로드하면 기존 파일 메타데이터를 잃습니다 (권한, 소유권이 날아갑니다)
- 작은 파일의 비용 폭탄 — 파일 크기 역시 꼬리가 두꺼운 분포를 따르는데, 작은 파일을 잔뜩 업로드하면 요청 비용이 매우 높아집니다
tar로 묶으면 되지 않을까?
여러 파일을 tar 아카이브로 묶으면 메타데이터를 보존하면서 업로드 비용도 낮출 수 있습니다. 하지만 모든 파일을 거대한 아카이브 하나로 합치면, 애써 만든 하드 링크 기반 증분 백업이 의미를 잃습니다. 조금만 바뀌어도 전체를 다시 올려야 하니까요.
그래서 50MB 단위 청크로 나누는 편이 낫습니다. 다만 이걸 검증 가능하고 안전한 방식으로 직접 구현하는 일은 결코 쉽지 않습니다.
결론: 직접 만들지 말고, 복원을 테스트하세요
백업 시스템을 직접 만드는 일은 처음엔 반나절 작업처럼 보입니다. 하지만 지금까지 살펴본 복잡성이 계속 누적되죠. 대부분의 경우, 그 값을 치를 가치가 없습니다.
검증된 도구를 쓰세요
Borg나 Restic 같은 도구는 위의 문제들과 함께 다음까지 처리해 줍니다.
- 암호화
- 청크 단위 중복 제거
- 체크섬 검증
오픈소스 커뮤니티의 개발과 유지보수, 실제 환경에서의 검증과 시행착오가 이 복잡성을 대신 추상화해 준 결과입니다.
그리고 반드시 복원을 테스트하세요
복원 테스트를 실제로 해보지 않으면 백업은 아무 소용이 없습니다. 6개월마다 한 번씩은 진짜로 복원을 실행해 보세요. 암호화, 청크 단위 중복 제거, GFS 순환, 시점별 아카이브, 클라우드, 3-2-1 구성을 모두 갖춘 백업이라 해도, 복원되지 않으면 그저 비싼 쓰레기일 뿐입니다.
🕑 마지막 팁: 백업 작업은 새벽 2시나 3시를 피해서 예약하세요. 서머타임 전환 때 그 시간대는 건너뛰거나 두 번 실행될 수 있습니다.
오늘의 체크리스트
- [ ] 내 데이터의 RPO는 얼마인가?
- [ ] 스냅샷(과거 상태)이 있는가, 아니면 미러(현재 복제본)뿐인가?
- [ ] 사본이 서로 다른 매체 2종에 있는가? 외부 장소에 1개가 있는가?
- [ ] DB는 파일 복사가 아니라 덤프로 백업하고 있는가?
- [ ] 마지막으로 복원을 테스트한 게 언제인가?