빠른 흐름
docker compose stop db
docker run --rm -v app_pgdata:/data -v "$PWD":/backup alpine tar czf /backup/pgdata.tgz -C /data .
docker volume create app_pgdata_restore
docker run --rm -v app_pgdata_restore:/data -v "$PWD":/backup alpine tar xzf /backup/pgdata.tgz -C /data
docker run --rm -v app_pgdata_restore:/data alpine ls -la /data백업과 복구 흐름
volume은 컨테이너보다 오래 살아남는 데이터 저장소다
Named volume은 컨테이너를 삭제해도 남습니다. 그래서 DB 데이터, 업로드 파일, 캐시처럼 컨테이너 lifecycle과 분리해야 하는 데이터를 보관할 수 있습니다. 반대로 이 특성 때문에 docker rm으로 컨테이너를 지웠다고 데이터가 정리되었다고 보면 안 됩니다.
docker volume ls
docker volume inspect app_pgdata백업 대상은 컨테이너 이름이 아니라 volume 이름입니다. Compose를 쓰면 project name이 volume 이름 앞에 붙을 수 있으므로 실제 이름은 docker volume ls로 확인해야 합니다.
백업 전에는 쓰기 프로세스를 멈춘다
파일이 계속 바뀌는 상태에서 tar를 뜨면 백업 안의 파일 간 시점이 어긋날 수 있습니다. 특히 PostgreSQL, MySQL, SQLite 같은 데이터 저장소는 단순 파일 복사만으로 일관성이 보장되지 않을 수 있습니다. 먼저 서비스를 멈추거나, DB 자체 백업 도구로 논리 백업을 만든 뒤 volume 백업을 보조로 사용합니다.
docker compose stop db
docker run --rm \
-v app_pgdata:/data \
-v "$PWD":/backup \
alpine \
tar czf /backup/pgdata.tgz -C /data .운영에서는 백업 파일 생성 후 파일 크기, checksum, 복구 테스트까지 확인해야 백업이 실제로 쓸 수 있는 상태인지 판단할 수 있습니다.
복구는 새 volume에 먼저 풀고 검증한다
기존 volume에 바로 덮어쓰면 실패했을 때 원본과 복구본이 함께 망가질 수 있습니다. 새 volume을 만든 뒤 백업을 풀고, 컨테이너를 그 volume에 붙여서 기동 테스트를 하는 편이 안전합니다.
docker volume create app_pgdata_restore
docker run --rm \
-v app_pgdata_restore:/data \
-v "$PWD":/backup \
alpine \
tar xzf /backup/pgdata.tgz -C /data
docker run --rm -v app_pgdata_restore:/data alpine find /data -maxdepth 2 -type f | headCompose 환경에서는 compose.yaml의 volume 이름을 임시로 바꾸거나 override 파일로 새 volume을 연결해 복구 검증을 분리할 수 있습니다.
백업 파일은 Docker 밖의 보관 정책이 필요하다
volume을 tar로 묶어도 백업 파일이 같은 호스트의 같은 디스크에만 있으면 디스크 장애나 실수 삭제에 같이 영향을 받습니다. 백업 파일은 호스트 밖 스토리지, 접근 권한, 암호화, 보존 기간, 복구 리허설까지 포함해서 관리해야 합니다.
sha256sum pgdata.tgz > pgdata.tgz.sha256개인 개발 환경에서는 단순 tar 백업만으로 충분한 경우가 많지만, 운영 데이터는 애플리케이션별 백업 도구와 Docker volume 백업의 역할을 분리해야 합니다.
체크포인트
| 상황 | 먼저 확인할 것 |
|---|---|
| 실제 volume 이름 확인 | docker volume ls |
| Compose volume 이름 확인 | project prefix 포함 여부 |
| 백업 전 안전 조치 | 쓰기 서비스 중지 또는 DB 백업 도구 사용 |
| 백업 생성 | 임시 컨테이너 + tar |
| 복구 테스트 | 새 volume에 먼저 복원 |
| 장기 보관 | 외부 스토리지, checksum, 권한 관리 |
주의할 점
실행 중인 DB volume을 단순 tar로 복사하면 일관성이 깨질 수 있습니다. 운영 DB는 pg_dump, mysqldump, snapshot, replication 등 데이터베이스가 보장하는 백업 절차를 우선 검토해야 합니다.
docker system prune --volumes나 docker volume prune은 사용 중이지 않은 volume을 삭제할 수 있습니다. 백업을 만들기 전에 정리 명령을 실행하지 말고, 복구 테스트가 끝나기 전까지 원본 volume을 보존해야 합니다.
참고 링크
1 sources