“백업은 매일 하고 있어요.” 그런데 사고가 나면 절반은 복구 못 합니다. 백업이 같은 디스크에 있었거나, 한 번도 복원 테스트를 안 했거나, 백업 파일이 손상됐거나. 이 글은 업계 표준인 3-2-1 규칙과 실전 적용 방법을 정리합니다.
3-2-1 규칙 — 한 줄 정의
- 3 개의 사본: 원본 + 복사본 2개
- 2 종류의 매체: SSD/HDD/테이프/오브젝트 스토리지 등 서로 다른 매체
- 1 개는 오프사이트: 물리적으로 다른 위치에
세 항목 중 하나라도 빠지면 진짜 백업이 아닙니다. 이유는 각 항목이 막는 사고가 다르기 때문입니다.
각 숫자가 막는 사고
“3 사본”이 막는 사고
원본이 사라져도 사본이 남아 있으면 복구 가능합니다. 사본이 1개뿐이면, 사본도 동시에 망가지는 사고(예: 정전 중 디스크 손상)에 무방비입니다.
“2 매체”가 막는 사고
같은 매체(예: 둘 다 SSD)는 같은 결함을 공유할 수 있습니다.
- 같은 펌웨어 버그
- 같은 제조사 결함
- 같은 PSU 고장으로 동시에 사망
SSD + HDD, 또는 SSD + 오브젝트 스토리지처럼 다른 매체로 분산하면 동시 사고 확률이 낮아집니다.
“1 오프사이트”가 막는 사고
같은 데이터센터에 있는 백업은 다음 사고에 무력합니다.
- 화재
- 자연재해 (지진·홍수)
- 데이터센터 전체 정전
- 랜섬웨어가 네트워크로 백업까지 암호화
- 침입자가 모든 시스템 삭제
다른 지역(IDC) 또는 클라우드에 최소 1개를 두어야 진짜 안전합니다.
잘못된 “백업”의 사례
다음은 백업이라고 부르지만 실제로는 위험한 사례들입니다.
| 사례 | 문제점 |
|---|---|
| 같은 서버 다른 디렉토리에 복사 | 디스크 자체가 죽으면 함께 사라짐 |
| RAID 1로 미러링하니까 OK | RAID는 가용성 도구지 백업이 아님 (실수 삭제는 복제됨) |
| Dropbox 동기화 | 원본 삭제 시 백업도 삭제됨 (버전이 있어도 짧음) |
| Git에 코드 push | 코드는 OK, 그런데 DB·업로드 파일은? |
| 매월 한 번 스크립트 실행 | 사고는 매월 한 번 일어나지 않음 — RPO 너무 큼 |
| 백업하지만 복원 테스트 없음 | 막상 복구 시도하면 파일 깨져 있음 |
RPO와 RTO 개념
백업 설계 전에 두 가지를 정해야 합니다.
- RPO (Recovery Point Objective): “어느 시점까지 데이터를 잃어도 괜찮은가”
- RTO (Recovery Time Objective): “복구에 최대 얼마나 걸려도 괜찮은가”
| 서비스 유형 | RPO | RTO |
|---|---|---|
| 정적 사이트 | 24시간 | 수 시간 |
| 일반 워드프레스 | 6~12시간 | 1~3시간 |
| 쇼핑몰 | 5분~1시간 | 30분 |
| 결제·은행 | < 1초 | < 1분 |
RPO가 짧을수록 백업 주기를 자주, RTO가 짧을수록 복구 절차를 미리 자동화해야 합니다.
실전 적용 — 일반 호스팅
백업할 것
- DB — 가장 중요. mysqldump, pg_dump, 또는 binlog 기반
- 업로드 파일 —
/uploads,/storage등 - 설정 파일 —
/etc/nginx,wp-config.php등 - 인증서 —
/etc/letsencrypt - (선택) 전체 OS — 이미지 스냅샷
실전 cron 예시 — 매일 새벽 4시 백업
#!/bin/bash
# /usr/local/bin/daily-backup.sh
set -euo pipefail
DATE=$(date +%F)
BACKUP_DIR=/backup/$DATE
mkdir -p $BACKUP_DIR
# 1. DB
mysqldump -uwp_user -p'PASS' wp_db | gzip > $BACKUP_DIR/db.sql.gz
# 2. 업로드 파일
tar -czf $BACKUP_DIR/files.tar.gz /var/www/example.com/wp-content/uploads
# 3. 설정
tar -czf $BACKUP_DIR/etc.tar.gz /etc/nginx /etc/letsencrypt
# 4. 14일 이상된 로컬 백업 정리
find /backup -maxdepth 1 -mtime +14 -type d -exec rm -rf {} \;
# 5. 외부 위치 동기화 (오프사이트)
aws s3 sync /backup s3://my-backup-bucket --delete
# 또는 rsync로 다른 서버로
# rsync -avz /backup remote-host:/backup
crontab -e
# 매일 04:00 실행
0 4 * * * /usr/local/bin/daily-backup.sh >> /var/log/backup.log 2>&1
3-2-1 매핑
- 3 사본: 원본(운영) + 로컬 디스크 백업 + 외부(S3/원격) 백업
- 2 매체: 운영 SSD + 백업 SSD + 오브젝트 스토리지(다른 매체)
- 1 오프사이트: S3·MinIO·다른 IDC의 서버
백업 종류 — Full / Incremental / Differential
Full (전체)
- 매번 전체 복사
- 단순, 복원 빠름
- 용량·시간 큼
- DB는 보통 매일 Full
Incremental (증분)
- 마지막 백업 이후 변경분만
- 빠르고 작음
- 복원에 여러 백업이 필요 → 복원 느림
- 파일은 보통 증분 (rsync 등)
Differential (차등)
- 마지막 전체 백업 이후 변경분
- Full + 차등 1개로 복원
- 중간 단계 (Full보다 작고, 증분보다 복원 빠름)
조합 예시:
- DB: 매일 Full + 1시간마다 binlog (point-in-time recovery)
- 파일: 주간 Full + 매일 증분
- OS 이미지: 월간 스냅샷
백업의 가장 큰 함정 — “복원 테스트 안 하기”
백업 자체는 잘 되는데 막상 복원하니 실패하는 경우가 매우 흔합니다. 원인:
- 백업 파일이 점진적으로 손상 (bit rot)
- 백업 스크립트가 한참 전부터 silently 실패 중
- 복원 절차를 아무도 모름
- 새 환경에서 호환 안 되는 형식
복원 테스트 주기
| 백업 종류 | 권장 테스트 주기 |
|---|---|
| DB 백업 | 매월 1회 |
| 파일 백업 | 분기 1회 |
| 전체 OS 복구 | 반기 1회 |
| DR(재해 복구) 시나리오 | 연 1회 |
테스트는 단순합니다. 새 서버에 백업을 복원해 정상 동작하는지 확인하면 됩니다. DR 훈련처럼 시간을 측정해 RTO를 검증하는 게 이상적입니다.
백업 보관 기간 (Retention)
오래된 백업도 의미가 있습니다. 사고가 즉시 발견 안 될 수 있기 때문입니다.
권장 보관 정책 (GFS — Grandfather-Father-Son):
- 일간 백업: 7~30일
- 주간 백업: 4~8주
- 월간 백업: 6~12개월
- 연간 백업: 3~7년 (법적 보관 요구사항이 있으면 그에 맞춰)
오늘부터:
1, 2, 3 ... 30일 (일간 30개)
4주 전, 8주 전 (주간 2개 추가)
6개월 전, 12개월 전 (월간)
백업 암호화
오프사이트로 보내는 백업은 반드시 암호화해야 합니다. 클라우드 측 키가 아닌 클라이언트 측 키로 암호화하면 보안이 더 강합니다.
# tar 후 GPG로 암호화
tar -czf - /data | gpg --symmetric --cipher-algo AES256 \
--passphrase-file /etc/backup-pass --batch \
-o backup.tar.gz.gpg
키는 절대 백업 대상 서버에 두지 마세요. 분실 시 복구도 못 합니다.
클라우드 백업 옵션
| 서비스 | 가격대 (1TB·월) | 특징 |
|---|---|---|
| S3 Standard | ~$25 | 즉시 접근, 가장 비쌈 |
| S3 IA | ~$15 | 접근 시 추가 비용 |
| S3 Glacier | ~$5 | 대기시간 3~5시간 |
| Backblaze B2 | ~$5 | S3 호환, 저렴 |
| Wasabi | ~$7 | 송신 무료 |
| 자체 MinIO | 하드웨어 비용만 | 완전 제어 |
장기 보관은 Glacier·B2가 매우 저렴합니다. 자주 접근하는 최근 백업은 Standard·MinIO, 오래된 건 콜드 스토리지로 옮기는 계층화가 일반적입니다.
마무리
3-2-1은 50년 가까이 살아남은 규칙입니다. 클라우드·SaaS 시대라고 사라진 게 아니라, 형태만 바꿔서 여전히 유효합니다.
가장 중요한 마음가짐 한 가지: 백업의 성공은 복원의 성공으로만 증명됩니다. 백업 시스템을 만들었다면 첫 달 안에 반드시 복원 테스트를 한 번 해보세요.
TCP-80.NET의 전용서버는 동일 IDC 내 자동 백업이 기본 포함되며, 오프사이트 백업 구성도 @tcp80net에서 가이드해 드립니다.