SAP HANA のファイルレベルのバックアップを確認する
SAP HANA ファイル レベルのバックアップは、次の複数の方法を使用して実行できます。
Azure Backup サービスによる SAP HANA バックアップ
Backint によって提供される SAP HANA Azure Virtual Machines のログ バックアップとログ以外のバックアップは、Azure Storage Blob を内部的に使用する Azure Recovery Services コンテナーへのストリームです。 このストリーミング手法を理解することが重要です。
HANA の Backint コンポーネントは、ディスクに接続された "パイプ" (情報を読み取るためのパイプと書き込むためのパイプ) の役割を果たします。基になるディスクには、データベース ファイルが存在します。それらが Azure Backup サービスによって読み取られて、リモート Azure Storage アカウントである Azure Recovery Services コンテナーに転送されます。 Azure Backup サービスでは、Backint のネイティブ検証チェックとは別に、チェックサムによってストリームが検証されます。 これらの検証により、Azure Recovery Services コンテナーに存在するデータを実際に信頼して回復できることが保証されます。
ストリームの処理対象になるのは主にディスクであるため、バックアップと復元のパフォーマンスを正確に測定するためには、ディスクの読み取りパフォーマンスとバックアップ データを転送するためのネットワーク パフォーマンスを把握する必要があります。 詳細については、「チュートリアル:Azure 仮想マシンで SAP HANA データベースをバックアップする」を参照してください。
その他のバックアップ方法
Azure Backup サービスを使用しない、ファイル レベルでバックアップ/復元を管理する標準的な方法としては、SAP HANA Studio または SAP HANA SQL ステートメントを使用したファイルベースのバックアップがあります。 種類 "ファイル" を選ぶ場合は、SAP HANA によってバックアップ ファイルが書き込まれるファイル システムのパスを指定する必要があります。 これは、復元を実行するときも同様です。
この選択は簡単に見えますが、いくつかの考慮事項があります。 Azure 仮想マシンにはデータ ディスクの数に制限があります。 データベースのサイズとディスク スループットの要件によっては、仮想マシンのファイル システムに SAP HANA バックアップ ファイルを格納する容量がないことがあります。 これを修正するには、複数のデータ ディスク間でのソフトウェアのストライピングが必要になる場合があります。 合計容量に関して自由度の高い別のオプションとしては、Azure Blob Storage があります。 また、このオプションを使うと、コスト上の利点があるクール BLOB ストレージを選択できます。
回復性を高めるため、geo レプリケートされたストレージ アカウントを使って SAP HANA のバックアップを格納できます。 SAP HANA バックアップ用の専用 VHD を、geo レプリケートされた専用のバックアップ ストレージ アカウントに配置することもできます。 または、SAP HANA バックアップを保持する VHD を geo レプリケートされたストレージ アカウント、または、別のリージョンにあるストレージ アカウントにコピーすることもできます。
Azure Backup エージェント
Azure Backup では、ゲスト OS にインストールする必要があるバックアップ エージェントを介して、仮想マシン全体だけでなくファイルやディレクトリもバックアップするオプションを提供します。 ただし、このエージェントは Windows でのみサポートされています。 回避策は、まず SAP HANA バックアップ ファイルを Azure 上の Windows 仮想マシンに (たとえば SAMBA 共有を介して) コピーし、そこから Azure バックアップ エージェントを使用することです。 技術的には可能ですが、Linux と Windows 仮想マシン間のコピーにより、複雑さが増し、バックアップまたは復元プロセスがかなり遅くなります。 この方法に従うことを推奨しません。
Azure Storage ユーティリティ
Azure Storage にファイルをコピーするには、CLI または PowerShell を使うか、Azure SDK のいずれかを使ってツールを開発することができます。 SAP HANA のバックアップ ファイルをコピーするその他のオプションとしては、多くのお客様が運用環境で使用している、AzCopy と blobxfer (どちらも GitHub で使用可能) があります。 これらのツールを使うと、Azure BLOB ストレージ、Azure ファイル共有のいずれかにデータを直接コピーできます。 また、md5 ハッシュや、複数のファイルを含むディレクトリをコピーする際の自動並列処理など、さまざまな種類の便利な機能も提供されます。
バックアップ ソフトウェア RAID 内の専用 Azure データ ディスクの BLOB コピー
手動の仮想マシン データ ディスクのバックアップとは異なり、このアプローチでは、HANA データ、HANA ログ ファイル、構成ファイルを含む SAP インストール全体を保存するために、仮想マシン上のすべてのデータ ディスクをバックアップすることはありません。 その代わり、複数の Azure データ VHD でストライピングを行う専用ソフトウェア RAID を作成し、完全な SAP HANA ファイル バックアップを格納することを検討します。 コピー プロセスに必要なのは、SAP HANA バックアップを含むディスクのみです。 これらは、専用の HANA バックアップ ストレージ アカウントに簡単に保存したり、さらなる処理のために専用の "バックアップ管理仮想マシン" にアタッチしたりできます。
コピーはバックアップ ファイルを保持するための専用ファイル システムにのみ影響を与えるので、ディスク上の SAP HANA データまたはログ ファイルの整合性に関する懸念はありません。 このコマンドの利点は、仮想マシンがオンラインのままでも機能することです。 何らかのプロセスによってバックアップ ストライプ セットに書き込まれることがないように、BLOB のコピーの前に必ずマウントを解除し、後で再度マウントしてください。 または、適切な方法を使ってファイル システムを "凍結" することができます (たとえば、XFS ファイル システムの xfs_freeze を使います)。
NFS 共有への SAP HANA バックアップ ファイルのコピー
パフォーマンスまたはディスク領域の観点から SAP HANA システムへの潜在的な影響を減らすために、NFS 共有に SAP HANA のバックアップ ファイルを格納することも検討できます。 技術的には機能しますが、従来は 2 つ目の Azure 仮想マシンを NFS 共有のホストとして使用する必要がありました。 Azure NetApp Files を使うことによって、これを回避できます。 NFS 共有への書き込みは、ネットワークに負荷がかかり、SAP HANA システムにある程度影響しますが、バックアップ ファイルの管理に関連する後続の影響はありません。
Azure ファイルへの SAP HANA バックアップ ファイルのコピー
Azure Linux 仮想マシン内に Azure Files 共有をマウントできます。 ただしテストでは、現在、SAP HANA バックアップがこの種の CIFS マウントと直接機能しないことが示されています。 CIFS が推奨されないことは、SAP Note #1820529 にも記載されています。