スナップショット戦略を調べる

  • 5 分

さまざまな種類のスナップショットの頻度は、SAP HANA Large Instance ディザスター リカバリー機能を使用するかどうかによって異なります。 この機能はストレージ スナップショットに依存しているため、場合によっては、ストレージ スナップショットの頻度と実行期間について特別な推奨事項が必要になることがあります。

以下の考慮事項と推奨事項では、SAP HANA Large Instances に用意されているディザスター リカバリー機能を使用しないことを前提としています。 代わりに、バックアップを保持し、過去 30 日間の特定の時点への復旧を実現できるようにするための手段として、ストレージ スナップショットを使います。 スナップショットの数と領域の制限がある場合、次のような要件を考慮します。

  • ポイントインタイム復旧の復旧時間。
  • 使用される領域。
  • 障害からの復旧可能性の、回復ポイントと回復時刻の目標。
  • ディスクに対する SAP HANA 完全データベース バックアップの最終的な実行。 ディスクまたは Backint インターフェイスに対するデータベースの完全バックアップを実行すると常に、ストレージ スナップショットの実行が失敗します。 ストレージ スナップショットに加えてデータベースの完全バックアップを実行する予定がある場合は、その実行中にストレージ スナップショットの実行が無効になるようにします。
  • ボリュームごとのスナップショットの数。 ハードウェアはボリュームあたり 255 個のスナップショットを維持できますが、この数を十分に下回るようにしておく必要があります。 推奨値は 250 以下です。

SAP HANA Large Instances のディザスター リカバリー機能を使用しない場合は、スナップショットの頻度が低くなります。 このような場合は、12 時間または 24 時間ごとに、/hana/data と /hana/shared (/usr/sap が含まれます) の結合スナップショットを実行します。 そのスナップショットを 1 か月間保持します。 ログ バックアップ ボリュームのスナップショットの場合も同じです。 ログ バックアップ ボリュームに対する SAP HANA トランザクション ログ バックアップは、5 から 15 分の間隔で実行されます。

スケジュールされたストレージ スナップショットは、cron を使用することで最適に実行できます。 すべてのバックアップとディザスター リカバリーのニーズに対して、同じスクリプトを使用します。 要求されるさまざまなバックアップ時間に合わせて、スクリプトの入力を変更します。 これらのスナップショットは、実行時間に応じて、cron でのスケジュールが異なります。 1 時間ごと、12 時間ごと、毎日、または毎週に設定されます。

次に示すのは、/etc/crontab での cron スケジュールの例です。

00 1-23 * * * ./azure_hana_backup --type=hana --prefix=hourlyhana --frequency=15min --retention=48

10 00 * * * ./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=28

00,05,10,15,20,25,30,35,40,45,50,55 * * * * ./azure_hana_backup --type=logs --prefix=regularlogback --frequency=3min --retention=28

22 12 * * * ./azure_hana_backup --type=logs --prefix=dailylogback --frequency=3min --retention=28

30 00 * * * ./azure_hana_backup --type=boot --boottype=TypeI --prefix=dailyboot --frequency=15min --retention=28

前の例では、1 時間ごとの結合スナップショットで、/hana/data と /hana/shared/SID (/usr/sap を含む) の場所が含まれるボリュームをカバーします。 この種のスナップショットは、過去 2 日以内の特定の時点への復旧を迅速化するために使用します。 また、これらのボリュームの日単位のスナップショットもあります。 そのため、時間単位のスナップショットによって 2 日間をカバーし、日単位のスナップショットによって 4 週間をカバーできます。 また、トランザクション ログ バックアップ ボリュームが毎日 1 回バックアップされます。 これらのバックアップは 4 週間保持されます。

crontab の 3 行目に示すように、SAP HANA トランザクション ログのバックアップは 5 分ごとに実行されるようにスケジュールされています。 ストレージ スナップショットを実行するさまざまな cron ジョブの開始時刻はずらされています。 これにより、すべてのスナップショットが特定の時点に一斉に実行されることはありません。

次の例では、/hana/data と /hana/shared/SID (/usr/sap を含む) の場所が含まれるボリュームをカバーする結合スナップショットを 1 時間ごとに実行します。 これらのスナップショットは 2 日間保持します。 トランザクション ログ バックアップ ボリュームのスナップショットは 5 分ごとに実行され、4 時間保持されます。 以前と同様に、SAP HANA トランザクション ログ ファイルのバックアップは 5 分ごとに実行されるようにスケジュールされています。

トランザクション ログ バックアップ ボリュームのスナップショットは、トランザクション ログ バックが開始されてから 2 分遅れて実行されます。 通常の状況では、SAP HANA トランザクション ログ バックアップはこの 2 分以内に完了します。 前と同様に、ブート LUN を含むボリュームがストレージ スナップショットによって 1 日 1 回バックアップされ、4 週間保持されます。

10 0-23 * * * ./azure_hana_backup --type=hana ==prefix=hourlyhana --frequency=15min --retention=48

0,5,10,15,20,25,30,35,40,45,50,55 * * * * ./azure_hana_backup --type=logs --prefix=regularlogback --frequency=3min --retention=28

2,7,12,17,22,27,32,37,42,47,52,57 * * * * ./azure_hana_backup --type=logs --prefix=logback --frequency=3min --retention=48

30 00 * * * ./azure_hana_backup --type=boot --boottype=TypeII --prefix=dailyboot --frequency=15min --retention=28

SAP HANA により、コミットされた変更をデータベースに記録するため、/hana/log ボリュームに対する定期的な書き込みが実行されます。 定期的に、SAP HANA によって /hana/data ボリュームにセーブポイントが書き込まれます。 crontab での指定に従って、SAP HANA トランザクション ログ バックアップが 5 分ごとに実行されます。

また、/hana/data および /hana/shared/SID ボリュームに対する結合ストレージ スナップショットのトリガーの結果として、1 時間ごとに SAP HANA のスナップショットが実行されることもわかります。 SAP HANA スナップショットが成功すると、結合されたストレージ スナップショットが実行されます。 crontab で指示されているように、/hana/logbackup のストレージ スナップショットは、SAP HANA トランザクション ログのバックアップの約 2 分後に、5 分間隔で実行されます。

重要

SAP HANA バックアップに対するストレージ スナップショットの使用は、スナップショットが SAP HANA トランザクション ログ バックアップと共に実行される場合にのみ有効です。 これらのトランザクション ログ バックアップは、ストレージ スナップショット間の期間をカバーする必要があります。

30 日間の特定の時点への復旧をユーザーに確約している場合は、次のことが必要です。

  • 極端なケースでは、/hana/data と /hana/shared/SID の 30 日前の結合ストレージ スナップショットにアクセスします。
  • 結合ストレージ スナップショット間の時間をカバーする連続したトランザクション ログ バックアップを保持します。 そのため、トランザクション ログ バックアップ ボリュームの最も古いスナップショットは 30 日前のものである必要があります。 ただし、トランザクション ログ バックアップを、Azure Storage にある別の NFS 共有にコピーしている場合を除きます。 このような場合、その NFS 共有から古いトランザクション ログ バックアップを取得できます。

ストレージ スナップショットとトランザクション ログ バックアップの最終的なストレージ レプリケーションのメリットを得られるようにするには、SAP HANA がトランザクション ログ バックアップを書き込む場所を変更します。 SAP HANA Studio でこの変更を行うことができます。

SAP HANA では完全なログ セグメントが自動的にバックアップされますが、ログ バックアップ間隔を決定論的に指定します。 特に、ディザスター リカバリー オプションを使用している場合、通常は決定論的期間でログ バックアップを実行します。 次の例では、ログ バックアップの間隔を 15 分に設定しています。

また、バックアップの間隔は 15 分よりも短くすることができます。 より頻度の高い設定は、多くの場合、SAP HANA Large Instances のディザスター リカバリー機能と組み合わせて使用されます。 トランザクション ログ バックアップを 5 分ごとに実行しているお客様もいます。

これまでデータベースをバックアップしたことがない場合は、最後にファイル ベースのデータベース バックアップを実行して、バックアップ カタログ内に存在する必要がある単一のバックアップ エントリを作成します。 これを実行しないと、SAP HANA は指定されたログ バックアップを開始できません。

ディスク ボリューム上のスナップショットの数とサイズを監視する

特定のストレージ ボリュームで、スナップショットの数とそれらのスナップショットによるストレージの使用量を監視できます。 ls コマンドでは、スナップショットのディレクトリまたはファイルは表示されません。 それらのストレージ スナップショットは同じボリュームに格納されているため、Linux OS の du コマンドを使用すると、それらについての詳細が表示されます。 コマンドでは次のオプションを使用します。

  • du –sh .snapshot: このオプションを指定すると、スナップショット ディレクトリ内のすべてのスナップショットの合計が表示されます。
  • du –sh --max-depth=1: このオプションを指定すると、.snapshot フォルダーに保存されているすべてのスナップショットと、各スナップショットのサイズの一覧が表示されます。
  • du –hc: このオプションを指定すると、すべてのスナップショットで使用されている合計サイズが表示されます。

作成および格納したスナップショットがボリューム上のストレージを使用し尽くしていないことを確認するには、上記のコマンドを使用します。

注意

ブート LUN のスナップショットは、上記のコマンドでは表示されません。

スナップショットの詳細を取得する

スナップショットについての詳細をさらに取得するには、スクリプト azure_hana_snapshot_details を使います。 ディザスター リカバリーの場所にアクティブなサーバーがある場合は、このスクリプトをいずれかの場所で実行できます。 このスクリプトは、スナップショットを含むボリュームごとに分類して次の出力を提供します。

  • ボリュームの合計スナップショットのサイズ

  • そのボリュームの各スナップショットに関する次の詳細情報:

    • スナップショット名
    • 作成時刻
    • スナップショットのサイズ
    • スナップショットの頻度
    • 該当する場合は、そのスナップショットに関連付けられている SAP HANA バックアップ ID

サーバー上のスナップショットの数を削減する

前に説明したように、特定のラベルで格納されるスナップショットの数を減らすことができます。 スナップショットを開始するコマンドの最後の 2 つのパラメーターは、ラベルと、保持するスナップショットの数です。

./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=28

前の例で、スナップショット ラベルは dailyhana です。 このラベルで保持するスナップショットの数は 28 です。 ディスク領域の使用量に応じて、格納されるスナップショットの数を減らすことができます。 スナップショットの数をたとえば 15 個に減らす簡単な方法は、最後のパラメーターを 15 に設定してスクリプトを実行することです。

./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=15

この設定でスクリプトを実行すると、スナップショットの数は、新しいストレージ スナップショットを含めて、15 個になります。 15 個の最新のスナップショットが保持され、15 個の古いスナップショットが削除されます。

注意

このスクリプトでは、1 時間以上経過したスナップショットが存在する場合にのみ、スナップショットの数が減らされます。 このスクリプトでは、作成から 1 時間経過していないスナップショットは削除されません。 これらの制限は、提供されるオプションのディザスター リカバリー機能に関連しています。

構文例でバックアップ プレフィックス dailyhana を使用して一連のスナップショットを維持する必要がなくなった場合は、リテンション数として 0 を指定してスクリプトを実行します。 これにより、そのラベルと一致するすべてのスナップショットが削除されます。 すべてのスナップショットを削除すると、HANA Large Instances のディザスター リカバリー機能に影響する可能性があります。

特定のスナップショットを削除するもう 1 つのオプションは、スクリプト azure_hana_snapshot_delete を使用することです。 このスクリプトは、SAP HANA Studio で検出された SAP HANA バックアップ ID を使用して、またはスナップショット名自体を介して、スナップショットまたはスナップショット セットを削除するように設計されています。 現在、バックアップ ID は、SAP HANA スナップショットの種類に対して作成されたスナップショットにのみ関連付けられています。 種類が logs および boot のスナップショット バックアップでは SAP HANA スナップショットは実行されないため、これらのスナップショットのバックアップ ID はありません。 スナップショット名を入力すると、入力したスナップショット名に一致するすべてのスナップショットがさまざまなボリューム上で検索されます。 このスクリプトは、root ユーザーとして実行します。

重要

削除しようとしているスナップショット上にのみ存在するデータがある場合、スナップショットが削除されると、そのデータが永久に失われることになります。

ストレージ スナップショットからのファイル レベルの復元

スナップショットの種類が hana および logs である場合、ボリューム上のスナップショット ディレクトリにあるスナップショットに直接アクセスできます。 スナップショットごとにサブディレクトリがあります。 スナップショットの作成時点での状態で、該当のサブディレクトリから実際のディレクトリ構造に、各ファイルをコピーします。

現在のバージョンのスクリプトでは、セルフサービスのスナップショットの復元用に提供されている復元スクリプトは "ありません"。 スナップショットの復元は、フェールオーバー中のディザスター リカバリー サイトでのセルフサービス ディザスター リカバリー スクリプトの一部として実行できます。 既存の使用可能なスナップショットから目的のスナップショットを復元するには、サービス要求を開いて、Microsoft の運用チームに問い合わせる必要があります。

注意

単一ファイル復元は、SAP HANA Large Instances のユニットの種類に関係なく、ブート LUN のスナップショットに対しては機能しません。 .snapshot ディレクトリは、ブートLUN では公開されません。

最新の SAP HANA スナップショットに回復する

運用環境停止のシナリオが発生した場合は、Microsoft Azure サポートでの顧客インシデントとして、ストレージ スナップショットからの復旧プロセスを開始できます。 運用システムのデータが削除されており、データを取得する唯一の方法が運用データベースの復元である場合は、緊急度の高い問題となります。

一方、特定の時点への復旧は緊急度が低く、数日前から計画されている場合があります。 この復旧は、優先度の高いフラグを設定するのではなく、SAP HANA on Azure と共に計画できます。 たとえば、新しい拡張機能パッケージを適用して、SAP ソフトウェアのアップグレードを計画する場合があります。 次に、拡張機能パッケージのアップグレード前の状態を表すスナップショットに戻す必要があります。

要求を送信する前に準備する必要があります。 そうすることで、SAP HANA on Azure チームが要求を処理し、復元されたボリュームを提供できます。 その後、スナップショットに基づいて SAP HANA データベースを復元します。

要求の準備をするには、次の手順のようにします。

  1. 復元するスナップショットを決定します。 特に指定しない限り、hana/data ボリュームのみが復元されます。

  2. SAP HANA インスタンスをシャットダウンします。

  3. 各 SAP HANA データベース ノードでのデータ ボリュームのマウントを解除します。 データ ボリュームがオペレーティング システムに引き続きマウントされていると、スナップショットの復元は失敗します。

  4. Azure サポート要求を開き、特定のスナップショットの復元に関する指示を記入します。

    • 復元中: SAP HANA on Azure Service から、適切なストレージ スナップショットの復元の調整、検証、確認に関する電話会議への参加が求められる場合があります。
    • 復元後: ストレージ スナップショットが復元されたことが、SAP HANA on Azure Service から通知されます。

  5. 復元処理が完了したら、すべてのデータ ボリュームを再マウントします。

異なる特定の時点への復旧

特定の時点に復元する方法については、「Manual recovery guide for SAP HANA on Azure from a storage snapshot (SAP HANA on Azure のストレージ スナップショットからの手動回復ガイド)」の「Recover the database to the following point in time (データベースを次の時点に回復する)」をご覧ください。