NASスナップショットの前に、アプリコンテナを一時停止すべき？それともアプリケーションバックアップを使うべき？

安全なアプローチは、アプリのバックアップ、調整済みの静止化、またはスナップショット前の正常停止のどれをワークロードごとに選ぶかを、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。

スナップショット機能を備えたNAS上でコンテナ化されたアプリケーションを運用する場合、実際のリスクは、稼働中のNASスナップショットからステートフルコンテナの状態を一貫して復元できるかどうかが不確かなことです。現在の識別情報とリカバリポイントを記録し、最も影響の小さい判別方法から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復元可能なコピーが1つしかなく、それが危険にさらされる場合は中止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーション境界に達した時点でのみ完了します。

スタックに触れる前に整合性の方針を決める

アプリまたはデータベースにネイティブのバックアップ機能がある場合は、それを使用します。調整済みの静止化とスナップショットのフックは、データベースがそのワークフローをサポートしている場合にのみ使用し、短時間の停止が許容される場合は正常停止を使用します。単純なコンテナの一時停止は、せいぜいクラッシュ整合性を保つものとして扱い、自動的にアプリケーション整合性が得られるとは考えないでください。

この区別が重要なのは、Docker pauseの動作が、通常のシャットダウンおよびフラッシュ処理を実行せずにプロセスを凍結するためです。非常に短時間のファイルシステムスナップショット中に新たな書き込みを停止することはできますが、データベースのバッファ、ジャーナル、添付ファイル、依存サービスが復元可能なアプリケーション状態を表していることを証明することはできません。

データベースエンジン、アプリのバックアップ機能、ボリュームパス、アップロードパス、シークレット、イメージのバージョン、許容できる停止時間を記録します。ステートフルなコンポーネントが1つでも不明な場合、判断は未解決のままであり、テスト済みバックアップとしてスナップショットを昇格させてはなりません。

影響を最小限に抑えた有効な方法を選ぶ

PostgreSQL、MariaDBなどのサービスデータベースでは、サポートされているダンプまたは物理バックアップの手順を優先します。SQLiteでは、利用可能であればアプリのエクスポートまたはSQLiteオンラインバックアップを使用します。データベースが存在しないファイルや将来のファイルを参照しないよう、アップロードされたファイルと設定も同じリカバリウィンドウ内で取得します。

サポートされたオンライン方式がない場合は、まず書き込み元を停止し、次にデータベースを正常に停止して、スナップショットを取得する前にプロセスが終了したことを確認します。一時停止は、この特定のワークロードでクラッシュリカバリが十分であることがドキュメントと復元テストによって示されている場合に限り、限定的なつなぎとして使用できます。アプリケーションバックアップの一般的な代替手段ではありません。

小規模なホームサーバースタックでは、データベースネイティブのダンプと正常停止したコピーについて、関連する一貫性のあるデータベースコンテナバックアップに従うことができます。この記事の範囲はより限定的に保ってください。ここではスナップショット前の操作を決定し、リンク先のガイドではより広範なバックアップパッケージの内容を扱います。

調整済みのスナップショットウィンドウを実行する

スケジュールされたジョブとユーザーによる書き込みを一時停止し、選択したアプリまたはデータベースの準備処理を実行して、ファイルシステムのスナップショットを作成する前に成功を確認します。スナップショットを迅速に作成したら、静止化を解除するかスタックを再起動します。その後でスナップショットをコピーまたはレプリケートし、停止時間と転送時間が同じにならないようにします。

すべてのカスタムフックに失敗時のトラップを追加します。準備に失敗した場合はスナップショットを取得しません。スナップショットの作成に失敗した場合は、必ずアプリケーションを再開します。再開に失敗した場合は、ユーザーを締め出したまま、意図的にサービスを復元します。各遷移をログに記録し、静かな事前フックのタイムアウトによってバックアップジョブが誤って成功したように見えないようにします。

アプリが通常の状態に戻り、スナップショットに想定したタイムスタンプとデータセットがあり、依存関係がウィンドウ外で取得されていなければ成功です。コンテナが一時停止したままになっている場合や、通常のスナップショットごとにデータベースがリカバリを報告する場合は、自動化をロールバックします。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

分離した復元で選択を検証する

スナップショットまたはネイティブバックアップを、異なるポートとストレージパスを使用する使い捨てのプロジェクトに復元します。まずデータベースを起動して整合性チェックを実行し、次にアプリを接続して、最近のレコード、ユーザー、添付ファイル、スケジュール済みジョブ、権限を確認します。本番データベースに対してテストしないでください。

成功には、コンテナが正常に起動するだけでは不十分です。アプリが復元された状態を読み取り、更新できること、関連ファイルがデータベースの参照と一致すること、2回目の再起動後も正常な状態が維持されることが必要です。クラッシュ整合性のあるスナップショットに依存する予定がある場合は、その結果をネイティブバックアップの復元結果と比較します。

元のワークロードがこのテストに合格してから、スナップショット方式を使用します。一時停止ベースの復元が断続的にしか成功しない場合、データベースの修復が必要な場合、または1つのコンポーネントでも同じリカバリポイントに結び付けられない場合は、アプリケーションネイティブのバックアップまたは正常停止に切り替え、失敗したスナップショットを上書きせず証拠として保持します。