ZFSを使用したバックアップストレージサーバー

私は小さな会社のITすべてです。会社全体のバックアップポリシーを使用して、新しいサーバーと別のバックアップサーバーを含む新しいインフラストラクチャを設計したいと考えています。

会社で最も重要なことは、SQL Serverとそのデータベースです。データベースは10個ありますが、本当に重要なのは2つだけです。最初の1つは8 GBで、主にテキストデータと数値です。2つ目は約300 GBで、16 GB /月でPDFとGIFが含まれます。

ストレージを保存するには、現在のバックアップポリシーは1週間に1回の完全バックアップと6つの差分で構成されます。週あたり約350 GB、月あたり1.4 TBだと思います。

サイレントデータ破損に関する記事を読んだ後、Nexenta CommunityエディションでZFSを試すことにしました。

私の質問：重複排除を備えたZFSは、信頼性の観点からバックアップファイルを保存するのに適していますか、それともテープバックアップなどを検討する必要がありますか？

編集：今のところ、パフォーマンス、重複排除率などを予測できないことはわかっていますが、それが良いアイデアかどうかを知りたいのです。

確かに、ZFSはこの種のことを実行するのに十分安定しています。ZFSとNexentaに完全に基づいた非常に大規模で信頼性の高い実稼働プラットフォームが数多くあります。

それはいつもあなたが提案しているもののようなオンサイトのディスクベースのバックアップと、毎日火事/地震/クトゥルフなどから保護するためにオフサイトに行くリムーバブルディスクまたはテープベースのバックアップを持ちたいと言っています。

だから私の答えは「はい」です。大丈夫ですが、できれば両方のオプションを選びます。

（ZFS内での重複排除とバックアップソフトウェアの使用について言及していると想定）

ストレージシステムを特別に設計しない限り、バックアップシステムにZFS ネイティブ重複排除を使用することはお勧めしません。

ZFSで重複排除を使用すると、RAMを集中的に使用します。データがストレージプールにストリーミング/書き込みされるときに重複排除がリアルタイムで発生するため、データブロックを追跡するテーブルがメモリに保持されます。これはDDTテーブルです。ZFSストレージサーバーにこのテーブルを収容するのに十分なRAMがない場合、パフォーマンスは大幅に低下します。Nexentaは、テーブルが特定のしきい値を超えると警告を出しますが、それまでには遅すぎます。これは、L2ARCデバイス（読み取りキャッシュ）を使用することで強化できますが、ZFSの初期の採用者の多くがこの罠に陥りました。

見る：

ZFS-重複排除されたzvolまたはデータセットを破棄すると、サーバーが停止します。回復するには？

ZFS-L2ARCキャッシュデバイス障害の影響（Nexenta）

重複排除を使用するためのRAM要件が高いと言うとき、64 GB以上のRAMと200 GB以上のL2ARCで記述しているデータセットのRAMとL2ARCのニーズを推定します。それは小さな投資ではありません。再読されないWindowsシステムファイルや画像ドキュメントをたくさん保存すると、DDTがすぐにいっぱいになります。見返りは、事前に行う必要があるエンジニアリング作業の価値がない場合があります。

より良いアイデアは、zpoolで圧縮を使用することです。おそらく、より圧縮可能なデータ型のgzip機能を活用します。重複排除されたデータを削除する必要がある場合にヒットするため、重複排除は価値がありません（DDTを参照する必要があります）。

また、バックアップソフトウェアにストレージをどのように提示しますか？どのバックアップソフトウェアスイートを使用しますか？Windows環境では、iSCSIを介してBackup ExecにブロックストレージとしてZFSを提示します。ZFS CIFSの機能が十分に堅牢であることに気づかず、ネイティブにフォーマットされたデバイスの利点を優先しました。

また、デザインのアイデアに関する優れたZFSリソースもここにあります。誰も言わなかったZFSについて

代替のOSはOpenIndianaです。これは同じように優れており、時々より頻繁に更新を受け取ります。

もう1つのオプションは、圧縮が有効になっている（潜在的に）小さいストレージプールを持つ2番目のZFSサーバーをセットアップすることです。この2番目のデバイスを静的バックアップに使用できます。したがって、読み取りキャッシュを省くことができ、それを処理するために愚かな量のCPU / RAMを必要としません。

私は次のようなセットアップを実行します。

• 3セットのミラーリングされたペアのRaidZ1プールに6つの2TBディスクを備えたOpenIndianaメインストレージサーバー[ main ]。これにより、使用可能なストレージスペースを削減しながら、高速かつ多重冗長のストレージプールが実現します。
• セカンダリストレージサーバー[ backup ]もOpenIndianaを実行しており、バックアップデバイスとしてのみ機能するディスクの同様の構成を使用しています。
• mainには、1日を通して/ tank / [dataset]を定期的にスナップショットするcronジョブから実行されるスクリプトがあります
• 毎晩、別のcronジョブが実行され、その日のスナップショットをネットワーク経由でバックアップにプッシュします。すべてのスナップショットの初期同期が完了すると（1回限りの手順）、スナップショットのインクリメンタルな性質により、変更がバックアップデバイスにすばやくプッシュされます。

ZFSの送信/受信をここでリグする方法の簡単な概要があります：http : //kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/