ペタバイトのデータをバックアップして保存する良い方法はありますか？

（SQL Serverのインストールで）数百テラバイトのデータを持つクライアントを見始めています。一部の企業のデータの総量がペタバイトの意味のある部分に近づくと、その規模のデータを扱う人々がそれを保護するために何をしているのかを知るために、集合的な知識ベースを調べたいと思います。

明らかな問題は、その量のデータの複数のバックアップを保存することは、エンタープライズクラスのストレージを使用して、非常に高価なことです。

表示されるオプションは次のとおりです。

1. 別のデータセンターにデータのミラーコピーを作成し、その差分を継続的に送信します（データソースで使用可能な任意のメカニズム（ログ配布やSQL Serverによるデータベースミラーリングなど）を使用します）
2. 大量の圧縮アルゴリズムを使用して定期的にバックアップを取ります（データが大きく圧縮されている場合にのみ適している可能性があります）
3. データの重要/変更部分の断片的なバックアップを取ります。
4. データをバックアップせず、腐敗の神を信頼しないでください。

オプション＃4がデフォルトとして採用されており、HA / DRの専門家としては本当に怖いのですが、代わりとして何を勧めますか？＃1が最良のアプローチであると思いますが、＃4およびおそらく＃3以外の代替案が提案された場合、「そうは思わない」が通常の答えです。

さて、もちろん、それはデータの変化率と重要度に依存します。Microsoftで働いていたときにSQL ServerのすべてのHA機能を担当していたので、それに答える必要はありません。したがって、「依存する」引数に精通しています-それが私のキャッチフレーズです:-)

私が見逃した代替案を聞いたり、他の全員が同じボートに乗っていて、より多くのストレージに多額のお金を費やすことに対する現実的な代替案がないことを聞いて、非常に興味があります。

事前に感謝します-すべてのよく考えられ、表明された答えに正当なクレジットが与えられます。

壁のアイデアから-保存された情報のすべてが必要ですか、さらには有用ですか？

情報は実際にどれくらいの価値がありますか？データの価値よりも多くを維持管理に費やすことは明らかにばかげているようです。

データベース内のデータは、データベース内のストレージに適していますか？たとえば、サポート組織のデータベースに圧縮されたマルチギガバイトのコアファイルを保持することは、実際に何らかの利点をもたらしますか？

データベースに多くの重複データがありますか？たとえば、1,000人が毎週10 MBのニュースレターを10部ずつ保持していますか？

一部のデータには「有効期限」があり、それ以降は値を提供しませんか？サポート組織の例に戻ると、さまざまな理由により、修正が配信されてから数か月以上、顧客のコアファイルを保持しても実質的にメリットはありません。

別の考えは-その量のデータを会社が負債にさらすことです。法律により、保持する必要があるデータもあります。ただし、一部のデータは、誤って、または悪意を持って不適切な関係者にリリースされた場合に生じるリスクがあるため、「シュレッド」する必要があります。

ええ、もう1つのオプションはストレージ仮想化です。IBMSVCのように、サーバーとSANの間にあるデバイスです。SVCはSAN間のコピーを管理し、リモートレプリケーションを実行できます（ただし、データ変更率が非常に低く帯域幅が非常に大きい場合を除き、ペタバイトレベルでは明らかに非常に苦痛です）。

なめらかな部分は、プロセス全体が関係するサーバーから見えないことです。SQL Serverを使用している場合は、ファイルグループを設計して、変更率の低いもの（3年以上前の販売アーカイブなど）をまとめ、変更率の高いもの（現在の販売など）を別のファイルグループに保持します。完全に読み取り専用である必要はありません。ファイルグループごとに異なるレプリケーション方法を使用できるように設計するだけです。SANギアは、ネットワーク、テープ、またはSANを介してLUNを同期できます。つまり、SANの一部を前後に出荷できます。これは、SANが参加ユニットのプールで構成されるLeftHandのようなギアでより効果的です。

その後、変更率の低いものを有線で自動的に同期し、変更率の高いものをスニーカーネットと同期できます。（私はそれを後方に持っているように聞こえますが、それは本当です-ボリュームのためにワイヤ上で高変化率のものを同期することはできません。）ローエンドのギアの一部でさえこれに対応しています：データセンター内のLeftHandユニットを、オフサイトデータセンターに出荷します。それらを接続し、IPとグループを変更することでそれらをリモート側に参加させると、それらはリモートバックアップSANの一部になります。これに関するLeftHandの売り込みは素晴らしいです。プライマリデータセンターで2つのSANを並べてセットアップし、それらを同期させて、それらの一部を現在のデータセンターに残したままリモートデータセンターに出荷できます。同期を維持するデータセンター。徐々に移動する '

しかし、私はこれをペタバイトレベルで実行していません。あなたは彼らが言うことを知っています-理論的にも理論的にも実際上も同じです。実際には...

オプション1はミラーリングで、＃4とほぼ同じくらい悪いです。データを破損し、すぐには検出されないバグは両方のコピーを破損します。

データが重要な場合は、専用のソリューションを検討してください。IBMのShark製品、またはEMSの競合製品などをお読みください。これらには、Flashコピーなどの機能があり、ディスク要件を2倍にすることなく、ファイルの論理コピーを即座に作成できます。その後、このコピーを（たとえば）テープにバックアップできます。ロボットのテープバックアップも調べてください。

ストレージが安くないペタバイトのデータを保存したい人に指摘してください。

ディスクは安いので、余分なテラバイトのオンラインストレージがないことを嘆く人々にうんざりしています。

バックアップの保存が非常に高価な場合、データを安全な方法で保存するのは非常に高価であるため、提案されたソリューションは実行可能ではありません。

バックアップを作成する最も重要な理由の1つはユーザーエラーからの保護です（ほとんどのハードウェア障害の問題はハードウェアソリューションで対処できます）が、データベースミラーリングでさえ、ドロップされたテーブルに対する保護ではありません（OK、あなたはそれに対して保護できますが、それでもまだです）削除できないガフをDBに取り込むことができます-DBが非常に大きい理由が挿入のみを発行する場合を除きます）。

私が見るように、テープはもはや実行可能なソリューションではありません。ディスクアレイで作業する方が安価になりました（ただし、物理ストレージは扱いにくい場合があります）。したがって、あなたの唯一のオプションは、データを適切な時間枠で復元するのに十分な小さなチャンクに分割し、定期的にディスクストレージに入れる方法だと思います（そして、ここでEMSタイプのソリューションが役立ちます現金）。

myspace.comのアーキテクチャを詳しく説明した興味深いビデオ（SQL2005バックエンド）。複数のデータベースでスケールアウトするため、個々のペタバイトデータベースがあるかどうかはわかりません。SANスナップバックアップを使用します。

http://wtv.watchtechvideos.com/topic70.html

ZFS。確かに、まだ始まったばかりですが、ZFSがこうした種類のことだけを処理するように設計されている領域がいくつかあります。まず、大量のデータと多数の異なるストレージデバイス（ローカル、SAN、ファイバーなど）を処理し、すべてのデータをチェックサムと「レイヤー違反」によりデバイスの状態を認識して安全に保ちます。失敗。しかし、これはこのようなデータのバックアップの解決にどのように役立ちますか？

1つの方法は、スナップショットを使用することです。スナップショットを作成し、それをテープ/ディスク/ネットに送信して、リモートサイトに転送します。後続のスナップショットは送信されたデータのみを送信し、必要に応じてライブデータを両端で保持できます。

もう1つの方法は、（十分なネットワーク帯域幅がある限り）2つのサーバー間でライブミラーリングを行い、1つがダウンした場合に2つ目が引き継ぐことができるSolaris Clusterソフトウェアを使用することです。高可用性（HA）が重要な場合に使用しますが、その量のデータを持つほとんどの場所でHAが必要になると思います。

ZFSはsqlserverを見つける通常の場所であるWindowsではサポートされていないと言います。バックエンドでSun / ZFSを実行し、iSCSI経由で接続するかもしれません。それは恐ろしいアイデアかもしれませんが、少なくとも考えてみる価値はあります。

Amazon Glacierをオプションとして検討しましたか？

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番目のコピーを最初のスナップショットにスナップショットして、続行します。これだけのデータがあれば、ここでいくつかの勤勉さが必要になると思います。ポール、ch​​eckdbはオンラインのマルチユーザー、100TBデータベースでどのように機能しますか？

前述のように、ログのバックアップ、およびおそらくログリーダーは重要ではありませんか？バックアップではなく、ログからドロップテーブル/ユーザーエラーを回復する必要はありませんか？多少の遅延を経てSANコピーを送信することで、潜在的にこれを短縮できますが、私はそのテクノロジーを見たことはありません。変更を4時間（または一定の間隔）遅らせて、データを上書きする前に問題から回復できるログ配布SAN。または、SANブロック変更ログリーダーツールがありますか？それなしでは、これらのトランザクションログを管理する必要があります。これは、さまざまなファイルシステムでこれらのバックアップをxxx時間追跡し、致命的でないエラーから潜在的に回復できるようにする他のレベルです。

技術的には、ストレージは安価ですが、ペタバイトレベルではそれほどではありません。それは本当にアプリケーションに依存しますが、戦略＃2と＃3の組み合わせが答えになると思います。＃2が与えられ、＃3はストレージへの投資額と種類によって異なります。ストレージとIO /計算能力。これにより、できる限り増分的でなく、できるだけ慎重なフルバックアップで逃げることができます。

また、Amazon S3のようなものも、帯域幅とデータの変化量に応じて機能します。このボリュームでは、少なくとも一部を他の誰かのサーバーに置き、冗長性を心配させます。費用対効果。

ストレージベンダーと話すと、以前に使用した重複排除製品があり、通常の圧縮と組み合わせて、データフットプリントを70％削減できます。もちろん、ペタバイトのストレージに費やすお金を持っている人は、まともなバックアップソリューションを購入する予算も持っている可能性があります-そうでない場合は、ペタバイトを失うとビジネスにどのような費用がかかるかを尋ねる必要があります。

大規模なエンタープライズデータウェアハウスでは、データの多くは既にバックアップされているソースから取得されます。私はTeradataおよびODWのインストールに取り組んでおり、オプション＃4を使用しましたが、1日または2日分のトランザクションデータを復元し、ソースシステムから変換できることを知っていました。

ある小売クライアント（当時、世界でトップ5の最大のDWの1つであった約200 TBで...これがどれくらい前かを知ることができます）、彼らは新しいペタバイトを購入した後、オプション＃1を選びましたクラスのTeradataサーバー。古いノードは前日のシステムのスナップショットに使用され、新しいノードは既存のシステムを維持します。これはフェイルオーバーの観点からも素晴らしいことでした-時々メンテナンスのためにすべてを停止し、古いデータのある古い低速サーバーの使用に切り替えるだけでした。

しかし、正直なところ、特に最大の利点が管理者とNCRの技術者が不規則なメンテナンスを実行するためにより少ない夜を働かせる必要があることでした。