Docker 볼륨을 백업하고 복원하는 운영 절차
woosday의 글과 발표자료는 Docker 이미지에 포함되지만, Support 자료와 Debug 자료와 방문자 통계는 컨테이너 밖의 볼륨에 저장한다. 이 둘을 구분하지 않으면 새 이미지를 배포할 때 운영 자료가 사라질 수 있다. 컨테이너를 다시 만드는 것과 데이터를 백업하는 것은 별개의 작업이다.
무엇을 백업하는가
현재 운영 데이터는 세 개의 볼륨으로 나뉜다.
woosday_support-data Support 자료
woosday_error-data Debug 자료
woosday_analytics-data 익명 방문자 통계
세 볼륨은 애플리케이션 컨테이너를 삭제하거나 새 이미지로 교체해도 남는다. 그렇다고 디스크 고장과 실수로 인한 삭제까지 막아 주는 것은 아니다. Docker 볼륨을 같은 PC 안에 복사하는 것만으로는 충분한 백업이라고 보기 어렵다.
tar 파일로 내보내기
운영 서버에서 백업 디렉터리를 만들고, 임시 Alpine 컨테이너를 읽기 전용으로 연결해 압축한다.
$backupDir = Join-Path (Get-Location) 'backups'
New-Item -ItemType Directory -Force -Path $backupDir
docker run --rm --mount type=volume,source=woosday_support-data,target=/source,readonly --mount "type=bind,source=$backupDir,target=/backup" alpine:3.22 sh -c 'tar -czf /backup/support.tar.gz -C /source .'
docker run --rm --mount type=volume,source=woosday_error-data,target=/source,readonly --mount "type=bind,source=$backupDir,target=/backup" alpine:3.22 sh -c 'tar -czf /backup/errors.tar.gz -C /source .'
docker run --rm --mount type=volume,source=woosday_analytics-data,target=/source,readonly --mount "type=bind,source=$backupDir,target=/backup" alpine:3.22 sh -c 'tar -czf /backup/analytics.tar.gz -C /source .'
백업 파일에는 고객사 자료나 내부 오류 기록이 포함될 수 있으므로 공개 저장소에 올리지 않는다. 외부 저장소로 옮길 때는 암호화하고, 파일명만 보고 어떤 데이터인지 드러나지 않게 관리한다.
복원은 별도 볼륨에서 먼저 시험한다
복원 명령을 운영 볼륨에 바로 실행하면 정상 데이터를 덮어쓸 수 있다. 먼저 테스트용 볼륨을 만들고 백업을 풀어 파일 목록과 애플리케이션 화면을 확인한다.
docker volume create woosday_restore-test
docker run --rm --mount type=volume,source=woosday_restore-test,target=/restore --mount "type=bind,source=$backupDir,target=/backup,readonly" alpine:3.22 sh -c 'tar -xzf /backup/support.tar.gz -C /restore'
docker run --rm --mount type=volume,source=woosday_restore-test,target=/restore alpine:3.22 find /restore -maxdepth 2 -type f
파일이 존재하는 것만으로 복원이 끝난 것은 아니다. Markdown front matter가 정상적으로 읽히는지, 한글이 깨지지 않는지, 날짜별 통계 파일이 관리자 화면에서 열리는지 확인한다. 테스트가 끝난 뒤에는 테스트 볼륨을 삭제해 혼동을 막는다.
테스트 검증을 마치면 아래처럼 이름을 확인한 테스트 볼륨만 제거한다.
docker volume rm woosday_restore-test
백업 주기와 보존
개인 사이트라도 최소한 배포 전과 큰 자료 수정 후에는 백업을 만든다. 방문자 통계처럼 매일 바뀌는 데이터는 주기적으로 복사하되, 모든 날의 파일을 영원히 보관할 필요가 있는지는 운영 목적과 개인정보 정책을 함께 보고 정한다.
백업 성공 여부를 파일 생성만으로 판단하지 않는다. 압축 파일 크기가 0이 아닌지, tar -tzf로 목록을 읽을 수 있는지, 최근 복원 테스트가 언제였는지 기록한다. 복원 절차를 한 번도 실행하지 않은 백업은 아직 검증되지 않은 파일이다.
PC 기반 운영의 한계
현재 원본 서버가 개인 PC이므로 PC가 꺼지면 사이트와 백업 작업도 중단된다. 외부 저장소에 백업을 복사하는 단계만큼은 다른 장치나 클라우드 스토리지에 두는 것이 안전하다. 백업 파일을 같은 디스크의 다른 폴더에 복사하는 것은 실수 복구에는 도움이 되지만 디스크 고장에는 대응하지 못한다.
운영 규모가 커져 데이터 변경이 잦아지면 DB와 전용 백업 도구를 검토할 수 있다. 지금은 저장 데이터를 세 볼륨으로 분리하고, 복사와 복원 명령을 문서화해 사람이 다시 실행할 수 있게 한 것이 핵심이다.
함께 읽기: