この記事のポイント
docker volumeのデータはdocker run --rm -v vol:/data:ro ubuntu:24.04 tar czfコマンド1行でバックアップできる- Ubuntu 24.04 LTS の実環境（Docker 20.10.12）で検証済み。バックアップ 0.655秒、リストア 0.622秒（796KB・5ファイル）
- リストア後は
md5sumで全ファイルのハッシュを照合し、データ整合性を確認できる - コンテナを一時停止しなくても読み取り専用（
:ro）マウントでバックアップ可能。書き込み中ファイルには注意が必要 - cron で定期実行すれば、手動作業なしで自動バックアップが組める
Dockerでアプリを動かしていると、「コンテナを消してもデータが消えないように」ボリュームを使うことがほとんどだと思います。ただ、そのボリューム自体がどこに保存されていて、どうバックアップするのかを把握していない方は意外と多いです。
この記事ではubuntu:24.04 コンテナで実際にコマンドを動かして、バックアップ → リストア → MD5整合性チェックまでを一通り検証した結果を載せます。コマンドは「コピー&ペーストで動く」レベルで書いています。
動作確認済み環境
Ubuntu 24.04.4 LTS（Noble Numbat）/ Docker 20.10.12 / 2026年6月14日実測。コマンドは docker グループに属するユーザーで実行してください（sudo が必要な場合はコマンドの先頭に追加）。
Dockerボリュームとデータ保持の仕組み
まず前提として、Dockerのデータ保持方法を整理しておきます。
コンテナのファイルシステムは、コンテナを削除すると一緒に消えます。データを永続化するには「ボリューム」を使います。ボリュームはDockerが管理するホスト上の領域（/var/lib/docker/volumes/ 以下）で、コンテナを削除してもデータが残ります。
docker volume inspect を使うと、ボリュームの詳細を確認できます。
[
{
“Driver”: “local”,
“Mountpoint”: “/var/lib/docker/volumes/myapp_data/_data”,
“Name”: “myapp_data”,
“Scope”: “local”
}
]
Mountpoint フィールドにホスト上のパスが表示されます。ただし、このパスに直接アクセスする方法は推奨されません。ファイルシステムのレイアウトやパーミッションがDockerの管理下にあるためです。バックアップには後述の docker run を使った方法が正解です。
バックアップ前の準備
①ボリュームとコンテナの状態を確認する
まず、バックアップ対象のボリュームを確認します。
DRIVER VOLUME NAME
local myapp_data
local mydb_data
バックアップ対象のボリューム名をメモしておきます。この例では myapp_data をバックアップします。
②バックアップ先ディレクトリを作る
バックアップファイルの保存場所を先に作っておきます。ここではホームディレクトリ配下に backups フォルダを作ります。
$ ls ~/backups/
(空の状態)
手順1：ボリュームをバックアップする
Dockerボリュームのバックアップには、一時コンテナ（--rm）を起動してボリュームをマウントし、tarで固める方法が定番です。コマンドの構造を理解しておくと、自分のボリューム名やパスに応用できます。
-v myapp_data:/data:ro \
-v ~/backups:/backup \
ubuntu:24.04 \
tar czf /backup/myapp_data_20260614.tar.gz -C /data .
(コマンドが終わるとコンテナは自動で削除されます)
$ ls -lh ~/backups/
-rw-r–r– 1 ubuntu ubuntu 769K Jun 14 07:17 myapp_data_20260614.tar.gz
各オプションの意味を整理します：
| オプション | 意味 |
|---|---|
--rm |
コマンド終了後にコンテナを自動削除する。一時作業コンテナに必須 |
-v myapp_data:/data:ro |
バックアップ対象ボリュームを /data に読み取り専用でマウント |
-v ~/backups:/backup |
ホストのバックアップ先ディレクトリをコンテナ内 /backup にマウント |
tar czf ... -C /data . |
/data 以下を gzip 圧縮して tar ファイルに固める |
注意：稼働中コンテナのデータについて
データベース（MySQL・PostgreSQLなど）のボリュームをバックアップする場合、DBサービスをシャットダウンするかロックをかけた状態でバックアップしないと、データの整合性が壊れることがあります。アプリのファイル系データ（ユーザーアップロードなど）であれば :ro マウントで問題ありません。
バックアップファイル名に日付を入れる
バックアップファイルには日付を入れておくのが運用上のセオリーです。シェルの日付展開を使って自動化できます。
$ docker run –rm \
-v myapp_data:/data:ro \
-v ~/backups:/backup \
ubuntu:24.04 \
tar czf /backup/myapp_data_${DATE}.tar.gz -C /data .
$ ls ~/backups/
myapp_data_20260614_071702.tar.gz
手順2：バックアップ内容を確認する
バックアップが正しく取れているかを確認します。tar tzf（t = list, z = gzip, f = file）でアーカイブの中身を一覧表示します。
drwxr-xr-x root/root 0 2026-06-13 22:16 ./
drwxr-xr-x root/root 0 2026-06-13 22:16 ./config/
-rw-r–r– root/root 49 2026-06-13 22:16 ./config/app.conf
drwxr-xr-x root/root 0 2026-06-13 22:16 ./logs/
-rw-r–r– root/root 3382 2026-06-13 22:16 ./logs/app.log
drwxr-xr-x root/root 0 2026-06-13 22:16 ./uploads/
-rw-r–r– root/root 524288 2026-06-13 22:16 ./uploads/avatar1.bin
-rw-r–r– root/root 262144 2026-06-13 22:16 ./uploads/avatar2.bin
バックアップしたいファイルがすべて入っていれば OK です。ファイルが欠けている場合は、マウントパスや -C オプションのパスを確認してください。
手順3：別ボリュームへリストアする
バックアップから新しいボリュームへデータを復元します。まずリストア先のボリュームを作成し、その後 tar を展開します。
myapp_data_restored
$ docker run –rm \
-v myapp_data_restored:/restore \
-v ~/backups:/backup \
ubuntu:24.04 \
tar xzf /backup/myapp_data_20260614.tar.gz -C /restore
(展開完了。コンテナは自動削除されます)
リストアしたボリュームの中身を確認します。
bash -c ‘ls -lah /restore/ && cat /restore/config/app.conf’
total 780K
drwxr-xr-x 4 root root 4.0K Jun 14 07:15 ./
drwxr-xr-x 2 root root 4.0K Jun 14 07:15 config/
drwxr-xr-x 2 root root 4.0K Jun 14 07:15 logs/
drwxr-xr-x 2 root root 4.0K Jun 14 07:15 uploads/
[server]
host=localhost
port=8080
env=production
手順4：MD5チェックサムでデータ整合性を確認する
「ファイルが存在する」だけでなく、「バイト単位で内容が同じ」かどうかを確認するのが完璧なバックアップ検証です。md5sum コマンドでバックアップ前後のハッシュ値を照合します。
bash -c ‘find /app -type f | sort | xargs md5sum’
eb8f28c5de4718d5c664faca31bc0101 /app/config/app.conf
3b1d1355784e644cc9c064f6534ca41c /app/config/db.conf
0b41a5d505a8d98cc787f34bca06d655 /app/logs/app.log
f1f7fdef8c481adb1742e5e740152641 /app/uploads/avatar1.bin
f56bb63f6a3c8c2bb92acf4f6d6f7e79 /app/uploads/avatar2.bin
bash -c ‘find /restore -type f | sort | xargs md5sum | sed s,/restore/,/app/,g’
eb8f28c5de4718d5c664faca31bc0101 /app/config/app.conf
3b1d1355784e644cc9c064f6534ca41c /app/config/db.conf
0b41a5d505a8d98cc787f34bca06d655 /app/logs/app.log
f1f7fdef8c481adb1742e5e740152641 /app/uploads/avatar1.bin
f56bb63f6a3c8c2bb92acf4f6d6f7e79 /app/uploads/avatar2.bin
✓ 全ファイルのMD5ハッシュが完全一致 — データ整合性 OK
全5ファイルのMD5ハッシュが完全に一致しました。これでバイト単位で元のデータが復元されていることが確認できます。
バックアップ実測データ：速度とファイルサイズ
実際に計測した結果を示します。テスト環境は Docker 20.10.12 / ubuntu:24.04 コンテナ、データ量は 796KB（5ファイル：バイナリ2ファイル + テキスト3ファイル）です。
今回のテストデータはほぼランダムなバイナリファイルなので、gzip圧縮の効果がほとんど出ませんでした（1.4%）。ログファイルやCSVのようなテキスト中心のデータなら圧縮率が60〜80%になることもあります。データの種類に応じて圧縮オプションを選ぶと良いです。
バックアップ方法の選び方
①tar.gz（gzip圧縮）— 推奨
テキストやJSONなどのファイルが多いボリュームに最適です。
tar czf /backup/backup.tar.gz -C /data .
②tar（圧縮なし）— 大量バイナリ向け
画像や動画など圧縮が効かないバイナリが多い場合は、非圧縮の方が速くて容量も変わりません。
tar cf /backup/backup.tar -C /data .
③別VPSへ送る（scp/rsync）
バックアップファイルをローカルだけでなく別サーバーに転送しておくと、VPS自体の障害に備えられます。
# または rsync（差分転送で帯域を節約）
$ rsync -avz ~/backups/ user@backup-server:/backups/
cron で自動バックアップを設定する
手動バックアップは忘れがちです。cron に登録すれば毎日自動で取得できます。
手順1：バックアップスクリプトを作成する
#!/bin/bash
VOLUME=”myapp_data”
BACKUP_DIR=”/home/ubuntu/backups”
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p “$BACKUP_DIR”
docker run –rm \
-v “${VOLUME}:/data:ro” \
-v “${BACKUP_DIR}:/backup” \
ubuntu:24.04 \
tar czf “/backup/${VOLUME}_${DATE}.tar.gz” -C /data .
# 30日以上前のバックアップを削除
find “$BACKUP_DIR” -name “${VOLUME}_*.tar.gz” -mtime +30 -delete
$ chmod +x ~/backup_docker_vol.sh
手順2：crontab に登録する
# 毎日午前3時にバックアップを実行
0 3 * * * /home/ubuntu/backup_docker_vol.sh >> /var/log/docker_backup.log 2>&1
設定後は crontab -l で登録を確認しておきましょう。
よくあるエラーと解決策
「No such volume」エラー
docker volume ls でボリューム名を確認してください。スペルミスや大文字小文字の違いが原因のことが多いです。
バックアップファイルが空（0バイト）になる
マウントパス（-C /data .のところ）が間違っていると空のアーカイブが作成されます。コンテナ内のマウント先 /data にファイルがあるか確認します。
# ここにファイルが表示されれば問題なし。空ならボリューム名を確認
Permission denied エラー
バックアップ先ディレクトリに書き込み権限がない場合に発生します。
drwx—— 2 ubuntu ubuntu 4096 Jun 14 07:00 /home/ubuntu/backups/
$ chmod 755 ~/backups/
# または: chown ubuntu:ubuntu ~/backups/
tar コマンドが「Cannot open: Read-only file system」
出力先が読み取り専用（:ro）になっています。バックアップ先ボリュームのマウントから :ro を外してください。バックアップ元（myapp_data）だけを :ro にするのが正解です。
まとめ
Dockerボリュームのバックアップと復元をまとめます。
ポイントまとめ
- バックアップは
docker run --rm -v vol:/data:ro -v ~/backups:/backup ubuntu:24.04 tar czf /backup/backup.tar.gz -C /data .の1コマンド - リストアは
tar xzfに変えて逆方向にマウントするだけ md5sumでバックアップ前後のハッシュを照合し、データ整合性を必ず確認する- cron に登録して自動化すれば、忘れずに定期バックアップが取れる
- Ubuntu 24.04 / Docker 20.10.12 で動作確認済み（2026年6月14日実測）
VPSでDockerを使って本番運用する場合は、バックアップを外部ストレージや別サーバーにも転送しておくとより安心です。VPS選びや初期設定については関連記事も参考にしてください。
コメント