はじめに
今回はつい最近やってしまった Docker で運用していた Nextcloud のボリュームを誤って初期化してしまった失敗談 を共有します。
「AI の提案どおりにコマンドを実行してしまい、データが全部飛びました！」という苦い経験です。同じ過ちを繰り返さないための 再発防止策 もまとめています。
事の発端
現在DockerComposeを使ってNextcloud+MariaDBの構成でクラウドサーバとして利用していました。 ところがある日、別のサービス（OJS）の設定でつまずき、docker-compose down --volumes を何の気なしに実行してしまったのです。これが 大惨事 の原因でした。
よくあるコマンド例
docker-compose down --volumes --remove-orphans
なぜこんなコマンドを？
とある AI（某Chat⚪︎⚪︎⚪︎）に質問していたところ「Docker コンテナや不要なボリュームをすべて片付けるコマンド」として --volumes オプションを指定した docker-compose down を提案されたのです。
自分の中で「ボリュームを消すとデータは消えるはずだよな」と知識はあったはずなのに、（年末疲れと体調が良くなく、実際この後4日寝込む）AIの回答をそのまま実行してしまい… 結果: Nextcloud のデータディレクトリが格納されていたボリュームも容赦なく削除されました。
どんな被害があったか
- Nextcloud 上のファイル全削除:
docker volumeが消えたことでコンテナのストレージ領域も再初期化。 - MariaDB のデータベース消失: DB 用ボリュームも一緒に削除してしまい、ユーザ情報やアプリ設定が全て初期化。
-
config.phpなどの設定ファイルも（マウントを間違えていれば）巻き込まれる。
Docker Compose のメリットとして幸いにも データボリュームは残っていた いたのが救いでした泣
もしバックアップがなければ…
今回は定期的に手動バックアップを取っていたのとデータボリュームが残っていたので、最悪な事態は免れました。しかし、それでも かなりビビりました。
なぜこのような事が起きたのか
1. AI の提案をうのみにしてしまった
ChatGPT や他の LLM（大規模言語モデル）は、ユーザのコンテキストによっては 最適解ではない コマンドを返すことがあります。
-
docker-compose down --volumesは"一見"整合性のとれたコマンドに見えるものの、実際には本番データを一緒に消去するリスクがある。
「自分は知識があるはず」という油断で、AI の提案を深く検証せずに実行したのが原因でした。
2. 作業環境の区分があいまい
本来はローカル開発環境なら down --volumes で一掃するのはよくある話です。しかし、本番運用中 (あるいは重要データが入っているステージング) では絶対にやってはいけません。
- 本番環境での作業に、開発環境のノリを持ち込んでしまった
- Docker Compose のオプションを明確に把握しないまま使っていた
これは個人利用だった事もあるのとOJSを早く構築したくて急いでいたこと。しんどかった事が重なったのが原因だと思います。
3. ボリュームのマウント先が意識できていなかった
再発防止策
1. 定期バックアップの徹底
- mysqldump + Nextcloud データディレクトリ の定期アーカイブ
- できれば
cron + rcloneなどでクラウドストレージへ自動バックアップ -
Docker ボリュームも
docker run --rm -v <volume_name>:/data -v $(pwd):/backup busybox tar cvf /backup/ncdata.tar /dataのようにアーカイブしておく
2. 大事なサービスは docker-compose down --volumes を使わない
- 開発用テンポラリサービスならまだしも、本番運用や実運用中のデータがあれば
--volumesは危険。 - どうしても削除が必要な場合は 対象のボリューム名を限定 して消す。例えば
docker volume rm myapp_cacheのように、不要ボリュームだけ削除する。
3. Docker Compose の定義を見直し
- ホストマシン側のディレクトリをバインドマウントにする方法（メリット：ホストファイルが消されにくい / デメリット：パーミッション管理が煩雑）
- Named Volume を使う場合は 2段構えのバックアップを必ず用意。
-
.envなどで本番環境と開発環境を分け、本番で--volumesが実行されないよう注意書きを入れる。
4. AI の回答を鵜呑みにしない
- AI が提案するコマンドを実行するときは 本当に大丈夫か？を自分の目で確かめる。
- もし不明点があれば「down --volumes で何が消えるのか？」と追加質問してリスクを再確認。
- 「これは危険な操作では？」という警戒心 を常に持つ。
これが1番言いたかった事です。
最近のAIは進化が凄くて信じきってしまっていました。
あとは背景コンテキストを正確に入力しておく事。これも防止には重要だと思いました。
いずれにせよ悪いのはじぶん。
5. Docker Volume やオプションの意味を再整理
-
docker-compose downはコンテナを止めて削除するだけ -
--volumesを付与すると ボリュームも一緒に削除 -
--remove-orphansは定義されていないコンテナ(サービス)を削除 -
docker volume pruneは未使用ボリュームを一括削除 - 「未使用かどうか」の判断が誤解を生むケースもあるため注意。
まとめ
Docker がもたらす手軽さと柔軟性の裏には、「本番ボリュームを簡単に削除できてしまう」リスクが隠れています。 今回は Nextcloud のデータボリュームを誤って消してしまった 失敗例でしたが、サービス名が違うだけで、同じような事故は各所で起きているでしょう。
- 最大の防御策はこまめなバックアップ
-
本番環境での
docker-compose down --volumesは厳禁 - AI の回答でも必ず自分の環境に合っているかチェック
これらを徹底して、私と同じ悲劇を繰り返さないよう気をつけてください！
参考リンク
以上が私の Docker 失敗談 でした。もし「自分もやらかしたことある...」という方は、ぜひコメントで失敗体験や防止策をシェアしていただけると嬉しいです！