ストレージサーバーをどのようにバックアップしますか？

私は、いくつかの他のサーバー（すべてLinuxベース）のライブNASとして使用される非常に大きなストレージサーバーの実装を検討しています。

非常に大きいということは、4TBから20TBの使用可能スペースを意味します（実際に20TBにすることはまずありませんが）。

ストレージサーバーは、データのセキュリティとパフォーマンスのためにRAID 10になりますが、オフサイトバックアップを含むバックアップソリューションが必要です。

私の質問は次のとおりです。どのくらいの量のデータをバックアップしますか？

ポータブルハードドライブを接続してファイルを転送するだけではいけません。現在、これほどのストレージ容量を持つ他のデバイスはありません。

2番目のオフサイトストレージサーバーに予算を入れる必要がありますか、それともより良いソリューションがありますか？

サイズの大きいデータを処理する方法は多数あります。それの多くは、あなたの環境とどれだけのお金を使うかによって異なります。一般に、いくつかの全体的な「サーバーからデータを取得する」戦略があります。

• イーサネット経由ボックスに記載されているように、データは処理のためにSome Where Elseにストリーミングされます。20TBは、1GbEを超えるコピーに時間がかかりますが、それは可能です。ハードウェアが役立ちます（10GbEリンク、場合によってはNICボンディングなど）。
• ストレージサブシステム経由ファイバーチャネルを使用している場合は、FCネットワーク上の別のデバイスに送信します。SASがある場合は、SAS接続デバイスに送信します。一般的にイーサネットよりも高速です。
• 別のディスクアレイに送信する同じサーバーに接続されている別のストレージの塊に送信します。

それが100Kmビューです。ズームインを開始すると、さらに断片化されます。既に述べたように、LTO5は、この種の高密度負荷用に設計された特定のテープテクノロジーです。特にGlusterFSやDRBDなどを使用してそこにデータを取得できる場合は、別の同一のストレージアレイが適切なターゲットです。また、バックアップローテーションが必要な場合、またはアレイに障害が発生した場合に実行を継続する機能のみが、配置する内容に影響します。

100Kmの表示方法に決まったら、ソフトウェアに入ることが次の大きなタスクになります。これに影響を与える要因は、最初にストレージサーバーにインストールできるものです（NetAppである場合、ストレージを備えたLinuxサーバーは、ストレージを備えたWindowsサーバーとまったく同じです）。 、どのハードウェアを選択するか（たとえば、すべてのFOSSバックアップパッケージがテープライブラリを適切に処理できるわけではありません）、必要なバックアップ保持の種類。

どのような災害復旧が必要なのかを本当に理解する必要があります。単純なライブレプリケーションは簡単ですが、先週から復元することはできません。先週から復元する機能が重要な場合は、そのようなことを考慮して設計する必要があります。法律により（米国およびその他の地域では）、一部のデータを7年以上保存する必要があります。

簡単な複製が最も簡単です。これがDRBDの目的です。初期コピーが完了すると、変更が送信されるだけです。2番目のアレイがプライマリDRBDの近くにない場合、複雑な要因はネットワークの局所性です。少なくとも最初と同じくらいのストレージスペースを持つ2番目のストレージサーバーが必要になります。

テープバックアップについて...

LTO5は、圧縮なしで1.5TBのデータを保持できます。これらのモンスターに餌をやるには、ファイバーチャネルまたは6Gb SASの非常に高速なネットワークが必要です。強打で1.5TB以上をバックアップする必要があるため、オートローダーを調べる必要があります（ここに例があります：link、HPの24スロット1ドライブオートローダー）。それらをサポートするソフトウェアを使用すると、バックアップ中にテープの変更を処理します。彼らは素晴らしいです。オフサイトに送信するにはテープを引き出す必要がありますが、バックアップが必要なときにテープを一晩中ロードして自分でテープをロードするよりも、見た目が良いです。

テープが「レガシー、ew」のヒビゲージーを提供する場合、仮想テープライブラリの方が速度が向上する可能性があります（Quantum：linkのようなもの）。これらは、ソフトウェアをバックアップするためのテープライブラリのふりをしながら、実際には堅牢な（希望する）重複排除技術を使用してディスクに保存します。あなたがそのようなことを好めば、より洗練されたものはあなたのために仮想テープを実際のテープにコピーします。それはオフサイトの回転に非常に便利です。

仮想テープでさえいじりたくないが、ディスクへの直接バックアップを行いたい場合は、その20TBを処理するのに十分な大きさのストレージアレイと、必要な大量の変更データが必要になります保持するために。異なるバックアップパッケージは、これを異なる方法で処理します。重複排除技術の中には本当に素晴らしいものもあれば、ハッキーなものもあります。私は個人的にこの分野のFOSSバックアップソフトウェアパッケージの状態を知りません（私はBaculaのことを聞いたことがあります）が、それで十分かもしれません。多くの商用バックアップパッケージには、多くのメリットがあるスループットを向上させるために、バックアップするサーバーにローカルエージェントをインストールします。

LTO-5ジュークボックス？そのアレイをバックアップするには3〜15本のテープが必要になりますが、これはそれほど大きな数字ではありません。ジュークボックスがテープの交換を行い、適切なバックアップソフトウェア（バキュラなど）がどのファイルがどのテープにあるかを追跡します。

また、その期間中にFSが変更される可能性が非常に高いため、ファイルシステムのバックアップに必要な時間も考慮する必要があります。最良の結果を得るには、スナップショットをサポートするファイルシステムが非常に役立つので、ライブファイルシステムではなく、瞬時のスナップショットを作成し、それに対してフルバックアップまたは増分バックアップを実行できます。

テープには時間がかかり、シーケンシャルアクセスであるため、ディスクへのバックアップを検討する必要があります。復元には永遠に時間がかかります。

間違いを活用する差分または増分バックアップ-あなただけのために理にかなってどんな頻度で変更をバックアップ。

おそらく理想的なソリューションは、別の場所に2番目の同じサイズのサーバーを持ち、増分バックアップが定期的に送信され、メインサーバーが停止した場合にすぐに交換できる可能性があります。ただし、別のオプションとして、場所にあるリムーバブルドライブを使用することもできます。その後、リムーバブルドライブはオフサイトに保管されます。

大量のデータを扱う場合は、バックアップを小さなバックアップジョブに分割することも意味があります。毎日すべてをバックアップできない場合は、バックアップをずらして、セットAが1日バックアップされるようにします。次にBを設定します。

常に復元手順について考えてください。数百ギガのバックアップジョブからファイルを復元する必要があり、バックアップインデックスを再構築して復元するのにかなりのメモリと時間がかかりました。最終的には、1日で完了できず、メインのバックアップサーバーが夜間のジョブを続行できるように、専用の復元サーバーを構築する必要がありました。

-追加-

また、複数のユーザーに対して同じ情報を複数回バックアップしないことで、大量のスペースを節約できる重複排除テクノロジーについても考えてください。多くのバックアップソリューションまたはファイルシステムは、その機能の一部として重複排除を提供しています。

最初に、保護するリスクを列挙します。いくつかの一般的なリスク：

• 災害：サイト全体に非常に不幸なことが起こります。
• 人為的エラー（これは_all_the_time_に発生するエラーです）：
  • 誰かが、製造元が意図していない方法でストレージサーバーの「ホットスワップ」機能を実行することにしました。
  • 誰かがデータを静かに破壊するプロセスを実行します。このプロセスは、問題に気付くまでの数ヶ月間、確実にバックアップされます。
  • 誰かが1時間で期限が切れ、数千ドルの価値がある重要なレポートを削除します。

次に、次のようなさまざまなリスク回避ソリューションのコストを評価します。

• オフサイトのオンラインバックアップ（リモートミラー）：災害からの安全、一部（すべてではない）のヒューマンエラー（まだオンラインです）。
• オフサイトのオフラインストレージ（テープ）：災害から安全で、データを迅速に回復するのが困難です。
• オンサイトのオンラインバックアップ（ミラー）：人的エラー、ハードウェア障害、災害に対して脆弱です。
• オンサイトのオフラインバックアップ（テープチェンジャーのテープ）：ほとんどの人的エラー、ほとんどのハードウェア障害から安全です。

次に、ローテーション戦略を評価します（どれだけさかのぼって回復できるようにしたいのか、どれだけのデータを失う余裕があるのか​​）。

次に、データの価値を選択します。

1GBで接続された2つの異なる建物に2つの同様の12 TBシステムがある顧客がいます。1つは運用システムです。優れたrdiff-backupユーティリティを使用して、他のバックアップに増分バックアップ（毎日のスナップショットを使用）します。rdiff-backupは、標準の配布リポジトリで利用可能でなければなりません。

オフサイトのオンラインバックアップ（リモートミラー）

sshでrsyncを使用します（変更のみ）-最初のバックアップはローカルで実行する必要がありますが、変更後はバックアップが簡単になります

変更したバージョンを保持する必要がある場合-rdiff-backup

http://www.nongnu.org/rdiff-backup/

Linuxのbtrfsファイルシステムは有望に聞こえますが、まだ重い開発中です

戦略を計画する前に、実際の「コンテンツ」とその頻度を確認してください。多くの場合、正当な理由もなく、同じデータを毎週何度も繰り返しテープに送ります。

一部のベンダーの重複排除テクノロジーでは、スナップショットを使用して個々のファイルの復元からユーザーを保護できますが、保護のために常にオフサイトが必要になります。