バックアップの目的は、システム障害や操作ミス、運用ミスがあった場合に、以前のある時点の状態に戻すことです。
　データだけでなく、アプリケーション、OS、システム設定などもその対象となります。システムの2重化やストレージの2重化だけでは、操作ミス、運用ミスからの復旧はできないので、バックアップが必要です。

　このルールは米国でよく知られたバックアップの最低限のルールです。日本国内でも重要なデータのバックアップにはこのルールは暗黙知として遵守されて来ています。
・3Copiesとは、原データとその2個のコピーを指します。
・2different Mediaとは2種のメディアを指します。例えば、ディスクとテープ媒体です。
・1offsite Copy とは別サイトに1個コピーを持つことを指します。

表1で説明します。
　・例1は、原データから媒体種別の異なる2個のコピーを作成し、1個はオフサイトにおいてあります。3-2-1ルールを満たしています。
　・例2は、原データから媒体種別が同じコピーと媒体種別が異なるコピーを作成し、オフサイトに媒体種別の異なるコピーを置いています。これも、3-2-1ルールを満たしています。
　・例3は、原データと同じ種別の媒体で、2個のコピーを作成しており、オフサイトにコピーを置いているものの3-2-1ルールを満たしていません。
　・例4は、原データから媒体種別の異なる2個のコピーを作成しているものの、オフサイトがないため、3-2-1ルールを満たしていません。
　2different Mediaの目的は、同種のシステムを利用していると、同種のシステムに共通に発生する想定外の障害から逃れられないので、使用するシステムの種別を複数にすることで、想定外の障害から回避することにあります。クラウドサービスでは、全てをHDDやSSDで構築しており、同一種類の媒体に相当するとも言えますが、他社のサービスは、仕組み・運用が異なるので、different Mediaに相当しているとも考えられます。実際、バックアップデータを現在利用中のクラウドサービス提供者以外のものを利用する事例（マルチクラウド利用）も出てきています。
　1 offsite Copyの目的は地震等の天災や火災に対する防衛です。日本においては、地震や大雨・大洪水などの天災もあるので、遠隔地サイトである必要があります。パブリッククラウドのセンターに例えると、メインサイトが東京リージョンならば、遠隔のバックアップセンターは、大阪リージョンです。海外のセンターをバックアップセンターに設定してしまうと、法律上の制約が大きくなるので、避ける利用には検討が必要です。さらに、デフォルトの設定が海外センターになっているサービスもあるので、入念な確認が必要です。
　同一リージョン内で、複数のアべイラビリティ・ゾーンにデータを置いても、日本では災害からの防衛にはならず、表1の例4相当になり3-2-1ルールからは不十分であることも、十分理解しておく必要があります。

　バックアップの対象は、データファイル群、データベースファイル群、OS,アプリケーション、設定ファイル群などです。
　これは、従来と変わりませんが、クラウドになって従来と大きく変わるのは、仮想環境で動作することです。ここでは詳細は説明しませんが、バックアップの対象ファイルも形式が変化します。リスク面から見ると単体ディスクの容量の増大が著しく、ディスク単体の障害でも仮想環境では影響を受けるシステム数が大幅に増えます。例えば、2019年12月の日本電子計算株式会社の自治体専用IaaS「Jip-Base」の事故では、SSD（半導体ディスクドライブ）障害で1318個の仮想OSシステムが影響を受けています。

　仮想環境では、物理マシンのリソース（CPU,メモリ、ディスク）を有効するように設計しますので、リアル環境に比べて、リソースの余裕は少なくなります。

　図1を見てみましょう。リアル環境では、バックアップ時にも物理サーバーのリソースに余裕があっても、仮想環境では、通常時の負荷レベルが上がっています。このために、バックアップ時にリソースに余裕がなくなってしまうことがあります。例えばCPUを考えてみますと、1台で使用した場合、CPUの使用率が25%であれば、余裕は75%あります。仮想化で3台として使うとCPUの使用率は75となり余裕は25%となります。 リソース余裕がないとバックアップ動作をしている間、同一リソースを使用する他の業務に影響を与えることになってしまいます。ですので、バックアップはシステム毎に順次行って、本番業務への影響がないように設計する必要があります。
　仮想化環境では、バックアップデータ量を少なくする仕組みもあり、このような仕組みをうまく利用する技術も必要です。このように、仮想環境のバックアップ設計は、リアル環境に比べて格段に設計の難易度が高くなっています。

　仮想環境のバックアップは基本的に以下の３方式があります。
　①仮想マシン上でのバックアップ方式（従来と同じ方式）
　②仮想機能連携型バックアップ方式
　③ストレージスナップショット連携型バックアップ方式

　以下、順に簡単に説明します。
　①仮想マシン上でのバックアップ方式（従来と同じ方式）
　従来のバックアップ方式と同じです。図2で説明します。バックアップエージェトを仮想マシン上にインストールし、バックアップサーバーへバックアップデータを転送します。バックアップ時、大量データ転送が発生するので、他の仮想マシンに影響することに留意する必要があります。

　②仮想機能連携型バックアップ方式
　仮想環境の大量のデータを速くバックアップするための仮想環境特有の方式です。図3で、説明します。VMWareなどのハイパーバイザ経由で、VADAP（vStorage API for Data Protection）やCBT(Change Block Tracking)などを使いLANを通さないで、バックアップデータをバックアップサーバーの指示するストレージに転送します。
　ただし、データベースを含むバックアップをする場合は、データベース内のレコードやデータベース外のファイル等々と整合を取る必要があり、データベースを使用するアプリケーションを一時停止して静止点を確保しなければいけません。しかし、②の方式では、静止点の確保が困難なため、従来方式である①を併用することも多くあります。

　③ストレージスナップショット連携型バックアップ方式
　ストレージシステムの中にはスナップショット機能を持つものがあります。ある時点でのファイルの写しが残せます。
　図4にて、説明します。仮想環境のストレージにスナップショットを取れるタイプを導入することで、バックアップを取ることもできます。そのスナップショットとバックアップサーバーが指定するストレージに転送します。

　バックアップ技術は、進歩が速いので制限、制約、性能については、最新情報を確認して頂く必要はありますが、3方式の特徴を以下に簡単にまとめます。
　①仮想マシン上でのバックアップ方式（従来と同じ方式）
　バックアップ設計者、運用者が慣れており、イニシャルコストも安い。一方、負荷変動の影響を大きく受ける。
　②仮想環境連携型バックアップ方式
　負荷変動の影響を受けにくいものの、データベースのバックアップは不得意である。
　③ストレージ連携バックアップ方式
　性能は一番高いが、スナップショットを取れるストレージの導入などでイニシャルコストがかさむ。

　オンプレミスの場合も同じですが、仮想環境ではリソース設計、スケジュール管理がより複雑になります。必ず、バックアップ運用の設計を行って、手順書を作成し、それに基づいてバックアップ、リストの運用テストを必ず行うことが必要です。
　また検証用の環境も備え、構成変更などの際もテストをやり直す、使用しているツールや製品間の適合確認もしっかりやる必要があります。これまでのバックアップに関する事故でも、手順書がなかった、手順書通り作業しなかった、検証環境を持たなかった、などの事例があります。
　バックアップ運用者にとっても一番怖いのがリストア作業です。リストア作業は日々行うものではありません。緊急時だけ行うものです。それだけに運用テストや日頃の訓練が欠かせません。

　通常、個々のバックアップ操作は、JOBという形で登録して、順次スケジューリングにより実行しますが、中にはいろいろな原因で正常終了しないことがあります。仮想環境の場合は、そのJOBの数が非常に多くなりますが、正常終了していないJOBがないか監視することが必要です。正常終了していない場合は、バックアップ運用者は、異常終了原因を取り除き、リトライする必要があります。この監視とリトライを確実に行わないと、バックアップ運用をしているだけで、復旧のためのリストアがうまくいきません。
　また仮想環境では、障害だけでなく、性能やリソースの推移も監視しておかないと、バックアップ障害や業務障害につながります。

　仮想環境下のバックアップ、リストアについて利用者部門の方も知っておくべき最小限の知識について紹介しました。
　以下に、仮想環境のバックアップリストアの確認ポイントを整理します。
　（１）オフサイト、異種媒体を使って、(3-2-1)バックアップルールに準拠しているか。
　（２）バックアップの方式はどれか。
　　・仮想マシン上でのバックアップ方式
　　・仮想機能連携型バックアップ方式
　　・ストレージスナップショット連携型バックアップ方式
　（３）バックアップ/リストアの運用設計を実施しているか。
　（４）バックアップ/リストアの運用テストを実施しているか。
　　※DR(ディザスタ―リカバリー)テスト内でも可。
　（５）実行環境で、リソースの充足やバックアップ異常終了を監視しているか。
　（６）システム構成に変更があった場合は、運用設計の見直しや必要に応じた再テストを行っているか。

　情報システムの専門家でない利用者も仮想環境を使用する場合は、自分の使用している環境がどの程度の配慮がなされているかに興味を持って頂ければと思います。パブリッククラウドのPaaS,IaaSの利用時だけでなく、クラウドサービスのSaaSを利用する場合も仕様確認をしておくことで、まさかそんなことになっていたとは、というため息を漏らすことは減らすことができると考えます。そのためにも情報システム部門と協力して、バックアップ責任者から説明や仕様を聞き出すことをお勧めします。