スナップショットとRAIDは、オンサイトの優れたバックアップソリューションとしてカウントされますか？

バックアップを取る理由として考えられる2つの主な理由は、スナップショットとRAIDの両方をbtrfsと共に使用する場合に注意が必要と思われます。（ここでRAIDとは、RAID1または10を意味します）

• データの偶発的な削除：スナップショットはこのケースをカバーします
• ドライブの故障とビットの腐敗
  • 完全な障害：RAIDはこのケースをカバーします
  • 不良データを返すドライブ：RAID + btrfsのエラー修正機能がこのケースをカバー

オンサイトのバックアップソリューションとしては、これはうまく機能しているようで、別のデータストレージデバイスは必要ありません！

ただし、RAIDとスナップショットの両方が適切なバックアップとは見なされないと聞いているので、何か見落としているのではないかと思っています。

btrfsがまだ成熟した技術ではないことを除けば、私が見落としたことはありますか？または、私の考えは正しいですか、これは有効なオンサイトバックアップソリューションですか？

いいえ、ちがいます。

ファイルシステムまたはRAIDボリュームが破損するとどうなりますか？または、サーバーが起動しますか？または誰かが誤って間違った配列をフォーマットしますか？

あなたが持っていたと思っていたすべてのデータと非現実的なバックアップを失います。実際のバックアップは、バックアップしているデータとはまったく異なるシステム上にあるのはこのためです。なぜなら、バックアップは、データ損失の原因となる問題のシステムで発生する何かから保護するためです。バックアップしているシステムと同じシステムにバックアップを保存すると、そのシステムでのデータ損失が「バックアップ」にも影響する可能性があります。

以下のためにオンサイトのバックアップ、スナップショットがあります、良い十分なものとすることは、受動的データとして存在するあなたが定期的に「輸出」どこか他のあなたのスナップショット、。

また、「出荷されたスナップショット」を復元できるかどうかを定期的にテストします。

これは、いくつかのサーバーのクイックバックアップを実装する方法です。データをZFSに保存し、ZFSスナップショットを取得し、ファイルシステム全体が再作成される別のサーバーにデルタを送信します（実際のサービスは実行されません）。

もちろん、最適なバックアップは常にオフサイトにあります。したがって、スナップショットを別のシステムに「出荷」した後、スナップショットの「テープアウト」を定期的に実行します。

したがって、私のシステムでは、スナップショットデルタを受信するサーバーは、すべてのZFSプール（以前のスナップショットを含む）をテープに定期的にダンプします。

そしてもちろん、テープアウトをテストして、復元できることを確認します。

注：静止ディスクアクティビティ中にスナップショットを作成し、できれば一貫性を確保するためにデータベース（存在する場合）と調整してください。そうでなければ、治療法は病気よりも悪いかもしれません。そのため、NetAppとEMCの「ライブスナップショット」機能は非常に便利です。LUNを使用するデータベースがスナップショットを実行しても安全であると示されるまで、LUNのスナップショットを延期します。

HopelessN00bが言ったこと。いや

適切なバックアップは、バックアップされるデバイスとは別のデバイスにあります。2台以上のドライブを失うとどうなりますか？サーバールームが焼失するとどうなりますか？誰かが誤ってアレイを破壊するとどうなりますか？

（Anecdoteアラート：最新のFedoraを自動インストールするようにPXEを設定した人のことを聞いたことがあります。UPSに障害が発生しました。ポイント？気まぐれなことが起こる。幸いなことに、彼は適切なバックアップを持っていた。）

できれば、データのコピーが少なくとも3つあり、1つはデータセンターが焼損した場合に備えて完全にオフサイトに保存してください。

適切なバックアップでは、バックアップジョブを作成する最初の段階としてスナップショットを使用するため、適切に実装されたスナップショットをストレージでサポートする必要があります。ただし、プライマリバックアップにスナップショットを使用することはお勧めできません。理由：

1）スナップショットとバックエンドストレージは失敗する可能性があります。したがって、実際のバックアップでは個別のスピンドルセットを使用する必要があります。そうしないと、プライマリワーキングセットとバックアップデータの両方が同時に失われる可能性が高くなります。

2）スナップショットは、使用可能なスペースを「噛み砕く」。現在のホットデータに高価で高速なストレージを使用し、一部の安価で低速のストレージへのアイスコールドデータであるスナップショットとバックアップのオフロードを行うのは理にかなっています。1）BTWで非常にうまく機能します。

3）通常、スナップショットはプロセス全体の速度を低下させます。ほとんどのシステムはコピーオンライトを使用し、このアプローチは断片化を引き起こします。Redirect-on-Writeは高速ですが、多くのスペースを消費します。スナップショットを適切に実装しているベンダーはほとんどありません。NetApp with WAFLおよびNimble Storage with CASL（私はそれらのいずれとも提携していません）。ほぼ全員が問題を抱えています。たとえば、Dell Equallogicは1バイト変更ごとに15 MBのページ更新（および無駄）をトリガーします。それは高価です。

はい、そうです。バックアップを保存するのに最適な方法です。他に何も必要ありません、完全性チェックを行うことさえも無駄な時間です。

ただ確認するために-私はより多くのアドバイスを与える前に...あなたは私の競争相手のために働いていますよね？本当にそうですか？いや？ああ。

申し訳ありませんが、NUTS。いいえ、まったくありません。すまん。

問題は、（a）システムおよび（b）オペレーティングシステムレベルで発生するエラーに対して完全にオープンであることです。基本的に、誰かがデータを削除するのを防ぐだけです。いいね これはよく発生するエラーです。

保護していないのは：

• マシンを一掃する電源スパイク。そこに行って、それを見ました。
• ディスクにsh **を書き込んでいる欠陥のあるRAIDコントローラーまたはメモリー-何でもあり

そして、他のものの長いリスト。

これは、当然ですが、競合他社で働いていない限り、常にバックアップを作成してください。

• 別のコンピューターで
• 少なくとも電力スパイクから隔離すること（USVを使用している場合でも）。

これがテープが揺れる理由です-それらは接続されておらず、火災や洪水の短いものはそれらを傷つけません。電力スパイク-テープリーダーとおそらくロボットに行きますが、リーダーにないテープは影響を受けません。

BESTはオフサイトでのバックアップになります（火事や洪水のようなものについては既に言及しましたか？）そのお金を節約します）。

今、あなたは「ああ、洪水は決して起こらない」と思うかもしれません。必ず確認してください。こちらは、09.09.09のボーダフォンデータセンターの洪水のビデオです。私はあなたが問題がインサイト/コンピュータバックアップのどこにあるかを理解するだろうと確信しています：

http://www.youtube.com/watch?v=ttcQy3bCiiU

レッスンは、互いに30分以内に失敗し、2つのRAID-1ドライブから学習：RAIDはないではない任意の方法、形状又は形態で、バックアップ機構。

RAIDは、ハードウェア障害の場合にダウンタイムを短縮する可用性メカニズムですが、ウイルス、データの削除/変更、または単純な壊滅的なハードウェア障害の場合にはまったく役に立ちません。

多くの経験豊富な管理者は、バックアップの3-2-1ルールと呼ばれるものを使用します。

• プライマリソースを含め、データのコピーを少なくとも3つ保持する必要があります。つまり、単一のバックアップでは不十分であり、同じ物理システム内のコピーはカウントされません。

• 少なくとも2つの異なるバックアップ方法を使用する必要があります。

• データの少なくとも1つのオフサイトコピーが必要です。

スナップショットは3つの部分すべてに違反します。

• 単一の物理マシンのみを使用します。PSUの障害など、マシン全体に影響を与えるものはすべて、すべてのデータを取り込む可能性があります。

• バックアップには単一の方法のみを使用しています。何か問題がある場合は、危機的な状況でバックアップを復元するときにのみ見つけることができます。

• オフサイトにバックアップはありません。洪水と火災は、あなたに起こるまで他の人にのみ起こります...

したがって：

• LAN 上の別のマシンに少なくとも1つのバックアップが必要です。

• スナップショットを使用して生成されないバックアップが少なくとも1つ必要です。おそらく、古き良きインクリメンタルtarアーカイブが適切なのでしょうか？またはrsyncベースのコピー？

• 現在の場所から可能な限り離れた場所に少なくとも1つのリモートバックアップが必要であり、間違いなく同じ建物内にある必要はありません。

ブロックレベルのスナップショットには、マシンのプラグを抜いてディスクにコピーするのとほぼ同じ一貫性の保証があることも指摘しておく必要があります。一般に、fsck復元後に実行するか、ジャーナルが十分であることを期待する必要があります。

ファイルシステムレベルのスナップショットは優れているはずですが、ファイルの一貫性は保証されません。多くのアプリケーション（データベースサーバーが思い浮かぶ）では、ライブインスタンスのファイルのコピーは、一貫性のない状態になる可能性があるため、まったく役に立たないことがあります。独自のアプリケーションレベルのバックアップメカニズムを使用して、クリーンコピーの存在を確認する必要があります。これには、3-2-1ルールも適用されます。

最後に、現時点では現在のデータのコピーについてのみ話していることに注意してください。しばらく検出されないままになった障害（または、セキュリティ違反）から保護するには、かなり前にデータの過去のコピーをいくつか保持する必要もあります。

それ自体では、バックアップソリューションではありません。特定の障害シナリオでダウンタイムを削減または削除しますが、他の多くのユーザーからはまったく保護されません。

もちろん、より丸みを帯びた可用性+バックアップソリューションの非常に貴重な部分になる可能性があります。

• 同じハードウェア上のRAIDとスナップショー
• 他のハードウェア上のオンサイトコピー（覚えておいてください：ボックス全体、コントローラー、ドライブ、およびすべてを一度に取り出す障害モードがあります）
• 半切断されたリモートコピー
• そしてもちろん、真の災害に対する適切なオフライン+オフサイトのコピー

また、バックアップを定期的にテストしてください。バックアップが機能していないことを発見する最悪の時期は、バックアップから何かを取得する必要があるときです...