Day6：データ永続化（ボリューム）後半
テーマ：ボリュームを“安全に運用できるレベル”まで深掘りし、削除・バックアップ・本番構成の注意点を理解する
後半では、前半・中盤で理解した
「ボリューム＝コンテナの外にあるデータ保存領域」
をさらに実務レベルへ引き上げます。
ここを理解すると、あなたは
「データが消えない Docker 環境を安全に運用できるエンジニア」
になります。
ボリュームは“消えない”が、“消せないわけではない”
ボリュームはコンテナ削除では消えない
前半・中盤で学んだ通り、ボリュームはコンテナとは独立しています。
しかし、Docker のコマンドで 意図的に削除することは可能 です。
ボリュームの削除
docker volume rm mydata
注意
この操作は取り消せません。
データベースのデータがすべて消えます。
実務では、誤削除を防ぐために：
- ボリューム名を分かりやすくする
- 本番環境では削除権限を制限する
- バックアップを定期的に取る
といった対策が必要です。
ボリュームのバックアップ方法を理解する
ボリュームは“フォルダ”なのでバックアップできる
ボリュームの実体は、Docker が管理するフォルダです。
例：/var/lib/docker/volumes/mydata/_data
バックアップ方法（安全な方法）
docker run --rm \
-v mydata:/data \
-v $(pwd):/backup \
alpine tar czf /backup/mydata.tar.gz /data
動作イメージ：
- mydata を
/dataにマウント - 現在のフォルダを
/backupにマウント - tar で圧縮して保存
復元方法
docker run --rm \
-v mydata:/data \
-v $(pwd):/backup \
alpine tar xzf /backup/mydata.tar.gz -C /
これで ボリュームのバックアップと復元が可能 になります。
ボリュームの“中身を確認する”方法
ボリュームはコンテナを使って中身を覗ける
docker run --rm -it -v mydata:/data alpine sh
これで /data の中身を確認できます。
例：
ls /data
MySQL の場合は、ibdata1 や *.frm などのデータファイルが見えます。
実務で必須の“ボリューム運用の注意点”
データベースのバージョンを変えると壊れる可能性がある
例：
MySQL 5.7 のデータを MySQL 8 にそのまま読み込むと壊れることがあります。
対策：
- バージョンアップ時はバックアップを取る
- 新しいコンテナでマイグレーションを行う
- 本番環境では必ずテスト環境で検証する
ボリュームは“本番の生命線”
本番環境では、ボリュームは次のように扱います。
- 定期バックアップ
- 誤削除防止
- バージョン管理
- ストレージ容量監視
ボリュームが壊れる＝サービス停止
という重大事故につながるため、慎重な運用が必要です。
docker-compose を使った“本番レベルの永続化構成”
version: "3.9"
services:
db:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: myapp
volumes:
- mydata:/var/lib/mysql
restart: always
volumes:
mydata:
この構成のポイント
restart: alwaysで自動復旧mydataにデータを永続化- コンテナを作り直してもデータは残る
実務ではこの構成が基本です。
ボリュームを使った“データが消えない本番構成”の考え方
データはコンテナではなく“ボリュームに宿る”
本番では次のように考えます。
- コンテナは壊れてもいい
- コンテナは作り直せばいい
- データは絶対に壊してはいけない
- データはボリュームに保存する
この考え方ができると、
Docker を使った本番運用が理解できます。
後半まとめ
あなたがここまで理解できていれば、Day6 のゴールは完全達成です。
- ボリュームは削除しない限り残り続ける
- バックアップ・復元ができる
- ボリュームの中身を確認できる
- DB のバージョン変更には注意が必要
- docker-compose で永続化を安全に管理できる
- 本番では「コンテナは消えていい、データは消えてはいけない」という考え方が重要