データ保護戦略としてSnapshotを使用する場合によく寄せられる質問の1つは、「実際の」データとSnapshotデータが同じドライブに配置されていることです。これらのドライブが失われると、プライマリデータとバックアップの両方が失われます。

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

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

ONTAP Snapshotコピーを使用してデータを保護する方法は多数ありますが、Snapshotは、レプリケーション、ディザスタリカバリ、クローニングなど、ONTAPの他の多くの機能の基盤となります。Snapshotテクノロジの完全な概要については本ドキュメントでは説明しませんが、ここでは概要について説明します。

データセットのスナップショットを作成するには、主に次の2つの方法があります。

データセットのcrash-consistentバックアップとは、ある時点におけるデータセット構造全体のキャプチャです。データセットが単一のボリュームに格納されている場合は、Snapshotはいつでも作成できるため、このプロセスは簡単です。データセットが複数のボリュームにまたがっている場合は、整合性グループ（CG）Snapshotを作成する必要があります。CG Snapshotを作成するには、NetApp SnapCenterソフトウェア、ONTAPのネイティブ整合グループ機能、ユーザが管理するスクリプトなど、いくつかのオプションがあります。

crash-consistentバックアップは、主にpoint-of-the-backupリカバリで十分な場合に使用します。よりきめ細かなリカバリが必要な場合は、通常、アプリケーションと整合性のあるバックアップが必要です。

「application-consistent」の「consistent」という言葉は、しばしば誤った名義である。たとえば、Oracleデータベースをバックアップモードにすることをアプリケーション整合性バックアップと呼びますが、データの整合性が確保されたり休止されたりすることはありません。バックアップ中もデータは変化し続けます。一方、ほとんどのMySQLおよびMicrosoft SQL Serverのバックアップでは、バックアップを実行する前にデータが休止されます。VMwareは、特定のファイルの整合性を確保する場合としない場合があります。

「コンシステンシグループ」とは、ストレージアレイが複数のストレージリソースを単一のイメージとして管理できることを指します。たとえば、データベースが10個のLUNで構成されているとします。アレイは、これらの10個のLUNを一貫した方法でバックアップ、リストア、およびレプリケートできる必要があります。バックアップ時点でLUNのイメージに一貫性がなかった場合は、リストアを実行できません。これらの10個のLUNをレプリケートするには、すべてのレプリカが相互に完全に同期されている必要があります。

ONTAPは、データの一貫したローカルイメージと複製イメージを取得することができます。ONTAP AFF/FASシステム上のさまざまなボリュームは、通常、正式には整合性グループとして記述されることはありませんが、実際には整合性グループです。そのボリュームのSnapshotは整合性グループイメージであり、そのSnapshotのリストアは整合性グループリストアであり、SnapMirrorとSnapVaultの両方が整合性グループレプリケーションを提供します。

AFFシステムには、より広範なタイプの整合性グループも含まれています。複数のボリュームをONTAP内でCGとして定義できます。Snapshot、クローン、レプリケーションは、CGレベルで設定できます。これにより、個々のボリュームやLUNだけでなく、データセットにポリシーを設定できるため、データ保護戦略が簡素化されます。CGは、ASAシステムにも存在します。複数のLUNまたはネームスペースをCGとして結合することができ、そのCGはSnapshotによる保護、レプリケート、リストア、またはクローン作成が可能です。

整合性グループ（CG）Snapshotは、基本的なONTAP Snapshotテクノロジの拡張機能です。標準のSnapshot処理では、単一のAFF/FASボリュームまたはASA LUN/ネームスペース内のすべてのデータの整合性のあるイメージが作成されますが、複数のストレージ リソース、さらには複数のストレージ システムにわたって整合性のあるSnapshotセットを作成する必要がある場合もあります。その結果、個々のボリュームのSnapshotと同じように使用できる一連のSnapshotが得られます。これらは、ローカル データ リカバリに使用したり、ディザスタ リカバリのためにレプリケートしたり、単一の整合性のある単位としてクローニングしたりすることができます。

CGスナップショットは非常に優れたスケーリング性能を発揮します。CGスナップショットの最大の既知の使用例は、12台のコントローラにまたがる約1PBのデータベース環境です。このシステムで作成されたCGスナップショットは、バックアップ、リカバリ、クローニングに使用されています。

ほとんどの場合、データセットがAFFボリュームまたはASA LUN/名前空間にまたがり、書き込み順序を保持する必要がある場合、ONTAP整合性グループを簡単に定義でき、ボリューム、LUN、または名前空間のグループをネイティブに管理してSnapshotを作成できます。管理ソフトウェアを使用する場合は、CGスナップショットの必要性を検出し、必要なAPIを呼び出す必要があります。

このような場合、CGスナップショットの技術的な詳細を理解する必要はありません。しかし、複雑なデータ保護要件を満たすためには、データ保護および複製プロセスを詳細に制御する必要がある状況も存在します。自動化ワークフローや、CGスナップショットAPIを呼び出すためのカスタムスクリプトの使用などが選択肢として挙げられます。最適な選択肢とCGスナップショットの役割を理解するには、この技術についてより詳細な説明が必要です。

整合性グループ Snapshot のセットの作成は、2 つのステップからなるプロセスです：

書き込みフェンスは連続的に確立されます。これは、フェンシング処理が複数のストレージ ターゲットにまたがって設定されると、リストの後半に表示されるターゲットでも書き込みI/Oが引き続きフリーズされるため、シーケンスの最初のオブジェクトで書き込みI/Oがフリーズされることを意味します。これは一見、書き込み順序を維持するという要件に違反しているように見えるかもしれませんが、それはホスト上で非同期的に発行され、他の書き込みに依存しないI/Oにのみ適用されます。

たとえば、データベースでは大量の非同期データファイル更新が問題され、OSがI/Oの順序を変更して、独自のスケジューラ設定に従って完了できる場合があります。アプリケーションとオペレーティングシステムが書き込み順序を保持する要件をすでにリリースしているため、このタイプのI/Oの順序は保証できません。

反例として、ほとんどのデータベースのログ記録処理は同期的に行われます。データベースは、I/Oが承認されるまでログの書き込みを続行せず、書き込みの順序は維持されなければなりません。フェンス付きLUNにログI/Oが到着した場合、それは確認応答されず、アプリケーションはそれ以降の書き込みをブロックします。同様に、ファイル システムのメタデータI/Oは通常同期的に行われます。たとえば、ファイル削除操作は失われてはなりません。xfsファイル システムを搭載したオペレーティング システムがファイルを削除し、そのファイルへの参照を削除するためにxfsファイル システムのメタデータを更新するI/Oがフェンス付きLUN上で実行された場合、ファイル システムのアクティビティは一時停止します。これにより、CG操作中のファイル システムの完全性が保証されます。

書き込みフェンシングがターゲット全体に設定されると、スナップショット作成の準備が整います。スナップショットは、依存書き込みの観点からターゲットの状態が固定されているため、必ずしも同時に作成する必要はありません。CGスナップショットを作成するアプリケーションの欠陥を防ぐために、初期書き込みフェンシングには、ONTAPが指定された秒数経過後に自動的にフェンシングを解除し、書き込み処理を再開する設定可能なタイムアウトが含まれています。タイムアウト期間が経過する前にすべてのスナップショットが作成された場合、結果として得られるスナップショットのセットは有効な整合性グループとなります。

Snapshotベースのバックアップには、主に次の2つの方法があります。

データベースのcrash-consistentバックアップとは、データファイル、REDOログ、制御ファイルなど、データベース構造全体を単一の時点でキャプチャすることを指します。データベースが単一のボリューム、LUN、またはネームスペースに格納されている場合、プロセスは簡単です。Snapshotはいつでも作成できます。データベースがAFFボリュームまたはASA LUN/ネームスペースにまたがる場合は、整合性グループ（CG）Snapshotを作成する必要があります。CGスナップショットを作成するためのオプションはいくつかあり、NetApp SnapCenterソフトウェア、ネイティブONTAP整合性グループ機能、およびユーザーが管理するスクリプトなどがあります。

crash-consistentスナップショット バックアップは、主にバックアップ時点のリカバリで十分な場合に使用されます。アーカイブ ログは状況によっては適用できますが、より詳細なポイントインタイム リカバリが必要な場合は、オンライン バックアップの方が望ましいです。

Snapshotベースのオンラインバックアップの基本的な手順は次のとおりです。

この手順により、バックアップモードのデータファイルと、バックアップモード中に生成された重要なアーカイブログを含む一連のSnapshotが作成されます。データベースのリカバリには、次の2つの要件があります。制御ファイルなどのファイルも便宜上保護する必要がありますが、絶対に必要なのはデータファイルとアーカイブログの保護だけです。

戦略はお客様によって大きく異なる可能性がありますが、これらの戦略のほとんどは、最終的には以下に概説されているのと同じ原則に基づいています。

Oracleデータベースのストレージ レイアウトを設計する際、最初に決めるべきことは、ボリューム ベースのNetApp SnapRestore（VBSR）テクノロジを使用するかどうかです。これは、AFFボリュームおよびASA LUN/ネームスペースのリストアに使用される基盤テクノロジです。

VBSRを使用すると、データをほぼ瞬時に以前の時点に戻すことができます。リバートされたすべてのデータがあるため、VBSRはすべてのユースケースに適しているとは限りません。たとえば、データファイル、REDOログ、アーカイブログを含むデータベース全体が単一のAFFボリュームに格納されていて、このボリュームがVBSRでリストアされた場合、新しいアーカイブログとREDOデータが破棄されるため、データが失われます。同じことがASAデータにも当てはまります。データベース全体が単一のASA整合性グループに格納されていて、そのCGが以前の状態にリストアされた場合、後のアーカイブログとREDOデータの一部が失われます。

VBSRはリストアには必要ありません。多くのデータベースは、ファイルベースの単一ファイルSnapRestore（SFSR）を使用するか、Snapshotからアクティブ ファイル システムにファイルをクローニングするだけでリストアできます。

VBSRは、データベースが非常に大きい場合、または可能な限り迅速にリカバリする必要がある場合に推奨され、VBSRを使用するにはデータファイルの分離が必要です。NFS環境では、特定のデータベースのデータファイルは、他の種類のファイルによって汚染されていない専用のボリュームに保存する必要があります。SAN環境では、データファイルは専用のLUNまたはネームスペースに保存する必要があります。ボリューム マネージャ（Oracle Automatic Storage Management [ASM]を含む）を使用する場合、ディスク グループもデータファイル専用にする必要があります。

このようにデータファイルを分離することで、他のファイルシステムに損傷を与えることなく、以前の状態に戻すことが可能になります。

AFF SAN環境でOracleデータを含む各ボリュームについては、 `percent-snapshot-space`をゼロに設定する必要があります。LUN環境でSnapshotリザーブ用のスペースを確保しても役に立たないためです。fractional reserveが100に設定されている場合、LUNを含むボリュームのSnapshotには、Snapshotリザーブを除いて、すべてのデータの100%の変更を吸収するのに十分な空きスペースがボリューム内に必要です。fractional reserveをより低い値に設定すると、それに応じて必要な空きスペースは少なくなりますが、Snapshotリザーブは常に除外されます。つまり、LUN環境ではSnapshotリザーブのスペースが無駄になります。

NFS環境には2つのオプションがあります。

最初のオプションでは、 percent-snapshot-space は、ゼロ以外の値（通常は約20%）に設定されます。このスペースはユーザーには表示されません。ただし、この値によって利用率が制限されるわけではありません。リザーブが20%のデータベースで30%の入れ替えが発生した場合、スナップショット領域は20%リザーブの範囲を超えて拡張され、リザーブされていないスペースを占有する可能性があります。

リザーブを20%などの値に設定する主な利点は、一部のスペースが常にスナップショットに使用可能であることを確認することです。たとえば、1TBのボリュームに20%のリザーブが設定されている場合、データベース管理者（DBA）が格納できるのは800GBのデータのみです。この構成では、Snapshot用に少なくとも200GBのスペースが保証されます。

いつ percent-snapshot-space がゼロに設定されている場合、ボリューム内のすべてのスペースをエンドユーザが使用できるため、可視性が向上します。データベース管理者は、Snapshotを利用する1TBのボリュームが表示された場合、この1TBのスペースはアクティブデータとSnapshotの書き替えの間で共有されることを理解しておく必要があります。

エンドユーザ間では、オプション1とオプション2の間に明確な優先順位はありません。

Oracle Doc ID 604683.1には、サードパーティ製スナップショットのサポート要件と、バックアップおよびリストア処理に使用できる複数のオプションが説明されています。

サードパーティベンダーは、会社のスナップショットが次の要件に準拠していることを保証する必要があります。

ONTAPおよびNetAppのOracle管理製品は、これらの要件に準拠しています。