워드프레스 백업을 DB만 받아두는 경우가 많습니다. 글이 DB에 있으니 맞는 말인데, 그것만으로는 복원이 안 됩니다.
백업 스크립트를 짜면서 빠뜨리면 복원이 막히는 것이 뭔지 정리했습니다.
결론부터 — 세 덩어리가 필요합니다
| # | 대상 | 없으면 |
|---|---|---|
| 1 | DB 덤프 | 글·설정·사용자가 전부 사라진다 |
| 2 | 업로드 파일 (wp-content/uploads/) |
글은 살아나는데 이미지가 전부 깨진다 |
| 3 | 설정 파일 (.env, wp-config.php) |
DB 비밀번호를 몰라 접속 자체가 안 된다 |
3번을 빠뜨리기 쉽습니다. 저도 처음 스크립트에 안 넣었습니다.
3번이 왜 치명적인가
DB를 복원하면 그 안의 사용자 계정과 비밀번호도 예전 값 그대로 돌아옵니다.
그런데 .env 를 잃으면 그 비밀번호를 모릅니다. 워드프레스가 DB에 접속하지 못합니다.root 비밀번호까지 같이 잃으면 비밀번호를 바꿀 수도 없습니다.
백업을 다 갖고 있는데 복원이 안 되는 상황이 됩니다.
새로 설치하면 되지 않냐 싶지만, 그러면 DB 덤프를 못 넣습니다.
덤프 안의 사용자와 새로 만든 비밀번호가 맞지 않기 때문입니다.
백업 스크립트
Docker Compose 환경 기준입니다.
#!/bin/bash
set -e
cd "$(dirname "$0")"
source .env
D=$(date +%F-%H%M)
# 1) DB 덤프
docker compose exec -T db mariadb-dump -u root -p"$DB_ROOT_PASSWORD" \
--single-transaction "$DB_NAME" | gzip > /backup/db-$D.sql.gz
# 2) 워드프레스 파일 (업로드 이미지 포함)
docker run --rm -v 프로젝트명_wp_data:/data -v /backup:/backup alpine \
tar czf /backup/wp-$D.tar.gz -C /data .
# 3) 설정 — 이게 없으면 복원 불가
tar czf /backup/conf-$D.tar.gz .env docker-compose.yml Caddyfile backup.sh
chmod 600 /backup/conf-$D.tar.gz
find /backup -name "*.gz" -mtime +14 -delete
echo "backup ok: $D"몇 가지 짚을 점이 있습니다.
--single-transaction — 덤프 중에도 사이트가 돌아가게 합니다. 없으면 테이블이 잠겨 그 시간 동안 사이트가 멈춥니다.
볼륨 이름 — 프로젝트명_wp_data 형식입니다. 디렉토리 이름이 프로젝트명이 되므로, 폴더를 옮기거나 이름을 바꾸면 볼륨 이름도 바뀝니다. docker volume ls 로 확인하세요.
chmod 600 — 설정 백업에는 비밀번호가 들어 있습니다. 권한을 막아둡니다.
⚠️ 같은 서버에만 두면 백업이 아닙니다
/backup/db-2026-10-04.sql.gz
/backup/wp-2026-10-04.tar.gz
/backup/conf-2026-10-04.tar.gz서버가 죽으면 이것도 같이 죽습니다. 디스크가 고장 나거나 인스턴스가 날아가면 백업도 사라집니다.
반드시 서버 밖으로 빼야 합니다.
- 클라우드 스냅샷 (제공사 기능)
- S3 등 오브젝트 스토리지로 주기 전송
- 다른 서버나 로컬로
rsync
복원을 한 번은 해보세요
안 해본 백업은 백업이 아닙니다. 실제로 복원해봐야 빠진 게 드러납니다.
# 1) 설정 복원
tar xzf conf-날짜.tar.gz
# 2) 컨테이너 기동 (빈 상태)
docker compose up -d
# 3) DB 복원
zcat db-날짜.sql.gz | docker compose exec -T db \
mariadb -u root -p"$DB_ROOT_PASSWORD" DB이름
# 4) 파일 복원
docker run --rm -v 프로젝트명_wp_data:/data -v $(pwd):/b alpine \
tar xzf /b/wp-날짜.tar.gz -C /data
# 5) 확인
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/순서가 중요합니다. 설정을 먼저 복원해야 DB 비밀번호가 맞습니다.
저는 백업 스크립트를 처음 짤 때 3번을 넣지 않았습니다. DB와 파일만 받으면 된다고 생각했습니다.
나중에 "서버가 통째로 날아가면 이걸로 복원이 되나" 하고 되짚어보다가 알았습니다. DB 비밀번호가 담긴 파일이 백업 어디에도 없었습니다. 백업은 꼬박꼬박 쌓이고 있었는데, 정작 그걸로 복원이 안 되는 상태였습니다.
그때 받아둔 백업이 전부 무용지물이 될 뻔했습니다.
주기와 보관
| 항목 | 기준 |
|---|---|
| 주기 | 글을 자주 쓰면 매일, 아니면 주 1회 |
| 보관 | 2주~1개월. 너무 오래 두면 용량만 |
| 자동화 | 크론 |
0 3 * * * /경로/backup.sh >> /경로/backup.log 2>&1로그를 남기세요. 조용히 실패하는 백업이 가장 위험합니다. 주기적으로 /backup/ 에 파일이 쌓이는지 눈으로 확인하는 것도 필요합니다.
ls -lh /backup/ | tail -5날짜가 끊겨 있으면 그때부터 실패한 겁니다.
정리
- DB·파일·설정 세 덩어리가 다 있어야 복원됩니다
- 설정(
.env)을 빠뜨리면 DB 비밀번호를 몰라 복원이 막힙니다 --single-transaction으로 덤프해야 사이트가 안 멈춥니다- 같은 서버에만 둔 백업은 백업이 아닙니다. 밖으로 빼세요
- 복원을 한 번은 실제로 해보세요. 안 해봤으면 모르는 겁니다
- 조용히 실패하지 않게 로그를 남기고 주기적으로 확인하세요