データ保護戦略としてSnapshotを使用することに対する一般的な反対意見の1つは、「実際の」データとSnapshotデータが同じドライブに配置されていることです。これらのドライブが失われると、プライマリデータとバックアップの両方が失われます。

これは有効な問題です。ローカルSnapshotは、日 々 のバックアップとリカバリのニーズに使用され、その点でSnapshotはバックアップです。NetApp環境のすべてのリカバリシナリオの99%近くが、最も厳しいRTO要件を満たすためにSnapshotを使用しています。

ただし、ローカルSnapshotが唯一のバックアップ戦略であるべきではありません。そのため、NetAppでは、SnapMirrorレプリケーションなどのテクノロジを使用して、独立したドライブセットにSnapshotを迅速かつ効率的にレプリケートできます。スナップショットとスナップショットレプリケーションを使用して適切に設計された解決策では、テープの使用を最小限に抑えて四半期ごとのアーカイブを作成することも、完全に排除することもできます。

整合グループのバックアップでは、データセット（または複数のデータセット）の状態を単一のアトミックポイントインタイムでキャプチャします。データベースの例では、データファイル、ログファイル、データベースに直接関連付けられているその他のファイルなど、すべてのデータベースコンポーネントが含まれます。Oracle RDBMS、Microsoft SQL Server、SAP HANA、PostgreSQL、 MySQL、MariaDBなどがあります。整合グループのバックアップを使用してVMware構成を保護する場合は、すべてのデータストアとESXブートLUNを1つのアトミックポイントインタイムでキャプチャすることになります。

このような整合性グループSnapshotの作成は、基本的にはクラッシュをシミュレートしたものです。そのため、このようなバックアップは、crash-consistentバックアップと呼ばれることがよくあります。リカバリシナリオのサポートに懸念が生じることがありますが、通常はリカバリ手順は不要であることを理解しておくことが重要です。整合グループのバックアップをリストアしたあとにアプリケーションを起動すると、通常のログリカバリプロセス、ファイルシステムジャーナルの再生、およびその他のタスクが実行され、バックアップ時点で転送中だったI/Oが再生されます。その後、アプリケーションは通常どおり起動します。

基本的に、データの破損なしに電源障害やサーバクラッシュに耐えることができるアプリケーションは、この方法で保護できます。この機能は、さまざまなベンダーの同期および非同期ミラーリング製品で保護されている膨大な数のアプリケーションによっても実証できます。プライマリサイトで突然災害が発生した場合、レプリカサイトには、災害が発生した時点の元の環境の整合性のあるイメージが格納されます。繰り返しになりますが、特別なリカバリ手順は必要ありません。

通常、このアプローチのRPOはバックアップの時点までに制限されます。原則として、単一ボリュームのSnapshotの最小RPOは1時間です。たとえば、時間単位のSnapshotを48個に加えて、夜間Snapshotを30日間追加するのが妥当であり、大量のSnapshotを保持する必要はありません。RPOを1時間未満に抑えることは難しくなります。環境、拡張性、データ保護の要件を理解するために、まずNetAppプロフェッショナルサービスに相談しないと、この目標を達成することはできません。

通常、RTOは数秒で測定できます。アプリケーションがシャットダウンされ、ボリュームがリストアされ、アプリケーションが再起動されます。

最も簡単な方法は、すべてのファイルまたはLUNを1つのボリューム整合性グループに配置することです。これにより、ONTAPで直接Snapshotの作成をスケジュールできます。データセットが複数のボリュームにまたがっている必要がある場合は、整合性グループSnapshot（cg-snapshot）が必要です。これは、System ManagerまたはRESTful API呼び出しを使用して設定できます。また、SnapCenterでは、定義済みのボリュームリストに対してシンプルな整合性グループSnapshotを作成できます。

ここでは、セキュアなオフサイトストレージとディザスタリカバリを目的として、データをリモートサイトにレプリケートするリモートデータ保護について説明します。これらのテーブルは、同期ミラーリングのデータ保護には対応していません。この要件については、およびを含むNetApp MetroClusterのドキュメントを参照してください。"MetroCluster""SnapMirrorアクティブ同期"

DRのRPOは、使用可能なネットワーク帯域幅と保護対象のデータの合計サイズによって制限されます。初回のベースライン転送の作成後は、変更されたデータのみに基づいて更新が行われます。これは通常、例外もありますが、総データ容量に占める割合は低くなります。

たとえば、週単位の変更率が10%の10TBデータベースでは、1時間あたりの合計変更量は約6GBです。10Gbの接続では、このデータベースの転送に約6分かかります。変更率はデータベースの変更率の変動に応じて変化しますが、全体的には更新間隔が15分であるため、RPOが15分になるはずです。このようなデータベースが100個ある場合、データの転送に600分かかります。したがって、RPOを1時間にすることはできません。同様に、100TBの単一データベースのレプリカのサイズが週に10%の変更率であれば、1時間で確実に更新することはできません。

レプリケーションのオーバーヘッドや同時レプリケーション処理数の制限など、レプリケーションに影響するその他の要因があります。ただし、単一ボリュームのレプリケーション戦略の全体的な計画は、使用可能な帯域幅に基づいて行うことができ、通常はレプリケーションのRPOを1時間にすることができます。RPOが1時間未満になると達成が難しくなるため、NetAppプロフェッショナルサービスに相談してから実行する必要があります。場合によっては、サイト間のネットワーク接続が非常に良好であれば15分で十分です。ただし、全体的に1時間未満のRPOが必要な場合は、マルチボリュームのログ再生アーキテクチャが適しています。

ディザスタリカバリシナリオにおける整合グループレプリケーションを使用したRTOは非常に優れており、ストレージの観点から見れば、通常は数秒で測定されます。最も簡単な方法は、単にミラーを解除することであり、データベースを起動する準備ができています。通常、データベースの起動時間は約10秒ですが、大量のトランザクションがログに記録された非常に大規模なデータベースには数分かかることがあります。

RTOを決定するうえで最も重要な要素は、ストレージシステムではなく、ストレージシステムを実行するアプリケーションとホストオペレーティングシステムです。たとえば、レプリケートされたデータを1秒または2秒で使用できるようにすることができますが、これはデータのみを表します。また、データを使用できるアプリケーションバイナリを備えた、適切に構成されたオペレーティングシステムも必要です。

場合によっては、オペレーティングシステムで事前に検出されたストレージを使用して、ディザスタリカバリのインスタンスを事前に準備していることもあります。このような場合、ディザスタリカバリシナリオをアクティブ化するには、ミラーを解除してアプリケーションを起動するだけです。また、OSと関連するアプリケーションをデータベースとともにESX Virtual Machine Disk（VMDK；仮想マシンディスク）としてミラーリングする場合もあります。このような場合のRPOは、お客様がVMDKを迅速にブートしてアプリケーションを起動できるように自動化にどれだけ投資したかによって決まります。

保持期間の一部はSnapshotの制限によって制御されます。たとえば、ONTAPのボリュームには、Snapshotの数が1024個に制限されています。場合によっては、レプリケーションを多重化して制限を引き上げていることもあります。たとえば、2000日分のバックアップが必要な場合、ソースを2つのボリュームにレプリケートし、別の日に更新を実行できます。そのためには、必要な初期スペースを増やす必要がありますが、フルバックアップを複数回実行する従来のバックアップシステムよりもはるかに効率的なアプローチです。