ロールバック機能を備えた冗長ストレージシステムがある場合、バックアップは必要ですか？

私の組織は最近ストレージシステムを購入しました。RAID6を備えた1.5ペタバイトで、物理的に異なる場所にオンライン同期ミラーがあります。

システムは、デフォルトで最大30日間を許可するロールバック/ファイルリカバリを許可しますが、これは増やすことができます。

ストレージ上にのみ存在するデータに追加のバックアップが必要な場合は、議論が続いています。

システムには非常に優れたレベルの冗長性があり、地理的冗長性があり、ある程度のロールバックが可能です。つまり、定義された時間（デフォルトでは30日間）の古いデータまたは誤って削除されたデータを回復できます。

このシナリオを考えると、「従来の」バックアップをとることはまだ意味がありますか？伝統的に、私は専用のバックアップシステムを意味し、何かがうまくいかない場合に取得できるスナップショットを備えています。

本当に必要ですか？何か不足していますか？私はただ伝統的な方法で考えて、熱心すぎていますか？

あなたが説明することは地理的に分散したRAIDに不可欠であり、RAID は決してバックアップではありませんでした。

通常、オンライン同期とは、攻撃者による（すべての）スナップショットやボリュームの削除、または単に管理者エラーなどの操作を含め、プライマリストレージで行うすべての操作がバックアップシステムに直ちに複製されることを意味します。

30日間のロールバックは優れた機能ですが、「critical-important-file-xyz」が破損/破損し、31日以上後まで検出されなかった場合はどうなりますか？この状況は、バックアップとアーカイブのスケジュールの違いですが、説明では後者については言及していません。アーカイブシステムは通常、非常に低コストのテープに保存されます。また、ビジネスが30日以上データを保持するための規制またはその他の要件を持っているビジネスであるかどうかに関する情報は入手できません。

これがあなたの状況に当てはまらない場合、あなたは良いはずです。

両方のデータを持つ地理的に離れたマシンを持つことは良いことです。

両方またはすべてのサイトに関連する複数の障害がある場合はどうなりますか？一方の火災、他方のサーバーの盗難？または、それらの間の回線に問題があり、プライマリロケーションのサーバーが停止し、HDコントローラーがサルになり、ジャンクを書き込みますか？または、一部のインサイダーは両方で悪意のある行為を実行しますか？または、FBIが疑われるために両方の場所であなたのサーバーを没収します（あなたは決してそうしませんが、多分あなたはschmucksとデータセンターで共同ホストされています）。または..いくつかの重要な「クラウド」機能停止を思い出しました。すべてが冗長であり、n次の程度まで分析されましたが、それでも問題が発生する可能性があります。これらがすべてありそうもないことを認めますが、ありそうもないことが起こりうることを認めました。

それで、それはそのデータがどれほど重要/貴重であるかということです。組織がなくなった場合、組織は何をしますか？

ここでの質問は、データの複製されたコピーがバックアップであり、高可用性/冗長性インフラストラクチャではない前に、データの複製されたコピーがどの程度切断され、地理的に区別される必要があるかについてのようです。私の直感は、あなたは近くにいるが、それでもバックアップが必要だということです。

他の回答やコメントでいくつかの考えをまとめる（チェリーピック）ために、「まあ、XテクノロジーはY災害シナリオをカバーしていないので、バックアップではありません」という道をたどることができます。あなたにとって何が合理的かを決める必要があり、それがあなたが尋ねている理由のようです。これに対する私の気持ち、そして多くのコメント者の気持ちは、障害、事故、悪意のある行為が広がらないか、または持ちこたえられないように、バックアップが使用中のデータとは別の技術インフラストラクチャに存在する必要があるということですはるかに高いハードルを越えます。コメントで示されている例は、ボリュームを削除する誰かです。これは、私の意見では、空のパイではなく、有効なシナリオです。しかし、さらに、私の作品からの実世界の例。私が働いている大学（ただし、ありがたいことに このインフラストラクチャを管理するには、多くのキャンパス施設をサポートする高可用性仮想化インフラストラクチャが必要です。複数のサイトにありますが、すべて1つのベンダーのプラットフォームで実行されています。ある日、あいまいなバグが発生し、最初に1台のサーバーがダウンした障害カスケードが発生しました。次に、負荷がシフトすると、そのサイトの残りの部分が削除され、負荷が再びシフトすると、他のサイトがホストされましたそのインフラ。（それ以来、彼らはこの問題を解決したと思います）。この場合、データは失われませんでしたが、データが含まれるシナリオを想像することは可能です。ある日、あいまいなバグが発生し、最初に1台のサーバーがダウンした障害カスケードが発生しました。次に、負荷がシフトすると、そのサイトの残りの部分が削除され、負荷が再びシフトすると、他のサイトがホストされましたそのインフラ。（それ以来、彼らはこの問題を解決したと思います）。この場合、データは失われませんでしたが、データがどこにあるかを示すシナリオを想像することは可能です。ある日、あいまいなバグが発生し、最初に1台のサーバーがダウンした障害カスケードが発生しました。次に、負荷がシフトすると、そのサイトの残りの部分が削除され、負荷が再びシフトすると、他のサイトがホストされましたそのインフラ。（それ以来、彼らはこの問題を解決したと思います）。この場合、データは失われませんでしたが、データがどこにあるかを示すシナリオを想像することは可能です。

バックアップはそのすべてに影響されず、インフラストラクチャがダウンしている間でもアクセスできるようにする必要があります。RAIDの再構築中に1週間データが利用できない場合、バックアップからビジネスクリティカルなドキュメントを回復できると便利です（必須ではありません）。RAIDが消えてから他のサイトに複製する場合は、そのバックアップを別のベンダーから、またはテープなどの分離されたメディア上に作成する必要があります。

以上のことをすべて繰り返しますが、バックアップはデータとは別のインフラストラクチャ上にある必要があることを繰り返します。ここにはさまざまなレベルの分離がありますが、直接レプリケーションで接続されたものはすべて、バックアップには近すぎると思います。さらに何かが必要になります。

仮定：ストレージシステムは多くのアプリケーションで使用されます。

別のバックアップシステムを使用すると、はるかに優れた結果が得られると思います。

RAIDとミラーリングはバックアップではありませんが、組み込みのロールバック機能により、従来のバックアップシステムを置き換えることができます。

しかし：

次の理由から、ストレージベースではなくアプリケーション/データベースのリカバリポリシーを好む：

1. アプリケーションには、リカバリと許容されるデータの損失に関連するさまざまな要件があります（それらの一部は、読み取り専用メディア、暗号化、過去X年間の保持など、さまざまな規制によって課されます）。
2. 一部のアプリケーションには（非常に）優れたバックアップおよびリカバリツール（oracle、mssql）が組み込まれており、バックアップ/リカバリ部分を実行する推奨方法です（Oracle DBAとして、rmanを使用してOracleに関連するすべてのバックアップを実行します）。
3. 成長、スペースの使用量は予想よりもはるかに速く成長する可能性があります。現在、このシステムは30日間のロールバックデータに対応できますが、今後は保証されません
4. 安価で、数年の成長の後、バックアップ/リカバリポリシーに対応するために大きなテープを使用するコストは、現在と同じロールバックウィンドウを尊重するために、新しい大きなディスクを購入するコストよりも小さくなります。