web-dev-qa-db-ja.com

重複排除とLTO5を使用したディスク間ディスク間バックアップの適切な使用

現在、ディスクからテープ(LTO3)へのフルバックアップ用に最大12TBのデータがあります。言うまでもなく、現在16本以上のテープが必要になっているため、他のソリューションを検討しています。これが私が思いついたものです。コミュニティの考えを聞きたいです。

  • ディスクツーディスク用サーバー
  • 重複排除テクノロジーを使用したBackupExec2010
  • 20TB以上のSATAドライブ
  • SAS経由で接続されたLTO5ロボットライブラリ
  • 1Gbps NICネットワークに接続

私が想定しているのは、ネットワーク全体の完全バックアップを実行することです。これは、最初は1Gbpsで長い時間がかかりますNICですが、重複排除が開始されると、バックアップは迅速になります。次に、 LTO5は、ディスクからテープへのバックアップを作成し、それに応じてそれらをアーカイブします。

みんなどう思いますか? 1Gbps NICを介して最初の完全バックアップを実行するより高速な方法はありますか?私の問題点は何ですか?私が達成しようとしていることを行うためのより良い方法はありますか?

5
Michael

私は現在、データシステムの夜間バックアップを行っており、主にrsyncrsnapshotを使用して「ユーザーに表示される」ボリュームを増やしています。

最大のボリュームは16TBの容量があり、現在9.5TBが使用されています。最初に、別のディスクアレイに対して単純なrsyncを実行します。これには通常30〜45分かかります。

次に、100Mビットのワイヤレスリンクを介してオフサイトサーバーに2番目のコピーを実行します(ただし、通常、パケットが失われると50〜60Mビットの効果が得られます)。これには、毎晩約3時間かかります。

あ、はい;大容量のディスク間バックアップは難しいことではないと思います。流行語に準拠した派手なソフトウェアも必要ありません。シンプルなツールで十分です。

4
Javier

ここで最も重要なのは、バックアップを実行するのか、アクティブなコピーを維持するだけなのかです。毎晩更新される16tbの単一のアクティブコピーは確かにディスク間で実行可能なものであり、テープライブラリよりもほぼ確実に安価です。とはいえ、最後の手段の復元オプションは、物理的に配置された回転ディスクに保存されていることを考慮してください。これは、ドライブ障害、電力損失による破損などの通常の問題すべてに対して脆弱です。したがって、適切なレベルの冗長性を備えたディスクシステムを設計してください。 。

約350TBのデータでこれまで行ってきた方法は、比較的高性能のフロントエンドディスクへの単純な同期であり、オフサイトストレージ用のロボットライブラリを介してテープに移行されます。これにより、最近の(アクティブな)データの高速バックアップと高速復元が可能になりますが、災害時に信頼性の高いテープオフサイトストレージが保証されます。

バックアップでの重複排除に関する積極的な販売クレームに巻き込まれないでください-ディスクで支払うのではなく、重複排除を処理するためにcpuサイクルで支払うことになります。重複排除に拘束されているため、復元時間はおそらく低下します。ブロックを復元する前にブロックがどこにあるかを通知するシステム、および(私の個人的な悪夢)重複排除システムでデータ損失エラー状態が発生した場合、最後の手段のバックアップは無駄になります。

もちろん、これらは私自身の意見にすぎません。それらがバックアップソリューションの設計に役立つことを願っています。頑張ってください!

1
Jeff Albert

Ext [234]などのdumpプログラムを備えたファイルシステムを使用している場合は、eSATAドックと多数の安価な1TBsataディスクを入手できます。初期レベルのゼロダンプの場合、12台のドライブが必要になります。これらのドライブを耐火金庫または貸金庫に投げ入れてから、別の5台または6台のドライブを回転させて、ハノイの塔のパターンバックアップを毎日実行します。この方法を使用すると、削除または上書きされたファイルを取得する必要がある場合に備えて、通常、毎日のドライブに頻繁に変更されるファイルの2つまたは3つのコピーがあり、完全な復元を行う必要がある場合は、ダースレベルをフェッチします0台のドライブを使用してから、システムがクラッシュした日に応じて、1日あたり1〜5台のドライブを復元します。

ハノイの塔のバックアップパターンの詳細については、 http://en.wikipedia.org/wiki/Backup_rotation_scheme を参照してください。

0
psusi