Docker Volumeの確認・バックアップ・復元手順｜bind mountとの違い
Dockerのコンテナ更新・移行・削除の前に、データがどこに保存されているか、バックアップと復元が成立するかを確認する運用ガイドです。特に名前付きVolumeとbind mount、コンテナの書き込み可能レイヤーを混同しないようにします。
この記事の目的
コンテナの削除で残るデータ・失われるデータを区別し、検証用Volumeで安全なバックアップ・リストア手順を学びます。
まず確認すること
docker context show→docker volume ls→docker inspect --format '{{json .Mounts}}'で接続先とマウントを確認。
web01・app-data・ポート番号などは説明用です。Docker context・対象コンテナ・データ保存先を照合してください。関連ガイド
Docker基本操作
コンテナの状態確認、起動・停止、接続先の基本操作へ戻ります。
ガイドへ →DockerDocker Compose設定
compose.yamlの変数、ポート、永続化、反映前チェックを確認します。
ガイドへ →DockerDockerログ運用
docker logsとログドライバー、保存容量の設計を確認します。
ガイドへ →1. Volume・bind mount・書き込み可能レイヤーの違い
| 保存場所 | コンテナ削除後 | 用途・注意 |
|---|---|---|
| 名前付きVolume | 通常はデータが残る | Dockerが管理する永続データ。使用元と削除条件を把握 |
| bind mount | ホスト上の実ファイルは残る | ホストのパス・所有者・権限・SELinux設定に依存 |
| コンテナの書き込み可能レイヤー | コンテナ削除で失われる | コンテナを再作成したときに残ると期待しない |
| tmpfs | 停止や再起動などで失われる | 一時データ用。永続バックアップ先ではない |
Docker公式はVolumeをコンテナのライフサイクルとは独立した永続保存として位置付けています。バックアップ対象はコンテナ名だけでなくマウント先から特定します。
2. データ保存先を変更前に確認
app-data・web01は説明用です。docker volume inspectにはMountpointが出ますが、Volumeの内部ファイルをホストから直接変更しないでください。rootlessやDocker Desktopではデータの実配置が異なることがあります。
3. 稼働中データの整合性と復元可否
アーカイブ作成成功、ファイルとしての読取り成功、アプリケーションとしての復元成功は別の判定です。書き込みが続いているVolumeのtar取得だけで整合性は保証されません。 ホストファイル、DB、キューや複数Volumeを同時に扱うアプリで手順を分けてください。
| データ | 取得前の条件 | 復旧確認 |
|---|---|---|
| 静的ファイル・検証用Volume | 書き込み停止を確認し、対象パス・アクセス権・容量を記録 | 別Volumeへ展開し、ファイルと権限・アプリからの読取りを確認 |
| DB・トランザクションを伴うアプリ | DB製品のオンラインバックアップ／整合性スナップショット等、製品固有の推奨手順を優先。単純tarを代用しない | 隔離環境への復元、起動、整合性チェックとアプリ機能確認まで実施 |
| 複数Volume・外部ストレージ | 取得時点をそろえる仕組みと依存関係を確認 | データ間の整合性とサービス全体の復元順序を確認 |
ハッシュ値はアーカイブの同一性確認には役立ちますが、アプリケーションのデータ整合性を証明しません。復元検証に失敗した場合は本番Volumeを上書きせず、原因を調査してバックアップ方式を見直してください。空の検証用Volumeへ復元する手順と、本番への復元手順を混同しないことが重要です。
4. 検証環境でVolumeをバックアップする
バックアップを取る瞬間にデータを書き換えているアプリがあると、アーカイブの整合性が崩れる場合があります。DBはまずアプリ固有のバックアップ機構や静止化・スナップショットの方法を確認してください。次は整合性が確保された検証用Volumeだけを対象とした一例です。この例のbind mountはdaemonホスト側のパスを参照します。リモートcontextではCLI端末のカレントディレクトリと一致しないため、そのまま実行しないでください。
busybox:1.37を取得・起動します。イメージ取得元、保存先への上書き、持ち出すデータの機密区分を確認してください。取得中のアプリ書き込みを止められない場合は別方式を選びます。Volumeの存在確認、専用ディレクトリの作成、空き容量確認のいずれかが失敗した場合はバックアップ用コンテナを起動せず、保存先と対象を再確認してください。5. 別Volumeへのリストアを検証
復元の確認は、いきなり本番Volumeへ上書きせず、新しい検証用Volumeを作って行います。アーカイブの出所・内容を確認し、絶対パスや意図しないファイルを展開しないことを確かめてください。
復元前の停止条件：BACKUP_DIR未設定、アーカイブ不在・破損、または同名の検証用Volumeが既に存在するときは復元しないでください。docker volume createは既存名でも失敗しないため、docker volume inspect app-data-restoreで事前に存在を調べ、新規の未使用名で作業します。
復元後はファイル件数や所有者だけでなく、アプリを別環境で起動して読み込み・書き込みが正常か確認してください。アーカイブ内のパス・権限・シンボリックリンクが信頼できるものかも監査対象です。
6. 削除時のデータ保持・消失条件
| 操作 | 確認すべき影響 |
|---|---|
docker rm | コンテナ本体を削除。Volumeの扱いと書き込み可能レイヤーを区別 |
docker rm -v | 匿名Volumeが削除対象になる場合がある。名前付きVolumeとは区別 |
docker compose down | Composeコンテナ・ネットワークを削除。既定では名前付きVolumeは保持 |
docker compose down -v | Compose定義の名前付きVolume等も削除対象となる |
docker volume prune | 既定では未使用の匿名Volumeが対象。--allを付けると未使用の名前付きVolumeも対象 |
down -vやvolume pruneを実行しないでください。復元手順とバックアップの実効性を確認してから削除判断します。7. 本番変更前のチェックリスト
- Docker context・ホスト・Volume名・利用中コンテナを確認したか
- データの整合性確保手段（DB固有のバックアップなど）を決めたか
- 機密データの保存先・暗号化・保持期限を確認したか
- 別Volumeで復元とアプリ動作を検証したか
- コンテナ変更後もVolumeが期待通りマウントされるか確認したか
コンテナ起動後の保存先が変わる場合はCompose設定確認、容量問題が起きている場合はLinux容量不足の切り分けも参照してください。
8. バックアップ・復元の合否を確認する
アーカイブ作成の成功と、アプリの復旧成功は異なります。バックアップ時に静止化・アプリ固有の整合性確保を実施したかを確認したうえで、別Volumeへ復元したデータを検査します。以下は検証専用の想定例であり、実機実測ではありません。
| 検証結果 | 次の行動 |
|---|---|
| アーカイブ読込み成功・取得時のchecksumと一致 | ファイル破損は検出されなかった。次に内容・所有者・パーミッション・アプリからの読込みを確認 |
| tarエラー・checksum不一致 | 本番復元を中止。バックアップ元と転送過程を調べ、正常なバックアップを再取得 |
| 復元後のファイル欠落・UID/GID違い | 展開方法・マウント先・実行ユーザーを確認して検証用Volumeで再試験 |
| ファイルは存在するがDB・アプリが異常 | データ整合性・DBバージョン・論理バックアップ/スナップショット・マイグレーションを担当者と確認 |
| 別環境のアプリがデータを読め、業務機能が正常 | 手順・所要時間・復元点・旧Volumeの保持方法を記録し、検証合格 |
9. 本番移行で失敗した場合の切り戻し
本番移行は元のVolumeを保持した状態で、別Volumeへの復元とアプリ動作検証を先に実施する方式が安全です。復元先で書込みが進んだ後は、旧版のデータ形式へ単純に戻せない場合があります。
| 状況 | 切り戻しの判断 |
|---|---|
| 元Volumeを保持・新Volumeの起動試験が失敗 | 承認された旧Compose定義・イメージ・元Volumeへの接続へ戻し、旧アプリからの読込みを再確認 |
| データベースのマイグレーションを実行済み | Volume切替で戻せるとは限らない。DB管理者とスキーマ互換性・逆マイグレーション・バックアップ復元を確認 |
| 意図しないVolumeを使っている | Composeプロジェクト接頭辞とexternal指定・mount先を確認し、削除する前に実利用先を記録 |
| バックアップは存在するが復元を未検証 | 本番更新を保留し、隔離した検証Volumeでアプリの復元試験を実施 |
docker compose down -vやdocker volume prune --allを復旧目的で実行しないでください。復旧成功の基準はアーカイブ作成ではなく、実アプリの必要データと業務動作の確認です。