アプリスタック全体を置き換えずに、1つのコンテナだけ復元できますか？

はい、構成、永続データ、依存関係の境界がスタックの他の部分から明確に分離されていれば、1つのコンテナだけを個別に復元できます。

ホームNASでは、表示上のコンテナは通常使い捨てですが、アプリの状態はバインドマウント、名前付きボリューム、別のデータベース、シークレット、プロキシルート、共有ネットワークにまたがっている場合があります。そのため、安全な単一サービス復元とは、1つのコンテナIDを元の場所に戻すことではありません。対象サービスを停止し、そのサービスが所有する状態だけを復元し、既知の定義から再作成したうえで、共有依存関係と正常な周辺コンテナに変更がないことを確認することを意味します。

停止する前に復元単位を定義する

障害が発生した正確なサービスを特定し、所有するすべてのオブジェクトを一覧化します。Composeのサービス名、イメージタグまたはダイジェスト、環境変数ファイル、シークレット、バインドマウント、名前付きボリューム、公開ポート、ネットワークエイリアス、スケジュール済みジョブ、リバースプロキシのラベルなどです。

Dockerボリュームの復元ガイドでは、永続ストレージをバックアップおよび個別に復元できるよう、コンテナのランタイムと分けて扱います。実践的な手順では、実行中のコンテナだけを復旧対象とみなすのではなく、コンテナとボリュームを分けて復元する方法が紹介されています。

アプリが共有データベースや共有ボリュームに書き込む場合、復元単位にはその共有依存関係も含まれるため、安全に分離できなくなる可能性があります。所有関係が明確になるまで、上書きは行わずに停止してください。

正常なスタックと障害サービスの状態を記録する

現在のComposeファイル、解決済みの環境変数、イメージダイジェスト、マウント一覧、ネットワーク参加状況、ヘルス状態、直近のログをエクスポートまたは保存します。復元時に影響を及ぼさない範囲を明確にするため、正常な周辺サービスも記録してください。

サービス単位のCompose操作では、すべてを再起動せず、名前を指定した1つのサービスだけを対象にできます。Linux Handbookの単一サービスの手順では、1つのComposeサービスとスタック全体に対する操作を区別しています。ただし、設定を変更した場合は、単純な再起動ではなく再作成が必要になることも説明されています。

障害が発生したサービスだけで、自動更新と再起動ループを無効にします。整合性を保つために連携停止が必要でない限り、データベースや共有インフラは稼働させたままにしてください。

まず分離した場所にデータを復元する

選択したバックアップは、稼働中のパスに直接上書きせず、一時ディレクトリまたは新しいボリュームに復元します。ファイル数、所有者、タイムスタンプ、データベースダンプのメタデータ、アプリケーションのバージョンを、破損した状態と比較してください。

ボリュームバックアップのプロジェクトでは、一時的なワンオフコンテナを使って対象ボリュームをマウントし、データを再投入する方法を説明しています。これにより、プロダクションサービスが書き込みを開始する前に、分離されたボリューム復元経路を作成できます。

データベースでは、可能な限りアプリケーションに対応したダンプまたは復元方法を使用してください。実行中のデータベースをファイルコピーしただけでは、最善でもクラッシュ整合性しか得られず、古いコンテナを削除した後に失敗する可能性があります。

マウントを切り替える前に、分離したコピーを検証します。バックアップを読み取れない場合や、そのスキーマが対象イメージと一致しない場合は、現在の状態を保持し、別の復旧ポイントを選択してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

元の識別情報を維持して障害サービスだけを再作成する

保存したCompose定義から、指定したサービスだけを再作成します。その際、同じプロジェクト名、外部ネットワーク、サービスエイリアス、ポート、シークレット、UID/GIDマッピング、検証済みの永続パスを維持してください。

データを正しく復元した後でも、所有者やセキュリティラベルが実行ユーザーと一致しなくなっていると、マウントへのアクセスに失敗することがあります。Rocky Linuxのコンテナ事例では、データを再コピーするのではなく、所有者とセキュリティコンテキストを確認することで、ボリュームにアクセスできない問題を解決しました。

ボリュームを削除したり、スタック全体に対するpruneコマンドを実行したりせずにサービスを起動します。復元したデータをマイグレーション、スキャン、バックグラウンドジョブが変更する前に、実際に適用されているマウントを確認してください。

依存関係を復元せずに再接続する

復元したコンテナから、データベース、キャッシュ、IDプロバイダー、オブジェクトストレージ、プロキシネットワークへのDNS名前解決とTCP接続をテストします。復旧した設定で定義されている同じサービス名と認証情報を使用してください。

共有依存関係が正常に動作している場合、アプリケーションが接続できないという理由だけで、それを復元または置き換えないでください。ネットワークエイリアスの欠落、ローテーションされたシークレット、スキーマの不一致、誤ったデータベース名によって、正常な依存関係が利用できないように見えることがあります。

復元したアプリのバージョンとデータベースバックアップの要件に応じて、必要な場合にのみマイグレーションを実行します。取り消しできないマイグレーションの前に依存関係をバックアップし、アプリが空のデータベースを初期化しようとした場合は停止してください。

トラフィックを戻す前に単一サービスの境界を検証する

ログイン、読み取り、書き込み、アップロード、スケジュール済みジョブ、API呼び出し、プロキシ経由のアクセス、制御された再起動を1回テストします。復元前に記録した状態と、周辺コンテナの再起動回数、ログ、ポート、データチェックサムを比較してください。

ZimaSpaceの永続コンテナ状態のマッピングに関するガイドでも、同じ復旧原則が示されています。つまり、想定上のコンテナシェルではなく、状態を所有する対象を復元します。

復元が完了するのは、復旧したサービスが意図したデータと依存関係を使用し、正常なスタックメンバーに変更がなく、もう一度再作成しても同じ結果になることを確認できたときです。共有状態を分離できない場合は、部分的なロールバックを無理に行わず、スタック全体を調整した復元へ切り替えてください。