1. SPOF 진단 — df로 드러난 진실

“외부 저장소가 있다”는 믿음은 df로 검증해야 한다. 마운트 지점이 어느 물리 디스크에 속하는지 봐야 진짜 분리됐는지 알 수 있다.

df -h /opt/_archive /opt/my-flashcard/data

다행히 이 서버에는 NAS가 NFS4로 마운트돼 있었다. 별도 물리 장비(11.11.11.1)의 3.5T 볼륨이고 서버 LVM과 완전히 분리돼 있다 — 진짜 외부 백업이 가능하다. NFS4라 하드링크도 지원해 증분 백업까지 된다.

mount | grep -E "cifs|nfs"
touch /mnt/docker/flashcard-backup/_write_test \
  && echo "쓰기 OK" && rm /mnt/docker/flashcard-backup/_write_test \
  || echo "쓰기 실패 - NFS 권한 문제"

2. WAL 모드 함정 — DB를 그냥 복사하면 안 된다

이 앱의 SQLite는 성능을 위해 WAL(Write-Ahead Logging) 모드를 쓴다. WAL 모드에서는 라이브 .db 파일을 단순 파일 복사하면 위험하다. 커밋되지 않은 트랜잭션이 별도 -wal 파일에 있을 수 있어, 복사한 시점에 따라 일관성이 깨진 DB를 백업하게 된다.

docker compose exec -T flashcard-app python3 -c \
"import sqlite3; \
 s=sqlite3.connect('/app/data/flashcards.db'); \
 d=sqlite3.connect('/app/data/_backup_snapshot.db'); \
 s.backup(d); d.close(); s.close(); print('snapshot ok')"

3. NFS 마운트의 숨은 사고

NFS/SMB 기반 백업에서 가장 위험한 시나리오는 따로 있다. NAS가 꺼지거나 네트워크가 끊기면 마운트가 조용히 풀린다. 그 상태에서 백업 스크립트가 돌면 — 마운트 지점인 로컬 디렉토리에 데이터를 그대로 쏟아붓는다. 외부 백업은 0건인데 로컬 디스크만 차오르는 최악의 상황이다.

if ! mountpoint -q /mnt/docker; then
    echo "ERROR: /mnt/docker NFS 미마운트 — 백업 중단"
    exit 1
fi

4. 완성된 백업 스크립트

앞의 모든 디테일(마운트 가드 + WAL 안전 스냅샷 + 하드링크 증분 + 세대 관리)을 하나로 합친다.

#!/bin/bash
set -euo pipefail
# cron 환경 대비 PATH 명시 (5장에서 설명)
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

APP_DIR=/opt/my-flashcard
NAS_PATH=/mnt/docker/flashcard-backup
DATE=$(date +%Y%m%d-%H%M)

# 0) NFS 마운트 생존 확인 (로컬 오염 방지)
if ! mountpoint -q /mnt/docker; then
    echo "ERROR: NFS 미마운트 — 백업 중단"; exit 1
fi

# 1) DB WAL-안전 스냅샷 (Python sqlite3.backup)
docker compose -f "$APP_DIR/docker-compose.yml" exec -T flashcard-app \
  python3 -c "import sqlite3; \
  s=sqlite3.connect('/app/data/flashcards.db'); \
  d=sqlite3.connect('/app/data/_backup_snapshot.db'); \
  s.backup(d); d.close(); s.close(); print('snapshot ok')"

# 2) rsync 하드링크 증분 (변경분만 복사)
rsync -a --delete --link-dest="$NAS_PATH/latest" \
  "$APP_DIR/data/" "$NAS_PATH/$DATE/"

# 3) latest 심볼릭 갱신 (다음 증분 기준점)
ln -sfn "$NAS_PATH/$DATE" "$NAS_PATH/latest"

# 4) N세대 초과분 자동 삭제 (쌓임 방지)
ls -1dt "$NAS_PATH"/2* 2>/dev/null | tail -n +15 | xargs -r rm -rf

# 5) 임시 스냅샷 정리
rm -f "$APP_DIR/data/_backup_snapshot.db"
echo "백업 완료: $NAS_PATH/$DATE"

5. 백업의 90% — 복구 검증과 cron 환경

5-1. 복구 검증 — 가장 자주 생략되는 단계

파일이 복사됐다고 백업이 완성된 게 아니다. 그 DB가 실제로 열리고 데이터가 온전한지 확인해야 진짜 백업이다. “복사는 됐는데 복구가 안 되는” 경우가 백업 실패의 대부분이다.

docker run --rm -v /mnt/docker/flashcard-backup/latest:/b python:3.11-slim \
  python3 -c "import sqlite3; c=sqlite3.connect('/b/_backup_snapshot.db'); \
  print('cards:', c.execute('SELECT COUNT(*) FROM cards').fetchone()[0]); \
  print('integrity:', c.execute('PRAGMA integrity_check').fetchone()[0])"

integrity: ok가 나와야 비로소 “복구 가능한 진짜 백업”이라고 말할 수 있다.

5-2. cron 환경은 로그인 셸과 다르다

손으로 돌리면 잘 되던 스크립트가 cron에서 조용히 실패하는 일이 흔하다. 원인은 cron의 PATH가 로그인 셸과 다르다는 것. docker 명령 경로가 cron 환경에 없을 수 있다. 그래서 스크립트 맨 위에 PATH를 명시했고, 등록 전에 cron 환경을 시뮬레이션으로 미리 테스트한다.

env -i /bin/bash /opt/my-flashcard/backup_to_nas.sh \
  && echo "cron환경 OK" || echo "cron환경 실패 - PATH 추가 필요"

(crontab -l 2>/dev/null; \
 echo "0 4 * * 0 /opt/my-flashcard/backup_to_nas.sh >> /var/log/fc-backup.log 2>&1") \
 | crontab -

5-3. 복구 절차 문서화 + 코드도 외부 보존

git clone --bare /opt/my-flashcard /mnt/docker/flashcard-backup/repo.git
# 백업 스크립트에 미러 갱신을 추가하면 코드도 주기적으로 따라온다

6. 전체 작업 총정리

“필요 없는 파일 지우고 싶다”는 한 문장에서 출발해, 프로덕션급 백업/복구 인프라까지 도달했다. 단계별 변화:

셀프호스팅의 진짜 난이도는 “앱을 띄우는 것”이 아니라 “데이터를 잃지 않게 운영하는 것”에 있다. 화려한 기능보다 묵묵한 백업 한 줄이 결국 데이터를 지킨다. 이 시리즈가 비슷한 개인 서버를 굴리는 누군가의 디스크 사고 한 건을 막는다면 충분히 값어치를 했다.