NetAppスナップショットをバックアップとして使用できますか？
当店では、バックアップをNetAppボリュームスナップショットに大きく依存しています。データのsomeには従来のエージェントベースのテープバックアップを使用しますが、大部分のシステムではスナップショットに依存しています。さらに、厳密な変更管理ポリシーや一元化された構成管理がないため、サービスが提供するデータがバックアップされているかどうかに関係なく、サーバーのall 、ベアメタルから再構築する必要があります（実際のドキュメントはありません）。当然ながら、ユーザーデータと構成を含めてサーバー全体を回復できるため、スナップショットは管理にとって非常に魅力的な提案になります。 NFSベースのVMwareデータストアのスナップショットを作成するためにNetAppの仮想ストレージコンソールを使用し、ゲストに直接提示されるrawデバイスマップ（物理）LUN用にNetAppのSnapDriveを使用します。重要なスナップショットを別のファイラーにオフサイトでSnapMirrorします。当然、定期的に復元プロセスをテストしています。
バックアップのスナップショットに依存していることに不快に感じざるを得ません。私にとって、テクノロジーがバックアップ戦略として十分であると考えるためには、次の基準を満たす必要があります。
- バックアップはアトミックである必要があります。つまり、バックアップは、リカバリのために他のものに依存することはできません。
- バックアップは、それが（帯域外）であるシステムから分離する必要があります。
- バックアップをリモートサイト（オフサイト）にコピーまたは転送する必要があります
ネットアップスナップショットがリダイレクトオンライト（RoW）の方法で機能することは私の理解です。 [〜＃〜] wafl [〜＃〜] ファイルレイアウトは、実際にストレージの各ブロックを参照する一連のポインター（メタデータ？）を使用します。スナップショットを作成するために、システムはボリュームのメタデータのコピーを取得し、それをそのボリュームの予約済みスペースに格納します。書き込み（作成/変更/削除）はすべて新しいブロックにリダイレクトされます。これは、NetAppのWAFLを非常に優れたものにする特別なソースであると考えられます。読み取りを行ってから古いデータを予約済みスペースに書き込んでから、新しいデータをコピーオンライトなどの古いスナップショットに上書きするからです。
ネットアップボリュームスナップショットの仕組みを正確に理解していない可能性がありますが、理解が多かれ少なかれ正しい場合、ネットアップスナップショットはバックアップの基準を満たしていません。
- それらはではないアトミックです。 「スナップショット」は、実際には元のデータへのポインタのセットにすぎません。元のデータがなくなった場合、メタデータは役に立ちません。
- スナップショットはシステムから分離されていません。誰かが間違ったボリュームを削除すると、スナップショットが失われます。 NetApp Filerが小さな子猫に爆発した場合、バックアップを失います。 SnapMirrorを使用してスナップショットを別のファイラーに移動できますが、これもメタデータを実際のブロックではなく移動するだけです。元のボリュームを紛失した場合、別のファイラーにコピーされたスナップショットがどのように役立つかわかりません。
ネットアップスナップショットをバックアップと見なす方法を誰かが説明できますか？私は 良い主観的 答えを探しているので、事実、参照、経験であなたの立場をサポートしてください。基盤となるテクノロジーについての私の理解が正しくない場合は、それが私の結論をどこで、なぜ変えたのか説明してください。ショップがバックアップとしてNetAppスナップショットに依存している場合、人々がどのようなリカバリポリシーを満たす必要があるかを理解できるように、十分なコンテキスト情報を含めてください。
バックアップには2つの機能があります。
- 何よりもまず、データが利用できなくなった場合にデータを回復できるようにします。この意味で、スナップショットはバックアップではありません。ファイラー上のデータ（ボリュームの削除、ストレージの破損、ファームウェアエラーなど）を失うと、そのデータのすべてのスナップショットも失われます。
- 次に、はるかに一般的に、バックアップは、誤って削除するなどの日常的な作業を修正するために使用されます。この使用例では、スナップショットはバックアップです。彼らは間違いなく、この種の回復を提供するための最良の方法の1つです。これは、以前のバージョンのデータを、ユーザーがファイルを直接読み取ることができる.snapshot非表示ディレクトリとしてユーザーまたはOSに直接利用できるようにするためです。
保存ポリシーなし
とはいえ、スナップショットがあり、それらを幅広く使用している場合でも、テープまたはデータドメインへのNetbackupで毎晩増分を行います。その理由は、スナップショットは保持ポリシーを確実に維持できないためです。 1週間は毎日の細分性、次に1か月は毎週の細分性からバックアップできるとユーザーに伝えた場合、スナップショットではその約束を守ることができません。
スナップショットのあるNetappボリュームでは、スナップショットに含まれる削除されたデータが「スナップリザーブ」スペースを占有します。ボリュームがいっぱいではなく、このように構成した場合は、そのスナップショット予約をプッシュして、未使用のデータ領域の一部を占有するスナップショットを持つこともできます。ただし、ボリュームがいっぱいになると、予約済みスペースのデータでサポートされているものを除くすべてのスナップショットが削除されます。スナップショットの削除は、利用可能なスナップショットスペースによってonlyが決定され、保持ポリシーに必要なスナップショットを削除する必要がある場合は、削除されます。
この状況を考えてみましょう：
- 定期的なスナップショットと2週間の保持要件を持つフルボリューム。
- 通常の変更率に基づいて、スナップショットに使用中の予約の半分を想定します。
- 誰かが大量のデータ（スナップショットの予約を超える）を削除し、一時的に変更率を大幅に増加させます。
この時点で、スナップショットリザーブは完全に使用されています。また、OnTapがスナップショットに使用することを許可したデータの空き容量と同じですが、スナップショットはまだ失われていません。ただし、誰かがボリュームでデータをバックアップするとすぐに、データセクションに含まれているすべてのスナップショットが失われ、大規模な削除直後の時点に復旧ポイントがプッシュされます。
概要
Netappスナップショットは、実際のデータ損失をカバーしません。ファイラーで誤って削除されたボリュームまたはデータの損失があると、データを再構築する必要があります。
これらは単純なルーチンリストアを可能にする非常にシンプルでエレガントな方法ですが、実際のバックアップソリューションを置き換えるほど信頼性は高くありません。ほとんどの場合、それらは日常的な復元を簡単で苦痛のないものにしますが、それらが利用できない場合は公開されます。
それらはaバックアップです、はい。私は以前、毎日インクリメンタルの代わりにそれらを使用しましたが、それでもテープに毎週フルを行いました。
それらは、非netapp（ボリュームにアクセスするシステム）のユーザーまたは管理者のエラーまたは問題から十分に保護します。
Netapp自体の壊滅的なハードウェア障害からは保護されません。私の理解では、SnapMirrorはすべてのデータ（スナップショット内）を他のファイラーにコピーします[1]。したがって、別のファイラーへのSnapMirrorは、そのデータセットを単一のファイラーの致命的な障害から保護する必要があります。
もちろん、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を使用して、ストレージシステム、高速ストレージの一時データベース、低速ストレージのシステムデータベース、大容量ストレージの読み取り専用データまたはアーカイブデータ、およびその間の作業データをよりよく利用することを好みます。これらのボリュームのスナップショットを作成しているだけの場合は、非常にデータベースを回復することはできません。
ネットアップは、スナップショットアプリケーションを認識させるための多数のスナップツールを提供しています。 SnapManager for SQLはその認識を提供します。 Microsoftエコシステムには、ExchangeおよびSharePoint用のSnapManagerツールもあると思います。 SnapDriveはこのアプリケーションを認識しません。ゲスト内のストレージを管理する便利な方法を提供するだけです。
すべてのIISデータと構成をLUNに保存し、それらのLUNに直接スナップショットを作成している場合、データが回復可能であることを保証することはできません。
複数のストレージタイプに異なるスナップショットスケジュールを設定できます
さまざまな方法でサーバーにストレージを提供している場合、スナップショットとリカバリの状況が複雑になる可能性があります。 NetAppのONTAPはマルチプロトコル製品であり、特定のサーバーに対して複数のメソッドまたはストレージタイプを使用している可能性があります。当店では、一部のサーバーがNFSベースのデータストア経由でC：\ドライブを取得し、Raw Device Mapped LUN経由で「ストレージ」ドライブを取得しています。 RDM LUNのスナップショットを撮っていましたが、NFSベースのデータストアは撮っていませんでした。これにより、サーバーの復旧が困難になりました。
スナップショットには保証された保持ポリシーがありません
繰り返しますが、 @ Basil は実際にこれをカバーしていますが、繰り返す価値があります。スナップリザーブは、Snpashot Autodeleteが自然に削除されていないスナップショットを削除するような方法で埋めることができます。再び。これは、あなたまたはあなたの顧客が3週間のスナップショットが利用可能になることを期待している場合は、本当に悪い場合があります。
スナップショットはインラインです
これは統合ストレージの欠点です...よく統合されています。スナップショットは、バックアップしているのと同じプラットフォームにあります。ボリュームまたはファイラーがオンの場合、バックアップも消えます。 SnapMirrorコピーはフルコピーではないという私の質問で誤って述べたように、SnapMirrorを使用してスナップショットを別のファイラーにコピーすることで、これをある程度軽減できます。
スナップショットにより、不適切な運用を継続できます
私が気づいたことの1つは、スナップショットを使用すると、マネージャーと顧客はひどい運用行動を継続できることです。私たちの環境では、ドキュメントと構成管理の方法が非常に貧弱です。つまり、ほとんどのサーバーは同じベース（テンプレートまたはイメージ）で起動しますが、その後、さまざまなグループの人々が手動で構成します。それらがその寿命を続けるにつれて、サーバーは、一般に文書化されていない、または構成管理で実装されていない方法で、テンプレートからますます離れています。
そして、スナップショットが来ます！すべてのサーバーのスナップショットを作成できるので、基本的な運用方法の一部に戻って対処する必要はありません。そして、SnapMirrorを使用してこれらのスナップショットをオフサイトに移動し、バックアップとして使用できます。
これはここで学ぶには間違った教訓だと思います。学ぶべきより良い教訓は、構成管理フレームワークは、変更ログのように単純であっても、ベアメタル復元の目的でバックアップする必要があるということです。スナップショットは素晴らしいツールですが、重要なファンダメンタルズを阻止するためにスナップショットに過度に依存したくなる誘惑があるかもしれません。