홈서버에 데이터가 모이기 시작하면 어느 순간 서늘한 질문이 떠오른다. “이 디스크가 내일 죽으면 어떻게 되지?” 그 질문에 “괜찮다”고 답할 수 있게 해주는 것이 백업 전략이고, 업계에서 수십 년 검증된 기준선이 3-2-1 규칙이다 (배경 설명: Backblaze의 3-2-1 전략 해설).
세 숫자의 의미
- 3 — 데이터 사본 3개: 원본 1 + 백업 2. 백업이 하나뿐이면 “원본이 죽은 순간부터 복구가 끝날 때까지” 사본이 하나뿐인 무방비 구간이 생긴다.
- 2 — 서로 다른 저장 매체 2종: 같은 모델 디스크 두 개는 같은 시기에 함께 죽을 수 있다(같은 생산 로트, 같은 사용 패턴). 내장 SSD와 외장 HDD처럼 종류를 섞는다.
- 1 — 오프사이트(집 밖) 1개: 화재·침수·도난·낙뢰는 집 안의 모든 사본을 한 번에 가져간다. 한 부는 반드시 물리적으로 다른 장소에 둔다.
흔한 착각: RAID는 백업이 아니다
NAS의 RAID(미러링)를 백업으로 여기는 경우가 많은데, RAID가 막아주는 것은 디스크 하드웨어 고장 하나뿐이다. 실수로 파일을 지우면? 두 디스크에서 동시에 지워진다. 랜섬웨어에 감염되면? 두 디스크가 동시에 암호화된다. RAID는 가용성(서비스가 멈추지 않음)의 도구이고, 백업은 시점 복원(어제의 파일로 돌아감)의 도구다. 역할이 다르므로 서로를 대체할 수 없다.
홈서버 현실 적용
원칙을 그대로 옮기면 이렇게 된다.
| 사본 | 위치 | 방법 |
|---|---|---|
| 1 (원본) | 서버 내장 디스크 | 운영 데이터 그 자체 |
| 2 (로컬 백업) | 같은 집의 NAS 또는 백업 전용 HDD | 매일 자동 동기화 + 스냅샷 |
| 3 (오프사이트) | 클라우드 스토리지, 가족 집 장비 | 주기적 암호화 백업 |
사본 2는 자동화가 생명이다. 손으로 하는 백업은 반드시 끊긴다. cron에 건 rsync 스크립트면 충분하고, 버전 보관(어제·그제 상태로 복원)까지 갖추는 방법은 rsync + hardlink 스냅샷 글에서 단계별로 다룬다.
사본 3은 비용과의 타협이다. 전체 데이터를 다 올릴 필요는 없다. “잃으면 안 되는 것”의 우선순위를 매기고 — 가족 사진 > 문서 > 서비스 설정 > 미디어 파일 순이 보통이다 — 상위 항목만 클라우드에 암호화해서 올리는 것이 현실적인 출발점이다. 미디어 파일처럼 다시 구할 수 있는 데이터는 오프사이트 대상에서 빼면 비용이 크게 줄어든다.
참고로 내 구성을 그대로 적으면: 원본은 서버 내장 NVMe, 2차 사본은 USB로 물린 4TB HDD에 매일 1회 하드링크 스냅샷(30일 보관), 여기에 NAS로 주 1회 별도 백업이 한 번 더 돈다. 사본 3개·매체 혼합까지는 충족인데, 솔직히 “1(오프사이트)“이 아직 숙제다 — 잃으면 안 되는 폴더부터 클라우드 암호화 백업으로 채우는 것이 다음 단계로 남아 있다. 한 가지 잘했다고 생각하는 것은 백업 결과를 매번 텔레그램으로 보고받게 만든 것이다. 보고에 스냅샷 개수가 찍히니, 어느 날 그 숫자가 줄어 있으면 백업이 조용히 죽었다는 뜻임을 바로 알 수 있다.
얼마나 자주, 얼마나 오래 — 두 개의 숫자
전략에는 두 숫자가 더 필요하다. 백업 주기(얼마나 자주)와 보관 기간(얼마나 오래)이다.
주기는 “이 데이터를 며칠치까지 잃어도 견딜 수 있는가”로 정한다. 매일 바뀌는 서비스 데이터라면 일 1회가 하한선이고, 일주일에 한 번 추가되는 아카이브라면 주 1회로 충분하다. 보관 기간은 “문제를 며칠 만에 알아차리는가”에 달려 있다. 실수로 지운 파일을 당일에 알아차리면 어제 백업이면 되지만, 한 달 뒤에 알아차리는 경우도 흔하다 — 그래서 일별 스냅샷을 30일치 보관하는 구성이 홈서버의 무난한 기본값이 된다.
랜섬웨어 관점에서 한 가지 더. 서버에 상시 마운트된 백업 디스크는 서버가 감염되면 함께 암호화될 수 있다. 보관 기간이 길다는 것 자체가 1차 방어(감염 전 시점으로 복원)가 되고, 오프사이트 사본을 서버에서 직접 쓸 수 없는 형태(클라우드의 버전 관리 기능 등)로 두면 방어가 한 겹 더 생긴다.
백업 대상 목록부터 만들자
전략보다 먼저 필요한 것이 “무엇을 백업할지”의 목록이다. 홈서버에서 빠뜨리기 쉬운 항목까지 포함해 점검하자.
- 개인 데이터 (사진, 문서)
- 각 서비스의 데이터 폴더 (컴포즈 폴더 구조를 따랐다면 서비스 폴더 그 자체)
- 서비스 설정 파일 (compose yml, .env, 프록시 설정)
- 크론탭·자동화 스크립트
- 인증서·키 (SSH 키, VPN 키)
마지막으로 백업의 완성 조건 하나. 복원해본 적 없는 백업은 백업이 아니다. 백업 스크립트는 성공 로그를 남기면서도 정작 빈 폴더를 백업하고 있을 수 있고, 디스크는 꽂혀 있지만 마운트가 풀려 있을 수도 있다. 분기에 한 번이라도 파일 몇 개를 실제로 꺼내 열어보는 복원 리허설까지가 3-2-1의 마침표다. 백업 실패를 그날 알아차리게 해주는 감시 장치는 텔레그램 알림 글에서 다룬다.