Docker データボリュームのバックアップと移行実践ガイド：3 つの方法を徹底解説

昨年のダブルイレブン（独身の日セール）の時期、会社は Alibaba Cloud から Tencent Cloud へサーバーを移行しました。Docker 内のデータベースデータをどうするかと上司に聞かれたとき——半年以上稼働した PostgreSQL コンテナに数 GB のユーザーデータがあり、一度もバックアップしていませんでした。

その夜、Docker のバックアップ方法を必死に調べ、無数のチュートリアルを読みました。docker cp、tar アーカイブ、docker-volume-backup ツール……見れば見るほど混乱。どれも正しそうに見えるのに、どれを使えばいいのかわからず、本番環境で試す勇気もありません。いちばん怖かったのは、バックアップ中に DB が書き込みを続けて、壊れたバックアップファイルができてしまうことでした。

何度か失敗を経て、ようやくコツが掴めました。Docker のデータバックアップは、そこまで複雑ではありません。大事なのは、方法ごとに向いている場面を知ること。この記事では 3 つの主流バックアップ方法について、いつ使うか、どう使うか、どんな落とし穴があるかを説明します。読み終われば、自分の Docker アプリに信頼できるバックアップを組み立てられます。

なぜ Docker データのバックアップが重要なのか

Docker のデータ保存の仕組み

Docker を使い始めたばかりの人は、データ保存の仕組みをあまり意識しないことが多いです。コンテナを起動すれば動く、データも残っている——一見問題なさそうに見えます。でも、多くの人が見落とす点があります。コンテナ自体は一時的なものです。

データをコンテナ内に直接書くと、再起動やイメージ更新のたびに消えてしまいます。そこで Docker には 2 つの永続化手段があります。

• Volume（ボリューム）：Docker が管理する保存領域で、データは /var/lib/docker/volumes/ に置かれます。公式推奨の方式で、権限やライフサイクルを Docker が面倒を見てくれます。
• Bind Mount（バインドマウント）：ホストのディレクトリをコンテナに直接マウントします。例えば /home/user/data をコンテナの /data に繋げば、データは馴染みのある場所に残り、cp でバックアップも取りやすいです。

バックアップすべきデータは、私の経験上、次のとおりです。

• データベースファイル（PostgreSQL、MySQL、MongoDB のデータディレクトリ）
• ユーザーアップロードファイル（アバター、ドキュメント、画像）
• 設定ファイル（多くは再構築できますが、機密設定はバックアップしておくと安心）
• ログファイル（過去ログの分析が必要な場合）

よくあるデータ消失シナリオ

私が目にしたり聞いたりしたデータ消失は、だいたい次のパターンです。

うっかりコンテナ削除。いちばん多いです。テスト用コンテナを消そうとして docker rm -v を実行し、-v オプションのせいで関連する匿名ボリュームまで消してしまう。初めて使ったとき、私もテスト環境の DB を丸ごと消しました。

ディスク障害。2〜3 年動いたサーバーで突然 SMART アラートが鳴り、急いでディスク交換。データ自体は読めましたが、冷や汗ものでした。普段からバックアップがあれば、新ディスクに復元して数十分で戻せます。

サーバー移行。冒頭の話です。データセンター変更、クラウド事業者の乗り換え、VPS から Kubernetes への移行——データをどう運ぶかは大きな課題。バックアップがなければ、転送中に scp が切れないことを祈るしかありません。

もう一つ、去年の知人のスタートアップの話。DB コンテナが原因不明で落ち、再起動したらボリューム内のデータが壊れて PostgreSQL が起動しませんでした。直近のバックアップは 2 ヶ月前。2 ヶ月分の注文データが消え、数十万の損失につながりました。

脅すつもりはありません。定期バックアップは本当に重要です。データを失ったあと、どんな技術も取り戻せません。

3 つのバックアップ方法を詳しく解説

方法 1：tar コマンドでバックアップ（⭐⭐⭐⭐⭐ 推奨）

いちばんよく使う方法で、あらゆる場面に向いています。考え方はシンプル。一時コンテナにボリュームをマウントして tar で固めるだけです。

バックアップコマンド：

docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/postgres-backup-20251217.tar.gz -C /data .

コマンドの内訳：

• --rm：実行後にコンテナを自動削除。ゴミを残しません
• -v postgres_data:/data:ro：バックアップ対象のボリューム postgres_data を /data に読み取り専用（:ro）でマウント。誤操作防止
• -v $(pwd):/backup：カレントディレクトリを /backup にマウント。ここにファイルが出力されます
• tar czf：c＝アーカイブ作成、z＝gzip 圧縮、f＝ファイル名指定
• -C /data .：/data に移動してから .（カレント以下すべて）を対象にします

復元コマンド：

docker run --rm \
  -v postgres_data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/postgres-backup-20251217.tar.gz -C /data

x は解凍を意味します。それ以外はバックアップ時とほぼ同じです。

いつ使うか？

• あらゆるボリュームタイプに対応。最も汎用的
• 圧縮して容量を節約したい（30〜50% 程度縮小）
• バックアップを別サーバーやクラウドストレージへ転送したい

注意点：

初めて使ったとき、稼働中の MySQL コンテナをそのままバックアップしました。バックアップ自体は成功したのに、復元後に DB が起動せず、テーブル破損エラーが出ました。DB が書き込み中にファイルレベルでバックアップすると、不整合な状態をキャプチャすることがあるのです。

最も安全な手順：

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

1. 書き込みを止める（コンテナ停止またはテーブルロック）
2. バックアップ実行
3. サービス再開

どうしても止められない場合は、journal や WAL ログが有効か確認してください。書き込み中でも、復元後に DB が自己修復できる場合があります。

実践例：PostgreSQL データのバックアップ

# 1. 可能なら PostgreSQL コンテナを停止
docker stop my-postgres

# 2. データボリュームをバックアップ
docker run --rm \
  -v postgres_data:/data:ro \
  -v /backup:/backup \
  ubuntu tar czf /backup/pg-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 3. バックアップファイルを確認
ls -lh /backup/pg-*.tar.gz

# 4. コンテナを再起動
docker start my-postgres

ファイル名にはタイムスタンプを入れるのがおすすめです。いつ取ったバックアップか一目でわかります。

方法 2：docker cp コマンド（⭐⭐⭐）

より直感的で、tar に固めずファイルを直接コピーします。設定ファイルや小さなディレクトリの素早いバックアップ向けです。

バックアップ手順：

# 1. ボリュームをマウントした一時コンテナを作成
docker create -v nginx_config:/data --name temp_backup busybox

# 2. データをホストへコピー
docker cp temp_backup:/data ./nginx-config-backup

# 3. 一時コンテナを削除
docker rm temp_backup

復元手順：

# 新しいコンテナへ復元する例
docker cp ./nginx-config-backup/. my-nginx:/etc/nginx/

いつ使うか？

• 設定ファイル数点だけバックアップしたい
• ファイルが小さい（数十 MB 以内）
• 解凍せず中身をすぐ確認したい

デメリット：

• 圧縮されないので容量を食う
• tar より転送が遅い場合がある
• 権限や特殊属性が完全には保持されない

実践例：Nginx 設定のバックアップ

# 一時コンテナを作成
docker create -v nginx_config:/config --name nginx_temp busybox

# 設定ファイルをコピー
docker cp nginx_temp:/config/nginx.conf ./backup/

# ディレクトリごとコピーすることも可能
docker cp nginx_temp:/config/. ./backup/nginx-config/

# 後片付け
docker rm nginx_temp

Nginx 設定を変える前に docker cp で現行設定を退避しておく——こういう使い方が多いです。設定を壊してもすぐ戻せます。

方法 3：docker-volume-backup ツール（⭐⭐⭐⭐ 自動化の定番）

前の 2 つは手動向け。本番環境では自動定期バックアップが欲しくなります。

今使っているのは offen/docker-volume-backup です。2025 年時点でも人気の OSS です。特徴は次のとおり。

• cron 式でスケジュール実行
• バックアップ前にコンテナを自動停止し、データ整合性を確保
• S3、Google Drive、SSH、WebDAV など複数バックエンドに対応
• 古いバックアップを自動削除

Docker Compose 設定例：

version: '3.8'

services:
  # データベースサービス
  postgres:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    labels:
      # バックアップ中にこのコンテナを停止
      - "docker-volume-backup.stop-during-backup=true"

  # バックアップサービス
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      # 毎日午前 2 時にバックアップ
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      # バックアップファイル名
      BACKUP_FILENAME: "db-backup-%Y%m%d-%H%M%S.tar.gz"
      # 直近 7 日分を保持
      BACKUP_RETENTION_DAYS: "7"
    volumes:
      # バックアップ対象ボリューム（読み取り専用）
      - db_data:/backup/db_data:ro
      # バックアップ保存先
      - ./backups:/archive
      # コンテナ停止のため Docker ソケットが必要
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  db_data:

動作フロー：

1. 毎日午前 2 時にバックアップコンテナが起動
2. postgres に stop-during-backup ラベルがあるため自動停止
3. db_data ボリュームを tar でアーカイブ
4. ./backups に保存
5. postgres を再起動
6. 7 日より古いバックアップを削除

いつ使うか？

• 本番環境で定期自動バックアップが必要
• S3 や GCS などクラウドへ転送したい
• 複数コンテナのバックアップを一元管理したい

注意点：

初回設定では権限に注意。/var/run/docker.sock を読めないと、他コンテナを停止できません。

また、このツールは数秒〜数十秒（データ量次第）サービスを止めます。無停止が必須なら stop-during-backup ラベルを外せますが、その場合は不整合バックアップのリスクを受け入れる必要があります。

実践例：MongoDB の自動バックアップ

version: '3.8'

services:
  mongodb:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    labels:
      - "docker-volume-backup.stop-during-backup=true"

  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "mongo-%Y%m%d.tar.gz"
      BACKUP_RETENTION_DAYS: "14"
      # AWS S3 へバックアップ
      AWS_S3_BUCKET_NAME: "my-backups"
      AWS_ACCESS_KEY_ID: "${AWS_KEY}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET}"
    volumes:
      - mongo_data:/backup/mongo_data:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  mongo_data:

この設定で毎日午前 3 時に MongoDB をバックアップし、S3 にアップロード。ローカルには残しません。半年以上問題なく動いています。

データ移行の完全フロー

サーバー移行の実践ステップ

バックアップ方法の次は、実際のサーバー移行フローです。昨年、Alibaba Cloud から Tencent Cloud へ移行したときの流れを整理します。

1. 準備段階（絶対に飛ばさない）

まず現状を把握します。

# 全コンテナを一覧
docker ps -a

# 全ボリュームを一覧
docker volume ls

# 各コンテナの設定をエクスポート（重要！）
docker inspect my-postgres > postgres-config.json
docker inspect my-nginx > nginx-config.json

# docker-compose.yml と .env を控える
cp docker-compose.yml docker-compose.backup.yml
cp .env .env.backup

これらの設定ファイルは必ずバックアップ。初回移行で環境変数を保存し忘れ、新サーバーで DB パスワードが合わず、かなり時間を浪費しました。

2. バックアップ段階

全サービスを止めてバックアップします。

# 全コンテナを停止
docker-compose down

# 各ボリュームをバックアップ
docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/postgres_data.tar.gz -C /data .

docker run --rm \
  -v nginx_config:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/nginx_config.tar.gz -C /data .

# バックアップファイルを確認
ls -lh backups/
md5sum backups/*.tar.gz > backups/checksums.txt

md5sum は重要です。転送中にファイルが壊れても気づけます。

3. 移行段階

バックアップを新サーバーへ送ります。

# rsync なら中断しても再開できる
rsync -avP --partial backups/ user@new-server:/tmp/backups/

# scp でも可
scp -r backups/ user@new-server:/tmp/backups/

ファイルが数十 GB で回線が不安定なら、S3 や OSS などオブジェクトストレージ経由がおすすめ。先にクラウドへ上げ、新サーバーから落とす方が速くて確実です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

新サーバーでの復元：

# 1. ボリュームを作成
docker volume create postgres_data
docker volume create nginx_config

# 2. データを復元
docker run --rm \
  -v postgres_data:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/postgres_data.tar.gz -C /data

docker run --rm \
  -v nginx_config:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/nginx_config.tar.gz -C /data

# 3. 復元データを確認
docker run --rm -v postgres_data:/data ubuntu ls -lh /data

# 4. サービス起動
docker-compose up -d

4. 検証段階

起動したらすぐにトラフィックを切り替えない。先に検証します。

# コンテナ状態を確認
docker ps

# ログでエラーがないか確認
docker-compose logs -f

# DB 接続をテスト
docker exec -it my-postgres psql -U postgres -c "SELECT COUNT(*) FROM users;"

# 新旧サーバーのデータ件数を比較
# （ここは私、主要テーブルの件数を比べるスクリプトを書くことが多い）

問題がなければ、DNS やロードバランサーの設定を変更してトラフィックを切り替えます。

私が踏んだ落とし穴：

昨年、50 GB のボリュームを docker run tar で解凍したら 1 時間近くかかりました。実は docker volume create 後、ホストの /var/lib/docker/volumes/volume_name/_data に直接解凍した方が速い場合があります。ただし権限には注意が必要です。

データベースバックアップの特別な注意点

DB バックアップは落とし穴が多いので、別途整理します。

なぜファイルレベルバックアップだけでは不十分か？

DB は稼働中も常に書き込まれます。MySQL の InnoDB には redo log や undo log、PostgreSQL には WAL ログがあり、トランザクション整合性を保っています。稼働中に tar でデータファイルを固めると、トランザクション書き込みの途中状態をキャプチャしてしまうことがあります。

最悪の例：MySQL をバックアップした瞬間、数百万行の一括 INSERT が走っていたケース。ファイルは正常に見えたのに、復元後 InnoDB テーブルスペース破損で起動不能になりました。

正しい方法：アプリケーション層バックアップ

PostgreSQL：

# 単一 DB をバックアップ
docker exec my-postgres pg_dump -U postgres mydb > mydb-backup.sql

# 全 DB をバックアップ
docker exec my-postgres pg_dumpall -U postgres > all-dbs-backup.sql

# 復元
docker exec -i my-postgres psql -U postgres mydb < mydb-backup.sql

MySQL：

# バックアップ
docker exec my-mysql mysqldump -u root -p mydb > mydb-backup.sql

# 復元
docker exec -i my-mysql mysql -u root -p mydb < mydb-backup.sql

MongoDB：

# バックアップ
docker exec my-mongo mongodump --out=/backup
docker cp my-mongo:/backup ./mongo-backup

# 復元
docker cp ./mongo-backup my-mongo:/backup
docker exec my-mongo mongorestore /backup

二重バックアップ戦略：

今の運用は アプリケーション層バックアップ + ボリュームバックアップ の二本立てです。

• アプリケーション層（pg_dump など）：メインの復元手段。データ整合性が保証される
• ボリュームバックアップ（tar）：災害復旧用の保険。論理バックアップが失敗・破損したときの最後の手段

容量は増えますが、安心です。冒頭の知人の会社はボリュームバックアップだけで、復元時に破損が判明。論理バックアップは取っていませんでした。

ベストプラクティスと落とし穴回避

バックアップ戦略の設計

方法があっても、戦略がなければバックアップが多すぎて無駄になったり、少なすぎてデータを失ったりします。

3-2-1 ルール（業界でよく言われる黄金律）：

• 3 つのコピー：本番データ + バックアップ 2 つ
• 2 種類の媒体：例えばローカル HDD + クラウド、または 2 台の別ディスク
• 1 つはオフサイト：地理的に離れた場所に 1 つ（火災・地震対策）

難しそうに見えても、実装はシンプルです。私の例：

• ローカルサーバー：直近 7 日分の日次バックアップ（1 つ目）
• NAS：直近 30 日分（2 つ目、別媒体）
• S3：直近 3 ヶ月分の月次バックアップ（3 つ目、オフサイト）

バックアップ頻度の目安：

バックアップ命名規則：

命名を乱すと、復元時に地獄を見ます。私の形式：

<サービス名>-<データ種別>-<YYYYMMDD>-<HHMMSS>.tar.gz

例：

myapp-postgres-20251217-020000.tar.gz
myapp-nginx-config-20251217-020000.tar.gz
myapp-uploads-20251217-020000.tar.gz

並べ替えると自然に時系列になり、いつのバックアップかすぐわかります。

よくある問題と対処法

問題 1：「volume is in use」と表示される

ボリュームは複数コンテナに同時マウントできるので、通常は出ません。出た場合の原因：

• ファイルロック
• NFS などネットワークストレージのマウント問題

対処：

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

# このボリュームを使っているコンテナを確認
docker ps --filter volume=my_volume

# 可能ならコンテナを停止
docker stop container_name

# または --volumes-from を使う
docker run --rm --volumes-from=my_container -v $(pwd):/backup ubuntu tar czf /backup/data.tar.gz -C /data .

問題 2：復元後にファイル権限がおかしい

tar は権限情報を保持しますが、Ubuntu から CentOS へ移すなど OS が違うと UID/GID が合わないことがあります。

症状：コンテナ起動時に読み書き権限エラー。

対処：

# 復元時に owner を指定
docker run --rm -v my_volume:/data -v $(pwd):/backup ubuntu sh -c "tar xzf /backup/data.tar.gz -C /data && chown -R 999:999 /data"

# 999:999 は PostgreSQL コンテナ内 postgres ユーザーの UID
# イメージごとに異なるので、ドキュメントか docker inspect で確認

問題 3：バックアップファイルが大きすぎて転送が大変

50 GB の MySQL を gzip 圧縮しても 30 GB。インターネット経由の転送は遅く、途中で切れることも。

対処：

1. より高い圧縮率：xz は gzip より 20〜30% 小さくなる（速度は遅い）

   tar cJf backup.tar.xz /data  # J は xz 圧縮

2. 分割圧縮：ファイルサイズ上限のある転送先向け

   tar czf - /data | split -b 1G - backup.tar.gz.
   # 復元：cat backup.tar.gz.* | tar xzf -

3. 増分バックアップ：変更分だけ（rsync や専用ツールが必要）

問題 4：復元時にバックアップファイルが壊れていた

いちばんキツい——バックアップ時は気づかず、必要になって初めて判明。

予防：

# バックアップ直後にチェックサム
md5sum backup.tar.gz > backup.tar.gz.md5

# 新サーバー到着後に再検証
md5sum -c backup.tar.gz.md5

# 定期的な復元テスト（最重要！）
# 毎月テスト環境で実際に復元し、使えるか確認

私の習慣：バックアップ後、先頭数ファイルを解凍して、ファイル自体が壊れていないか確認します。

自動化と監視

手動バックアップは信頼できますが、人は忘れます。本番では自動化が必須。

crontab で定期実行する例：

# バックアップスクリプト /opt/scripts/backup-docker-volumes.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/backup

# PostgreSQL をバックアップ
docker run --rm \
  -v postgres_data:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/postgres-$DATE.tar.gz -C /data .

# Nginx 設定をバックアップ
docker run --rm \
  -v nginx_config:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/nginx-$DATE.tar.gz -C /data .

# 7 日より古いバックアップを削除
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

# 通知（任意）
echo "Backup completed: $DATE" | mail -s "Docker Backup Report" admin@example.com

# crontab に追加
crontab -e

# 毎日午前 2 時に実行
0 2 * * * /opt/scripts/backup-docker-volumes.sh >> /var/log/docker-backup.log 2>&1

監視とアラート：

自動化だけでは不十分。成功したかも知る必要があります。

1. ログ記録：時刻、ファイルサイズ、MD5 を毎回記録
2. 監視スクリプト：新しいバックアップが生成されたか毎日確認。なければアラート
3. サイズ異常検知：平均より 50% 以上大きい／小さい場合は問題の可能性

シンプルな監視スクリプト：

#!/bin/bash
BACKUP_DIR=/backup
EXPECTED_SIZE=100000000  # 100MB。環境に合わせて調整

LATEST_BACKUP=$(ls -t $BACKUP_DIR/postgres-*.tar.gz | head -1)
if [ -z "$LATEST_BACKUP" ]; then
  echo "ERROR: No backup file found!"
  exit 1
fi

# 今日のバックアップか確認
BACKUP_DATE=$(stat -c %Y "$LATEST_BACKUP")
TODAY=$(date +%s)
AGE=$((TODAY - BACKUP_DATE))

if [ $AGE -gt 86400 ]; then
  echo "ERROR: Latest backup is older than 24 hours!"
  exit 1
fi

# ファイルサイズを確認
SIZE=$(stat -c %s "$LATEST_BACKUP")
if [ $SIZE -lt $(($EXPECTED_SIZE / 2)) ]; then
  echo "WARNING: Backup file is too small: $SIZE bytes"
  exit 1
fi

echo "Backup check passed: $LATEST_BACKUP ($SIZE bytes)"

これらは Prometheus や Zabbix に組み込むか、メールや Slack 通知に直結できます。

まとめ

ここまで読んで、最初の疑問に戻りましょう。Docker のデータはどうバックアップするか？

答えはシンプル。万能な方法はなく、場面に合った方法を選ぶことが大事です。

• 一時バックアップ・素早い移行：tar 方式。汎用的で確実
• 設定ファイル・小ファイル：docker cp で十分。シンプル
• 本番・定期自動化：docker-volume-backup。手間が少ない

最も重要なのは 定期バックアップと、定期的な復元テスト。本当に必要になってから、バックアップが壊れていたり復元できないと気づくのは手遅れです。私は毎月テスト環境で最新バックアップを実際に復元し、手順に問題がないか確認しています。

最後に一つ。今日、Docker アプリの最初のバックアップを取ってみてください。難しくする必要はありません。最もシンプルな tar 方式で一度試すだけ。バックアップファイルがディスクにあるだけで、安心感が全然違います。

バックアップで困ったことや、もっと良い方法があれば、コメントで教えてください。みんなで情報を共有すれば、落とし穴は減らせます。