web-dev-qa-db-ja.com

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

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

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

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

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

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

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

backupstoragezfsnexentadeduplication
9
Krystian Lieber

確かにZFSはこの種のことを行うのに十分なほど安定しており、ZFSとNexentaに完全に基づいた非常に大規模で信頼性の高いプロダクションプラットフォームが数多く存在します。

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

だから私の答えはイエスです、それは問題ありませんが、可能であれば両方のオプションを選択します。

10
Chopper3

（バックアップソフトウェアではなく、ZFS内で重複排除を使用することに言及していると仮定します）

私はnotバックアップシステムにZFSネイティブ重複排除を使用することをお勧めしません専用のストレージシステムを設計します。

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

見る：

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

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

重複排除を使用するためのRAM要件が高いと言うとき、64GB +で説明しているデータセットに対するRAMおよびL2ARCのニーズRAMおよび200GB + L2ARC。これは少額の投資ではありません。再読み込みされないWindowsシステムファイルとイメージドキュメントを大量に保持すると、そのDDTがすぐにいっぱいになります。見返りはエンジニアリングの価値がない可能性があります。事前に行う必要のある作業。

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

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

また、ここに設計アイデアのための優れたZFSリソースがあります。 誰もあなたに言わなかったZFSについてのこと

10
ewwhite

代替OSはOpenIndianaで、これも同様に優れており、より頻繁に更新を受け取ることがあります。

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

私が働いている場所では、次のようなセットアップを実行します。

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

ここでZFSの送信/受信を調整する方法について簡単に説明します： http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/

0
poolski