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

[アーティクル]
11/08/2024

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

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

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

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

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

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

ファイルは、ボリュームに書き込まれたメタデータとデータブロックで構成されます。この図には 3 つのファイルがあり、それぞれファイル 1、ファイル 2、ファイル 3の 3 つのブロックで構成されています。
スナップショット Snapshot1 が作成され、メタデータと、ファイルを表すブロックへのポインターのみがコピーされます。
ボリューム上のファイルは引き続き変更され、新しいファイルが追加されます。変更されたデータブロックは、ボリューム上に新しいデータブロックとして書き込まれます。以前に Snapshot1 でキャプチャされたブロックは変更されません。
次のように、変更と追加をキャプチャするための新しいスナップショット Snapshot2 が作成されます。

スナップショットが作成されると、データブロックへのポインターがコピーされ、変更が新しいデータの場所に書き込まれます。スナップショットポインターは、スナップショットが作成されたときにファイルが占有していた元のデータブロックを引き続き指し、データのライブビューと履歴ビューの両方を提供します。仮に新しいスナップショットを作成する場合、現在のポインタ（直近の追加・変更後に作成されたもの）は新しいスナップショットSnapshot2にコピーされます。これで、3 つの完全なコピーに必要なボリューム領域を占有することなく、3 世代のデータ (ライブデータ、Snapshot2、および Snapshot1 (経過時間順)) にアクセスできます。

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

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

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

手動 (オンデマンド)。次のものを使用:
- Azure portal、REST API、Azure CLI、または PowerShell ツール
- スクリプト (例を参照)
自動。次のものを使用:
- Azure portal、REST API、Azure CLI、または PowerShell ツールによるスナップショットポリシー
- AzAcSnap またはサードパーティソリューションなどのアプリケーション整合性スナップショットツール

ディザスターリカバリーと事業継続のために、ボリュームとスナップショットがレプリケートされるしくみ

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 ストレージにスナップショットを送信することで、データ保護期間を 1 年以上に延長するために使用されます。図に青色で示されているように、一番最初の転送がベースラインであり、ソース Azure NetApp Files ボリュームとスナップショットの消費されたデータブロックはすべてコピーされます。連続するバックアップではスナップショットメカニズムを使用して、ブロック増分更新のみでバックアップリポジトリを更新します。

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

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

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

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

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

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

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

スナップショットを新しいボリュームに復元すると、ボリュームの概要ページの "復元元" フィールドに、新しいボリュームの作成に使ったスナップショットの名前が表示されます。ボリュームの復元操作については、「スナップショットから新しいボリュームを復元する」を参照してください。

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

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

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

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

重要

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

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

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

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

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

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

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

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

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

単一ファイルスナップショットの復元を使用してオンラインスナップショットからファイルまたはディレクトリを復元する

スナップショット全体を新しいボリュームに復元することも、ネットワーク経由で大きなファイルをコピーすることもしたくない場合は、単一ファイルのスナップショット復元機能を使用して、スナップショットからボリューム内の個々のファイルを直接復元することができます。この場合、外部クライアントのデータのコピーは必要ありません。

この機能では、スナップショット全体を新しいボリュームに復元したり、ボリュームを元に戻したり、ネットワーク全体で大きなファイルをコピーしたりする必要はありません。この機能を使用すると、外部クライアントを使用したデータコピーを必要とせずに、ボリュームスナップショットからサービス上の個々のファイルを直接復元できます。この方法により、大きなファイルを復元するときの RTO とネットワークリソースの使用量が大幅に削減できます。

次の図では、単一ファイルスナップショットの復元のしくみを示しています。

1 つのファイルがインプレース (file2) またはボリューム内の新しいファイル (file2’) に復元されると、スナップショットで以前にキャプチャされた既存のブロックへのポインターのみが元に戻されます。この操作により、データブロックのコピーが不要になり、ファイルのサイズ (ファイル内のブロック数) に関係なく、ほぼ瞬時に実行されます。

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

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

Azure NetApp Files ボリュームを削除したときに、バックアップはバックアップボールトに保持されます。バックアップを保持しない場合は、最初に古いバックアップを削除してから、最新のバックアップを削除します。

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

次の方法で共有

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

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

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

ディザスターリカバリーと事業継続のために、ボリュームとスナップショットがレプリケートされるしくみ

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