Docker volumeのバックアップだけで復元できるかを確かめる

運営・編集: 村上祥太（公式ドキュメント・一次情報の確認と構成をもとに編集。有償VPSでの比較実測はまだ実施していません）

Docker volumeはコンテナを作り直しても残せる永続ストレージだが、volumeを一つ退避しただけで復元が完成するとは限らない。特にデータベースは、コピーした時点の整合性、設定、認証情報、アプリ側のバージョンがそろって初めて戻せる。バックアップは「ファイルがあること」ではなく、隔離した場所で復元確認まで通ったときに役に立つ。

Docker公式はvolumeをコンテナのためにDockerが管理する永続ストレージと説明し、バックアップ・復元・移行の例も掲載している。次の表はその仕様を前提に作った確認表であり、実機の復元結果ではない。確認日: 2026年9月12日。Docker公式: Volumes

volumeが残すもの、残さないもの

named volumeはDockerホスト上に保存され、コンテナへマウントして使う。コンテナの削除とvolumeの削除は別の操作だが、どのデータがどのvolumeへ入るかをComposeファイルから追えないと、退避漏れが起きる。アプリの設定がbind mount、環境変数ファイル、外部のオブジェクトストレージに分かれている場合、volumeアーカイブだけでは足りない。

Docker公式の例では、別コンテナからvolumeをマウントし、ホスト側のバックアップ先へtar形式で退避する流れが示されている。これはvolume内容を扱う方法の一つであり、データベースが処理中でも安全な完全バックアップを自動で保証する仕組みではない。DB製品の公式手順にある論理バックアップ、スナップショット、停止方法を確認して採用する。

データベースは整合性を別に考える

DBのデータディレクトリを稼働中に単純コピーすると、書き込み途中の状態が混ざる恐れがある。許容される方法はDBの種類、バージョン、バックアップ方式で変わる。たとえばPostgreSQLを使うなら、採用中の公式資料で論理バックアップと復元、物理バックアップの前提を確認する。Dockerのvolume機能はDBのトランザクション整合性までは判断しない。

n8nでは、初回起動時に暗号化キーが作られ、認証情報をDBへ保存する前の暗号化に使われる。自分で N8N_ENCRYPTION_KEY を設定する構成なら、その値を失わずに復旧できる保管場所を別に持つ必要がある。鍵そのものをバックアップ本文やGitへ置かず、復旧時に取り出せる保管場所と担当を決める。n8n公式: カスタム暗号化キー

復元テストで確認する項目

本番へ戻す前に、別名のvolumeや隔離したホストで復元できるかを試す。既存volumeへ上書きする復旧テストは、失敗すると元データを損ねるため避ける。確認は次の順にすると、失敗箇所を分けやすい。

1. アーカイブの作成日時、対象volume、サイズ、保存先を記録する。
2. 復元先を本番と分離し、同じイメージ識別子と必要な設定を用意する。
3. DBまたはアプリが起動するかを確認する。
4. 件数や代表レコードなど、秘密を表示しない確認項目で内容を照合する。
5. 外部Webhook、メール、AI APIなどの送信先を止めたうえで、テストデータによる最小経路を一件だけ確認し、結果を記録する。

この手順で失敗した場合は、volumeアーカイブの欠落、アプリ版の不一致、環境変数不足、DB整合性のどこで止まったかを残す。復元に必要なものが判明した時点で、バックアップ対象表を直す。世代数や保管期間は、消えて困る期間と利用中のストレージ条件から決め、根拠なしに固定値を置かない。

参考資料

• Docker公式: Volumes（確認日: 2026年9月12日）
• n8n公式: カスタム暗号化キー（確認日: 2026年9月12日）