ただし、実際にデータ保護（＝バックアップ）を行うのは利用者ではなく、運用者が行うのが一般的であり、バックアップの手法や詳細をユーザーサイドで指定できる項目は少なく、あらかじめ指定された方法から選択する方式を取っているケースも多い。
部門サーバや従来の企業内システムと比べると求められるパフォーマンス、拡張性、セキュリティなど、どの項目をとっても高度なものが求められる中、柔軟性とのバランスを取るための現実的な方法ともいえる。
仮想化環境におけるバックアップ手法
図2：仮想マシンにバックアップエージェント
※クリックすると拡大画像が見られます
では、リカバリに先立ち、どのようなバックアップ方法があるのか、ここで代表的な方法を簡単に紹介したい。
（1）仮想マシンにバックアップエージェント
従来の物理環境の方法をそのまま適用する、エンドユーザーサイドでもノウハウがあるなどの理由で使用されるケースが多い。バックアップソフトウェアからは、一部の例外を除き、原則的に物理環境との違いはないといえる。
メリット
- 容易な導入
- 個別ファイルの検索、リストア
- データベースエージェントとの連携 （コラムを参照）
デメリット
- 仮想マシン全体のリカバリにおける煩雑さ
- 全ての仮想マシンのバックアップソフトのエージェントをインストール
- ハードウェアリソースの消費
最近では、1台の物理サーバに数十、ときには百を超える仮想マシンが動作するのが一般的になる中で、特定の仮想マシンのバックアップにより物理リソースを消費することで他の仮想マシンへのリソース面で影響が発生し、結果として統合効率を上げられないことにもつながる。バックアップに必要とされる主なリソースは、（1）ディスクへのI/O、（2）バックアップサーバへのネットワーク転送、（3）CPUだ。
データベースのバックアップ
データベース（DB）のバックアップやリカバリでは、実際のデータが格納されたデータファイルも重要であるが、むしろ変更履歴を管理しているログが重要になる。
DBのログは、設定にも依存するが、基幹システムでは累積させる方法が一般的である。 累積させないと古いログが新しいログによって上書きされてしまい、任意の時点（＝トランザクション）へのリカバリができないためである。
一方、ログを累積させる場合、リカバリの柔軟性が向上するが、ログ情報が増え続けディスク容量を圧迫することを避けるため、周期的にログを削除する。DB管理者が主導でログの切り捨てなどを行うこともあるが、バックアップ処理とログの切り捨てを同時に行うことは多い。
