よく寄せられる質問 - Azure VM 上の SAP HANA データベースをバックアップする

1 日に 1 回の完全バックアップと複数のオンデマンド バックアップをスケジュールできます。

現在、成功したバックアップ ジョブではアラートは生成されません。 アラートは、失敗したバックアップ ジョブに対してのみ生成されます。 Azure portal を使用してバックアップ アラートを表示する方法を参照してください。

次のいずれかの場所から、バックアップ (スケジュールまたはオンデマンド) の状態を確認できます。

1. バックアップ ジョブ: Azure Backup では、手動でトリガーされたすべてのジョブが Azure portal の [バックアップ ジョブ] セクションに表示されます。
   
   Azure portal に表示されるジョブには、データベースの検出と登録操作、バックアップと復元操作などがあります。 スケジュールされたジョブ (ログ バックアップを含む) はこのセクションに表示されません。 また、SAP HANA ネイティブ クライアント (Studio、Cockpit、または DBA Cockpit) から手動でトリガーされたバックアップも、ここには表示されません。

   

   

2. バックアップ アラート: アラートは、SAP HANA データベースのバックアップを監視するために役立ちます。 これらを使用すると、必要なイベントに集中できるため、バックアップによって生成される多数のイベントを頻繁にチェックする手間を省くことができます。 詳細については、「バックアップ アラートを表示する」を参照してください。

3. バックアップ レポート: バックアップ ジョブの状態を表示するためのもう 1 つの方法がレポートです。 レポートは、次のようになります。

   

   

   Azure Backup のレポートを構成する方法について学習してください。

4. SAP HANA ネイティブ クライアント: SAP HANA のユーザーの場合は、最も一般的な HANA クライアントの 1 つである HANA Studio を使用することもできます。 このクライアントでバックアップの状態を確認するには、[バックアップ コンソール] ->[バックアップ カタログ] の順に移動します。

   

[バックアップ ジョブ] メニューには、進行中か、成功したか、失敗したオンデマンド バックアップ ジョブだけが表示されます。 スケジュールされたジョブの場合は、Azure Monitor を使用します。

Azure Backup では、自動修復の完全バックアップに対して明示的な保持期間が設定されていません。 このバックアップは、依存デルタ (差分または増分) とログ バックアップを保持するまで保持されます。 この自動修復バックアップの最後の依存バックアップを削除すると、自動修復バックアップも削除されます。

はい。完全バックアップとログ バックアップは同時に実行できます。 このインスタンスは、次のいずれかの方法で発生します。

• 完全バックアップが進行中で、ログ バックアップがトリガーされる: ログ バックアップは、進行中の完全バックアップに関係なく成功します。 トリガーされた完全バックアップが、LSN チェーンのブレークを処理するために完全な修復である場合を除きます。
• ログ バックアップが進行中で、完全バックアップがトリガーされる: 両方のバックアップが同時に実行され、成功します。

いいえ。これは現在サポートされていません。

SAP HANA インスタンスからデータベースが削除された場合でも、データベース バックアップは引き続き試行されます。 これは、削除されたデータベースが [バックアップ項目] に異常として表示され始め、引き続き保護されていることを示しています。 このデータベースの保護を停止するための正しい方法は、このデータベースに対して "バックアップを停止してデータを削除する" を実行することです。

名前が変更されたデータベースは、新しいデータベースとして処理されます。 このため、サービスにより、この状況は、データベースが見つからず、バックアップが失敗した場合と同様に処理されます。 名前が変更されたデータベースは新しいデータベースとして表示されるため、保護するように構成する必要があります。

SAP HANA データベースのために Azure Backup の使用を開始する手順のガイドについては、チュートリアルを参照してください。 また、CLI を使用してバックアップを構成および管理することもできます。

SAP HANA で Azure Backup を使用するための前提条件を参照してください。

トラブルシューティング ガイドのこちらのセクションをご覧ください。

トラブルシューティング ガイドのこちらのセクションを参照してください。

現時点では、仮想 IP またはプロキシに対してソリューションを設定することはできません。 ソリューションを実行するには、仮想マシンが必要です。

SAP HANA ネイティブ クライアントを使用して、Backint ではなくローカル ファイル システムへのオンデマンド バックアップをトリガーできます。 SAP ネイティブ クライアントを使用して操作を管理する方法について説明します。

BACKUP CATALOG DELETE ステートメントや HANA Studio/Cockpit などの SAP 推奨の方法を使用して HANA カタログを排除できます。 SAP ネイティブ クライアントを使用して操作を管理する方法について説明します。

現時点では、Azure Backup は HSR の設定を理解する機能を備えていません。 つまり、HSR のプライマリおよびセカンダリのノードは、関連のない 2 つの個別の VM として扱われます。 最初に、プライマリ ノードでバックアップを構成する必要があります。 フェールオーバーが発生した場合は、セカンダリ ノード (こちらがプライマリ ノードになります) でバックアップを構成する必要があります。 他のノードに対するバックアップの自動フェールオーバーはありません。

任意の時点のアクティブ (プライマリ) ノードからデータをバックアップするために、フェールオーバー後にプライマリになったセカンダリ ノードへに保護の切り替えができます。

この保護の切り替えを実行するには、次の手順に従います。

• プライマリで (データを保持して) 保護を停止します
• セカンダリ ノードで事前登録スクリプトを実行します
• セカンダリ ノードでデータベースを検出し、それらにバックアップを構成します

これらの手順は、フェールオーバーが終了するたびに手動で実行する必要があります。 これらの手順は、Azure portal に加えて、コマンド ライン/HTTP REST を使用して実行できます。 これらの手順を自動化するには、Azure Runbook を使用します。

保護の切り替えを実行する方法の詳細な例を次に示します。

この例では、HSR セットアップにノード 1 (プライマリ) とノード 2 (セカンダリ) の 2 つのノードがあります。 バックアップはノード 1 で構成されています。 前述のように、まだノード 2 でバックアップを構成しないようにしてください。

最初のフェールオーバーが発生すると、ノード 2 がプライマリになります。 このとき、次のようになります。

1. [データの保持] オプションを使用して、ノード 1 (前のプライマリ) の保護を停止します。
2. ノード 2 (現在のプライマリ) で事前登録スクリプトを実行します。
3. ノード 2 のデータベースを検出し、バックアップ ポリシーを割り当て、バックアップを構成します。

その後、ノード 2 で最初の完全バックアップがトリガーされ、その完了後にログ バックアップが開始されます。

次のフェールオーバーが発生すると、ノード 1 が再びプライマリになり、ノード 2 がセカンダリになります。 ここで、手順を繰り返します。

1. [データの保持] オプションを使用して、ノード 2 の保護を停止します。
2. ノード 1 (再びプライマリになっています) で事前登録スクリプトを実行します。
3. 次に、必要なポリシーを使用してノード 1 でバックアップを再開します (前にノード 1 でバックアップが停止されているため)。

その後、ノード 1 で完全バックアップが再度トリガーされ、その完了後にログ バックアップが開始されます。

1. HANA システム レプリケーション (HSR) の場合、セカンダリ ノードはどのような接続も受け付けません。 バックアップが構成された後、Azure Backup サービスは定期的に ping を実行し、失敗します。 これらの失敗した試行が、プライマリ ノードに反映される場合があります。 複数のエラーが発生すると、ユーザーはロックされ、プライマリ ノードが ODBCConnectionError で失敗し始めます。
   
   すべてのユーザーにこの問題が発生するのではないことが確認されています。 セカンダリ ノードでユーザー接続が失敗した場合には、プライマリ ノードでユーザーがロックされる原因を調査するようにお勧めします。

2. 事前登録スクリプトを実行すると、プライマリ ノードの新しいパスワードでユーザー情報が更新されます。 その後、バックアップを試行するための接続が再確立されます。 しかし、同じシナリオが再現される場合があります。

3. また、セカンダリ ノードで失敗するバックアップ (完全バックアップ) によってアラートが作成されます。

上の問題を回避するには、ノードがセカンダリになったら (接続が試行されず、ユーザーがロックされないように) 保護を停止し、プライマリになったら保護を再開することをお勧めします。 HSR セットアップでこのロックされる状況に直面せず、アラートが発生しても問題ない場合は、サービスが引き継ぎとフェールバックを処理するように、両方のノードでバックアップを構成できます。

Azure Backup によって HANA ワークロードに対して提供されるバックアップと復元のスループット パフォーマンスに関するセクションを参照してください。

向上したパフォーマンスを活用するように HANA システムを設定するには、以下のリソースを使用してください。

• Azure IaaS VM 用のディスクの種類の選択 - マネージド ディスク
• Azure マネージド ディスクのパフォーマンス レベル
• M シリーズ
• SAP HANA Azure 仮想マシンのストレージ構成

現在、SAP HANA 用 Azure Backup は 、parallel_backup_using_backint プロパティの値として 1 を受け取ります。 ただし、Azure Backup は、パフォーマンスを向上させるために、その 1 つのストリームを複数のストリームに分割します。

現在、HSR では Backint ベースのバックアップのみがサポートされています。 スナップショットはまだサポートされていません。

状態を更新するには、"準備ができていません" とマークされているサーバーでインスタンスの再検出を実行する必要があります。

HANA システムまたはインスタンスごとに、1 日あたり最大 10 回の復元を実行できます。 復元を取り消した場合や失敗した場合も、復元の試行と見なされることに注意してください。

ターゲットの SAP HANA インスタンスに復元するためのすべての前提条件が満たされているかどうかを確認してください。 詳しくは、Azure VM の SAP HANA データベースの復元の前提条件に関する記事をご覧ください。

復元の間に [強制的に上書きします] オプションが選択されていることを確認します。

SAP HANA ノート 1642148 を参照し、現在サポートされている復元の種類を確認してください。

はい。SLES で実行されている HANA データベースでトリガーされたストリーミング バックアップを使用して、RHEL HANA システムに復元できます。また、その逆も可能です。 つまり、ストリーミング バックアップを使用すると、OS を跨いだ復元が可能になります。 ただし、復元先の HANA システムと復元に使用する HANA システムの両方が、SAP による復元に互換性があることを確認する必要があります。 互換性のある復元の種類については、SAP HANA メモ 1642148 を参照してください。

はい。ここに記載されているように、部分的にファイルをダウンロードできます。

はい。ターゲット システムで HANA System Replication (HSR) を無効にしてから、復元を実行する必要があります。 SAP の仕様により、HSR 対応システムを復元することはできません。

ポリシーを作成する前に、RPO および RTO の要件とその関連コストへの影響について明確にする必要があります。

RPO (目標復旧時点) は、ユーザーまたは顧客が許容できるデータ損失量を示します。 これは、ログ バックアップの頻度によって決まります。 ログ バックアップの頻度が高いほど RPO は短くなります。Azure Backup サービスでサポートされる最小値は 15 分です。 このため、ログ バックアップの頻度は、15 分以上にすることができます。

RTO (目標復旧時間) は、データ損失シナリオの後、最後の使用可能な時点にデータを復元する速度を示します。 これは、HANA によって採用される回復戦略によって異なり、通常は、復元に必要なファイルの数によって異なります。 これはコストにも影響します。次の表は、すべてのシナリオとその影響を理解するのに役立ちます。

このため、RPO と RTO の目標とコストに関する考慮事項に基づいてポリシーのバリエーションを選択できます。

バックアップ項目のポリシーをポリシー 1 (P1) からポリシー 2 (P2) に切り替えるか、またはポリシー 1 (P1) を編集することによる影響を判断する場合、いくつかの原則に留意する必要があります。

• すべての変更はさかのぼっても適用されます。 最新のバックアップ ポリシーは、以前に作成した復旧ポイントにも適用されます。 たとえば、現在アクティブなポリシーに従って、毎日の完全なコピーの保持期間が 30 日で、10 個の復旧ポイントが作成されたとします。 毎日の完全コピーの保持期間を 10 日に変更した場合、以前のポイントの有効期限も、開始時間 + 10 日として再計算され、有効期限が切れている場合は削除されます。
• 変更の範囲には、保持期間だけでなく、バックアップの日、バックアップの種類も含まれます。 次に例を示します。ポリシーを毎日の完全から毎週日曜日の完全に変更した場合、日曜日以外の以前の完全コピーはすべて削除対象としてマークされます。
• 子が非アクティブまたは期限切れになるまで、親は削除されません。 すべてのバックアップの種類には、現在アクティブなポリシーに従って有効期限があります。 しかし、完全バックアップの種類は、それ以降の '差分'、'増分'、'ログ' の親と見なされます。 '差分' と 'ログ' は、他のどのバックアップの親でもありません。 '増分' は、それ以降の '増分' の親になることができます。 '親' が削除対象としてマークされても、子の '差分' または 'ログ' の有効期限が切れていなければ、実際には削除されません。 たとえば、ポリシーを毎日の完全から毎週日曜日の完全に変更した場合、日曜日以外の以前の完全なコピーはすべて削除対象としてマークされます。 しかし、それらは、以前に毎日作成されたログが期限切れになるまで実際には削除されません。 つまり、最新のログ期間に従って保持されます。 ログの有効期限が切れると、ログとこれらの完全なコピーの両方が削除されます。

これらの原則に留意して次の表を読むと、ポリシー変更の影響を理解することができます。

ルート フォルダー内の領域は、次のいずれかのオプションを使用して管理できます。

• /opt/msawb 用に独自の LV を作成します。
• 同じ/異なるディスク上の別の場所/フォルダーへのソフト link/symlink を作成します。
• ルート パーティションの領域を増やします。

次のステップ

• Azure VM で実行されている SAP HANA データベースをバックアップする方法を学習します。
• SAP HANA データベース バックアップのトラブルシューティングの方法について説明します。