Dockerのvolumeとは？DBデータを消さないための永続化の基本

Docker を触り始めた人がかなりの確率でハマるのが、あれ、コンテナ作り直したらデータ消えた です。
アプリ本体はまた作ればよくても、データベースやアップロードファイルまで消えると一気に怖くなります。

この記事では、2026年4月21日時点で Docker Docs の Storage Volumes Bind mounts docker compose down を確認しながら、ボリューム とは何か、データベースのデータを消さないために何を見ればよいかを初心者向けに整理します。
Docker 全体の基本から見たいなら、Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説 から読むと流れがつかみやすいです。Docker Composeを本番で使う判断は、Docker Composeは本番で使っていい？小規模運用の判断基準と注意点 でも整理しています。

なぜ Docker でデータが消えるのか

まず前提として、コンテナ 本体の書き込み領域は、長く残す前提の保存場所 ではありません。
止めただけで即消えるとは限りませんが、コンテナを削除したり作り直したりすると、その中に直接置いたデータは消えやすいです。

Docker Docs でも、コンテナデータの永続化は volumes や bind mounts を使って外へ出す考え方で整理されています。
つまり、何も考えずにコンテナの中へだけデータベースのデータを書いていると、環境の作り直し と一緒にデータも消えやすいです。

初心者向けにかなりざっくり言うと、こうです。

• コンテナ本体: 作り直しやすいが、一時的
• ボリューム: 残したいデータの置き場

ボリュームとは何か

ボリューム は、コンテナ外にデータを保持して、永続化しやすくするための仕組みです。
Docker Docs でも、volumes は persistent data stores for containers とされています。

たとえば、MySQL コンテナを立てるときに、データベースのデータをボリュームへマウントしておけば、コンテナを作り直してもデータを残しやすくなります。

要するに、ボリュームは 消えて困るデータを、コンテナ本体とは別で持つ仕組み です。

一番よくある例はデータベースのデータ

これはかなり実務的です。
アプリコンテナは更新や作り直しがあっても、データベースのデータまで巻き込んで消えるのは困ります。

たとえば Compose なら、こういう形です。

services:
  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

この db-data が named volume です。
こうしておくと、データベースコンテナを消して作り直しても、同じボリュームを使う限りデータを保持しやすくなります。

逆に、ボリューム無しでデータベースを立てると、開発中に down したらデータが消えた でかなりハマりやすいです。

データベースのデータはどこに保存されるのか

MySQLやPostgreSQLの公式イメージには、データを保存する標準的なディレクトリがあります。
MySQLならよく見るのは /var/lib/mysql、PostgreSQLなら /var/lib/postgresql/data です。

Dockerでデータベースを使うときは、まずこの「データベースが実際にデータを書く場所」にボリュームをつなぎます。
アプリの設定ファイルや初期化SQLをマウントしていても、肝心のデータディレクトリが永続化されていなければ、データは守れません。

確認するときは、Composeファイルで次を見ます。

• データベースサービスに volumes: があるか
• db-data:/var/lib/mysql のように、データディレクトリへつながっているか
• volumes: のトップレベルに named volume が定義されているか
• 本番データなら、バックアップ先と復元手順があるか

たとえば次のような設定なら、db-data というDocker管理のnamed volumeをMySQLのデータディレクトリへつないでいます。

services:
  db:
    image: mysql:8.4
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

ここで大事なのは、db-data という名前そのものではなく、データベースがデータを書く場所に正しくマウントされているかです。
マウント先を間違えると、ボリュームを定義していてもデータベースのデータが守れていないことがあります。

named volume と bind mount は何が違うのか

似て見えますが、Docker が管理するか、ホストOSのパスが直接管理するかで使いどころが大きく変わります。

docker compose down と down -v の違い

初心者が一番怖い事故を起こしやすいのが、docker compose down -v です。

通常の docker compose down は、Composeで作ったコンテナやネットワークを停止・削除します。
一方で、-v または --volumes を付けると、Composeファイルの volumes セクションで宣言されたnamed volumeや、コンテナに付いた匿名volumeも削除対象になります。

つまり、データベースのデータをnamed volumeに置いている環境で、意味を分からずに down -v を実行すると、データを入れたボリュームまで消す可能性があります。

ボリューム名を確認する

Composeで作ったボリューム名は、プロジェクト名が前に付くことがあります。
たとえば db-data と書いていても、実際のDocker上では myapp_db-data のような名前になることがあります。

確認には次のコマンドを使います。

docker volume ls
docker volume inspect myapp_db-data
docker compose config

docker volume inspect では、ボリュームの詳細やマウントポイントを確認できます。
ただし、Docker Desktopや環境によってホスト上の見え方は違うため、ホストのファイルを直接触る前提にしない方が安全です。

実務では、Composeファイル、docker volume ls、データベースコンテナのマウント先を合わせて見ます。
「どのボリュームがどのデータベースに対応しているか」をメモしておくだけでも、復旧時の混乱をかなり減らせます。

じゃあ何が消えて、何が消えないのか

ここをざっくり整理すると、かなり分かりやすいです。

消えやすいもの

• コンテナ本体の writable layer にだけ書いたデータ
• コンテナ削除前提で置いた一時ファイル
• tmpfs のようなメモリ上の一時データ

残しやすいもの

• ボリュームに置いたデータベースのデータ
• bind mount でホスト側へ保存したファイル
• 外部ストレージへ逃がしたデータ

大事なのは、Docker を使っているか ではなく、どこへ書いているか です。

bind mount が向いている場面

bind mount は、ホストのフォルダをそのままコンテナへ見せる仕組みです。
Docker Docs でも、ホストとコンテナの両方からファイルへアクセスしたい場面に向いていると説明されています。

たとえば、

• ローカルのソースコードをコンテナから読みたい
• エディタで編集した内容をすぐ反映したい

といった開発用途ではかなり便利です。

ただし、ホストのパス構成や権限にも影響されやすいので、永続化の基本を全部 bind mount で済ませるより、用途で分けた方が分かりやすいことが多いです。

実務でどう考えると失敗しにくいか

1. 消えて困るものを先に分ける

まず、何が消えたら困るかを決めます。
データベースのデータ、アップロードファイル、ユーザー生成データはかなり優先度が高いです。

2. アプリ本体とデータを分ける

アプリ本体は作り直してよい、データは残す、という切り分けがかなり大事です。
この考え方があると、デプロイやトラブル時も整理しやすくなります。

3. ボリュームがあるだけで安心しない

ボリュームは永続化に役立ちますが、バックアップの代わりではありません。
実務では、ボリュームがあってもバックアップと復旧確認は別で必要です。
ここは バックアップは何世代必要？実務で多い考え方・復旧確認・具体的な戻し方を解説 もかなりつながります。

データベースの場合は、volumeディレクトリを丸ごとコピーすれば常に安全、とは限りません。
データベースが動いている最中のファイルを雑にコピーすると、整合性の問題が出ることがあります。MySQLなら mysqldump や物理バックアップの手順、PostgreSQLなら pg_dump など、データベースとして安全に取り出す方法を検討します。

小規模なら、まずは次の形でも十分な第一歩になります。

• 日次でSQLダンプを取る
• ダンプをサーバー外へ転送する
• 何世代残すか決める
• 復元コマンドをメモする
• 月1回でも復元テストをする

ボリュームは「コンテナを作り直しても残す」ための仕組みで、バックアップは「サーバー障害・誤削除・破損から戻す」ための仕組みです。
この2つを混ぜないことが、データベースのデータを守るうえでかなり大事です。

Docker ボリュームに関するよくある質問

docker compose down ではボリュームは消えますか？

通常の docker compose down ではコンテナとネットワークは削除されますが、named volume は保持されます。-v または --volumes を付けたときだけ named volume も削除対象になります。匿名 volume はコンテナと一緒に消えることがあるので、データベースのデータは必ず named volume に置いてください。

named volume と bind mount、どちらを使うべき？

データベースのデータや永続データは named volume、ローカルのソースコードを開発中に共有したい場合は bind mount が定番です。両方を混ぜて使うのは普通で、たとえばアプリ本体は bind mount、DB データは named volume、という構成がよく使われます。

ボリュームがあればバックアップは不要ですか？

不要にはなりません。ボリュームは「コンテナを作り直しても残す」ための仕組みであって、サーバー障害・誤削除・破損から戻すための仕組みではありません。データベースなら mysqldump / pg_dump で定期バックアップを取り、できれば月1回でも復元テストを行ってください。

ボリュームのデータをホストにコピーするにはどうすれば？

named volume は docker run --rm -v <volume>:/source -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz -C /source . のように、一時コンテナを使ってアーカイブするのが定番です。データベースが動作中の場合は、ファイルを直接コピーする前にデータベース側の整合性確保（mysqldump 等）を優先してください。

ボリュームの中身を直接ホストから触ってもいい？

Docker Desktop や OS によって挙動が変わるため、named volume を直接ホストから触る前提にはしない方が安全です。中身を確認したいときは docker volume inspect でマウントポイントを調べるか、一時コンテナを起動して中で操作する方が確実です。

Compose のプロジェクト名が変わるとボリュームはどうなる？

named volume には Compose プロジェクト名がプレフィックスとして付くため（例: myapp_db-data）、プロジェクト名（通常はディレクトリ名）が変わると別ボリュームとして扱われます。データを引き継ぎたいときは COMPOSE_PROJECT_NAME を明示的に設定するか、docker volume ls で確認してから操作してください。

まとめ

ボリューム は、Docker でコンテナ外にデータを保持して、消えにくくするための仕組みです。
Docker でデータが消える・消えないの違いは、コンテナ本体に置いたか ボリュームや bind mount に逃がしたか でかなり決まります。

最初は、

• データベースのデータはボリューム
• ローカルのコード共有は bind mount
• ボリュームはバックアップの代わりではない
• down -v はデータベース入り環境で安易に使わない

くらいで分けるだけでもかなり理解しやすいです。
続けて読むなら、Docker Composeとは？複数コンテナをまとめて動かす基本を初心者向けに解説、Docker Composeは本番で使っていい？小規模運用の判断基準と注意点、Dockerイメージとは？コンテナとの違いを初心者向けにわかりやすく解説 もつながりやすいです。

参考リンク

• Docker Docs: Storage
• Docker Docs: Volumes
• Docker Docs: Bind mounts
• Docker Docs: docker compose down