スナップショット+ RAIDは、優れたオンサイトバックアップソリューションとしてカウントされますか？
バックアップを取るために考えられる2つの主な理由は、スナップショットとRAIDの両方をbtrfsと一緒に使用するときに対処されるようです。 （ここでのRAIDとは、RAID1または10を意味します）
- データの誤った削除：スナップショットはこのケースをカバーします
- ドライブの故障とビットの腐敗
- 完全な障害：RAIDはこのケースをカバーします
- ドライブが不良データを返す：RAID + btrfsのエラー修正機能がこのケースをカバーします
オンサイトのバックアップソリューションとしては、これは問題なく機能するようで、個別のデータストレージデバイスも必要ありません。
ただし、RAIDとスナップショットの両方が適切なバックアップとは見なされないと聞いたので、何かを見落としたのではないかと思います。
Btrfsがまだ成熟した技術ではないことを除けば、私が見逃したことは何ですか？それとも私の考えは正しいですか？これは有効なオンサイトバックアップソリューションですか？
いいえ、ちがいます。
ファイルシステムまたはRAIDボリュームが破損するとどうなりますか？またはあなたのサーバーは燃え始めますか？または誰かが誤って間違った配列をフォーマットしましたか？
すべてのデータが失われますand想定していた非実際のバックアップ。実際のバックアップは、バックアップしているデータとは完全に異なるシステム上にあるのはそのためです。バックアップは、問題のシステムで発生したデータ損失の原因となる何かから保護するためです。バックアップと同じシステム上にバックアップを保持します。そのシステムでのデータ損失は、「バックアップ」にも影響を与える可能性があります。
オンサイトバックアップの場合、スナップショットmightで十分であり、それが提供されたスナップショットをパッシブデータとして存在する別の場所に定期的に「エクスポート」します。
また、「出荷されたスナップショット」を復元できるかどうかを定期的にテストします。
これは、いくつかのサーバーのクイックバックアップを実装する方法です。ZFSにデータを保存し、ZFSスナップショットを取り、deltaを別のサーバーに送信します。ここで、ファイルシステム全体が再作成されます（実行されている実際のサービスを除く）。
もちろん、最良のバックアップはalwaysオフサイトです。したがって、スナップショットを別のシステムに「出荷」した後、定期的にスナップショットの「テープアウト」を実行します。
したがって、私のシステムでは、スナップショットデルタを受信するサーバーが、すべてのZFSプール（以前のスナップショットを含む）を定期的にテープにダンプします。
そしてもちろん、テープアウトをテストして、復元できることを確認します。
注：スナップショットは静止ディスクアクティビティの間に、できればデータベース（存在する場合）と連携して、整合性を確保することをお勧めします。そうでなければ、治療法は病気よりも悪いかもしれません。これが、NetAppとEMCの「ライブスナップショット」機能が非常に役立つ理由です。LUNを使用するデータベースがスナップショットを実行しても安全であることが示されるまで、LUNのスナップショットを延期します。
HopelessN00bの発言。番号。
適切なバックアップは、バックアップされるデバイスとは別のデバイスにあります。 2つ以上のドライブを紛失するとどうなりますか？サーバールームが燃え尽きるとどうなりますか？誰かが誤ってアレイを破壊した場合はどうなりますか？
（Anecdoteアラート：PXEで最新のFedoraを自動インストールするように設定した人のことを聞いたことがあります。彼のUPSは失敗しました。停電後、彼のサーバーは再起動し、PXEブートに設定され、データにFedoraをインストールしました。Myポイント？奇妙なことが起こります。幸いにも、彼は適切なバックアップを持っていました。）
できれば、少なくともデータのコピーを3つ用意し、データセンターが焼失した場合に備えて、1つは完全にオフサイトに保存します。
適切な実装のスナップショットは、適切なバックアップがバックアップジョブを作成する最初の段階として使用するため、ストレージでサポートされている必要があります。ただし、プライマリバックアップにスナップショットを使用することはお勧めできません。理由：
1）スナップショットとバックエンドストレージが失敗する可能性があります。したがって、実際のバックアップでは別のスピンドルセットを使用する必要があります。そうしないと、プライマリワーキングセットとバックアップデータの両方が同時に失われる可能性が高くなります。
2）スナップショットは使用可能なスペースを「かき消す」。現在のホットデータとオフロードスナップショットには高価で高速のストレージを使用し、バックアップは氷のように冷たいデータであり、より安価で低速のストレージに使用することは理にかなっています。これは1）BTWで非常にうまく機能します。
3）スナップショットは通常、プロセス全体の速度を低下させます。ほとんどのシステムはコピーオンライトを使用しており、このアプローチは断片化を引き起こします。 Redirect-on-Writeは高速ですが、大量のスペースを消費します。スナップショットを適切に実装しているベンダーはほとんどありません。 WAFLを備えたNetAppおよびCASLを備えたNimble Storage（私はそれらのいずれにも関係していません）。他のほとんどすべての人が問題を抱えています。たとえば、Dell Equallogicは、変更された1バイトごとに15 MBのページ更新（および無駄）をトリガーします。それは高価です。
はい、そうです。バックアップを保存するのに最適な方法です。他には何も必要ありません、一体、整合性チェックを行うことさえ、ただの時間の無駄です。
確認するだけです-私がアドバイスをする前に...あなたは私の競争相手のために働いていますよね本当にそうですか番号？ああ。
すみません、NUTS。いいえ、まったくありません。すまん。
問題は、（a）システムと（b）オペレーティングシステムレベルで発生するエラーに完全に対処できることです。基本的には、誰かがデータを削除するのを防ぐだけです。いいね。 ISよくあるエラーです。
あなたが守っていないのは：
- マシンを一掃するパワースパイク。そこにいて、それを見た。
- いくつかの欠陥のあるRAIDコントローラまたはディスク上のメモリ書き込みsh **-何でもあります。
そして、他のものの長いリスト。
これは-当然ですが、私の競合他社で働いていない限り、常にバックアップを作成してください。
- 別のコンピューター
- 少なくとも電源スパイクから分離すること（たとえUSVを持っている場合でも）。
これがテープが揺れる理由です-テープは接続されておらず、火災や洪水での短いものはテープを傷つけません。パワースパイク-テープリーダーとおそらくロボットが動作しますが、リーダーにないテープは影響を受けません。
BESTは、オフサイトでのバックアップになります（すでに、火災や洪水などについて言及しましたか？）（ここでも、競合他社で働いている場合、建物の火災などはなく、火災保険も必要ありません。そのお金を節約します）。
今、あなたは「ああ、洪水は決して起こらない」と思うかもしれません。あなたが確信していることを確認してください。こちらをご覧ください。ボーダフォンデータセンターの09.09.09フラッディングのビデオです。問題がインサイト/コンピューターのバックアップのどこにあるかを理解できると思います：
2つのRAID-1ドライブが互いに30分以内に故障することから学んだ教訓：RAIDはnotバックアップメカニズムであり、いかなる形、形でもありません。
RAIDは、ハードウェア障害が発生した場合のダウンタイムを短縮する可用性メカニズムですが、たとえば、ウイルス、データの削除/変更、または壊滅的なハードウェア障害。
それ自体はバックアップソリューションではありませんです。特定の障害シナリオでのダウンタイムを削減または削除しますが、あなたを保護しませんまったく他の多くの人から
もちろん、より丸みを帯びた可用性+バックアップソリューションの非常に貴重な部分になる可能性があります。
- RAIDと同じハードウェア上のスナップショー
- 他のハードウェア上のオンサイトコピー（ボックス全体、コントローラー、ドライブ、およびすべてを一度に実行する障害モードがあることに注意してください）
- 半切断されたリモートコピー
- そしてもちろんtrue災害に対して適切なオフライン+オフサイトコピー
また、バックアップを定期的にテストしてください。バックアップが機能していないことを発見する最悪の時期は、バックアップから何かを取得する必要があるときです...
多くの経験豊富な管理者は、いわゆる3-2-1のバックアップルールに従っています。
プライマリソースを含む、少なくとも3つのデータのコピーが必要です。つまり単一のバックアップでnotで十分であり、同じ物理システム内のコピーはカウントされません。
少なくとも2つの異なるバックアップ方法を使用する必要があります。
データのオフサイトコピーが少なくとも1つ必要です。
スナップショットは3つの部分すべてに違反しています。
単一の物理マシンのみを使用します。 PSUの障害など、マシン全体に影響を与えるものはすべて、すべてのデータを取り込む可能性があります。
バックアップに単一の方法のみを使用しています。 anythingが間違っている場合は、危機的な状況でバックアップを復元するときにのみわかります。
オフサイトにバックアップがありません。洪水や火災は、あなたに起こるまで他人にのみ起こります...
したがって：
LAN上のseparateマシンに少なくとも1つのバックアップが必要です。
スナップショットを使用して生成されたnotであるバックアップが少なくとも1つ必要です。古き良きインクリメンタル
tarアーカイブが適切なのでしょうか？または、rsyncベースのコピーですか？現在の場所から可能な限り遠くに少なくとも1つのリモートバックアップが必要であり、同じ建物内に間違いなくが存在しない。
また、ブロックレベルのスナップショットには、マシンのプラグを抜いてディスクにコピーするのとほぼ同じ一貫性が保証されていることにも注意してください。一般に、復元後にfsckを実行するか、ジャーナルが十分であることを期待する必要があります。
ファイルシステムレベルのスナップショットはより良いはずですが、それでもファイルの一貫性は保証されません。多くのアプリケーション（データベースサーバーが思い浮かぶ）では、ライブインスタンスのファイルをコピーしても、一貫性のない状態になる可能性があるため、まったく役に立たない場合があります。クリーンコピーの存在を確認するには、独自のアプリケーションレベルのバックアップメカニズムを使用する必要があります。これには、3-2-1ルールも適用されます。
最後に、ここではcurrentデータのコピーについてのみ話していることを覚えておいてください。しばらくの間検出されないままになっている障害（または、セキュリティ違反）を防ぐために、かなり長い間、データの過去のコピーをいくつか保持する必要もあります。