# 12 – データ回復の計画
**SAP ワークロードの論理的なデータ関連の復旧をどのように計画しますか?** ビジネス要件から逆算して、ビジネスデータを復旧または再構築するためのアプローチを定義します。回復力をどのように設計したかに応じて、さまざまなシナリオがこのカテゴリに当てはまる可能性があります。少なくとも、バックアップまたは災害対策 (DR) によって、偶発的な削除、論理データの破損、およびマルウェアからユーザーを保護する必要があります。サービスに戻るまでの時間とシステム間の依存関係を考慮して、復旧の決定について慎重に検討します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-12.html)
# ベストプラクティス 12.1 – ビジネスデータの一貫した復旧方法を確立する
データの損失や破損が発生した場合に、個々のシステムのビジネスデータの一貫性を確保するのに役立つデータ復旧計画を定義します。
**提案 12.1.1 - データベースの状態を認識するバックアップメカニズムを使用して、一貫性のあるバックアップを実現**
SAP は、データベースベンダーのバックアップ機能 (例えば brtools) と統合し、SAP のトランザクションまたは管理コンソール内で可視性を提供するためのメカニズムを提供します。また、サードパーティーのバックアッププロバイダーまたは [AWS Backint Agent for SAP HANA を含むストレージソリューションと統合するオプションがあります](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) 。これらのサポートされているオプションは、データベースの状態を認識し、変更を継続的にキャプチャするか、データベースを静止 (アクティビティの一時停止または削減) しながら、例えば、ストレージスナップショットを使用して一貫したコピーを作成します。
各データベースベンダーの SAP ガイド、および AWS のドキュメントを確認します。
+ AWS ドキュメント: [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)
+ SAP ドキュメント: [SAP NetWeaver と ABAP プラットフォームのためのガイドファインダー](https://help.sap.com/viewer/nwguidefinder)
+ SAP on AWS ブログ: [How to back up Microsoft SQL Server databases for SAP with VSS Snapshots (VSS スナップショットで SAP 用 Microsoft SQL Server データベースをバックアップする方法)](https://aws.amazon.com/blogs/awsforsap/how-to-back-up-microsoft-sql-server-databases-for-sap-with-vss-snapshots/)
+ AWS ブログ: [Amazon EC2 インスタンス上の複数の Amazon EBS ボリューム間でクラッシュ整合性のあるスナップショットを作成する](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/#:~:text=AWS%20Storage%20Blog-,Taking%20crash%2Dconsistent%20snapshots%20across%20multiple%20Amazon%20EBS,on%20an%20Amazon%20EC2%20instance&text=Snapshots%20retain%20the%20data%20from,to%20as%20crash%2Dconsistency).)
**提案 12.1.2 – ビジネスに不可欠なファイルベースのデータの耐久性と復旧可能性を評価する**
データベース内に保存されていないビジネスデータは、別のバックアップ戦略が必要な場合があります。
標準的な SAP NetWeaver システムでは、ファイルベースのインターフェイスファイル、SAP トランスポートディレクトリのコンテンツ、およびバッチログ、ジョブログ、ワークプロセスディレクトリログを含むログが含まれることがよくあります。SAP NetWeaver 以外およびドキュメント管理ソリューションなどのサポートシステムには、評価する必要のある他のファイルベースのビジネスデータが含まれている場合があります。該当する [Amazon EFS](https://aws.amazon.com/efs/) または [Amazon FSx を](https://aws.amazon.com/fsx/) 評価して、そのようなファイルシステムの可用性と耐久性を向上させます。
ファイルシステムのバックアップは、スナップショット、AWS バックアップ、またはサードパーティーのバックアップソリューションを使用して実行することができます。
ビジネスデータは、バイナリおよび設定データとは別に評価する必要があります。これらのデータは、SAP のダウンロード、再インストール、または Infrastructure as Code を介して再プロビジョニングできる場合があります。以下を参照してください。
+ SAP Lens [運用上の優秀性]: [提案 12.2.1 - 設定の作成と変更に対する Infrastructure as Code アプローチを定義する](best-practice-12-2.md)
+ SAP Lens [運用上の優秀性]: [提案 12.2.2 - ルートボリュームを含むファイルシステムのコンテンツのバックアップのためのアプローチを定義する](best-practice-12-2.md)
**提案 12.1.3 – データベースのバックアップとログの耐久性と場所を評価する**
バックアップやログは、ライブデータのレコードですが、それ自体に障害が発生する可能性があります。アクティブなデータコピーに関連するバックアップの場所を評価することによって、障害の影響を最小限に抑える方法を検討してください。以下の点を検討することが重要です。
+ バックアップの保護にかかる時間 - 復旧ポイントに影響する
+ バックアップの取得/復旧にかかる時間 - 復旧時間に影響する
追加情報については、次のドキュメントをご覧ください。
+ AWS ドキュメント: [AWS Backint Agent for HANA](https://aws.amazon.com/backint-agent/)
+ AWS ドキュメント: [FSR (スナップショットの高速復元)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html)
+ AWS ドキュメント: [Amazon S3 レプリケーションオプション](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html)
**提案 12.1.4 – ポイントインタイムリカバリの要件を評価する**
特定の時点に復旧する必要がある場合、それが可能なバックアップ設計になっていますか? バックアップ方法はデータベースを認識し、一貫性のある復旧ポイントにデータベースをロールフォワードできますか? 一貫性を保つために必要なファイルベースの復旧を検討しましたか?
以下の点を考慮してください。
+ ログの間隔とログの保護速度
+ 増分バックアップまたは差分バックアップによる復旧時間の短縮
+ バックアップカタログまたはその他のメカニズムが必要な場合
+ データベースやストレージのオプションを使用して、過去にさかのぼることは可能か
**提案 12.1.5 – データ消失による復旧のメカニズムを見直す**
データの破損、削除、元に戻すことができない誤ったコードのデプロイなど、重大なデータ損失の状況からの復旧が何を意味するかを判断します。データベースまたはストレージベースのレプリケーションを使用する場合のデータ損失の伝播と、バックアップなどのセカンダリ復旧メカニズムを使用した場合の RTO および RPO の影響を評価します。
**提案 12.1.6 – データバンカーを作成する**
以下のガイダンスに従います。 [提案 10.3.7 - バックアップからの復旧が必要になる障害シナリオを判断する](best-practice-10-3.md) 誤って削除したり、悪意あるアクティビティからバックアップを保護したりするためのデータバンカーを作成します。
# ベストプラクティス 12.2 – 設定データの復旧方法を確立する
SAP ワークロードを実行するために必要な多くのさまざまなタイプのデータは、SAP データベースには存在しません。これには、オペレーティングシステムの設定、必要な AWS リソースを再作成するためのメタデータ、ファイルシステム内に保存されている SAP アプリケーションで必要なデータなどが含まれます。データ損失の際に、このデータを復旧または再作成するプロセスを定義します。
**提案 12.2.1 – 設定の作成と変更に対する Infrastructure as Code アプローチを定義する**
個々のインスタンスに直接マニュアルで変更を加えると、システム間の設定に不整合が生じ、状態を復旧するためにバックアップに依存する可能性があります。Infrastructure as Code を使用することにより、SAP システムをデプロイし、アプリケーションコードを管理するのと同じ方法で変更を実装できます。コードパイプラインのような DevOps のメカニズムは、追加のコントロールとテストを提供し、ランドスケープ内での一貫性と再現性を確保するのに役立ちます。
アプローチの一環として、以下の AWS のサービスを評価する必要があります。
+ AWS サービス: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS サービス: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ AWS サービス: [AWS Cloud Development Kit](https://aws.amazon.com/cdk/)
+ SAP on AWS ブログ: [DevOps for SAP (SAP 向け DevOps)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
+ AWS ドキュメント: [Introduction to DevOps on AWS (AWS での DevOps 入門)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/welcome.html)
**提案 12.2.2 – ルートボリュームを含むファイルシステムのコンテンツのバックアップのためのアプローチを定義する**
オペレーティングシステムのパッケージと設定、アプリケーションのバイナリ、ファイルシステムのコンテンツは、実行中の SAP システムに不可欠ですが、コア SAP データベースのバックアップの一部ではありません。Amazon Machine Images (AMI)、EBS ボリュームスナップショット、その他のバックアップオプションなど、このデータを保護および復旧するメカニズムを評価します。
AMI、スナップショット、ファイルシステムのコピーの頻度と整合性、復旧の詳細度、所要時間時間などを検討する必要があります。
特定のシナリオでは、Infrastructure as Code を使用することで、再作成と復旧との比較に注力し、ビジネス以外のデータのバックアップ要件を減らすことができます。
+ SAP ドキュメント: [Required File Systems and Directories (必要なファイルシステムとディレクトリ)](https://help.sap.com/viewer/910828cec5d14d6685da380aec1dc4ae/CURRENT_VERSION/en-US/de6cad1446a743d3853dbcae48bddfba.html)
+ AWS ドキュメント: [バックアップとリカバリのソリューションの設計](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/design.html)
**提案 12.2.3 – マニュアル設定を文書化する**
データベースに含まれていない、コードでデプロイ可能な、またはボリュームバックアップを使用して復元できるマニュアルアクティビティは、最悪のシナリオでも SAP システムを再作成できるように記録する必要があります。
# ベストプラクティス 12.3 - SAP システム全体の復旧アプローチを定義する
SAP システム全体が複数の SAP システムで構成されている場合、ビジネスの優先順位に基づいて、各システムの復旧順序を定義する詳細なアプローチを作成する必要があります。データの損失がシステムおよびビジネスオペレーション全体の一貫性にどのように影響するかを評価します。
**提案 12.3.1 – 復旧の優先順位と計画を含むビジネス継続性計画を作成し、整合性を確保する**
[信頼性] で決定されたシステムの分類に基づいて、各 SAP システムを復元する優先順位を決定する事業継続性計画 (BCP) を用意します。 [提案 10.1.2 – 障害の影響に基づいてシステムを分類する](best-practice-10-1.md) .計画では、システム間の整合性要件と、復元の優先度に対するマルチテナントデータベースの使用の影響も考慮する必要があります。
**提案 12.3.2 – 共有サービスへの依存関係を評価する**
復旧方法を定義する際には、SAP ワークロードを実行するための基盤の一部 (DNS、アクティブディレクトリなど)、または復元自体を実行するために必要な共有サービス (バックアップツールなど) を検討します。リスクを評価し、これらの依存関係に関連する前提条件を復元します。
**提案 12.3.3 – 災害時のランブックを作成する**
事前に定義されたランブックは、災害時に実証済みの一連のステップに従うことを保証し、リスクや重要な活動が見落とされるのを低減します。
# ベストプラクティス 12.4 – 復旧手順を検証するための定期的なテストを実施する
ソフトウェアと手順が予測可能な結果をもたらすことを証明し、バックアップファイルの状態と健全性を検証するために、重要な障害シナリオからの復旧を定期的にテストします。追加のテストが必要かどうかを判断するには、アーキテクチャ、ソフトウェア、またはサポート担当者への変更を評価する必要があります。
**提案 12.4.1 – 復旧テストの障害シナリオを特定する**
[信頼性] に基づいて、復旧が必要となる障害シナリオを定義する必要があります。 [提案 10.3.2 – バックアップからの復旧が必要になる障害シナリオを判断する](best-practice-10-3.md) プロセスとツールを検証するために必要なテストの適切なレベルを決定する。
**提案 12.4.2 – システム変更が復旧アプローチに与える影響を判断する**
変更の影響を評価するアプローチと、そのアプローチが無効にならないことを確認するために必要なその後の復旧テストを定義します。ワークロードの復旧に影響を与える可能性のある変更のタイプの例には、ソフトウェアのアップグレード、パッチ、およびパラメータの変更などがあります。
マネージドサービスパートナーや主要な担当者の変更など、SAP 環境をサポートするために使用される運用モデルに大幅な変更があった場合にも、復旧テストを計画する必要があります。
**提案 12.4.3 – 復旧テストプランを定義する**
復旧の必要性が生じるような重要な障害シナリオをシミュレートするために、完全なテストセットを定義しておく必要があります。復旧テストは、最初の実装時に計画し、その後は定期的に、あるいは必要に応じて実施する必要があります。
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 4.3 - 事業継続性計画と障害復旧を定期的にテストする](best-practice-4-3.md) .