SAP でのバックアップ方法の組み合わせ方
Google Cloud Japan Team
※この投稿は米国時間 2022 年 7 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。
バックアップ ソリューションを設計する SAP アーキテクトは、ビジネス（何をすべきか）と提供方法（どのように実現できるか）について検討する必要があります。このブログでは、課題の概要、取りうる選択肢、その長所と短所について説明します。結論として、複数の方法を組み合わせたバックアップ コンセプトを提案することになります。この方式ではクラウド テクノロジーを使用して最高水準の方法を組み合わせてビジネスの要件を満たし、一方で複雑さやコストが過度にならないようにしています。最後に Actifio GO を紹介します。これは将来の Google Cloud バックアップと DR で、複数のワークロードを一元的にポリシーに基づいて保護するための Google のエンタープライズ規模のバックアップ ソリューションです。ここではその機能を紹介します。また、この機能を利用して論理エラーが発生した時点を特定する方法、さらにデータベースを修復する方法も説明します。
このドキュメントで使用されている用語
重要な用語について、復元プロセスの図を使用して説明します。
破損、すなわち論理エラーは通常のオペレーション中に発生します。その後、データベースは復元する必要があります。復元の後、ログをリプレイする必要があります。この手順はロール フォワードと呼ばれることがあります。その後データベースは起動しますが、完了までには再び時間がかかります。ダウンタイムには、破損とその検出が含まれます。ダウンタイムの最大許容限度は RTO（目標復旧時間）と呼ばれています。また、データ損失の最大許容限度は RPO（目標復旧時点）と呼ばれています。
ファイル システムの場合も図の内容は同様ですが、ログのリプレイとデータベースの起動はありません。
多くのお客様はダウンタイムの短縮のために高可用性ノードを利用しています。この方法は基本的には有効ですが、テーブルを削除してしまった場合などの論理エラーに対しては有効ではありません。このような場合の復旧には、完全バックアップまたはスナップショットが解決策となります。この記事では、バックアップは完全バックアップとスナップショットのどちらも意味します。
スナップショットは処理速度もコスト効率も高い方法です。この方法では、変更分だけが保存され、元のディスク状態は保持されます。そのため、バックアップ（「スナップショット」）と復元（「復旧」）は、サイズとは無関係に非常に短時間で発生します。そのサイズはデータの変更量に対応します。スナップショットは、そのスナップショットの作成時のディスクの内容を表します。通常のオペレーション中に作成したスナップショットには、電源をオフにした場合と同様に、クラッシュ整合性があります。スナップショットの時点まで戻った場合、データベースとファイル システムは復元が必要です。データベースについてこの時間がかかる作業を避けるには、データベースの状態を、アプリケーション整合性があるデータベース スナップショットを作成できる状態にする必要があります。SAP NetWeaver でサポートされるデータベースはすべてこの機能をサポートしています。HANA の場合、HANA スナップショットの準備段階がこれに該当します。コンセプト上の観点から見ると、これはディスクに対して必要なすべての DB ストレージ書き込みアクティビティを実行してから OS レベルでディスク アクティビティを静止して、スナップショットを作成できるようにすることを指します。
Google Cloud では、スナップショットを基にして別のスナップショットを作成できます。たとえば、1 時間ごとの間隔で 24 個のスナップショットを作成できます。デフォルトでは、スナップショットは Multi-Regional Storage にあり、リージョン レベルでサービスが停止しても許容できるようになっています。
HANA の場合、データベースの完全バックアップは通常、RAM 容量の 0.6 倍を使用します。一方、スナップショットのサイズは開始時点では 0 で、受け取るデータ変更に応じて拡大していきます。
ランサムウェア攻撃では通常、攻撃者にしかわからない鍵を使用して会社のデータが暗号化されます。このような攻撃があった場合に復旧するには、感染していないバックアップを復元する必要があります。ただし、攻撃者がバックアップを感染させてしまった場合はそれも困難です。しかし、Google Cloud のバケットロック機能があれば、バックアップは最大 100 年間変更できないようにすることができます。
SAP コンポーネント別のバックアップ ソリューション
一般的には、本番環境用システムのバックアップには DEV や QAS などより多くのリソースが必要です。リソースの消費量は各システムの変更の量によって決まるため、スナップショットの使用によりリソース量の制御ができます。従来は本番環境で日次の完全バックアップを実行し、非本番環境で週次の完全バックアップを実行していました。aつまり本番環境の重要性は非本番環境の 7 倍であると言えます。完全バックアップではなくスナップショットを利用すると、データの変動率が低くなり、ストレージ コストを抑えられます。本番環境と非本番環境でバックアップ SLA を区別する必要はなくなります。
バックアップ手法の組み合わせ
ここまでに説明したとおり、スナップショットでは RTO が低くなり、高い頻度で実行できます。そのため、RPO も低くできます。一方で、データベースの完全バックアップでは、SAP による整合性チェックができ、バックアップが作成された場所やストレージ インフラストラクチャからバックアップを切り離すことができます。ストレージ消費量を少なくし、同時に RTO / RPO を小さくして、コストを抑えるために、以下の方法を提案します。
Terraform スクリプトなどを使用して、ルートファイル システムがあるアプリケーション サーバーとデータベース サーバーを短時間で作成できるようにする。このアジャイルな処理を実現することにより、復旧速度が向上するだけでなく、アプリケーション レイヤで迅速な調整を行い、DR のコンセプトを最適化できます。
アプリケーション サーバーとデータベース サーバーのルートファイル システムの PD スナップショットを毎日作成し、古いスナップショットを削除（統合）する。このスナップショットはデフォルトではマルチリージョン バケットに保存されます。ストレージ消費量は、前日からのデータ変更分のみです。
オペレーティング システムやソフトウェアの更新前に、Persistent Disk スナップショットを作成し、数秒で復旧できるようにする。
共有ファイル システム: 共有ストレージ方式を利用して、日次のスナップショットを作成する。インターフェースの使用が多い場合は、この作業はより頻繁に実行できます。既存のスナップショットを上書きすると、ストレージ消費量は、前日からのデータ変更分のみとなります。
データベース: ストレージ スナップショットを作成するためのサポートはどの SAP データベースでもほぼ同様です。本番環境のデータベースと非本番環境のデータベース（たとえば、HANA を使用しているもの）のいずれであっても、以下の方法を最初に考えてみてください。
一次方式: 10 分ごとなどの低頻度で、HANA Studio からオーケストレーションされたデータベース整合性スナップショットを使用します。一連のスナップショットを保持します。これにより、完全なデータベース整合性バックアップを実現できます。復元時間は非常に短くなり、同時にストレージの消費が非常に効率的になります。オペレーションにかかる追加の負荷は非常に小さくなります。 さらに、デフォルトでは他のリージョンに複製されます。
二次方式: オペレーションが最も少ない時間帯（深夜など）に、週次の完全データベース バックアップを実行して、マルチリージョンのクラウド ストレージで以前のバックアップを上書きします。これにより、データベースでチェックされた整合性のあるバックアップが作成され、他のリージョンに複製されます。この方式により、データベース レベルのブロックエラーに対する保護が強化されます。
この方法では、RPO が 10 分未満となり、1 つだけの完全バックアップと、一連のスナップショットが保持されます。復元時にはスナップショットの状態に戻るだけでよいため、復元速度は非常に早くなります。ストレージの消費量は非常に少なく、1 つの完全バックアップ、最大で 1 週間分の変更、1 週間分のログ バックアップだけです。
設計はお客様の好みに合わせて調整できます。完全バックアップの頻度は週ごとから日ごとに変更できます。以前のバックアップが上書きされるため、ストレージ消費量が増えることはありません。システムが稼働しているリージョン以外の場所に保存することを強くおすすめしますが、コストを抑えるため単一リージョンでのバックアップも選べます。ログ バックアップを追加すると、RPO をさらに小さくできます。
ではデータベースのスナップショットはいくつ保持すればよいでしょうか。15 分ごとにスナップショットを作成すると、最新のスナップショットには復旧が必要なエラーが含まれてしまう可能性が高くなります。この場合、さらに前の状態に戻れるようになっていなければならないため、複数のスナップショットを管理する必要があります。Actifio はこの点で高い効果を発揮します。
重要: 多数の SAP システムでクロスシステム データ同期性の要件（例: SAP ECC や SAP CRM など）があり、密接に連結していると考えられるため、すべてのシステムの間でデータ整合性を確保する必要があります。どのシステムで復旧作業を行う場合でも、他のシステムで同様の復旧処理が実行されます。お客様の環境によっては、クロスシステム データ整合性の要件を満たすために、追加のバックアップ方式が必要となることがあります。
Actifio バックアップ ソフトウェア
Actifio（Google Cloud Backup and DR に改称予定）はバックアップ管理のための Google のソフトウェアです。
GCP ネイティブの PD スナップショットと SAP でサポートされるデータベース（DB2、Oracle、SAP ASE、SAP HANA、SAP IQ、SAP MaxDB、SQL Server）をサポートしています。
SAP のお客様にとっては、特に次のような利点があります。
SAP のデータに限らず、さまざまなデータベースとファイル システムのバックアップを 1 つの管理インターフェースで管理できます。
ディスクレベルではなく VM レベルでのバックアップができます。
中間ストレージを使用せずに Sky サーバー（バックアップ アプライアンス）に直接バックアップできます。
Actifio を使用すると、論理エラーがどの時点で発生したかを特定できます。それぞれが異なるスナップショットへのマウントを保持する 10 台の仮想マシンをスピンアップできます。管理者はこれを使用してエラーがいつ発生したか（スナップショット 7 と 8 の間、など）をチェックできます。これにより、データの損失は最小限に抑えられます。
しかし選択肢はこれだけではありません。データベースを「修復」することも可能です。先ほどの例で言えば、スナップショット 7 を仮想マシンにマウントします。その中には、スナップショット 8 以降から抜けてしまったテーブルが含まれています。このテーブルのみをエクスポートして、本番環境のデータベースにインポートできます。もちろん、不整合が発生する可能性はありますが、それでも選択肢の一つではあります。
関連情報
- カスタマー エンジニア Iraia Betolaza- カスタマー エンジニア Thorsten Staerk
