웹사이트 공개 14편: 백업·복구와 안전한 업데이트
웹사이트 공개 실습 14/14 · 가상 프로젝트 작은 작업실 기준입니다.
example.com은 설명용 예약 도메인이며 실제 연결에는 본인 소유 도메인을 사용합니다.
이번 편의 목표
파일이 있다는 것뿐 아니라 복구 가능한지 확인합니다. 이 예제의 저장 데이터는 data/notes.json이며 SQLite나 회원 DB가 아닙니다. 다른 앱의 DB 백업 명령으로 그대로 사용하지 않습니다.
백업 만들기
예제 사이트의 글 목록을 한 번 연 뒤 프로젝트 터미널에서 실행합니다.
docker compose -f compose.yaml -f compose.tunnel.yaml exec web node scripts/backup.mjs
docker compose -f compose.yaml -f compose.tunnel.yaml exec web node scripts/backup.mjs --list
첫 명령은 시각이 들어간 JSON 파일 이름을 출력하고, 두 번째는 보관 목록을 표시합니다. site-backups 볼륨에 저장되므로 컨테이너를 교체해도 유지되지만, 같은 실행 환경 안의 볼륨만으로 장비·디스크 장애까지 대비한 것은 아닙니다. 중요한 백업은 접근을 제한한 다른 저장소에도 복사합니다. .env나 인증 파일은 공개 ZIP과 분리해 보호합니다.
먼저 복구를 시험하기
아래 복구는 현재 데이터를 덮어씁니다. 운영 데이터가 아닌 가상의 실습 데이터에서 먼저 검증합니다. BACKUP_FILENAME.json은 --list에 나온 실제 이름으로 바꿉니다.
docker compose -f compose.yaml -f compose.tunnel.yaml stop web
docker compose -f compose.yaml -f compose.tunnel.yaml run --rm --no-deps web node scripts/restore.mjs BACKUP_FILENAME.json --confirm-restore
docker compose -f compose.yaml -f compose.tunnel.yaml start web
브라우저에서 글 목록·상세를 열어 백업 시점의 제목과 본문을 비교합니다. 복구에 실패했다면 성공한 것으로 처리하지 말고 서비스를 다시 공개하기 전에 원인을 확인합니다. 백업 스크립트가 출력한 실제 파일 이름을 그대로 사용해야 합니다.
업데이트할 때의 순서
- 개발 환경에서 코드를 수정하고 4101 화면으로 확인합니다.
- 링크·로그인·데이터·모바일 동작 중 변경에 해당하는 항목을 시험합니다.
- 검토 결과와 바뀌는 내용을 확인받고 배포할 버전을 정합니다.
- 운영 데이터를 백업하고 현재 실행 버전도 기록합니다. 되돌릴 소스나 이미지가 없다면 실패 후 원상복구가 어렵습니다.
- 공개 환경의 두 Compose 파일을 함께 사용해
up -d --build로 반영합니다. - 대표 도메인·주요 화면·로그인·Tunnel 상태를 다시 확인합니다. 앱 코드의 복귀와 데이터 복구는 서로 다른 작업입니다.
자주 막히는 지점
코드 폴더만 복사하면 백업인가요? 소스·볼륨 데이터·인증 설정은 별개입니다. 무엇을 복구할 수 있는지 구분해야 합니다.
새 이미지로 바꿨는데 글은 이전 내용이에요. 볼륨 데이터가 이미지의 초기값과 별도로 유지되기 때문입니다. 기존 글을 바꿀 목적으로 볼륨을 삭제하지 않습니다.
개발 컨테이너에서 운영 데이터를 복구해도 되나요? 실제 회원정보를 개발로 복사하지 않습니다. 익명·가상 데이터로 복구 절차를 시험합니다.
완료 기준과 검증
가상 기록에 대해 백업 생성, 컨테이너 재생성 후 데이터 유지, 백업 복구 후 원문 회복을 Node 24 Docker 환경에서 확인했습니다. 이 스크립트는 수동 백업이며 자동 주기 실행·보관 개수 제한을 제공하지 않습니다. 실제 서비스는 데이터 종류·저장량·삭제 정책에 맞는 백업 운영을 추가로 설계합니다.
공식 자료 확인: 2026-11-15. Docker 볼륨 백업·복구 공식 문서(영문), Compose 다중 파일 공식 문서(영문).