ストレージサーバーをどのようにバックアップしますか？
他のいくつかのサーバー（すべてLinuxベース）のライブNASとして使用される非常に大規模なストレージサーバーの実装を検討しています。
非常に大きいとは、4TBから20TBの使用可能スペース（実際に20TBにする可能性は低いですが）を意味します。
ストレージサーバーは、データのセキュリティとパフォーマンスのためにRAID 10になりますが、オフサイトバックアップを含むバックアップソリューションが必要です。
私の質問は：どのように多くのデータをバックアップしますか！？
ポータブルハードドライブを接続してファイルを転送できるわけではありません。現在、これほど多くのストレージスペースを備えたデバイスは他にありません。
2台目のオフサイトストレージサーバーの予算を立てる必要がありますか、それともより良い解決策がありますか？
そのサイズのデータを処理する方法はたくさんあります。それの多くはあなたの環境とあなたが費やしても構わないと思っている金額に依存します。一般に、いくつかの全体的な「サーバーからデータを取得する」戦略があります。
- イーサネット経由ボックスに記載されているように、データは処理のために他の場所にストリーミングされます。 20TBは1GbEをコピーするのに長い時間がかかりますが、それは可能です。ハードウェアが役立ちます（10GbEリンク、場合によってはNICボンディング））。
- ストレージサブシステム経由ファイバーチャネルを使用している場合は、FCネットワーク上の別のデバイスに送信します。 SASをお持ちの場合は、SASに接続されたデバイスに送信してください。一般的にイーサネットよりも高速です。
- 別のディスクアレイに送信します同じサーバーに接続されている別のストレージの塊に送信します。
それが100Kmのビューです。ズームインを開始すると、さらに断片化されます。すでに述べたように、LTO5は、この種の高密度負荷用に設計された特定のテープテクノロジーです。特にGlusterFSやDRBDなどを使用してデータを取得できる場合は、別の同一のストレージアレイが適切なターゲットです。また、バックアップrotationが必要な場合、またはアレイに障害が発生した場合に実行を継続する機能が必要な場合は、配置する内容に影響します。
100Kmの表示方法に落ち着いたら、ソフトウェアに取り掛かることが次の大きなタスクになります。これに影響を与える要因は、最初にストレージサーバーにインストールできるものです（NetAppの場合、それは1つですが、大量のストレージを備えたLinuxサーバーは、大量のストレージを備えたWindowsサーバーとはまったく別のものです） 、選択するハードウェア（たとえば、すべてのFOSSバックアップパッケージがテープライブラリを適切に処理するわけではありません）、および必要なバックアップ保持の種類。
あなたは本当にあなたが望む災害復旧の種類を理解する必要があります。単純なライブレプリケーションの方が簡単ですが、先週から今だけ復元することはできません。先週から復元する機能が重要な場合は、そのようなことのために設計する必要があります。法律により（米国およびその他の国で）、一部のデータは7年以上保存する必要があります。
単純なレプリケーションが最も簡単です。これは、DRBDが行うように設計されていることです。最初のコピーが完了すると、変更が送信されるだけです。ここでの複雑な要因はネットワークの局所性です。2番目のアレイがプライマリDRBDの近くにない場合は、実行できない可能性があります。少なくとも最初のストレージサーバーと同じ容量の2番目のストレージサーバーが必要です。
テープバックアップについて...
LTO5は、圧縮なしで1.5TBのデータを保持できます。これらのモンスターに餌をやるには、ファイバーチャネルまたは6GbSASのいずれかである非常に高速なネットワークが必要です。ワックで1.5TB以上をバックアップする必要があるため、オートローダーを調べる必要があります（例： link 、HPの24スロット1ドライブオートローダー）。それらをサポートするソフトウェアを使用すると、バックアップの途中でテープの変更を処理できます。彼らは素晴らしいです。それでもオフサイトに送信するにはテープを引き出す必要がありますが、バックアップで必要なときにテープを自分でロードするために一晩中ぶらぶらするよりも、それはひどい光景です。
テープが 'legacy、ew' heebiegeebiesを提供する場合、仮想テープライブラリの方が速度が速い可能性があります（Quantumのこのライブラリのように： link ） 。これらは、ソフトウェアをバックアップするためのテープライブラリのふりをして、堅牢な（希望する）重複排除技術を使用して実際にディスクに保存します。そのようなものが好きなら、もっと凝ったものはあなたのために仮想テープを実際のテープにコピーすることさえあります、それはオフサイトローテーションのために非常に便利です。
仮想テープでさえもいじくり回したくないが、それでもディスクへの直接バックアップを実行したい場合は、その20TBを処理するのに十分なサイズのストレージアレイに加えて、必要な量のネット変更データが必要になります。保持する。バックアップパッケージが異なれば、これの処理も異なります。いくつかの重複排除テクノロジーは本当に素晴らしいです、他はハッキーな応急修理です。私は個人的にこの分野のFOSSバックアップソフトウェアパッケージの状態を知りませんが（Baculaについて聞いたことがあります）、それで十分かもしれません。多くの商用バックアップパッケージには、スループットを向上させるためにバックアップするサーバーにインストールするローカルエージェントが含まれていますが、これには多くのメリットがあります。
LTO-5ジュークボックス？そのアレイをバックアップするには、3〜15本のテープが必要になりますが、これはそれほど多くはありません。ジュークボックスがテープの変更を処理し、優れたバックアップソフトウェア（Baculaなど）がどのファイルがどのテープにあるかを追跡します。
また、その期間中にFSが変更される可能性が非常に高いため、ファイルシステムのバックアップに必要な時間も考慮する必要があります。最良の結果を得るには、をサポートするファイルシステムを使用します。スナップショットは非常に役立つので、ライブファイルシステムではなく、瞬時のスナップショットを作成して、それに対して完全バックアップまたは増分バックアップを実行できます。
おそらく、ディスクへのバックアップを確認する必要があります。テープには長い時間がかかり、シーケンシャルアクセスであるため、復元には永遠に時間がかかります。
差分または増分バックアップを確実に活用してください-自分にとって意味のある頻度で、変更のみをバックアップします。
おそらく理想的なソリューションは別の場所にある2番目の同じサイズのサーバーで、増分バックアップが定期的に送信され、メインサーバーが停止した場合にすぐに元の場所に交換できます。ただし、別のオプションは、リムーバブルドライブオンロケーションを使用することです。これは、ストレージのためにオフサイトに移動されます。
大量のデータを処理する場合は、バックアップを分割小さなバックアップジョブに分割することも理にかなっています。毎日すべてをバックアップできない場合は、バックアップをずらして設定してくださいある日バックアップされ、次の日にBを設定します。
常に復元手順について考えてください。数百ギガのバックアップジョブからファイルを復元する必要があったときに、私たちは一度悩まされました。これには、バックアップインデックスを再構築して復元するために、多くのメモリと多くの時間がかかりました。結局、1日で完了することができず、メインのバックアップサーバーが夜間のジョブを継続できるように専用の復元サーバーを構築する必要がありました。
-追加-
また、複数のユーザーに対して、同じ情報を複数回バックアップしないことで大量のスペースを節約できる重複排除テクノロジーについても検討する必要があります。多くのバックアップソリューションまたはファイルシステムは、機能の一部として重複排除を提供します。
2つの類似した12 TBシステムが2つの異なる建物にあり、1GBで接続されています。1つは本番システムです。もう1つは段階的に（毎日のスナップショットで）バックアップされます。 rdiff-backup ユーティリティ。rdiff-backupは、標準の配布リポジトリで使用可能である必要があります。
まず、保護しているリスクを列挙します。いくつかの一般的なリスク：
- 災害：サイト全体に非常に不幸なことが起こります。
- ヒューマンエラー（これは_all_the_time_で発生するエラーです）：
- 誰かが、製造元が意図していない方法でストレージサーバーの「ホットスワップ」機能を実行することにしました。
- 誰かがデータをサイレントに破壊するプロセスを実行します。このプロセスは、問題に気付く前の2、3か月間確実にバックアップされます。
- 誰かが1時間以内に期限が到来し、数千ドルの価値がある重要なレポートを削除します。
次に、さまざまなリスク回避ソリューションのコストを評価します。例：
- オフサイト、オンラインバックアップ（リモートミラー）：災害から安全、一部（すべてではない）の人的エラー（まだオンラインです）。
- オフサイトオフラインストレージ（テープ）：災害から安全で、データを迅速に回復するのは困難です。
- オンサイトオンラインバックアップ（ミラー）：人的エラー、ハードウェア障害から安全で、災害に対して脆弱です。
- オンサイトオフラインバックアップ（テープチェンジャーのテープ）：ほとんどの人的エラー、ほとんどのハードウェア障害から安全です。
次に、ローテーション戦略を評価します（どのくらい前に回復できるようにしたいのか、どれだけのデータを失う余裕があるのか）。
次に、データの価値を選択します。
オフサイトのオンラインバックアップ（リモートミラー）
sshを介してrsyncを使用する（変更のみ）-最初のバックアップはローカルで実行する必要がありますが、その後のバックアップは変更に応じて簡単になります
変更を加えたバージョンを保持する必要がある場合-rdiff-backup
http://www.nongnu.org/rdiff-backup/
linuxのbtrfsファイルシステムは有望に聞こえますが、まだ開発が進んでいます
戦略を立てる前に、実際の「コンテンツ」とその変更頻度を確認してください。多くの場合、人々は正当な理由もなく、同じデータを毎週何度もテープにチャーンします。
一部のベンダーの重複排除テクノロジーでは、スナップショットを使用して個々のファイルの復元から保護できますが、保護のために常にオフサイトが必要になります。