Azure NetApp Files のスナップショットのしくみ

この記事では、Azure NetApp Files のスナップショットのしくみについて説明します。 Azure NetApp Files のスナップショット テクノロジにより、パフォーマンスに影響せずに安定性、スケーラビリティ、高速回復性が実現します。 1 つのファイルの復元、ボリュームの復元とクローン、リージョン間のレプリケーションと長期保有を含め、データ保護ソリューションの基盤が提供されます。

ボリューム スナップショットの使用手順については、「Azure NetApp Files を使用してスナップショットを管理する」を参照してください。 リージョン間レプリケーションでのスナップショット管理に関する考慮事項については、「リージョン間レプリケーションを使用するための要件と考慮事項」を参照してください。

ボリューム スナップショットとは

Azure NetApp Files のスナップショットは、特定の時点のファイル システム (ボリューム) のイメージです。 オンライン バックアップとして使用するのに最適です。 スナップショットを使用すると、新しいボリュームの作成 (クローン)、ファイルの復元、またはボリュームを元に戻すことが可能です。 Azure NetApp Files ボリュームに保存されている特定のアプリケーション データでは、アプリケーションの整合性を確保するために追加の手順が必要になることがあります。

基盤となるボリューム仮想化テクノロジ (Azure NetApp Files の一部) の固有の機能によって、オーバーヘッドの少ないスナップショットを実現できます。 データベースと同様に、このレイヤーでは、ディスク上の実際のデータ ブロックへのポインターが使用されます。 しかし、データベースとは異なり、既存のブロックは書き換えられません。更新されたデータは新しいブロックに書き込まれ、ポインターが変更されるため、新しいデータと古いデータが維持されます。 Azure NetApp Files のスナップショットでは、単にブロック ポインターが操作され、ボリュームの "固定された" 読み取り専用ビューが作成されます。これにより、アプリケーションは、特別なプログラミングなしで、古いバージョンのファイルやディレクトリ階層にアクセスできます。 実際のデータ ブロックはコピーされません。 そのため、スナップショットは、作成に必要な時間に関して効率的であり、ボリューム サイズに関係なく、ほぼ瞬時に完了します。 スナップショットは記憶域でも効率的です。スナップショットとアクティブなボリューム間の差分ブロックのみが保持されます。

次の図は、その概念を示しています。

スナップショットの主要な概念を示す図

この図では、図 1a でスナップショットが作成されています。 図 1b では、変更されたデータが "新しいブロック" B1 に書き込まれ、ポインターが更新されています。 しかし、スナップショット ポインターは引き続き "以前に書き込まれたブロック" B を指すため、データのライブおよび履歴ビューが得られます。 図 1c では、別のスナップショットが作成されています。 これで、3 つの完全なコピーに必要なボリューム領域を占有することなく、3 世代のデータ (ライブ データ、スナップショット 2、およびスナップショット 1 (経過時間順)) にアクセスできます。

スナップショットでは、ボリューム メタデータ ("inode テーブル") のコピーのみが作成されます。 ボリュームのサイズ、使用されている容量、ボリュームのアクティビティのレベルに関係なく、作成には数秒しかかかりません。 そのため、100-TiB ボリュームのスナップショットを作成するのにかかる時間は、100-GiB ボリュームのスナップショットを作成するのにかかる時間と同じ (ほぼゼロ) です。 スナップショットが作成された後、データ ファイルへの変更は、通常どおり、アクティブなバージョンのファイルに反映されます。

一方、スナップショットからポイントされているデータ ブロックは変更されません。 Azure NetApp Files ボリュームの "書き込み時のリダイレクト" の性質により、スナップショットではパフォーマンスのオーバーヘッドは発生せず、それら自体ではいずれの領域も消費されません。 時間の経過に伴いボリュームごとに最大 255 のスナップショットを保存でき、そのすべてに読み取り専用およびオンライン バージョンのデータとしてアクセス可能であり、各スナップショット間で変更されたブロック数と同程度の容量しか消費されません。 変更されたブロックは、アクティブなボリュームに保存されます。 スナップショットでポイントされているブロックは、保護のためにボリュームに (読み取り専用として) 保持され、(アクティブなボリュームおよびスナップショットの) すべてのポインターがクリアされている場合にのみ再利用されます。 そのため、スナップショットで保持される新しいデータ ブロックまたは (変更された) データ ブロックにより、時間の経過に伴いボリューム使用率が増加します。

次の図は、ボリュームのスナップショットと、時間の経過に伴い使用されるスペースを示しています。

ボリュームのスナップショットと、時間の経過に伴い使用されるスペースを示す図

ボリューム スナップショットでは、最新のスナップショット以降のブロックの変更のみが記録されるため、次のような主な利点があります。

  • スナップショットは "ストレージ効率に優れています"。
    スナップショットでは、ボリューム全体のデータ ブロックはコピーされないため、消費される記憶域は最小となります。 順番に作成された 2 つのスナップショットの相違点は、2 つの間の時間間隔で追加または変更されたブロックのみです。 このブロック増分動作によって、関連するストレージ容量の消費を最小限に抑えることができます。 他の多くのスナップショットの実装では、アクティブなファイル システムと同等のストレージ ボリュームが消費されるため、ストレージ容量の要件が高くなります。 アプリケーションの毎日の "ブロック レベル" の変更率によっては、Azure NetApp Files スナップショットの消費容量は増減しますが、これは変更されたデータにのみ基づきます。 1 日あたりの平均スナップショット消費量の範囲は、多くのアプリケーション ボリュームで使用されるボリューム容量の 1% から 5% が下限で、SAP HANA データベース ボリュームなどのボリュームの 20 % から 30% が上限です。 必ずボリュームとスナップショットの使用量を監視して、作成され保持されているスナップショットの数と比較してスナップショットの容量消費を確認してください。

  • スナップショットは "すばやく作成、レプリケート、復元、複製" できます。
    ボリュームのサイズとボリュームでのアクティビティのレベルに関係なく、スナップショットの作成、レプリケート、復元、クローンには数秒しかかかりません。 ボリュームのスナップショットはオンデマンドで作成できます。 また、スナップショット ポリシーを使用して、Azure NetApp Files でスナップショットを自動的に作成するタイミングと、ボリュームに対して保持するスナップショットの数を指定できます。 アプリケーション層でスナップショットを調整することで、アプリケーションの整合性を維持できます。たとえば、SAP HANA には AzAcSnap ツールを使用します。

  • スナップショットは、ボリュームの "パフォーマンス" には影響しません。
    基盤テクノロジの "書き込み時のリダイレクト" の性質により、Azure NetApp Files スナップショットを保存または保持してもパフォーマンスには影響しません。これは、大量のデータ アクティビティがあっても同様です。 また、スナップショットを削除しても、多くの場合、パフォーマンスにはほとんど影響しません。

  • スナップショットは頻繁に作成でき、多くを保持できるため、"スケーラビリティ" が提供されます。
    Azure NetApp Files ボリュームでは、ボリュームあたり最大 255 個のスナップショットがサポートされます。 少ない影響で多くのスナップショットを頻繁に作成して格納できるため、必要なバージョンのデータを正常に回復できる可能性が高くなります。

  • スナップショットは、Azure ストレージに 保管 できます。
    コンプライアンスとデータの長期保有の要件に合わせて、Azure NetApp Files バックアップ機能を使用して、保護されているボリュームの外部で、コスト効率の高い ZRS 対応の Azure ストレージにスナップショットを保管します。

  • スナップショットでは、"ユーザーの可視性" と "ファイルの回復性" が提供されます。

Azure NetApp Files スナップショット テクノロジはパフォーマンス、スケーラビリティ、安定性が高いため、ユーザー主導の回復のための最適なオンライン バックアップが提供されます。 スナップショットは、ファイル、ディレクトリ、またはボリュームの復元を目的として、ユーザーがアクセスできるようにすることができます。 追加のソリューションを使用すると、保有またはディザスター リカバリーの目的で、バックアップをオフライン ストレージにコピーしたり、リージョン間でレプリケートしたりすることができます。

スナップショットを作成する方法

いくつかの方法を使用して、スナップショットを作成および管理できます。

DR のためにボリュームとスナップショットをリージョン間でレプリケートする方法

Azure NetApp Files では、ディザスター リカバリー (DR) の目的でリージョン間レプリケーションがサポートされます。 Azure NetApp Files のリージョン間レプリケーションでは、SnapMirror テクノロジが使用されます。 変更されたブロックだけが、圧縮された効率的な形式でネットワーク経由で送信されます。 ボリューム間でのリージョン間レプリケーションを開始すると、ボリュームの内容全体 (つまり、実際に保存されているデータ ブロック) が 1 回だけ転送されます。 この操作は "ベースライン転送" と呼ばれます。 初回の転送後は、変更されたブロック (スナップショットでキャプチャされたもの) のみが転送されます。 その結果、すべてのスナップショットを含む、ソース ボリュームの非同期の 1:1 のレプリカが生成されます。 この動作は、完全および増分の永続的なレプリケーション メカニズムに従います。 このテクノロジにより、リージョン間でのレプリケーションに必要なデータ量が最小限に抑えられるため、データ転送コストが削減されます。 また、レプリケーション時間も短縮されます。 回復ポイントの目標 (RPO) を小さくすることができます。これは、最小限のデータ転送で、より頻繁により多くのスナップショットを作成して転送できるためです。 さらに、ホストベースのレプリケーション メカニズムが不要になり、仮想マシンとソフトウェアのライセンス コストをなくすことができます。

次の図は、リージョン間レプリケーション シナリオでのスナップショット トラフィックを示しています。

リージョン間レプリケーション シナリオでのスナップショット トラフィックを示す図

長期保有とコスト削減のためにスナップショットを保管する方法

前述のとおり、スナップショットは、Azure NetApp Files ボリュームの高速で領域効率の高いバックアップを効率的かつ迅速に作成するために使用され、データ ファイルまたは完全なボリュームを非常に効果的に復元する手段が提供されます。 これらのオンライン スナップショットは、防御の最前線として機能し、ほとんどのデータ回復操作に対応します。

スナップショットをより長い期間保持したり、オンライン スナップショットの最大数よりも多くのスナップショットを保持したりする場合は、Azure NetApp Files ボリュームのスナップショットを ZRS 対応の Azure ストレージに保管できます。 これは、Azure NetApp Files バックアップ機能を使用すると容易になります。 この機能を使用すると、スナップショットは長期間 (最大 1 年以上) 保持されます。 バックアップは Azure ストレージに格納され、Azure NetApp Files 容量プールの場合よりもコスト面で優位となります。また、依存関係を排除し、保有要件に準拠するために、別のストレージ プラットフォームが利用されます。

Azure NetApp Files ボリュームでスナップショットを保管できるようにするには、([データ保護] セクションにある) Azure NetApp Files サブスクリプションでバックアップ ポリシーを構成し、保持する日単位、週単位、および月単位のバックアップの数を指定します。 コスト効率の高い長期ストレージを使用して、データ保護を拡張するために行う必要があるのはこれだけです。

次の図は、スナップショット データが Azure NetApp Files ボリュームから、Azure ストレージでホストされている Azure NetApp Files バックアップ ストレージにどのように転送されるかを示しています。

Azure NetApp Files ボリュームから Azure NetApp Files バックアップ ストレージに転送されるスナップショット データを示す図

Azure NetApp Files バックアップ機能は、この簡略化された例に示されているように、バックアップのより長い履歴を保持するように設計されています。 右側のバックアップ リポジトリに、左側の保護されたボリュームとスナップショットよりも多くの古いスナップショットがどのように含まれるかに注目してください。

ほとんどのユース ケースでは、アプリケーションまたはユーザーのエラーが原因で失われたデータの最も一般的な回復を行うために、比較的短時間 (通常は数か月)、Azure NetApp Files ボリュームにオンライン スナップショットを保持する必要があります。 Azure NetApp Files バックアップ機能は、コスト効率の高い Azure ストレージにスナップショットを送信することで、データ保護期間を 1 年以上に延長するために使用されます。 図に青色で示されているように、一番最初の転送がベースラインであり、ソース Azure NetApp Files ボリュームとスナップショットの消費されたデータ ブロックはすべてコピーされます。 連続するバックアップではスナップショット メカニズムを使用して、ブロック増分更新のみでバックアップ リポジトリを更新します。

スナップショットからデータを復元する方法

Azure NetApp Files スナップショット テクノロジにより、バックアップの頻度と信頼性が大幅に向上します。 パフォーマンスのオーバーヘッドが最小限に抑えられ、アクティブなボリュームでの安全な作成が可能になります。 Azure NetApp Files スナップショットを使用すると、必要に応じて、ほぼ瞬時かつ安全にユーザー管理の復元を実行できます。 このセクションでは、Azure NetApp Files スナップショットからデータにアクセスしたり、データを復元したりするためのさまざまな方法について説明します。

オンライン スナップショットからのファイルまたはディレクトリの復元

[Snapshot Path visibility](スナップショット パスの表示)hidden に設定されていない場合は、データの誤った削除、破損、変更から回復するために、スナップショットに直接アクセスできます。 ファイルとディレクトリのセキュリティはスナップショットでも維持されます。スナップショットは、設計上、読み取り専用です。 そのため、復元は安全かつ簡単です。 [Snapshot Path visibility](スナップショット パスの表示) が hidden に設定されている場合は、サポート チケットを開き、バックアップ管理者またはシステム管理者にスナップショットからファイルを復元してもらうことができます。

次の図は、スナップショットへのファイルまたはディレクトリのアクセスを示しています。

スナップショットへのファイルまたはディレクトリのアクセスを示す図

この図では、スナップショット 1 により、アクティブなボリュームとスナップショット作成時の間の差分ブロックのみ消費されています。 ただし、ボリューム スナップショット パスを使用してスナップショットにアクセスすると、スナップショットの作成時にボリュームの容量がいっぱいになっているかのようにデータが "表示" されます。 スナップショット フォルダーにアクセスし、選択したスナップショットからファイルとディレクトリをコピーすることで、データを復元できます。

同様に、ターゲットのリージョン間レプリケーション ボリューム内のスナップショットには、DR リージョンのデータ復旧のために読み取り専用でアクセスできます。

次の図は、リージョン間レプリケーション シナリオでのスナップショット アクセスを示しています。

リージョン間レプリケーションでのスナップショット アクセスを示す図

スナップショットから個々のファイルまたはディレクトリを復元する方法については、「クライアントを使用してスナップショットからファイルを復元する」を参照してください。

新しいボリュームへのオンライン スナップショットの復元 (クローン)

Azure NetApp Files スナップショットを、個別の独立したボリュームに復元 (クローン) することができます。 この操作は、ボリュームのサイズと消費される容量に関係なく、ほぼ瞬時に実行されます。 実際のボリュームとスナップショットのデータ ブロックがコピーされている間、新しく作成されたボリュームはほぼ即座にアクセス可能になります。 ボリュームのサイズと容量によっては、このプロセスに相当な時間がかかる場合があり、その間は親ボリュームとスナップショットを削除することはできません。 ただし、コピー プロセスがバックグラウンドで実行されている間、ボリュームは、初めて作成された後にすぐにアクセスできます。 この機能により、データ回復のための迅速なボリューム作成や、テストおよび開発のためのボリューム複製が可能になります。 データ コピー プロセスの性質上、復元が完了するとストレージ容量プールの消費量が 2 倍になり、新しいボリュームに元のスナップショットの全アクティブ容量が表示されます。 このプロセスが完了した後、ボリュームは独立し、元のボリュームから関連付けが解除され、ソース ボリュームとスナップショットを新しいボリュームとは別に管理または削除できます。

次の図は、スナップショットの復元 (複製) によって作成された新しいボリュームを示しています。

スナップショットの復元によって作成された新しいボリュームを示す図

ディザスター リカバリー (DR) ボリュームにレプリケートされるスナップショットでも、同じ操作を実行できます。 リージョン間レプリケーションがアクティブまたは進行中であっても、すべてのスナップショットを新しいボリュームに復元できます。 この機能により、レプリケートされたボリュームが DR 目的でのみ使用される一方で、DR リージョンでテストおよび開発環境を中断なしで作成でき、データを使用できるようになります。 このユース ケースでは、テストおよび開発環境を運用環境から分離でき、それにより運用環境への潜在的な影響を排除できます。

次の図は、リージョン間レプリケーションが行われているときの、DR ターゲット ボリューム スナップショットを使用したボリュームの復元 (複製) を示しています。

DR ターゲット ボリューム スナップショットを使用したボリュームの復元を示す図

ボリュームの復元操作については、「スナップショットから新しいボリュームを復元する」を参照してください。

オンライン スナップショットをインプレース復元する (元に戻す)

場合によっては、新しいボリュームがストレージ容量を消費するため、スナップショットから新しいボリュームを作成することが不要な場合や適切でない場合があります。 データの破損 (たとえば、データベースの破損やランサムウェアの攻撃) から迅速に回復するために、ボリューム自体にスナップショットを復元する方が適切な場合があります。 この操作は、Azure NetApp Files スナップショットを元に戻す機能を使用して実行できます。 この機能を使用すると、特定のスナップショットが作成されたときの状態にボリュームをすばやく戻すことができます。 ほとんどの場合、ボリュームを元に戻す方が、個々のファイルをスナップショットからアクティブなファイル システムに復元するよりもはるかに高速です (特に大規模なマルチ TiB ボリュームの場合)。

ボリューム スナップショットを元に戻す操作はほぼ瞬時で、最大のボリュームであっても、完了するまでに数秒しかかかりません。 アクティブなボリューム メタデータ ("inode テーブル") は、スナップショットの作成時からスナップショット メタデータに置き換えられるため、その特定時点にボリュームがロールバックされます。 元に戻す操作を有効にするために、データ ブロックをコピーする必要はありません。 そのため、新しいボリュームにスナップショットを復元する場合よりも、領域効率が高くなり、高速になります。

次の図は、以前のスナップショットに戻されるボリュームを示しています。

以前のスナップショットに戻されるボリュームを示す図

重要

選択したスナップショットよりも後に書き込まれたアクティブなファイル システム データと、作成されたスナップショットは失われます。 スナップショットの復元操作によって、ターゲット ボリューム内のすべてのデータが、選択したスナップショットのデータに置き換えられます。 スナップショットを選択するときは、スナップショットの内容と作成日に注意する必要があります。 スナップショットの復元操作を元に戻すことはできません。

この機能の使用方法については、「スナップショットの復元を使用してボリュームを元に戻す」を参照してください。

保管されたスナップショットからのボリューム バックアップの復元

ボリューム レベルまたは NetApp アカウント レベルで、バックアップを検索することができます。 スナップショットに使用される名前は、スナップショットのバックアップ時に保持され、プレフィックス "daily"、"weekly"、または "monthly" が含まれます。 また、スナップショットの作成時刻と日付のタイムスタンプも含まれます。 バックアップ機能が有効になっているときに作成される最初のスナップショットは、ベースライン スナップショットと呼ばれます。 ベースライン スナップショットには、保護されたボリュームとスナップショットのすべてのデータが含まれます。 連続する保管済みスナップショットはブロック増分更新ですが、スナップショットは常に、保管済みスナップショットが作成された時点のボリュームの完全な表現であり、増分更新でベースラインをスタック ''しなくても'' 直接復元できます。

次の図は、選択した保管済みスナップショットを新しいボリュームに復元する操作を示しています。

選択した保管済みスナップショットの新しいボリュームへの復元を示す図

保管済みスナップショットからの個々のファイルまたはディレクトリの復元

個々のファイルまたはディレクトリを復元するために、完全な保管済みスナップショットが新しいボリュームに復元されてから、ボリュームをマウントして、復元するファイルまたはディレクトリを参照できます。 復元は、必要なファイルまたはディレクトリを新しく復元されたボリュームから目的の場所にコピーすることで行われます。 復元が完了したときに、復元されたボリュームが削除される可能性があります。

ボリュームが削除された場合、ボリュームの一部であり、ボリュームの削除時に削除されるオンライン スナップショットとは異なり、保管済みスナップショット (バックアップ) は引き続き保持されます。 アプリケーションまたはユーザーのエラーが原因で親ボリュームが削除または失われた場合でも、保管済みバックアップから完全なボリュームを復元してから、個々のディレクトリを復元できます。 バックアップ リストから適切な保管済みスナップショットを選択し、それを新しいボリュームに復元することでこれを行うことができます。 詳細については、「バックアップを新しいボリュームに復元する」を参照してください。

スナップショットの削除方法

このセクションでは、オンライン スナップショットと保管済みスナップショットの削除方法について説明します。

オンライン スナップショットの削除

スナップショットではストレージ容量が消費されます。 そのため、通常は無期限に保持されることはありません。 データの保護、保持、回復性のために、通常、多くのスナップショット (さまざまな時点で作成されたもの) が、RPO、RTO、保持の SLA の要件に応じて、一定期間オンラインで保持されます。 ただし、古いスナップショットは、多くの場合、ストレージ サービスで保持する必要がなく、スペースを解放するために削除する必要がある場合があります。 管理者は、いつでもすべてのスナップショットを削除できます (作成順である必要はありません)。

重要

スナップショットの削除操作を元に戻すことはできません。 データの保護と保有の目的で、ボリュームのオフライン コピー (保管済みスナップショット) を保持する必要があります。

スナップショットを削除すると、そのスナップショットから既存のデータ ブロックへのすべてのポインターが削除されます。 データ ブロックに、(アクティブなボリューム、またはボリューム内の他のスナップショットによって) それを指すポインターがなくなった場合にのみ、将来の使用のために、そのデータ ブロックはボリュームの空き領域に戻されます。 そのため、スナップショットを削除すると、通常、アクティブなボリュームからデータを削除するよりも、ボリュームの容量がより多く解放されます。これは、通常、データ ブロックが以前作成されたスナップショットでキャプチャされているためです。

次の図は、ボリュームからスナップショット 3 を削除した場合のストレージ消費への影響を示しています。

スナップショットを削除した場合のストレージ消費への影響を示す図

必ずボリュームとスナップショットの消費量を監視して、アプリケーション、アクティブなボリューム、スナップショットの消費量がどのように関係しているか理解してください。

スナップショットの削除を管理する方法については、「スナップショットの削除」を参照してください。 このプロセスを自動化する方法については、「スナップショット ポリシーを管理する」を参照してください。

保管済みスナップショットの削除

ボリュームのバックアップを無効にすると、そのボリュームの Azure ストレージに格納されている保管済みスナップショット (バックアップ) はすべて削除されます。

ボリュームが削除されても、ボリュームの削除前にバックアップ ポリシーが無効になっていなかった場合は、そのボリュームに関するすべてのバックアップは Azure ストレージに保持され、関連付けられている NetApp アカウントの下に一覧表示されます。

詳細については、Azure NetApp Files ボリュームのバックアップ機能の無効化に関するページを参照してください。

保管済みスナップショットの履歴は、適用されるスナップショット ポリシーによって自動的に管理されます。このポリシーでは、保管済みスナップショット (バックアップ) スケジューラによって新しいスナップショットが追加されると最も古いものが削除されます。 保管済みスナップショットを手動で削除することもできます。

次のステップ