実際に復元できるバックアップを構築する

必要な復旧から始める

バックアップ計画は2つの実用的な質問から始まります。どれだけ最近の作業を失うことができるか、サービスがどれだけ利用不可のままでいられるか？これらの答えがスケジュール、含めるデータ、復元方法を決定します。毎日のコピーはほとんど変更されないウェブサイトに合うかもしれませんが、忙しいアプリケーションには大きなギャップを残します。

サービスを機能させるものを、単に最大のフォルダだけでなく、すべてリストアップしましょう。アプリケーションデータ、データベースの内容、設定、アップロードされたファイル、環境を再構築するために必要な情報がすべて重要になる可能性があります。依存関係と復旧キーの非公開の目録を保管しましょう。バックアップは、目的が忘れられたアーカイブを生成するだけでなく、動作するシステムをサポートするものであるべきです。

障害境界の外にコピーを保持する

同じマシン上の2番目のディレクトリは、誤った編集からの復旧に役立つ場合がありますが、そのマシンの損失に晒されることに変わりはありません。ローカルスナップショットは迅速なロールバックに価値があるものの、より広範なインシデントには独立したコピーが依然として必要です。別の復旧先を選択し、どのアクセスがバックアップの読み取り、書き込み、削除を行えるようにするかを決定しましょう。

本番環境の認証情報がすべての復旧コピーを削除できる場合、侵害されたアプリケーションアカウントが戦略全体を無効にする可能性があります。可能な限りアクセスを分離し、ストレージの認証情報を保護しましょう。暗号化は保存された内容の保護に役立ちますが、復旧プロセスは、損傷した環境の外部でそのキーを安全に保持することにも依存します。

一貫したアプリケーション状態をキャプチャする

適切な方法を使わずに開いているデータベースファイルをコピーすると、使用不可能な状態を取得する可能性があります。アプリケーションまたはデータベースがサポートするバックアップ手法を使用し、それが一貫したスナップショット、論理エクスポート、または書き込みの一時停止を必要とするかどうかを理解しましょう。アップロードディレクトリとそのデータベース参照がワークフローの同じ時点を表すように、関連するデータを調整しましょう。

除外項目は意図的に文書化しましょう。キャッシュや一時的なビルドファイルは再現可能かもしれませんが、顧客のアップロードは通常そうではありません。機能を追加したりディレクトリを移動した後は、リストを見直しましょう。成功したバックアップジョブは、含まれなかったパスを保存することはできません。

分離環境で復元をテストする

代表的なデータを別の場所に復元し、正しく開くことを確認しましょう。アプリケーションの場合は、ファイルだけでなく復旧したサービスもテストしましょう。テスト環境では送信メール、スケジュールされたジョブ、外部連携を無効にして、リハーサルが実際のユーザーに作用したり、本番タスクを重複させたりしないようにしましょう。

リポジトリの整合性チェックと復元テストは、異なる問いに答えるものです。ツールは保存された構造とデータをチェックできますが、アプリケーションには依然として不足した設定や忘れられたキーが必要な場合があります。復旧にかかる時間、必要な手動ステップ、手順の改善が必要な箇所を記録しましょう。重要な変更の後には、この演習を繰り返しましょう。

実践シナリオ：ローンチ前に復旧をリハーサルする

データベース、ユーザーアップロード、少数の非公開設定ファイルを持つアプリケーションを考えてみましょう。所有者は復旧目録を作成し、データベースがサポートする整合性手法を選択します。別のバックアップ先が必要なコピーを保存し、復旧キーは本番マシンの外部に保管されます。最初のテストは空の分離された環境から始まるため、隠れた依存関係を稼働中のサーバーから借用することはできません。

所有者はデータと設定を復元し、ログイン、代表的なレコード、アップロードされたファイルを確認します。リハーサル中は、送信メール、スケジュールされたジョブ、外部アクションは無効のままです。データベースが起動してもアップロードパスやシークレットが欠けている場合、テストは成功したアーカイブジョブでは明らかにならないギャップを発見したことになります。所有者は目録を修正し、影響を受けた復旧チェックを繰り返します。

最後に、所有者は復元時間と手動ステップを記録します。スケジュールと保持ポリシーは、どれだけ最近の作業が失われる可能性があるか、サービスがどれだけ利用不能なままでいられるかと比較されます。これらはストレージのラベルによって提供される保証ではなく、プロジェクト固有の決定です。テスト済みの手順により、オプションのバックアップやストレージ製品が、より広範な復旧戦略の一部として役立つものになります。

障害を可視化し、保持を意図的にする

静かに停止するバックアップは将来の驚きです。ジョブの完了、利用可能な容量、最新の使用可能な復旧ポイントの経過時間を監視しましょう。後で発見された問題から復旧できるだけの履歴を保持し、プルーニングがその履歴にどう影響するかを理解しましょう。保持の誤りが唯一の有用なバージョンを削除する可能性があるため、削除操作は慎重に確認しましょう。

選択したSwissOctetサービスで、任意のバックアップオプションの範囲を読み、復元プロセスを確認しましょう。Vault Storageは容量コンポーネントとして検討できますが、ストレージ製品だけでは完全な復旧ポリシーにはなりません。何を復元する必要があるかを決定し、コピーを独立させ、サービスが重要になる前に手順を証明しましょう。