バックアップサーバーでRAIDを使用する必要がありますか?


17

バックアップサイズがテープ容量を超えているため、テープではなくハードディスクに保存するSymantec Backup Execを使用して、新しいバックアップサーバーをセットアップするように求められました。

「バックアップ」であるため、バックアップサーバーがあらゆる種類のRAIDを実行するのに本当に意味があるのか​​、それとも利点があるのか​​と思いました。

私にとっては、追加コストを正当化するメリットはそれほど大きくありません。

他の人の意見を見てみたいです。

ありがとう!



1
これは、私の視点からは、「バックアップとしてraidを使用する」ではなく、「バックアップサーバーでraidを使用する理由がある場合」と彼が尋ねるのと同じ質問ではありません。それは質問のほぼ反対側です。
半径

私は同意します。答えのいくつかが関連しているため、リンクを投稿しただけです。
アンドリオイド09

他のポスターからのすばらしい回答。追加することはあまりありませんが、「..追加費用を正当化するメリットがそれほど大きくない場合」は、自分が仕事に危険を冒していることに気付かないかもしれません。あなたの仕事を危険にさらす価値がある数百ドルを節約していますか?あなたが会社とあなたのキャリアのための完全な災害を避けるために比較的少ない金額を費やしたならば、だれもあなたのことを考えないでしょう。ちょうど私の2セント。
osij2is 09

回答:


16

Imo、レイドを使用することには大きな利点があります。

RAIDなしでバックアップマシンにディスク障害が発生した場合、すべてのバックアップが失われます。それらを再構築するのにどれくらい時間がかかりますか?

また、ディスク障害が原因ですべてのバックアップを失い、それらを正常に再構築してから、以前にバックアップされたがこのディスク障害の原因を失ったものを見つける必要がある場合はどうなりますか。

他に何もなければ、ディスクは非常に安価であるため、システムをRAID 5に入れるための追加のディスクのコストは、障害から回復する必要がある場合の時間よりもおそらく安くなります。


1
特定のRAIDレベルが提供するディスク速度の大きな利点は言うまでもありません。バックアップから再構築する場合、読み取り速度が問題になる可能性があり、RAID5またはRAID10が役立ちます。
ラスウォーレン

1
実際のディスク容量は非常に大きいので、同じRAID構成は期待したほど安全ではないことに注意してください。私は、ディスクのサイズが大きいと、故障確率も(セクタごとに)高くなるという事実に言及しています。この単純な統計的事実により、ディスク故障後のRAID再構築により、生き残ったディスクも死にます。 ..非常に安全なRAID1 + HSを完全に信頼性の低いシステムにする...したがって、フォールトトレラントRAIDシステムに非常に大きなディスクを使用しないでください。hds.com/assets/pdf/…を
drAlberT

11

サーバーコンピューターには、非常に特殊な状況(Googleのような「スケールアウト」1Uアプリケーションサーバーのラックごとに考える)を除き、冗長ディスクが必要です。冗長ディスクのないサーバーコンピューターは時限爆弾です。

そうは言っても、バックアップはオフサイトでオフラインでない限りバックアップではありません。オンサイトでオフライン(引き出し内のテープ)の場合、建物が燃え尽きると消えます(サーバーからのすすのクリーニングを参照 )。オフサイトであるがオンラインの場合、攻撃および「破損」に対して脆弱です。

そして今、ディスク対テープなどについての宗教的な議論に注目してください。


ディスク+テープ。いずれも、すべての点で他より優れているわけではありません。ディスクは、メインサーバーからバックアップメディアサーバーへのバックアップの取得が高速であるため、ダウンタイムウィンドウを短く予測可能に保つことができます。ロボット#1、ドライブ#0がいつ利用可能になるかは保証できません。テープはオフサイトに適しています。私は特にVTLを気にしません。ここにはblobが好きです。ここにはblobに1000個のデータセットがあり、それらをすべてテープに効率的に配置します。(NetBackup 6.5はこれをうまく行います)。
クリスK

1
合意された再:「どちらも他のものよりも優れている」ディスクツーディスクは、バックアップウィンドウの縮小とクイックリストアに最適です。ただし、データをオフサイトでオフラインにすることは、テープが優れているところです。ディスクからディスクへのテープは、今日のバックアップにおける最も一般的な「スイートスポット」です(余裕があれば、そこに重複排除ステップがあります)。
エヴァンアンダーソン

ディスク->オフサイトディスク、およびディスク->オンサイトディスクを使用します。すべてのバックアップを取得しやすくします。しかし、残念ながら帯域幅のコストのおかげで、多くの場合は不可能です。
シアン

7

RAID-10を使用します。

RAID-5は、次の理由により、バックアップサーバーには適していません。

  • サーバーは、非アイドルライフタイムの大部分を大量のシーケンシャル書き込みに費やします。パフォーマンスが重要です。
  • ディスクの使用率は時間の経過とともに増加する傾向があるため、バックアップウィンドウが現在心配しているものでない場合、将来的に使用される可能性があります。
  • ディスクがダウンした状態で操作することでパフォーマンスが低下すると、バックアップが失敗します。
  • 大容量のSATAディスクを使用できるため、RAID-5を使用するための通常の言い訳(「ディスクはすごい高価です、ワウ、ワウ」)は、バックアップ用に100%の合計バンクです。
  • ランダムI / Oワークロードは比較的小さいため、SATAとSASはバックアップにとってそれほど重要ではありません。

バックアップを事実上のアーカイブソリューションとして使用しているかどうかによっては、RAIDをまったく使用しないことも可能です。


バックアップのパフォーマンス面について完全に同意します。私のバックアップサーバーは現在RAID-5であり、パフォーマンスはひどく、RAID-10を切り替えるのは面白くないでしょう。
ダン

4

費用は?ハードドライブは安価であり、Raid 1は現在マザーボードでほぼ標準となっています。

私の意見では、あなたはあまり注意することはできません。メインの開発マシンを急襲し、定期的にホームサーバーにバックアップを作成し、ホームサーバーが毎晩オフサイトバックアップを作成しています。安くて、簡単で、シームレスなら、なぜだと言いますか


3

現在、複数レベルのバックアップ、ニアラインおよびオフサイトがあります。ニアラインは、ディスクにバックアップする場所です。ここでは、非常に重要なデータの複数のバックアップセットを近くに保持し、バックアップサーバーのディスクからテープにコピーを作成してから、テープをオフサイトに送信できます。これにはいくつかの利点があります。

  1. 通常、ディスクへのバックアップは高速です
  2. 実質的に無制限のディスクデバイスがあり、通常、テープへのバックアップは、一度に書き込む必要があるヘッドの数に制限されます。

ただし、データベースサーバーと同じ種類の冗長性を備えたバックアップサーバーディスクを扱う必要があります。データベースサーバーが正午に失敗した場合、昨夜からディスクコピーのバックアップサーバーにロールバックして復元を行うことができます。ここで、テープは既に250ドルのオフサイトベンダーからの緊急返品となります。

RAIDを、実行するすべてのサーバーに配置する必要があります。:-)


逸話:データセンターを移動すると、データベースサーバーで一部のドライブに障害が発生しました。システムを使用し続けるリスクとなるのに十分であることが判明しました。そのため、2つのコピーを作成しました。1つはネットワーク経由でディスクスペースのある別のサーバーに、もう1つはいくつかの外部ディスクにコピーしました。まあ、アレイは悪かったので、ネットワークコピー(SCSI-> EthernetがSCSI-> SCSIに勝つことを知っている人)しか取得できませんでした。一度に2つの異なるシステムで2つのディスクを失う可能性が低いからといって、それが起こりそうにないというわけではありません。
クリスK

2

はい、それをしてください。ハードドライブは、他のコンピュータコンポーネントよりも何倍も故障する可能性が高くなります。RAIDに移行することにより、発生する可能性が最も高い1つの問題から保護します。データの価値で、RAIDセットアップの限界コスト(低から中規模のサーバーを想定して、おそらく500ドル未満)を測定します。

それを言って、私はエヴァン・アンダーソンが上で言ったことを第二にします。これは絶対に唯一のバックアップではありません。エヴァンはオフサイトでオフラインであることについて話しました。そのリストに冗長性を追加します。バックアップメディア、バックアップジョブ、盗難、紛失、メディアの紛失などが発生した場合に備えて、バックアップの複数のコピーが必要です。


2

バックアップサーバーでRAIDを使用する必要がありますか?

冗長性のために、私はしません

バックアップシステムのファイルの特定のリビジョンを復元する習慣がなく、バックアップシステムディスクに障害が発生した場合にそれを行う必要があるのではないかと心配している場合。その後、はい、RAID 5またはミラーリング、またはストライピングとミラーリングを使用します。

最悪の場合に元のデータが利用できない可能性があると予想する場合、これを行う唯一の理由です。

ディスクを1つのボリュームに拡張する(ストライピング)

たぶん、しかし、1つのディスクが死ぬとアレイ全体が死ぬことに注意してください。

ボトムライン

バックアップサーバーをバックアップすることをお勧めします。ばかげているように聞こえますが、我慢してください。システムディスク、構成ファイル、およびバックアップ設定をバックアップします。そうすれば、バックアップサーバーに障害が発生しても、できるだけ早く起動できます。

(編集:申し訳ありませんが、他の答えについては、私は質問を読み違えました)


1

テープではなくサーバーにデータを保存する予定があるため、バックサーバーでRAIDを使用することは絶対に意味があります。

RAID 5、1、または10をお勧めします。

このように考えると、ハードドライブが故障します。適切なRAID設定により、これが発生した場合のデータ損失から保護されます。故障したハードドライブを交換し、RAIDを再構築します。

ハードドライブが死んだとき(ある時点で死ぬ)にRAID保護が無効になっていると、バックアップが失われます。


1

これは、「バックアップ」についてどう思うかに大きく依存します。

このサーバー上の他のサーバーから「ライブ」データを複製するサーバーを作成することが目的である場合、このバックアップサーバーでraidを使用することはほとんど役に立ちません。この場合、ディスクに障害が発生した場合にバックアップサーバーを短時間でオンラインに戻すことができるように、予備のディスクが必要です。

目標が時間内にバックアップをアーカイブすることである場合。毎日バックアップを行い、1か月、1年程度保持します。はい、ディスクを失うとアーカイブを失うため、RAIDを使用する必要があります。X週間前のバックアップからデータを復元できることが重要な場合は、この「バックアップ/アーカイブ」を別のサーバーまたはテープにバックアップすることもできます(テープは長期間のアーカイブに非常に適しています) )


0

本番サーバーとバックアップサーバーのハードディスクが同時に故障する可能性は何ですか?それらが精神的に分離されている場合(つまり、同じ電力網などにない場合)、この可能性は非常に低くなります。だから、私はRAIDなしに投票します。

もちろん、バックアップサーバーに障害が発生した場合は必ずアラートを受信して​​ください。


1
運用サーバーとバックアップサーバーの両方のドライブが同じバッチからのものである場合はどうなりますか?チャンスが大幅に増加します。
ラズロー

0

すでに述べたことに同意しますが、パリティ付きのRAIDを使用している場合は、ドライブとバックアップデータの状態を監視する方法があります。ほとんどのアダプタまたはオンボードコントローラは、syslog、Windowsイベント、または電子メールを介して警告を送信します。

SMARTが故障したドライブを報告したときにこのボックスが単にWindowsイベントをスローするだけの場合、手遅れです。

バックアップのやり直しには、RAIDコントローラーといくつかの追加のSATAドライブよりも時間がかかります(人件費)。

M.


0

ディスクへのバックアップには価値があります。私は議論のテープ側にしっかりといる間。ただし、バックアップボリュームが冗長性のない単一ディスクである場合、最終的にすべてのデータが失われます。ディスクが最終的に故障するためです。

ディスクへのバックアップが本当に適切なソリューションであるかどうかは、バックアップのニーズの性質に依存すると思います。オフサイトでデータを必要とせず、災害復旧や長期にわたるデータの存続性を気にしない場合、テープは必要ありません。私は確かに、決してディスクから出ず、データセンターを離れないバックアップを持っていますが、それらはユーザー削除エラーを修正するためにあります。

また、テープ容量をどのように拡張しますか?それがテープの美しさです。いつでも別のテープを入手できます。ただし、何らかのテープチェンジャーが必要です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.