コンテナを作り直すと、データも消える？保存先をComposeから読む

開発用コンテナを作り直す手順を見て、日記や記事のデータまで消えるのか気になりました。Composeを読むと、PostgreSQLのデータ保存先には名前付きボリュームが割り当てられています。コンテナを置き換えることと、その保存領域を消すことは別でした。今回は既存のデータを操作せず、構成を追って整理します。

起動の材料、動くもの、保存領域を分ける

PostgreSQLの保存先は、名前付きボリューム

Appli Parkのローカル構成は、PostgreSQL 17のコンテナ内にある/var/lib/postgresql/dataへ、postgres_dataというCompose上のボリュームを接続します。DBが書く場所と、Docker側が管理する永続領域を対応させています。 同じ保存領域を新しいコンテナへ接続すれば、そこにあるDBデータを引き継ぐ構成です。ただし、実際にどのボリュームを使うかも重要です。Composeのプロジェクト名を変えて別の領域が作られれば、以前と違う空の保存先を見ている可能性があります。

「停止」「再作成」「保存領域の削除」は違う

停止はプロセスが動いていない状態にする操作です。再作成は新しいコンテナへ置き換える操作です。ボリューム自体の削除は、別にある保存領域をなくす操作です。Docker公式も、ボリュームの内容はコンテナのライフサイクルの外にあると説明しています。 だからこそ「コンテナを消したから必ず全部消える」「ボリュームがあるから何をしても残る」のどちらも不正確です。データが本当にその領域へ書かれているか、同じ領域を再び使うか、領域自体を削除しないかを見ます。

コードの共有フォルダーやキャッシュとも区別する

同じComposeには、ホストのソースコードをコンテナへ見せるバインドマウントや、依存ライブラリ・ビルド用のキャッシュ領域もあります。記法が似ていても、開発中のコード、再生成できるキャッシュ、失いたくないDB記録では役割が違います。 このローカルPostgreSQLの図を、そのまま本番にも当てはめません。本番構成コードは別のDBサービスへ接続する設計です。どちらもデータを保存しますが、同じDockerボリュームを使っているという説明ではありません。

永続化は、バックアップの代わりにはならない

同じボリュームにデータが残ることと、過去の状態へ戻せることは別です。誤ってデータを書き換えれば、その変更も保存先へ残ります。保存領域の障害や削除まで、コンテナを分けただけで防げるわけでもありません。 今回確認したのはComposeの保存先とDockerの仕組みです。バックアップの復元試験や、既存DBの再作成は行っていません。「何を作り直すのか」と「どこにデータがあるのか」を図で分けると、実行前に確認すべき対象がはっきりします。

参照：Docker Docs「Volumes」「Networking in Compose」。保存先の対応はAppli Parkのdocker-compose.ymlによります。

確認日：2026年9月22日。画面・実装・検証結果は確認時点のものです。