SQLite는 데이터베이스가 파일 하나처럼 보이지만, 실행 중인 파일을 무조건 복사하면 일관된 백업이 된다고 보장할 수 없습니다. 특히 WAL 모드에서는 -wal, -shm 파일이 함께 사용될 수 있습니다. 서비스 중인 DB는 SQLite가 제공하는 온라인 백업 기능을 사용하고, 백업 성공과 복구 가능성을 별도로 검증해야 합니다.
[목차]
상황별 백업 방법
| 상황 | 권장 방법 |
|---|---|
| 앱이 DB를 사용 중 | .backup 또는 Online Backup API |
| 압축된 새 복사본 필요 | VACUUM INTO |
| 앱을 완전히 종료함 | DB와 관련 파일 상태를 확인한 뒤 파일 복사 가능 |
| 손상 DB에서 최대한 추출 | .recover 검토, 원본 보존 필수 |
sqlite3 CLI로 온라인 백업
mkdir -p backups
chmod 700 backups
sqlite3 app.db ".backup 'backups/app-20260827.db'"
sqlite3 backups/app-20260827.db "PRAGMA integrity_check;"
integrity_check 결과가 ok인지 확인합니다. 백업 파일의 존재와 크기만 확인해서는 충분하지 않습니다.
자동화 스크립트 예제
#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
db="/srv/app/app.db"
backup_dir="/srv/backups/sqlite"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"
tmp="$backup_dir/.app-$stamp.tmp"
dest="$backup_dir/app-$stamp.db"
mkdir -p "$backup_dir"
trap 'rm -f "$tmp"' EXIT
sqlite3 "$db" ".backup '$tmp'"
test "$(sqlite3 "$tmp" 'PRAGMA integrity_check;')" = "ok"
mv "$tmp" "$dest"
trap - EXIT
# 30일보다 오래된 백업만 삭제
find "$backup_dir" -type f -name 'app-*.db' -mtime +30 -delete
printf 'backup complete: %s\n' "$dest"
스크립트를 실제 서비스에 적용하기 전에 경로에 작은따옴표 같은 특수문자가 없는지 확인하고, 백업 저장소의 남은 용량과 실행 로그를 모니터링하세요.
VACUUM INTO를 사용하는 경우
sqlite3 app.db "VACUUM INTO 'backups/app-compact.db';"
VACUUM INTO는 사용하지 않는 공간을 제거한 새 파일을 만듭니다. 대상 파일이 이미 존재하면 실패하므로 자동화에서는 임시 이름을 사용합니다. 인메모리 DB 복사나 증분 백업 용도는 아닙니다.
복구는 원본을 덮어쓰기 전에 시험합니다
cp backups/app-20260827.db restore-test.db
sqlite3 restore-test.db "PRAGMA integrity_check;"
sqlite3 restore-test.db ".tables"
- 애플리케이션을 중지합니다.
- 현재 DB 파일과 WAL 관련 파일을 별도 위치에 보존합니다.
- 백업을 다른 이름으로 복원해 무결성과 핵심 테이블을 확인합니다.
- 검증이 끝난 뒤에만 운영 경로로 교체하고 권한을 확인합니다.
백업과 같은 디스크에만 사본을 두면 디스크 고장이나 랜섬웨어에 함께 영향을 받을 수 있습니다. 별도 장치 또는 버전 관리가 가능한 원격 저장소에도 복제하고 정기적으로 복구 테스트를 해야 합니다.
공식 참고자료
관련 글
내용 검토 및 업데이트: 2026년 8월 27일
