정확히 무엇을 복사해야 할까

저희는 회원님의 머신을 자동으로 백업하지 않아요. 제어판에도 상태 스냅샷이 없고, OS를 재설치하면 디스크가 완전히 지워져요. 즉, 백업은 전적으로 회원님의 책임이며, 손실이 발생한 뒤가 아니라 첫날부터 시작해야 해요.

반드시 백업해야 하는 것

• 애플리케이션 데이터 — Docker 볼륨, 사이트 디렉터리, 사용자가 업로드한 파일.
• 데이터베이스 덤프 — 실행 중인 데이터베이스 파일이 아니라 반드시 덤프여야 해요(아래에서 자세히 설명해요).
• 구성 — /etc/nginx, /etc/caddy, systemd 유닛, compose.yaml과 .env 파일, 방화벽 규칙.
• 인증서와 키 — /etc/letsencrypt, 애플리케이션 키, 메일 서버 DKIM 키.
• 예약 작업 — 백업 전에 crontab -l > /root/crontab.txt를 실행하세요. 그렇지 않으면 스케줄만 빼고 모든 것을 복원하게 돼요.
• 설치된 패키지 목록 — dpkg --get-selections > /root/packages.txt. 몇 킬로바이트로 몇 시간을 절약할 수 있어요.

백업하지 않아도 되는 것

OS, 패키지, Docker 이미지는 재설치하고 명령을 실행하면 복원돼요. 공간과 시간을 들일 가치가 없어요. /proc, /sys, /dev, /var/lib/docker 전체, 캐시 디렉터리, 스왑 파일은 백업하지 마세요.

합리적인 기준은 이래요. 백업에는 인터넷에 없고 지침으로 재현할 수 없는 모든 것이 들어가야 해요.

데이터베이스

실행 중인 데이터베이스의 파일을 복사하면 안 돼요. 쓰기 도중의 스냅샷이 만들어져서 열리지 않을 수 있어요. 올바른 방법은 데이터베이스 자체 도구를 사용한 덤프예요.

docker compose exec -T db pg_dump -U postgres app | gzip > /backup/app-$(date +%F).sql.gz
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction app | gzip > /backup/app-$(date +%F).sql.gz
sqlite3 /data/app.db ".backup '/backup/app-$(date +%F).db'"

PostgreSQL과 MySQL은 서비스를 중지할 필요가 없어요. SQLite는 cp가 아니라 .backup을 사용하세요. 실행 중에 파일을 복사하면 손상된 데이터베이스가 만들어져요.

한 번도 복원해 본 적 없는 백업은 백업이 아니에요. 빈 머신이나 별도 컨테이너에서 테스트하세요 — 복원 훈련을 참고하세요.

완전한 세트의 예시

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

docker compose -f /opt/myapp/compose.yaml exec -T db pg_dump -U postgres app | gzip > "$DEST/db.sql.gz"
tar czf "$DEST/etc.tar.gz" /etc/nginx /etc/letsencrypt /opt/myapp/compose.yaml /opt/myapp/.env
tar czf "$DEST/uploads.tar.gz" /var/www/uploads
crontab -l > "$DEST/crontab.txt"
dpkg --get-selections > "$DEST/packages.txt"

스크립트를 /usr/local/bin/backup.sh에 넣고 chmod 700 권한을 부여한 뒤 스케줄에 추가하세요. 그런 다음 백업을 다른 위치로 보내야 해요. 데이터 옆에 있는 파일은 아무것도 보호해 주지 않아요.

얼마나 보관할까

간단히 정리한 “3-2-1” 규칙은 이래요. 최소 두 개의 복사본, 그중 최소 하나는 이 머신 밖에 있어야 해요. 보관 기간은 일간 7개, 주간 4개, 월간 3개면 충분해요. 바로 알아차리지 못한 조용한 장애 이전 상태로 되돌리기에 충분해요.

공간을 미리 계획하세요. VDS-1은 디스크가 40 GB뿐이라 백업 이력을 저장할 공간이 전혀 없어요 — 디스크 공간을 참고하세요.

흔한 실수

• 백업이 같은 머신에 있어요. 재설치, 접근 권한 상실, rm -rf 실수 — 그러면 백업이 데이터와 함께 사라져요.
• .env를 잊었어요. 데이터는 있는데 그 데이터의 비밀번호와 키를 잃어버렸어요.
• 실행 중인 데이터베이스 볼륨을 복사했어요. 손상된 파일 때문에 복원이 실패해요. 덤프만 사용하세요.
• 백업이 중단된 걸 아무도 몰라요. Uptime Kuma에 푸시 검사를 설정하세요. 스크립트가 성공 후 주소로 핑을 보내고, 하루 동안 조용하면 알림이 울려요.