ペタバイトのデータをバックアップして保存する良い方法はありますか？
（SQL Serverのインストールで）数百テラバイトのデータを持つクライアントが表示され始めています。一部の企業のデータの総量がペタバイトの意味のある部分に近づいているので、その規模のデータを扱う人々がデータを保護するために何をしているのかを確認するために、集合的な知識ベースを調査したいと思います。
明らかな問題は、エンタープライズクラスのストレージを使用すると、RAID-5だけでも、その量のデータの複数のバックアップを保存するのは非常にコストがかかることです。
私が見るオプションは次のとおりです。
- 別のデータセンターにデータのミラーコピーを作成し、違いを継続的にデータセンターに送信します（データソースで使用可能なメカニズムを使用します-ログ配布やSQL Serverでのデータベースミラーリングなど）
- 大量の圧縮アルゴリズムを使用して定期的にバックアップを取ります（おそらく、データが重く圧縮されるのに適している場合にのみ適しています）
- データの重要な部分/変化する部分の断片的なバックアップを取ります。
- データをバックアップせず、腐敗の神々を信頼してください。
オプション＃4がデフォルトとして採用されているのを見て、HA/DRの専門家としては本当に怖いですが、代わりに何をアドバイスすればよいですか？ ＃1が最善のアプローチだと思いますが、＃4とおそらく＃3以外の代替案が提案された場合、「そうは思わない」が通常の答えです。
さて、もちろんそれはデータの変化率と重要度に依存します。私はマイクロソフトで働いていたときにSQLServerのすべてのHA機能を担当していたので、それに答える必要はありません。そのため、「依存する」引数に精通しています。これが私のキャッチフレーズです:-)
私が見逃した代替案について聞いたり、他の全員が同じボートに乗っており、より多くのストレージに多額のお金を費やす現実的な代替案がないことを聞いて、非常に興味があります。
事前に感謝します-よく考えられ、表明されたすべての回答に正当なクレジットが与えられます。
ええ、別のオプションはストレージ仮想化です。IBMSVCのように、サーバーとSANの間にあるデバイスです。 SVCはSANからSANへのコピーを管理し、リモートレプリケーションを実行できます（ただし、データ変更率が非常に低く、帯域幅が非常に高い場合を除いて、ペタバイトレベルでは明らかにかなり苦痛です）。
巧妙な部分は、プロセス全体が関係するサーバーから見えないことです。 SQL Serverを使用している場合は、変更率の低いもの（3年以上前の販売アーカイブなど）と変更率の高いもの（現在の販売など）を別のファイルグループにまとめるようにファイルグループを設計します。完全に読み取り専用である必要はありません。ファイルグループごとに異なるレプリケーション方法を使用できるように設計するだけです。 SANギアは、ネットワーク、テープ、またはSANを介してLunを同期できます。つまり、SANの一部を前後に出荷できます。これは、より効果的です。 SANは参加ユニットのプールで構成されているLeftHandのようなギアを使用します。
次に、低変化率のものをネットワーク経由で自動的に同期し、高変化率をスニーカーネットと同期させることができます。 （私はそれを逆に持っているように聞こえますが、それは本当です-ボリュームのためにワイヤー上で高い変化率のものを同期することはできません。）ローエンドのギアのいくつかでさえ今これに対応しています：LeftHandはあなたが他に複製することを可能にしますデータセンター内のLeftHandユニットを、オフサイトのデータセンターに発送します。プラグインし、IPとグループを変更してリモート側に参加させると、リモートバックアップSANの一部になります。これに関するLeftHandのセールスピッチは素晴らしいものです。プライマリデータセンターに2つのSANを並べてセットアップし、同期させてから、一部を現在のデータセンターに残したまま、その一部をリモートデータセンターに出荷できます。同期を維持するデータセンター。同期が外れることなく、徐々に移動します。
ただし、これはペタバイトレベルでは行っていません。あなたは彼らが言うことを知っています-理論的にも、理論的にも実際にも同じです。実際には...
壁から離れたアイデア-保存されているすべての情報が必要ですか、それとも有用ですか？
情報は実際にどのくらいの価値がありますか？データの価値よりも維持管理に多くを費やすことは明らかにばかげているようです。
データベース内のデータは、データベース内のストレージに適していますか？たとえば、圧縮された数ギガバイトのコアファイルをサポート組織のデータベースに保持することは、実際に何らかのメリットをもたらしますか？
データベースに重複データがたくさんありますか？たとえば、1,000人が毎週10MBのニュースレターを10部ずつ保管していますか？
一部のデータには「有効期限」があり、それ以降は値が提供されませんか？サポート組織の例に戻ると、さまざまな理由から、修正が提供されてから数か月以上顧客のコアファイルを保持することに実質的なメリットはありません。
もう1つの考えは、会社を負債にさらすほどのデータを保持することです。法律により、保持しなければならないデータもあります。ただし、一部のデータは、誤って、または悪意を持って不適切な関係者に公開された場合にリスクが生じるため、「細断処理」する必要があります。
オプション1はミラーリングですが、これは＃4とほぼ同じくらい悪いです。データを破壊し、すぐには発見されないバグは、両方のコピーを破壊します。
データが重要な場合は、専用のソリューションを検討してください。たとえば、IBMのShark製品、またはEMSの競合製品などについて読んでください。Flashコピーなどの機能があり、ディスク要件を2倍にすることなくファイルの論理コピーを即座に作成できます。次に、このコピーを（たとえば）テープにバックアップできます。ロボットテープのバックアップも調べてください。
Petabyteのデータを保存したいが、ストレージが安くないことを指摘してください。
ディスクが安いので、余分なテラバイトのオンラインストレージがないことについてうめき声を上げる人々にとてもうんざりしています。ディスクは安いかもしれませんが、管理されたストレージは確かにそうではありません。
バックアップを保存するのに法外な費用がかかる場合、安全な方法でデータを保存するのは法外に費用がかかるため、提案されたソリューションは実行可能ではありません。
バックアップを作成する最も重要な理由の1つは、ユーザーエラーからの保護です（ほとんどのハードウェア障害の問題はハードウェアソリューションで対処できます）が、データベースミラーリングでさえ、ドロップされたテーブルに対する保護ではありません（OK、それから保護できますが、それでもまだですDBが非常に大きい理由が挿入を発行するだけである場合を除いて、DBに取り外し不可能なガフを入れる可能性があります）。
私が見ているように、テープはもはや実行可能なソリューションではありません-ディスクアレイを操作するだけの方が安価になりました（物理ストレージは扱いにくい場合があります）。したがって、あなたの唯一の選択肢は、データを十分に小さいチャンクに分割して、適切な時間枠で復元し、定期的にディスクストレージに保存する方法だと思います（ここではEMSタイプのソリューション）あなたが現金を持っているなら、助けることができます）。
Myspace.comのアーキテクチャ（SQL2005バックエンド）の詳細を説明する興味深いビデオ。複数のデータベースでスケールアウトするため、個別のペタバイトデータベースがあるかどうかはわかりません。 SANスナップバックアップを使用します。
ZFS。確かに、まだ始まったばかりですが、ZFSがこの種のことだけを処理するように設計されている領域がいくつかあります。まず、大量のデータだけでなく、多数の異なるストレージデバイス（ローカル、SAN、ファイバーなど）を処理する機能であり、チェックサムとデバイスの状態の「レイヤー違反」認識によってデータを安全に保ちます。失敗。しかし、これはこれだけのデータのバックアップを解決するのにどのように役立ちますか？
1つの方法は、スナップショットを使用することです。スナップショットを取り、それをテープ/ディスク/ネットに送信してリモートサイトに転送します。後続のスナップショットは送信されたデータのみを送信し、必要に応じて両端でライブデータを保持できます。
もう1つは、Solaris Clusterソフトウェアを使用することです。このソフトウェアでは、（十分なネットワーク帯域幅がある限り）2つのサーバー間でライブミラーリングを実行でき、一方がダウンした場合は、もう一方が引き継ぐことができます。高可用性（HA）が重要な場合に使用する方が適していますが、データ量が多いほとんどの場所でHAが必要になると思います。
そして、あなたはZFSがWindowsでサポートされていないと言います。これは、sqlserverが見つかる通常の場所です。おそらく、バックエンドでSun/ZFSを実行し、iSCSI経由で接続します。それも恐ろしい考えかもしれませんが、少なくとも考えてみる価値はあるので、何をすべきでないかを知っておいてください。
オプションとしてAmazonGlacierを検討しましたか？
IMO、ある種のゴジラレベルのハードウェアがない限り、それだけのデータがある場合は、バックアップ圧縮技術を使用する必要があります。私はLiteSpeedに最も精通していますが、他のベンダーからの同様の製品があり、（もちろん）同様の機能がSQL2008に組み込まれています。 10対1の圧縮は得られない可能性がありますが、バックアップのストレージ要件が削減され、バックアップウィンドウの要件が縮小される可能性もあります。目標が複数のバックアップセット（昨日とその前日、さらに先週と先月の1つ、または一連の差分とフル）を保持することである場合、多くのデータを変更するとかなり大きくなる可能性がありますデータベース）、それはストレージスペースの単純な問題です。
ファイルグループベースのバックアップ（IOW、特定のFGに不揮発性データを配置し、バックアップを頻繁に行わない）は、開発者またはユーザーがどのデータが揮発性で何が揮発性でないかを判断できないか、判断できないため、飛ぶようには見えません。多くの場合、リスクを冒すことはできません。
フェイルオーバーサイトが必要な場合は、データベースミラーについて考えるだけでなく、クライアントのストレージベンダーに相談して、ハードウェアベースのデータレプリケーションテクノロジであるSRDFのようなものが提供されているかどうかを確認することをお勧めします。当然のことながら、レプリケーション（あらゆる種類ですが、特にリアルタイムまたはほぼリアルタイムのレプリケーション）はバックアップの代わりにはなりません。
ここでテープとディスクのどちらを選ぶかはあまり選択できないと思います。テープをストライプ化しない限り、通常のバックアップウィンドウでテープがカットされる可能性は低く、信頼性がそこにあるかどうかはわかりません。
つまり、ディスクバックアップに取り掛かっています。バージョン管理していますか？つまり、バックアップ2（現在のデータベースから2つのバックアップを引いたもの）に戻ることを心配していますか？またはバックアップ3？その場合、問題が発生する可能性がありますが、処理する必要があるのはログのバックアップであり、データのバックアップはそれほど多くありません。
一部のデータを読み取り専用/変更なしとして分割できる場合は、管理可能なバックアップサイズ/ウィンドウがある可能性があります。または、少なくとも、バックアップテクノロジーと帯域幅がデータの増加に追いついていることを期待しています。
プライマリの問題から回復するために、2番目のコピーを保持しているほどバックアップしているとは思いません。これは、ハードウェア、破損などを意味し、エラーが2番目のコピーに送信されないように毎日祈っています。コピーは、スナップショット技術を使用してSAN-SANで作成されている可能性があります。ただし、元のコピーは、ネットワークを介してではなく、Fed-Ex経由である可能性があります。 100TBを移動するための帯域幅は、誰にとっても簡単ではありません。
優れたログバックアップ管理を備えた、1、2、および3（4ではない）の組み合わせが必要だと思います。
実際、どの時点でも、実際にはデータの3つのコピーを見ていると思います。 2番目のコピーを使用して実際に変更を受信しているときに、1つのコピーでCHECKDBを実行します。次に、その2番目のコピーを最初のコピーにスナップショットして続行します。これだけのデータがあるので、ここではある程度の注意が必要だと思います。ポール、checkdbはオンラインのマルチユーザー100TB dbでどのように機能しますか？
前述のように、ログのバックアップ、そしておそらくログリーダーは重要ではありませんか？バックアップではなく、ログからドロップテーブル/ユーザーエラーを回復する必要はありませんか？ SANコピーを少し遅らせて送信することで、これを短縮できる可能性がありますが、そのテクノロジーは見たことがありません。変更を4遅延させる可能性のあるログ配布SANデータを上書きする前に問題から回復できるようにするための時間（または一定の間隔）またはSANブロック変更ツールのログリーダー？それがなければ、これらのトランザクションログを管理する必要があります。これはまったく別のレベルである可能性があります。致命的でないエラーから潜在的に回復できるように、さまざまなファイルシステムでこれらのバックアップを約xxx時間追跡します。
ストレージベンダーに相談すると、以前に使用した重複排除製品があり、通常の圧縮と組み合わせると、データフットプリントを70％削減できることがよくあります。もちろん、ペタバイトのストレージに費やすお金を持っている人は誰でも、まともなバックアップソリューションを購入する予算を持っている可能性があります-そうでない場合は、そのペタバイトを失うとビジネスに何がかかるかを尋ねる必要があります。
大規模なエンタープライズデータウェアハウスでは、データの多くはすでにバックアップされているソースから取得されます。オプション＃4を採用したTeradataとODWのインストールに取り組んできましたが、1日か2日のトランザクションデータを復元し、ソースシステムから変換できることを知っていました。
ある小売クライアント（当時、世界でトップ5のDWの1つであり、約200TBでした...これがどれくらい前かがわかります）では、新しいペタバイトを購入した後、オプション＃1を選択しました。 -クラスTeradataサーバー。古いノードは前日のシステムのスナップショットに使用され、新しいノードは既存のノードを維持します。これは、フェイルオーバーの観点からも素晴らしいことでした。たまに、メンテナンスのためにすべてが停止し、1日経過したデータで古い低速サーバーを使用するように切り替えるだけでした。
正直なところ、物事を続けるのは処理/保管などの大きな無駄のように見えました...特に最大の利点は、管理者とNCR技術者が不規則なメンテナンスを実行するために必要な夜が少ないことでした。
技術的には、ストレージis安価ですが、ペタバイトレベルではそれほど多くはありません。それは実際にはアプリケーションによって異なりますが、戦略＃2と＃3の組み合わせが答えになると思います。＃2は与えられ、＃3はストレージへの投資額と種類によって異なります。ストレージとIO /計算能力により、漸進主義を最小限に抑え、目立たない完全バックアップを可能な限り回避できます。
あるいは、帯域幅とデータにどの程度の変化があるかによっては、Amazon S3のようなものも機能する可能性があります。このボリュームでは、少なくとも一部を他のサーバーに配置し、冗長性について心配させることがますます増えています。費用対効果が高い。