NetAppスナップショットをバックアップとして使用できますか？

私たちの店は、バックアップのためにNetApp Volume Snapshotsに大きく依存しています。一部のデータには従来のエージェントベースのテープバックアップを使用しますが、大部分のシステムではスナップショットを使用しています。さらに、厳格な変更管理ポリシーや一元化された構成管理がないため、すべてサーバーが提供するデータがバックアップされているかどうかに関係なく、サーバーの一部は、ベアメタルから再構築する必要があります（実際のドキュメントはありません）。当然、これにより、スナップショットは、サーバー全体、ユーザーデータおよび含まれる構成のみを回復できるため、管理にとって非常に魅力的な提案となります。NetAppの仮想ストレージコンソールを使用して、NFSベースのVMwareデータストアのスナップショットを作成し、NetAppのゲストに直接提示されるrawデバイスマップ（物理）LUNのSnapDriveを作成します。重要なスナップショットを別のファイラーにオフサイトでSnapMirrorします。当然、定期的に復元プロセスをテストします。

バックアップのスナップショットに依存していることに不快感を覚えずにはいられません。私にとって、バックアップ戦略として十分であると考えられる技術では、次の基準を満たす必要があります。

• バックアップはアトミックである必要があります。つまり、バックアップはその回復のために他の何かに依存することはできません。
• バックアップは、システムのバックアップ（帯域外）から分離する必要があります。
• バックアップをコピーまたはリモートサイト（オフサイト）に転送する必要があります

NetAppスナップショットはRedirect-On-Write（RoW）方法論の下で機能することを理解しています。WAFLのファイルのレイアウトは、実際にそれがあるかもしれない、これまでのストレージの各ブロックを参照するポインタのセット（メタデータを？）を使用します。スナップショットを作成するために、システムはボリュームのメタデータのコピーを取得して、そのボリュームの予約スペースに保存します。書き込み（作成/変更/削除）はすべて新しいブロックにリダイレクトされます。これは、NetAppのWAFLを非常に優れたものにする特別なソースであると想定されています。これは、古いデータを予約スペースに読み取ってから書き込み、その後コピーオンライトなどの古いスナップショットに新しいデータを書き込む必要がないためです。

NetAppボリュームスナップショットがどのように機能するかを正確に理解していないかもしれませんが、理解が多かれ少なかれ正しい場合、NetAppスナップショットはバックアップの基準を満たしていません。

• それらはアトミックではありません。「スナップショット」は、実際には元のデータへのポインターのセットにすぎません。元のデータがもう存在しない場合、メタデータは役に立ちません。
• スナップショットはシステムから分離されていません。誰かが間違ったボリュームを削除すると、スナップショットが失われます。NetApp Filerが小さな子猫に爆発すると、バックアップが失われます。SnapMirrorを使用してスナップショットを別のFilerに移動できますが、これも実際のブロックではなくメタデータを移動するだけです。元のボリュームを失うと、別のファイラーにコピーされたスナップショットがどのように役立つかわかりません。

誰かがNetAppスナップショットをバックアップとみなす方法を説明できますか？良い主観的な答えを探しているので、事実、参考文献、経験であなたの立場をサポートしてください。基礎となるテクノロジーに対する私の理解が正しくない場合、結論が変わる場所と理由を説明してください。ショップがバックアップとしてNetAppスナップショットに依存している場合は、十分なコンテキスト情報を含めて、どのようなリカバリポリシーを満たす必要があるかを人々が理解できるようにしてください。

バックアップには2つの機能があります。

• 何よりもまず、データが利用できなくなった場合にデータを回復できるようにします。この意味で、スナップショットはバックアップではありません。ファイラーでデータを失うと（ボリュームの削除、ストレージの破損、ファームウェアエラーなど）、そのデータのすべてのスナップショットも失われます。
• 第二に、そしてはるかに一般的に、偶発的な削除のような日常的なものを修正するためにバックアップが使用されます。このユースケースでは、スナップショットはバックアップです。これらは、この種のリカバリを提供する最良の方法の1つであると考えられます。これは、ファイルを直接読み取ることができる.snapshot隠しディレクトリとして、以前のバージョンのデータをユーザーまたはOSで直接利用できるようにするためです。

保持ポリシーなし

つまり、スナップショットがあり、それらを広範囲に使用していますが、Netbackupでテープまたはデータドメインへの夜間増分を引き続き行っています。その理由は、スナップショットが保持ポリシーを確実に維持できないためです。1週間の1日単位から1か月の1週間単位でバックアップできることをユーザーに伝えると、スナップショットではその約束を守ることができません。

スナップショットがあるNetappボリュームでは、スナップショットに含まれる削除されたデータが「スナップリザーブ」スペースを占有します。ボリュームがいっぱいではなく、この方法で構成した場合は、そのスナップショットの予約を超えてプッシュし、未使用のデータ領域の一部を占有するスナップショットを作成することもできます。ただし、ボリュームがいっぱいになると、予約スペースのデータでサポートされているスナップショットを除くすべてのスナップショットが削除されます。スナップショットの削除は、使用可能なスナップショットスペースによってのみ決定され、保持ポリシーに必要なスナップショットを削除する必要がある場合は、削除されます。

この状況を考慮してください：

• 定期的なスナップショットと2週間の保持要件を備えたフルボリューム。
• 通常の変化率に基づいて、スナップショットに使用中の予約の半分を想定します。
• 誰かが大量のデータ（スナップショットの予約より多く）を削除し、変更率を一時的に大幅に増加させます。

この時点で、スナップショットの予約は完全に使用され、OnTapがスナップショットに使用できるデータの空き容量と同様に、スナップショットはまだ失われていません。ただし、誰かがボリュームをデータで満たすとすぐに、データセクションに含まれるすべてのスナップショットが失われます。これにより、大規模な削除の直後にリカバリポイントが戻されます。

概要

Netappスナップショットでは、実際のデータ損失を防ぐことはできません。誤った削除されたボリュームまたはファイラーのデータ損失により、データを再構築する必要があります。

これらは、単純な定期的な復元を可能にする非常にシンプルでエレガントな方法ですが、実際のバックアップソリューションを置き換えるほど信頼性がありません。ほとんどの場合、彼らは定期的な復元を簡単で痛みのないものにしますが、それらが利用できない場合、あなたは暴露されます。

彼らは、はい、バックアップ。私は以前は毎日の増分の代わりにそれらを個人的に使用しましたが、私たちはまだテープに毎週フルを行いました。

これらは、netapp以外（ボリュームにアクセスするシステム）のユーザーまたは管理者のエラーや問題から非常によく保護します。

netapp自体の壊滅的なハードウェア障害から保護しません。私の理解では、SnapMirrorはすべてのデータ（スナップショット内）を他のファイラーにコピーします[1]。

もちろん、1つの大きな問題は、netappを管理している誰かがボリュームを削除した場合、すべてのスナップショットがそれに伴うことです。別のファイラーへのSnapMirrorは、それに対して適切に保護する必要があります。

すべてのNetAppファイラーが同じデータセンターにある場合、大規模な災害をカバーするものは何もありません。テープバックアップがオフサイトで出荷されるので、それが得られます。

適切なSnapManagerエージェントを使用すると、VMやデータベース（またはデータベースに似たもの）のバックアップが向上し、スナップショットの取得時にデータの静止が短時間調整されます。特定のVMとそのデータが完全に単一のNetAppボリュームに含まれている場合、そのVMのスナップショットはクラッシュコンシステントになるはずです。つまり、サーバーのプラグを抜いてドライブをイメージ化するのと同じくらい良いはずです。これは通常、ファイルシステムのチェックとデータベースの同等物を意味します。データベースのデータがLUN間で分割されている場合、データ破損の重大なリスクがあるようです。

私なら、ローカルディスクへの定期的なバックアップを行うようにすべてのデータベースを設定し、それらのジョブを1つまたは2つのコピーを保持するように設定します。これにより、回復性がはるかに向上します。

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

すぐに@Basilの優れた答えを読む必要がありますが、ここに私の2セントがあります。

スナップショットはアプリケーションに対応していません

基礎となるストレージボリュームのスナップショットを取得したからといって、そのボリューム上のデータが回復可能であるとは限りません。MS SQLはその良い例です。使用しているストレージのスナップショットを作成する前に、データベースのトランザクション整合性を確認する必要があります。@ freiheitが述べたように、ハードダウンの障害から回復するよりもましです。DBAは、SQLのさまざまな部分にさまざまなLUNを使用して、ストレージシステム、高速ストレージの一時データベース、低速ストレージのシステムデータベース、バルクストレージの読み取り専用またはアーカイブデータ、およびその間の作業データをより活用することを好みます。それらのボリュームのスナップショットを作成するだけの場合、データベースを回復できる可能性は非常に低いです。

NetAppは、スナップショットアプリケーションを認識するための多数のスナップツールを提供しています。SnapManager for SQLはその認識を提供します。Microsoftエコシステムには、ExchangeおよびSharePoint用のSnapManagerツールもあると思います。SnapDriveには、このアプリケーション認識機能はありません。ゲスト内のストレージを管理する便利な方法を提供するだけです。

すべてのIISデータと構成をLUNに保存し、それらのLUNのスナップショットを直接作成する場合、データが回復可能であることを保証できません。私の知っていることを聞いてください...

複数のストレージタイプに異なるスナップショットスケジュールを設定できます

サーバーにさまざまな方法でストレージを提供している場合、これによりスナップショットとリカバリの状況が複雑になる可能性があります。NetAppのONTAPはマルチプロトコル製品であり、特定のサーバーに対して複数の方法またはストレージタイプを使用している可能性が非常に高いです。私たちのショップでは、サーバーのいくつかはNFSベースのデータストアを介してC：\ドライブを取得し、RawデバイスマッピングされたLUNを介して「ストレージ」ドライブを取得します。RDM LUNのスナップショットを作成していましたが、NFSベースのデータストアは作成していませんでした。これにより、サーバーの復旧が困難になりました。

スナップショットには保持ポリシーが保証されていません

繰り返しになりますが、@ Basilはこれを本当にうまくカバーしていますが、繰り返す価値はあります。Snpashot Autodeleteが自然に削除されていないスナップショットを削除するような方法で、スナップリザーブをいっぱいにすることができます。再び。あなたまたはあなたの顧客が3週間のスナップショットが利用できることを期待している場合、これは本当に悪いことです。

スナップショットはインラインです

これは統合ストレージの欠点です...それは...統合されています。スナップショットは、バックアップしているのと同じプラットフォームにあります。ボリュームまたはそれがオンになっているファイラーが消えると、バックアップも消えます。SnapMirrorコピーは完全なコピーではないという質問で誤って述べたように、SnapMirrorを使用して別のFilerにスナップショットをコピーすることにより、これを多少軽減できます。

スナップショットにより、不正な運用慣行を継続できます

私が気づいたことの1つは、スナップショットを使用すると、マネージャーと顧客がひどい運用動作を継続できることです。私たちの環境では、ドキュメントと構成管理のプラクティスが非常に貧弱です。つまり、ほとんどのサーバーは同じベース（テンプレートまたはイメージ）で開始されますが、その後、異なる人々のグループによって手動で構成されます。サーバーが存続するにつれて、サーバーは、一般に構成管理で文書化または実装されない方法で、テンプレートからますます分岐します。

そしてスナップショットが来ます！すべてのサーバーのスナップショットをとることができるため、基本的な運用慣行の一部に取り組む必要はありません！また、SnapMirrorを使用してこれらのスナップショットをオフサイトに移動し、バックアップとして使用できます！

これはここで学ぶべき間違った教訓だと思います。学ぶべきより良い教訓は、構成管理フレームワークは、たとえ変更ログのように単純であっても、ベアメタル復元の目的でバックアップする必要があるということです。スナップショットは素晴らしいツールですが、重要なファンダメンタルズを抑止するためにスナップショットに過度に依存したくなる誘惑があります。