Skip to main content
CaseBenderの復旧ポイントは、PostgreSQLに加えて、参照されるすべての正確なオブジェクト バージョン、設定、および暗号鍵です。データベースダンプまたはバケットコピー だけでは、有効な復旧セットではありません。

​
復旧セットの内容

  • PostgreSQLスナップショット/ダンプと移行識別子
  • 記録された profileKey、 objectKey、および providerVersion における、削除されていない確定済みのすべての StoredObject
  • 各オブジェクトのSHA-256とサイズ
  • バックアッププロファイル、バックアップオブジェクトキー、および正確なバックアップバージョン
  • ストレージ/アイデンティティ/CA設定バージョン
  • フィールド、資格情報、監査整合性、認証、および署名キー
  • 不変のCaseBenderイメージダイジェストとリリースマニフェスト
  • タイムスタンプ、承認、ツールバージョン、測定済みRPO/RTO、およびエビデンスダイジェスト
セットを暗号化し、アクセスを制限し、プライマリ 障害ドメインから独立して保管します。バックアップログに資格情報またはオブジェクト内容を書き込んではなりません。

​
一貫性ポイントの取得

ユーザー/統合の書き込みを静止するか、同等の一貫性境界を保証する プロバイダー/データベーススナップショット方法を使用します。ワーカーをドレインまたは永続的に一時停止します。 再開前にPostgreSQLスナップショット/LSNと正確なオブジェクトバージョンを記録します。 オブジェクトインベントリを生成します。
このコマンドはシリアライザブルなデータベーストランザクションを実行し、正確なバージョン、SHA-256、またはサイズメタデータがないオブジェクトを 拒否します。バイトはコピーしません。 承認済みバックアッププロセスは、すべてのマニフェストエントリに対して backupProfileKey、 backupObjectKey、および backupVersionId を設定する必要があります。 完成したマニフェストをハッシュして保護します。

​
コピーポリシー

先にコピーし、プライマリを保持します。最初のバックアップまたは移行ステップとして、破壊的な同期 操作を使用してはなりません。ダウンロードしてSHA-256を計算することでバイトを検証し、 ETagに依存しないでください。 必要なすべての履歴バージョンと保持/ホールド状態を保全します。通常の オブジェクトコピーでは、プロバイダー固有のACL、CMEK、Object Lock、 不変性、リーガルホールド、イベントベースホールド、メタデータ、またはバージョン履歴が保全されない場合があります。 宛先でそれらの制御を証明し、再現してください。

​
隔離リストア検証

同じ互換CaseBenderリリースを使用して、隔離環境にPostgreSQLをリストアします。 マニフェストのデータベース移行と保存オブジェクト メタデータが一致することを確認してから、専用の検証プレフィックスにオブジェクトをリストアします。
スクリプトは各正確なバックアップバージョンを読み取り、サイズとSHA-256を検証し、 隔離ターゲットにアップロードし、ダウンロードして、再度SHA-256を検証します。エビデンス ファイルをモード 0600 で書き込みます。エビデンスレビュー後、承認済みの 保持対応プロセスで隔離プレフィックスをクリーンアップします。 次に、ログイン、組織、ケース、証拠、添付、エクスポート、 スキャナー状態、保持、リーガルホールド、監査チェーン整合性、および認可を検証します。 リハーサルを本番統合に接続してはなりません。

​
プロバイダー固有の注意点

​
S3およびCeph RGW

バージョンIDとすべての削除マーカーを取得します。Object Lockは バケット作成時に存在する必要があり、アダプターから推測できません。コピーされたオブジェクトは 新しいバージョンと保持状態を受け取る場合があります。リストア中は正確な認定済み製品 バージョンとプライベートCAを使用します。

​
Google Cloud Storage

数値世代を取得します。保持ポリシーロック、オブジェクト保持、 イベントベースホールド、CMEKアクセス、均一バケットアクセス、および公開アクセス 防止を検証します。別のバケットにコピーすると世代番号は変わります。

​
Azure Blob Storage

BlobバージョンIDを取得します。セキュア転送、アカウント/コンテナ バージョニング、暗号化キー、不変性ポリシー、およびリーガルホールドを検証します。リストアされた バージョンは宛先固有のIDを受け取ります。

​
ローカルまたはレガシーMinIO

ローカルストレージは本番ターゲットではありません。移行中はレガシーMinIOボリューム スナップショットとAPIレベルの正確なオブジェクトエクスポートの両方を保全し、 MinIOの内部レイアウトを通常ファイルとしてインポートしてはなりません。

​
RPOおよびRTOエビデンス

記録するもの:
  • 最後に含まれたデータベーストランザクションとオブジェクトバージョン
  • 最初に除外されたトランザクション
  • バックアップ所要時間、リストア所要時間、検証所要時間、およびサービス再開 時刻
  • 実際のデータ損失間隔（RPO）と復旧所要時間（RTO）
  • 欠損、変更、読み取り不可、ホールド中、またはポリシーブロックされたオブジェクト
  • ロールバック演習の結果
ポリシー目標はエビデンスではありません。サポートされるすべての リリーストレインおよび重要なストレージ変更後に、測定結果を保持してください。 カットオーバーとロールバックについては ストレージ移行 を、 より広いインストール復旧セットについては バックアップと復旧 を参照してください。