VxRail Integrated Backup機能について

結論を先におつたえすると、Kubernetes環境のように従来の仮想マシンのバックアップ製品を必要としない用途で利用している場合に、管理VMのためだけにバックアップ製品が必要となったり、管理VMのバックアップが取得されないような状況を避けるために存在していると解釈しています。

したがって、現行運用においてお客様環境での標準的な仮想マシンのバックアップ方法が確立している場合に、必ずしもそれらを本機能（File Base BackupのGUIからの取得）で置き換える必要はありません。

たとえば、VADPベースのVMイメージバックアップ、リストア手順が運用として確立されている環境において必ずしもVxRailの本機能に置き換える必要はありません。

従来型のVADPベースのバックアップと比較して、VxRailの本機能によってFile Baseバックアップを取得するメリットとして以下が考えられます。

①バックアップソリューションが不要（標準機能で取れる）

②標準機能であるため互換性や動作検証が不要

③バックアップサイズが小さい（OS部分の冗長な領域のバックアップがされない）

④OS破損などの論理障害に対応しやすい

上記のうち、②においては稀にvCenterのバックアップリストアに対応していないバックアップソリューションがあったりもしますが、主要な製品であれば基本的には対応しているはずです。手順などが若干特殊な場合もありますので、念のためお使いのバックアップ製品窓口にご確認されたほうが良いかと思います。

③については、バックアップ製品側で重複排除機能があったり、仮想化環境全体のバックアップサイズが大きい場合はあまり気にならず、むしろ一貫したバックアップリストア手順が適用できることのメリットが大きい場合も多いかと思います。

④については、状況的にはかなり限られますが動作不良などの問題が顕在化した際にOS部分の破損であることが判明し、VMイメージベースのバックアップではかなり世代を遡らないと状況が改善できず、その間の構成変更が失われるというリスクがありますが、ファイルベースバックアップであれば比較的浅い世代（もしくは新規取得）で改善できるケースがあります。そのため、File Base Backup対象となっていないOS部分の論理障害についてはFile Base Backupが優位といえますが、標準的な従来のバックアップを置き換えるというよりも、スポットで必要に応じて取得するような運用でも問題はないと思います。

したがって、すでにお客様環境に標準的なバックアップ手法が存在している場合においては、わざわざvCenterとVxRailのみを切り出して個別運用にするほどのものではないと考えています。

一方で、お客様環境で標準的なバックアップ手法を持たない環境や、Kubernetest環境のようにそもそもUserVMに対してVMベースのバックアップが必要ない場合は、①のメリットが活きてきます。

vCenterやVxRail Managerといった管理VMは、当然のことながらバックアップを取得しておく必要があります。

UserVMに対してVMベースのバックアップ手法をもたないor必要としない場合、管理VMのバックアップをどのように取得するかが課題となってしまいます。

そこで本機能があることによって、VxRail（vSphere/vSAN）の標準機能の範囲で管理VMのバックアップを取得できるようになります。もちろん7.0.450未満においても同様のFile Base Backupの機能は存在しましたが、CLIベースだったり、個別のGUI操作が必要であったりと、アップグレード前や構成変更前などに、オンデマンドで簡易的に取得するには適していませんでした。7.0.450でVxRail GUIの追加機能として実施されたことによって、vCenterの操作やCLIの手順になれていないユーザでも簡単に取得できるようになりました。