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スナップショットに依存している場合は、十分なコンテキスト情報を含めて、どのようなリカバリポリシーを満たす必要があるかを人々が理解できるようにしてください。