大企業はどのようにデータをバックアップしていますか?


8

GoogleやFacebookなどの大量のデータを扱う企業は、どのようにすべてをバックアップしますか?

ウィキペディアに関するこのGoogleプラットフォームの記事によると、Googleにはそれぞれ80 GB以上のハードディスクを備えた推定450,000以上のサーバーがあります。それはたくさんのデータです。彼らは本当に1 GBのデータごとに1 GB以上のバックアップを保持していますか?


サーバーソフトウェアをベアメタルから非常に迅速に構築できるように見えるため、Boogleがサーバーソフトウェアをバックアップすることはないと思います。ユーザーデータのバックアップコピーがあるようです。
BillThor 2010年

さて、Googleには100万を超えるサーバーがあります(2007年以降):pandia.com/sew/481-gartner.html
Kedare

私はあなたが1つの根本的な間違いを犯していると思います:GOogleにはたくさんのサーバーが似ています。インデックスを提供するXサーバーのノード。同じインデックスを100万回バックアップしません。
TomTom 2013年

回答:


8

それはあなたの目的が何であるかに依存します。

災害復旧用のバックアップ(サーバーの爆発、データセンターの焼失など)を探している場合、簡単に言えば、バックアップをまったく実行できない可能性があります。機密性の高い政府のデータを扱うクライアントがおり、その使命の一部として、バックアップやリムーバブルメディアへのバックアップを行うことは許可されていません。DRサイトへのライブレプリケーションは許可されています。どちらのサイトも同じレベルの物理的および論理的セキュリティでカバーされています。ここでの問題は、サイトAで何かを台無しにすると、ほぼ瞬時にサイトBに複製されることです。

データ整合性の観点からバックアップについて話している場合(たとえば、誤ってCustomersテーブルを削除し、それがすでにDRサイトに複製されている場合)、大きなテープライブラリのLTO-5テープがよく使用されます。テープあたり最大3 TB、テープライブラリ内の複数のテープを使用すると、大量のデータをすばやくバックアップできます(ここでは、Mbpsを指しますが、25 TBのデータのバックアップには、まだ何時間もかかる場合があります)。

適切なバックアップスイートは、高圧縮と重複除外を実行します。これにより、必要なストレージ容量が大幅に削減されます。15:1の比率(1GBのバックアップに15GBのデータが保存されている)と主張されていた圧縮および重複排除されたExchangeバックアップツールの見積もりを見ました。

多くの検索エンジンデータのバックアップにGoogleが煩わしいと思います。ほとんどのデータは置換可能であり、広範囲に分散しているため、データセンターのかなりの部分、またはおそらく全体が失われた場合でも、システムは残ります。フェイルオーバーBGPルートのおかげでオンライン。


実際のところ、Googleはメトリックの断片的なデータをテープバックアップしているようです。これは、私が期待していたものとはかなり異なります。

Googleテープライブラリの一部


2

ほとんどのデータは独自のGFSファイルシステムに保存されており、GFSではファイルを作成する64 MBブロックごとに少なくとも3つのコピーが必要です(GFSは64 MBブロックを使用します)。そうは言っても、すべてのファイルのコピーが少なくとも3つあり、障害が発生したノードのブロックは、残りの2つの適切なコピーのいずれかから新しいノードにデータを複製するだけですばやく置き換えることができるため、バックアップに煩わされることはないと思います。

詳細については、http://labs.google.com/papers/gfs.htmlをご覧ください。


1
冗長性により可用性が向上しますが、上書きが簡単なため、これは正確にはバックアップではありません(そして、そう呼ばれていませんでした)。
東武

はい、それは良い点です。私の要点は、ほとんどのデータのバックアップはおそらく必要ないということだけでした
ipozgaj 2010年

0

farseekerの答えは良いですが、この観点から考えることで明確にできると思います。何を復元しようとしているのですか?DR用ですか?必要な回復時間は?たとえば、会社が25 TBのsqlサーバーデータベースに依存しているとします。データ障害またはエラー(テーブルの削除、dbの破損など)が発生した場合、CTOは1時間以内にデータベースを回復できるようにしたいと考えています。サイト障害が発生した場合は、2時間必要です。

一見するとこれは難しいように思えますが、不可能ではありません。バックアップ戦略が1時間で回復する必要があることを知っているので、フルバックアップを復元する予定はなく、dbaチームと協力して、DBが管理可能なチャンクに分割されていることを確認する必要があります。また、トランスログバックアップを頻繁に実行します。DRの場合は、レプリケーション戦略を検討する必要があります(ログデータがリアルタイムでレプリケートされたが、適用されていない時間遅延バージョンの可能性があります)。ファーシーカーが言ったようにそれは目的に依存し、その目的は何らかの形の回復を行うことであるべきです。

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