リポジトリの境界を選択する
本番サーバーとは別の保存先と認証情報を使用してください。クライアント側の暗号化は保存されたコピーを保護できますが、リポジトリのパスワードや鍵は非公開でバックアップする必要があります。これを失うと、すべての暗号化スナップショットが使用できなくなる可能性があります。
一貫したデータを取得する
データベースネイティブのダンプまたはアプリケーションがサポートするスナップショット手順を使用してください。設定、デプロイ手順、リカバリーに必要な保護されたシークレットをバックアップしてください。再構築可能であると確認できる場合に限り、一時キャッシュを除外してください。
削除をより困難にする
ソースマシンがすべての履歴コピーを消去できないよう、追記専用または不変の保存先を検討してください。可能な限り、保持と削除の認証情報を分離してください。暗号化だけでは、侵害されたサーバーが書き込み可能なリポジトリを削除することを防げません。
チェックと復旧訓練をスケジュールする
ジョブの終了ステータスと最後の正常なバックアップの経過時間を監視してください。ツールがサポートするリポジトリ整合性チェックを実行してください。定期的にサンプルを復元し、主要なアプリケーション変更後に完全な復旧リハーサルを行ってください。
コピーの追加と履歴の削除を分ける
追記専用の保存先を使用すると、本番サーバーはスナップショットを追加しつつ、削除権限を別の信頼できるマシンに保持できます。保持期間については慎重な検討が依然として必要です。偽造された新しいスナップショットは、一部のカレンダーベースの選択ポリシーを損なう可能性があります。ツールのガイダンスを確認し、保持期間のドライランを実行し、容量を監視してください。Resticのforget操作はスナップショットを選択し、pruneは参照されていない保存データを削除します。
- リポジトリ保守用の認証情報を本番マシンから分離してください
- 削除を許可する前に保存のドライランを実行する
- 各リカバリ演習には新しい空のターゲットを使用する
restic check
restic snapshots
restic restore latest --target /srv/restore-drill公式ドキュメント: Resticの保持とプルーニング
合格条件を伴うリストア演習
現実的な障害を1つ選びます。削除されたファイル、失われたデータベース、またはマシンの完全な再構築です。別のディレクトリまたは分離されたホストに復元します。ファイルの内容、権限、アプリケーションがそれらを使用できることを確認します。所要時間と、ランブックに欠けていた手動手順を記録します。リポジトリチェックは、実際に動作するアプリケーションの復元とは異なる特性を確認するものです。
- 最初のテストとして本番アプリケーション上に復元しないでください
- 暗号化認証情報を独立して復元できることを確認する
- 最新の成功したバックアップが復旧目標を超えた場合にアラートを出してください
除外項目を選ぶ前にリカバリマニフェストを作成する
パッケージの再インストールでは再現できないものを列挙してください。データベースの内容、アップロード、アプリケーション設定、署名または暗号化キー、デプロイのバージョンなどです。各項目の横に整合性の確保方法を記録します。データベースのダンプは特定の時点に属し、稼働中のデータベースディレクトリをコピーすると異なる結果になる可能性があります。リポジトリへのアクセス情報、そのパスフレーズ、Borgキーのエクスポートは、別の非公開の復旧場所に保管してください。唯一の復旧コピーとする前に、代替マシンでリポジトリを開けることをテストしてください。
- 目標復旧時点を定めてください。つまり、直近の作業のうちどれだけが失われ得るかです。その要件に合わせてスケジュールを設定してください。
- 目標復旧時間を明示してください。再構築にどれだけ時間がかかるかを示します。リハーサルにはデータベースのインポートとDNSの変更を含めてください。
- キャッシュ向けの除外設定が、アップロード、コンテナボリューム、保護された設定まで削除していないか確認してください。
- インストールされているBorgのメジャーバージョン向けのドキュメントを使用してください。リポジトリ形式とコマンドは、すべてのバージョン間で互換性があるわけではありません。
公式ドキュメント: Borg：暗号化、整合性、復元
保存データとリポジトリのメタデータの両方を確認してください
Resticのデフォルトのリポジトリチェックと読み取り検証では、役割が異なります。帯域幅と実行時間のコストを考慮して、データ検証をスケジュールしてください。この例では、パックファイルの定義された5分の1をチェックします。以降のスケジュールされたチェックでは、リポジトリ全体をカバーするために残りの割合を使用する必要があります。ランダムに選択されたサブセットでは、同じカバレッジ保証は得られません。どちらの操作も、復元されたデータでアプリケーションが起動できることを証明するものではありません。
restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill公式ドキュメント: restic：リポジトリのチェックとデータ検証
メンテナンスを侵害されたクライアントの手の届かない場所に保つ
Borgの追記専用ストレージはコミット済みセグメントデータを保持しますが、クライアントは表示されるアーカイブ一覧を変更できます。復旧とコンパクションには文書化された管理手順が必要です。リモートバックアップの認証情報は、こうした保護を回避しうる無制限のシェルやファイルシステムログインではなく、Borgのサーバーコマンドに限定してください。resticの場合は、追記専用保持におけるkeep-withinのガイダンスを確認してください。履歴を削除しうるメンテナンスの前に、信頼できるマシンでリポジトリの健全性を確認し、選択内容をプレビューしてください。
- 最後に成功したコピーの経過時間、リポジトリの増加、キャッシュ容量、両端の空き容量を監視してください。
- リストアが失敗した場合は、修復やクリーンアップを試みる前に元のリポジトリとログを保存してください。
- ジョブは成功したものの想定したファイルが見つからない場合は、保持期間を変更する前にアーカイブの内容と除外パターンを確認してください。
- ドリルを完了するには、ファイルを開き、アプリケーションのチェックを分離環境で実行してください。復元コマンドには本番環境の宛先を含めないでください。
公式ドキュメント: Borg: 追記専用の運用と保守 · restic：保持期間と追記専用に関する考慮事項