バックアップ/リカバリ アプライアンスでの低スプラッシュ バックアップの原因

低スプラッシュ バックアップとは何ですか？

通常の状況下では、Backup and DR のバックアップ / リカバリ アプライアンスで、Backup and DR は時間のかかるデータベースの最初の完全取り込みバックアップを取得します。その後、後続のバックアップはすべて、はるかに高速な増分バックアップになります。増分バックアップでは、現在のスナップショットと前のスナップショットのビットマップを比較し、増分変更のみを適用します。

ロースプラッシュ バックアップは、前のバックアップ ジョブでシステムエラーが発生し、ビットマップ イメージの信頼性が低下したり、ビットマップを読み取れなくなったりした場合に発生する特別なタイプのバックアップ ジョブです。ビットマップを読み取るサービスは、Linux 環境では cbt_server、Windows 環境では AAMService です。

低スプラッシュ バックアップは、信頼性の高いビットマップを再作成するために完全な取り込みを再度実行する必要があるため、通常の条件で作成されたバックアップよりも時間がかかります。これにより、フル バックアップを置き換えることなく、増分変更を適用できます。

低スプラッシュ バックアップの原因にならないもの

  • コネクタのアップグレード
  • システムのグレースフル リブート
  • cbt_server または AAMService のグレースフル リスタート（バックアップ時にサービスがまだ実行されていることを前提とする）

  • 信頼性の低いビットマップの原因となるエラーが発生しなかったフェイルオーバー。

信頼できないビットマップの原因

信頼性の低いビットマップは、次のようなバックアップ ジョブを中断する原因によって発生します。

  • ホストの不適切なシャットダウン:
    • 正常なシャットダウンが行われないと、ビットマップの信頼性が低下するため、低スプラッシュが発生します。これには、物理マシンの電源を切る、正常なシャットダウンを行わずに Windows をオフにする、ブルースクリーン エラーが発生するなど、さまざまな方法があります。これは、クラスタ内の 1 台のマシンでブルースクリーン エラーが発生してフェイルオーバーがトリガーされた場合でも同様です。障害が発生したマシンのビットマップは信頼できないためです。
    • 前回のバックアップ以降にデータベースをホストしていたクラスタ内のすべての Windows サーバーが利用できず、Backup and DR エージェントを実行していない場合。前回のバックアップ以降にデータベースをホストした各クラスタホストからビットマップを pull して変更を検出します。すべてのビットマップがない場合は、データの整合性を維持するために low-splash を実行する必要があります。データベースをホストしていたクラスタホストが BSOD になった場合、バックアップ時にビットマップが利用可能であっても信頼性が低いため、ロースプラッシュ復元が必要になります。
  • カーネル モジュールの更新に失敗した
  • ユーザーモード デーモンでのクラッシュまたは再起動
  • バックアップの実行中にフィンガープリント エラーが発生した。（Backup and DR は、各バックアップ ジョブで「フィンガープリント チェック」を実行してエラーを確認します）。
  • OS のシャットダウン中にストレージ ディスクがいっぱいになり、システムがすべてのデータを Vault に書き込めない場合、Vault 処理中にエラーが発生します。
  • SAP HANA ノードのフェイルオーバー。バックアップが別のノードにリダイレクトされます。
  • カーネル モジュールを読み込めないため、バックアップがデグレード モードで実行されています。これは通常、OS がサポートされていないバージョンである場合に発生します。
  • バックアップ中に cbt_server または AAMService が停止すると、ビットマップを取得できず、バックアップ ジョブは低スプラッシュ モードで実行されます。AAMService が長時間停止していない場合は、AAMService を起動すると、通常のバックアップでビットマップを使用できるようになります。
    • cbt_server または AAMService が長時間停止し、数ギガバイトのイベントがドライバによってキューに入れられた場合、ビットマップを再作成できず、バックアップは低スプラッシュ モードになります。これにかかる時間は、データベースで発生するディスク I/O の量によって異なります。これには通常、数日間の AAMService のダウンタイムが必要です。
  • cbt_server または AAMService が正常にシャットダウンされないと、現在読み込まれているビットマップの信頼性が低下する可能性があります。追跡対象のファイルが過去 15 分以内に書き込まれた場合、ビットマップが読み込まれます。そのため、一般的に、ビジー状態のデータベースでは、スプラッシュが低くなります。
  • 追跡対象ファイル（SQL Server の .mdf ファイルなど）を含むボリュームがホストでマウント解除されてから再マウントされた場合、マウント解除中にファイルに書き込まれた内容を把握する方法がないため、ビットマップは信頼できません。