Dockerのcontainer削除前にデータの保存先を確認する方法

先に結論

Docker containerを削除する前に、残したいファイルがどこへ書かれているか確認してください。mountされていないcontainer内の変更はwritable layerにあり、containerを削除すると失われます。named volumeはcontainerを削除しても通常は残り、bind mountはhost側の指定directoryを使います。ただし匿名volumeは--rm付きで起動したcontainerとともに削除される場合があり、volumeも個別にprune・削除すれば消えます。

まず対象containerのMountsをinspectし、保存したいcontainer pathがどのmountの下にあるかを照合します。該当mountがなければ、削除前に必要なファイルを別の保存先へ退避するか、次回作成時にvolumeまたはbind mountを明示します。

確認日: 2026年10月19日（Asia/Tokyo）
対象: Docker Engineのcontainerを削除・再作成する前に、dataの保存先を判定したい初心者
確認方法: Docker公式資料による机上調査です。特定のhostやcontainerでinspect・削除・復元を実行した実測ではありません。

最初に確認する3つの書込先

保存先	見分け方	container削除時
writable layer	対象pathを覆うvolumeまたはbind mountがない	containerと一緒に消える
Docker volume	inspectのMountsにType: volumeがある	通常は別に残る。匿名volumeと--rm、明示削除・pruneに注意
bind mount	Type: bindとhost側のSourceが表示される	container削除後もhost directory側に残るが、そのhost側を消せば失われる

mountはcontainer内の特定destinationを覆います。同じcontainerでも、あるpathはvolume、別のpathはwritable layerということがあります。containerの「データ」を一括して残る・消えると判断せず、残したいファイルのpathごとに対応を調べます。

削除前にmountと保存先を照合する

1. 対象containerを特定する: docker ps -aで名前やIDを確認します。同じimageから複数起動している場合、名前だけで決めず、目的のcontainerかを照合します。
2. mountを読む: docker inspect <container>の出力でMountsを探します。Type、Source、Destinationを記録し、保存したいファイルのcontainer内pathが、どのdestination配下にあるか確認します。
3. mountの種類を判定する: TypeがvolumeならDocker管理のvolume、bindならhost側のpathです。どちらのmountにも含まれない書込先は、writable layerにある可能性があります。
4. 起動時の削除条件を確認する: 実行履歴やCompose設定で--rmが指定されていないか見ます。匿名volumeは--rmでcontainerと一緒に削除されることがあります。別の管理者が後からvolumeをprune・rmする運用も確認してください。
5. 削除前の選択を決める: 残す必要があるデータの保存先を特定できなければ、container削除を止めます。必要ならvolume backupやhost directoryのcopyを準備し、退避先と対象を別の人にも確認できる状態にします。

たとえばType: volume、Name: app-data、Destination: /var/lib/appなら、/var/lib/app以下のデータはapp-dataが保存先の候補です。表示されたSourceはvolume driverのhost側表現で、Docker Desktopなどでは直接編集する作業場所とは限りません。bind mountならSourceに出たhost pathを、実際に保持するdirectoryとして確認します。

次のcontainerでデータを使うには

次回起動時にも同じnamed volumeを使うには、起動定義へ明示します。たとえばdocker run --mount type=volume,src=app-data,dst=/var/lib/app IMAGEなら、container内の/var/lib/appにnamed volumeを割り当てます。存在しないvolume名を使うと新規作成されるため、旧containerのvolume名を取り違えると空に見えることがあります。起動後もdocker inspectでNameとDestinationを照合してください。

hostから直接ファイルを読み書きする必要があるならbind mountが候補ですが、host directoryの場所と権限、対象OSによる差を確認します。volumeがあるだけでbackupがあるとは限らず、container削除とvolume削除を同じ操作だと考えないことが大切です。Dockerのvolume pruneやvolume rmは、保持したいdataがないと確認できてから実行してください。

削除後の確認と戻し方

削除・再作成後は、起動したcontainerのMountsを再度inspectし、期待したvolume名またはhost sourceとcontainer destinationの組み合わせかを確認します。アプリが実際に必要なfileを読めたことも確認します。mountの表示だけではarchiveの完全性やアプリの復旧までは証明できません。

誤ったvolumeを指定した、またはdataが見えなくなった場合は、追加の削除・pruneを行わずに停止します。元のcontainerまたはvolumeがまだ残っているなら、名前とmountの割当を再確認します。backupがある場合も、まず本番とは別のvolumeやdirectoryへ復元して内容を確認します。この記事では破壊的な復元操作や実データの復旧を検証していません。

既存記事との関係

Dockerの導入ガイドはinstallや基本操作を扱います。Docker Model Runnerの記事はmodelを起動してAPI応答を確認する内容です。Docker上のLLMが遅い場合はMacのcontainerとGPUのつながりも参照できます。本稿はcontainerを削除する前のdata所在確認に限定しています。

参考資料

• Docker公式: Volumes（2026年10月19日確認。資料上の日付は示されていません）
• Docker公式: Running containers（2026年10月19日確認。資料上の日付は示されていません）