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