コンテナを作り直す前に：ボリューム・成果物・バックアップの所在を分ける
コンテナを更新する前に、必要なデータをコンテナ外の保存先へ分けます。再起動できても、設定・成果・データベースが残るとは判断しません。保存先と復元方法が決まるまで更新を保留します。
公式資料確認日：。
ファイルが見えるだけで永続化を判断しない
containerの書込みlayerにあるのか、volumeなのか、bind mountなのかを実際の構成で確認します。imageに入っているfileと実行後に変わったfileを分けます。外部databaseやobject storageの内容はcontainer imageの再作成だけでは戻りません。
一つのfixtureで所在を確かめる
| 確認対象 | 判断に使う記録 | 次の選択 |
|---|---|---|
| 設定 | image／環境変数／mount／secret | 新containerで同じ条件を再現 |
| 成果 | 保存pathとvolumeの識別 | 同名の別volumeへ接続しない |
| database | appの整合性と取得時刻 | fileのcopyだけで十分か確認 |
| backup | containerと別の保存先・復元権 | volumeの存在をbackupとしない |
架空例：起動はしたが成果が消えた
成果をcontainer内部へ保存したまま再作成すると、以前の成果が見えなくなる構成があります。試験用containerで小さなfixtureを保存し、再作成・再接続・成果照合の順に試します。本番のcontainerやvolumeを検証目的で削除しません。
ボリュームにも復旧条件を置く
volumeが残っていても、誤更新やhost故障から復元できるとは限りません。配置、権限、backup、復元先を確認します。安いhostへの移行を選ぶ前に、データがどこへ移り、誰が読めるようになるかを同じ表で確かめます。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- Docker volumes
Dockerのvolumeはcontainerの書込み層とは別にデータを保持します。保持されることと、別の障害範囲にバックアップがあることは別です。