Dockerのデータはどこにあるのか

コンテナは作り直せても、データが自動的に戻るとは限らない。保存先の種類と、削除する対象の境界を理解する必要がある。本記事はDocker公式資料を確認した演習手順であり、本番のコンテナやボリュームで実験を実施したものではない。確認日は2026-09-07。

三つの保存場所

単なるコンテナの停止・再起動と、削除して再作成することは違う。Volumesで寿命を確認できる。anonymous volumeは名前を自分で指定しない形式で、--rmなどによる削除条件がnamed volumeと異なるため、この演習では使わない。

図1 · ボタンで表示を切り替え

演習用のnamed volumeを作る

Docker Engine、Linuxコンテナ、alpine:3.21を使う例である。Dockerのバージョンと実際に取得したイメージのダイジェストを記録する。タグは将来同じ内容とは限らない。duskcoil-lifetime-demoという名前が未使用であることをdocker volume lsで確認してから実行する。

docker volume create duskcoil-lifetime-demo
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data alpine:3.21 sh -c 'echo saved > /data/note.txt; echo temporary > /tmp/note.txt'
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data,readonly alpine:3.21 sh -c 'cat /data/note.txt; test ! -e /tmp/note.txt'

期待結果は/data/note.txtからsavedを読めて、2個目のコンテナの/tmp/note.txtは存在しないこと。最初の--rmでコンテナを削除してもnamed volumeは残る。2個目は読み取り専用で接続する。既存のサービス名や本番データへ置き換えて試す演習ではない。

bind mountはホストのどこを指すか

Bind mountsでは、パスはDocker daemonが動くホスト側を指す。リモートのDockerを操作している場合、手元のPCのファイルとは限らない。Docker DesktopでもVMとの境界を意識する。

docker inspect <コンテナ名>のMountsでType、Source、Destination、RWを確認する。見えている/dataが想定したディレクトリと違えば、アプリの設定を直す前に接続を直す。既存ファイルがあるディレクトリへマウントすると、その下のファイルが見えなくなることもある。「消えた」と「別のものが上に見えている」を区別する。

Composeの削除操作を読み分ける

docker compose downとdocker compose down --volumesは同じではない。後者はComposeで定義したnamed volumeなども削除対象にする。external volumeは別管理である。downの公式リファレンスで対象を確認する。

また、Composeのプロジェクト名を変えると、別の名前のvolumeが作られて初期状態に見えることがある。古いデータが壊れたと判断する前に、実際のvolume名を調べる。演習で作ったvolumeの後片付けは、内容が不要と確認した後にその名前だけを指定して行う。全volumeを対象にした一括削除は手順に含めない。

永続化はバックアップではない

volumeはコンテナの寿命からデータを分けるが、同じディスクの故障やアプリによる誤削除から守るとは限らない。別の保存先へのコピーと復元確認が必要である。データベースを動かしたままファイルをコピーすると整合しない場合があるため、アプリのバックアップ機能や停止・スナップショット条件を確認する。

イメージやComposeだけを保存しても、利用者の投稿やDBが戻るとは限らない。逆にDBだけあっても、必要な設定、鍵、バージョンがなければ復元できないことがある。復元先でアプリが読めるかを確認して初めて、保存の手順が具体的になる。

自分のサービスで作る台帳

各サービスについて「コンテナ内の保存先／Mountsの実体／所有者と権限／バックアップ方法／復元先／最後に復元を試した日」を記録する。まずこの台帳で保存先を確認し、自宅サーバーの復元演習へ進むと、失うと困るものを漏らしにくい。