Google Cloud Well-Architected Framework の信頼性の柱におけるこの原則では、データ損失からの復元をテストするうえで役に立つ推奨事項が示されています。
この原則は、信頼性の学習 重点分野に関連しています。
原則の概要
データが失われたり破損したりする状況からシステムを復元できるようにするには、これらのシナリオのテストを実行する必要があります。データ損失のインスタンスは、ソフトウェアのバグや自然災害によって発生する可能性があります。このようなイベントが発生した場合は、バックアップからデータを復元し、新しく復元したデータを使用してすべてのサービスを再度起動する必要があります。
このタイプの復元テストの成功または失敗を判断するには、データ整合性、目標復旧時間（RTO）、目標復旧時点（RPO）の 3 つの基準を使用することをおすすめします。RTO 指標と RPO 指標の詳細については、DR 計画の基本をご覧ください。
データ復元テストの目的は、組織がビジネス継続性の要件を継続的に満たせることを定期的に確認することです。RTO と RPO の測定に加えて、データ復元テストには、復元されたデータを使用したアプリケーション スタック全体とすべての重要なインフラストラクチャ サービスのテストを含める必要があります。これは、デプロイされたアプリケーション全体がテスト環境で正しく動作することを確認するために必要です。
推奨事項
データ損失からの復元テストを設計して実行する場合は、次のサブセクションの推奨事項を考慮してください。
バックアップの整合性を確認し、復元プロセスをテストする
バックアップに、アプリケーションをすぐに復元してサービスを再開できる、整合性のある使用可能なデータのスナップショットが含まれていることを確認する必要があります。データの整合性を検証するには、各バックアップ後に実行される自動整合性チェックを設定します。
バックアップをテストするには、非本番環境で復元します。バックアップを効率的に復元し、復元されたデータがアプリケーションの要件を満たすようにするには、データ復元シナリオを定期的にシミュレートします。データ復元の手順を文書化し、障害発生時に手順を効果的に実行できるようチームをトレーニングします。
定期的なバックアップを頻繁にスケジュールする
復元中のデータ損失を最小限に抑え、RPO 目標を達成するには、定期的にスケジュール設定されたバックアップが不可欠です。RPO に合わせてバックアップの頻度を設定します。たとえば、RPO が 15 分の場合は、少なくとも 15 分ごとにバックアップを実行するようにスケジュールします。バックアップ間隔を最適化して、データ損失のリスクを軽減します。
Cloud Storage、Cloud SQL 自動バックアップ、Spanner バックアップなどの Google Cloud ツールを使用して、バックアップをスケジュールして管理します。重要なアプリケーションの場合は、Cloud SQL のポイントインタイム リカバリ（PITR）や、大規模なデータセットの増分バックアップなど、ほぼ継続的なバックアップ ソリューションを使用します。
RPO を定義してモニタリングする
ビジネスニーズに基づいて明確な RPO を設定し、RPO の遵守状況をモニタリングします。バックアップ間隔が定義された RPO を超える場合は、Cloud Monitoring を使用してアラートを設定します。
バックアップの健全性をモニタリングする
Google Cloud Backup and DR サービスなどのツールを使用して、バックアップの健全性を追跡し、安全で信頼性の高い場所に保存されていることを確認します。復元性を高めるために、バックアップが複数のリージョンに複製されていることを確認します。
バックアップ以外のシナリオを計画する
バックアップと障害復旧戦略（アクティブ / アクティブ フェイルオーバー設定やクロスリージョン レプリケーションなど）を組み合わせて、極端なケースでの復元時間を短縮します。詳細については、障害復旧計画ガイドをご覧ください。