私たちのチームの 1 つは、ある程度の大きさ (~500 GB) のデータベースを開発しており、そこから拡大していきます (500 GB は多くの人にとって小さいと思われるかもしれませんが、これは私たちのショップで最大のデータベースの 1 つになります)。彼らが取り組んでいる問題の 1 つは、データベースのバックアップと復元です。基本的に、データベースには複数の「データ」テーブルと、画像やドキュメントを保存するための 1 つのテーブルが含まれます。次の作業を行う必要があります。
- デバッグとテストの目的で、データ テーブル (画像なし) のみをテスト サーバーにすばやくバックアップおよび復元できます。
- 壊滅的なデータベース障害が発生した場合は、データ テーブルのみを復元して、アプリケーションの大部分をできるだけ早く起動して実行できるようにします。その後、可能な場合はイメージ テーブルを復元します。
- 割り当てられた夜間の時間枠 (数時間) 内にデータベースをバックアップします。質問は次のとおりです。
同じデータベースにイメージを保存したまま、最初の 2 つの目標を達成することは可能ですか? 可能であれば、ファイル グループ、ファイル ストリーム、または他のものを使用しますか? 他のショップでは、高可用性を維持しながら、適切な時間枠でデータベースをどのようにバックアップしていますか? 2 番目のサーバーにレプリケートして、そこからバックアップしていますか?
答え1
非常に簡単です。復元を計画しないでください。
壊滅的なデータベース障害が発生した場合は、データ テーブルのみを復元して、アプリケーションの大部分をできるだけ早く稼働させます。
本当に？あなたの定義する大惨事は、私や世界の他の人々の定義とは違います。
データ災害が発生した場合、できるだけ早く復旧する必要がありますが、火災のため、できるだけ早くデータセンターを再構築する必要があるかもしれません。これは大災害です。
サーバー障害などの場合、バックアップの使用は計画しないでください。レプリケーションとログ ファイルの送信を使用して、2 番目のサーバー (別の SAN 上) をホットおよび読み取り状態に保ち、定義された短い時間枠内で引き継ぐようにします。10 分ごとにログ ファイルを送信している企業を知っています。
ほとんど唯一のチャンスです。大惨事を、RAID/SAN の障害ではなく、本当の災害にまで引き上げてください。問題は「どれだけ早く復旧できるか」ではなく、「どれだけ早く新しいハードウェアを入手できるか」です。
開発などの復元は時間的にそれほど重要ではありません。