5.スナップショットをバックアップにしない

　VMスナップショットを最優先のバックアップ手段にしてはいけない。スナップショットを短期的な臨時のVMバックアップに使うのは問題ないが、これを使うと不利益が生じる。

　スナップショットが作成されると、VMのディスクファイルに対する全ての書き込みは新しい差分ディスクファイルに格納され、元のディスクは読み取り専用になる。データが書き込まれると、差分ディスクファイルは16MB単位で増加する。増加のたびにディスクが存在するLUN（論理ユニット）にロックがかけられ、パフォーマンスが低下する恐れがある。実行中のスナップショットが増えるほど、そのLUNで実行されているVM全てのパフォーマンスへの影響が大きくなる可能性がある。

　加えて、スナップショットはデータストアのディスク領域を余分に占有する。各ディスク領域は元のディスクのサイズまで拡大する場合がある。データストアのディスク領域を使い果たしてしまうと、全てのVMが停止する。

　スナップショットを削除するときに元のディスクにデータを統合することも、VMのパフォーマンスに影響を与える負荷の高いI/O操作だ。スナップショットでは元のディスクとリンクした新しい仮想ディスクが作成される。そのため一部の機能が利用できない場合や、元のディスクとそのスナップショット間でマッピングの問題が起きる場合もある。スナップショットは慎重に使用し、必要なくなったらすぐに削除しなければならない。

6.バックアップのスケジュールとテストを実施する

　仮想環境でのバックアップでは、共有型の仮想化アーキテクチャが原因でリソースが酷使される恐れがある。そのため、単一のリソースに大きな負荷が集中しないように、バックアップとリストアのスケジュールを立てるべきだ。

　同時にバックアップするホストまたはLUN上のVMが多くなり過ぎてはいけない。バックアップスケジュールをバランスよく設定してリソース使用量が均一になるようにし、1つのリソースが酷使されないようにする。そうしなければ、バックアップ速度が遅くなり、VMのパフォーマンスが低下する恐れがある。

　vSphereバックアップでリカバリーの準備が整っているかどうかはテストしない限り分からない。バックアップをテストすると、リカバリーに関する潜在的な問題を理解するのに役立つ可能性がある。それが問題を解決するきっかけになったり、バックアップツールを詳しく調べて製品を変える必要があるかどうかを確認する機会となったりする。

7.バックアップの代替手段を把握する

　イメージレベルバックアップを使用する仮想化バックアップ製品は、バックアップ実行中の仮想ディスクへの書き込みを停止するために、VMスナップショットを活用する。仮想マシン保護機能「VMware Fault Tolerance」（FT）では、別々のホストに配置される2つのVMとしてプライマリーVMとセカンダリーVMを使用する。ただし、これらはどちらも同じ仮想ディスクファイルを共有する。

　2019年1月時点で、VMスナップショットではFTを利用できない。そのためFTが有効になっているVMのバックアップは難しい場合がある。こうした制約を回避するには、これらのVMをバックアップするための代替手段を探す必要がある。

　バックアップの実行中にFT機能を一時的に無効にすることは、FTが有効になっているVMをバックアップする方法の一つだ。こうすることでスナップショットを作成できるようになる。この機能を無効にしてもセカンダリーVMは保持されるため、バックアップが完了したら簡単に再び有効にできる。これはMicrosoftの「PowerShell」を使用して自動化することが可能だ。バックアップ前後にスクリプトを使用することで、プロセス全体を自動化できる。

　もう一つ、サーバ管理ツール「vCenter Server」や、VMへの変換ツール「vCenter Converter」を使ってVMをクローニングする方法がある。新しくVMのコピーを作成し、バックアップにできる。このクローンは後で削除できる。ストレージレベルのスナップショットを使用することや、OSにインストールされたエージェントを使用してVMをバックアップすることも可能だ。

8.ホストとサーバ構成をバックアップする

　ホストやvCenter Serverを失ったとしても簡単に再構築できる。ただし、構成情報は失われるため、そうした情報を定期的にバックアップするのが得策だ。

　バックアップホストがある場合、VMのみをバックアップして、ホストの管理コンソールにある個々のファイルはバックアップしないのが一般的だ。管理コンソール内のファイルをバックアップする必要はないが、構成情報はバックアップすべきだ。そうすることで、ホストの再構築が楽になる。

　VMwareのハイパーバイザー「ESX」がホストの場合は、ホストのプロセス情報を出力する「esxcfg-info」コマンドを使用できる。このコマンドにより、大量の構成情報がテキストファイルに出力される。VMwareのハイパーバイザー「ESXi」がホストの場合は、vSphere CLIで使える「vicfg-cfgbackup」コマンドを使用することで、構成情報をテキストファイルに出力できる。

　ESXでは、esxcfg-infoの出力情報を使ったリストアはできない。だが少なくとも再構成に何が必要かは分かる。ESXiでは、ホスト構成のリストアにもvicfg-cfgbackupコマンドを使える。

　vCenter Serverでは、サーバ固有の構成情報が全て格納されたデータベースのバックアップが不可欠だ。これにはクラスタ、リソースプール、アクセス許可、アラーム、パフォーマンスデータなどに関する構成情報がある。適切なデータベースバックアップがあれば、vCenter Serverを再インストールしてデータベースを参照させるようにするだけで、元のように起動および稼働できる。

　vCenter ServerデータディレクトリにあるvCenter Server用のSSL（Secure Sockets Layer）証明書フォルダをバックアップしていることも確認する必要がある。このフォルダには、vCenterがESXホスト、ESXiホスト、クライアントと安全に通信するために使用するSSL証明書が格納されている。