次の方法で共有

  • [アーティクル]

SQL Server

SQL Server のバックアップを理解します。

Paul S. Randal

 

概要。

  • 完全バックアップ
  • トランザクション ログのバックアップ
  • 差分バックアップ
  • バックアップ戦略の計画とバックアップの整合性

内容

完全バックアップ
差分バックアップ
トランザクション ログのバックアップ
バックアップ戦略の計画
バックアップの整合性
結果

必要が本当にありますか? SQL Server のバックアップを実行するには はい。 データを気しないか、データベース、障害の発生を完全に再作成することもかまわない、しない限り使用可能なポイントに、データベースの復元のいくつか方法が必要です。 一部のユーザー証明バックアップ、必要が削除どこか他のデータベースの冗長コピーを持ちますが破損しているかアクセスできないはコピーする場合ですか。 バックアップは、常に回復できることを確認するでも必要があります。

しかし、バックアップの種類を考慮でしょうか。 どのくらいの頻度を実行するでしょうか。 どのような効果に、データベースとワークロードでしょうか。 方法の操作を行うを確認して、有効なでしょうか。

バックアップ戦略をまとめるが、バックアップおよび復元コマンドがある、大量のオプションでも考えよりに実際に簡単です。 する、支援がすべて出力図します。

これは 3 部で構成される資料の第 1 です。 ここで第 1 部、するについてバックアップします。 第 2 部 (2009年 9 月問題) では、バックアップを使用して障害から回復について説明します。 第 3 部 (2009年 11 月問題) でする、バックアップせず障害から回復します。 通常、これらの資料でより深い少し移動しようとしている必要がありますに従って、背景マテリアルの助けをすることです。

今月の記事で方法の基礎について説明します、各種のバックアップ作業方法がしたいし、バックアップ計画で使用します。 (私の資料を参照"トランザクション ログの機能の知識がある場合に役立つ、 理解ログおよび SQL Server での回復." いくつかの整合性チェックを追加する方法について説明しますもので、使用するときに破損は出力に、場合にバックアップを持つ内のポイントのありません。 途中いくつかの一般的な misconceptions の debunk しより詳しい情報へのリンクを提供する説明します。

行うには予定もないは、各種のバックアップを実行する方法と、バックアップの構文のしくみについて説明します。 のでこの理由浪費ここで、複製する領域をカバーする優れたセクションが SQL Server Books Online のでしょうか。 トピックを参照してください" バックアップ (Transact SQL)"の詳細情報は、最後の例」では特にです。 トピック「 バックアップと復元方法を説明したトピックの検索 (SQL Server の管理 Studio)"ツールを使用してバックアップをする方法を説明します。 ここで、何と、その理由について説明しますする移動中に、この記事を読んだ後、使い方を確認することをお勧めします。

バックアップ戦略の実装は、比較的簡単な部分です。 効果的な戦略を設計、一部見落とすことがよくありますが、重要、です。

完全バックアップ

最も簡単なバックアップの種類はデータベース全体バックアップです。 1 つのデータ ファイルまたはファイル グループの完全バックアップに可能です。 ただし、これら一般的使用されないし、それらに説明したすべての原則を適用するとしています起こってフォーカスをデータベース レベルのバックアップ。 SQL Server 2005 の各より細かなバックアップの種類に正確に、同じ動作 (このできなかった SQL Server 2000 で true)。 差分バックアップに適用される同じ — ファイル、ファイル グループ、またはデータベース レベルで実行できる — これら同じすべての作業方法、同様に、コンポーネントに関係なくバックアップ対象しますが、します。

データベース全体のバックアップは、データベースの完全なコピーを示し、1 つで-時点のデータベースを復元できるを提供します。 多く、バックアップ処理を実行する時間がかかる場合があります、にもかかわらずまだのみを復元できます、バックアップ単一ポイント (実質的に、バックアップですがの末尾に説明内容を正確にポイントがこの資料で後述)。 完全バックアップを許可されていません任意の位置に回復時間、バックアップが実行中にします。 これはまた、同じ差分バックアップのです。

これについて、ただし、fuelled、WITH STOPAT を使用できるという事実によって、誤解が < 時間またはログ シーケンス番号 > = フル バックアップと差分バックアップの復元オプション。 構文にはそのできますが、オプションは影響を与えません、だけ便宜上。

完全バックアップに関する別の誤解はことだけがデータです。 完全バックアップと差分バックアップの両方によってトランザクション ログ レコードも含めるその (データベース、ファイル、またはファイル グループ) は、復元されたコンポーネントはトランザクション一貫性のあるできます。

1 つの非クラスター化インデックスを持つテーブルにレコードを挿入する、次の使用例トランザクション検討します。 テーブルとインデックスのページは、データ ファイルを介して拡散します。 トランザクションが 2 つの部分を内部的に分割: データのページの表は、および非クラスター化インデックスで、インデックス ページ内の必要なレコードの挿入にレコードを挿入します。 バックアップ プロセスだけでレコードを挿入する前に、非クラスター化インデックス ページを読み取るにはレコードを挿入した後、テーブルのデータ ページを読み取り場合、バックアップ内のデータだけで表されるデータベースは矛盾したトランザクションです。

これは、トランザクション ログは再生に場所です。 バックアップ内の一部のトランザクション ログ レコードを含めるも、ことによって回復を実行してトランザクション一貫性のあるので、データベースの復元、コピーできます。 コミットすると、に応じてこの例トランザクションの回復部分復元の可能性がありますロールフォワードが (としてコミットされることを意味復元されたデータベースのコピーで)、再び (つまりがまったく表示されない、データベースの復元コピーで) ロールまたは。 どちらの場合でも、トランザクション一貫性は維持されます、非常に重要です。

完全バックアップは、次の処理を行います。

  1. データベース チェックポイントを強制し、メモ ログ シーケンス番号の時点で。 これは、フラッシュによって、バックアップの復元の復元の部分が行うには作業時間を抑えるに何もが読み取られる前にディスクにすべてのメモリで更新ページ。
  2. データベース内のデータ ファイルからの読み取りを開始します。
  3. (これらの用語のマイ資料についてのログと回復で SQL サーバー」についてを参照)、データ ファイルと作成する、最も古いアクティブ トランザクションをその時点での開始のログ シーケンス番号をメモからの読み取りを停止します。
  4. 必要に応じてできるだけトランザクション ログを読み取る。

どの程度トランザクション ログが必要な説明は、最適な 図 1 で、視覚補助で行われます。 タイムライン上の赤、番号については、この一覧で説明します。

  1. チェックポイントと、データベースからの読み取りを開始します。
  2. 読み取り操作ページ X を読み取ります。
  3. トランザクション A が開始されます。
  4. トランザクション A が、ページ X に変更を行います。 バックアップ内のコピーは期限切れのようになりました。 バックアップは X もう一度ページを読み取らないことを確認など、データベース内のポイントです過ぎています。
  5. トランザクション B を開始します。 データの操作の完了を読み込む前に完了しません。
  6. トランザクション、コミットします。 ページ X に変更をコミットこれとします。
  7. バックアップ データは、操作が完了し、トランザクション ログの読み取りの開始を読み取ら。

fig01.gif

図 1 [ 全体のバックアップ中の変更の全体のバックアップ中の変更のタイムラインの例

必要十分なトランザクション ログのバックアップありは必要回復が正常に復元中に実行できるように時間内の同じ時点で、データベース内のすべてのページがように —、バックアップ操作の一部を読み取り、データに (7 ポイント) が完了するした時刻。 復旧を実行するには、バックアップ (ポイント 7) の最後に、最も古いアクティブな (またはコミットされていない) トランザクション (ポイント 5、トランザクション B) の先頭からトランザクション ログが必要です。 バックアップ (7 ポイント) の末尾に (1 ポイント) のバックアップ、チェックポイントからトランザクション ログが同じポイントに時間内にできるすべてのページを許可する必要です。

のみ含まれていた、トランザクション ログの最も古いアクティブ トランザクション (5 ポイント)、先頭からページのポイント 2 では、バックアップから復元されましたが X の読み取りのコピーは更新されませんポイント 4 で発生するトランザクション A からの変更。 つまりはいないトランザクション、データベース、データの読み取り操作 (ポイント 7) を完了する時間の残りの部分と一致します。

したがって、完全バックアップに含まれるトランザクション ログの最小ログ シーケンス番号 (LSN) MIN (バックアップのチェックポイントの LSN、最も古いアクティブ トランザクションの LSN) ありに、バックアップの開始前に開始されたトランザクションの可能性があります。 これが復元されたデータベースのコピー (または復元するあらゆる-ページ、ファイル、ファイル グループ、データベース) が完全に一致します。

データベースの余分な I/O 負荷が遅くに多少はこの機構はことトランザクションはしない何らかの方法でによって一時停止、バックアップ操作。 このメカニズムの欠点はこと、トランザクション ログことはできませんのではクリア、完全バックアップの間必要になります。 このトランザクション ログの増加につながる可能性、多数の更新処理が、完全バックアップを完了する時間がかかる場合 — および SQL に関する Q & A 列は、いくつかの以前の記事で既に説明した問題です。

完全バックアップ内のデータは必ずしもすべてのすべてのデータ ファイルの内容はありません。 バックアップでは、データ ファイルから割り当てられたページのみがなります。 たとえば、シングル ファイル データベースが 100 GB しますですが、のみ 15 GB の割り当てられたデータを含みます。 その場合は、完全バックアップのみは、15 GB の割り当てられたデータに加えて、必要なトランザクション ログ。 (ただし、復元されたデータベースが元として同じサイズである常に (この場合は、100 GB)。

別の誤解が、バックアップ処理を調べかがバックアップ データを変更ことです。 これは、バックアップのチェックサムが有効な場合をすぐに説明する untrue を除く場合は 1 つです。

差分バックアップ

データのバックアップの他の種類は、差分バックアップです。 差分バックアップ、完全バックアップと同じ操作が行われますがだけすべてデータを含むが、変更または、前回の完全バックアップ以降に追加されています。 一般的な誤解をここでは、差分バックアップが増分ことです。 実際に累積と連続の差分バックアップを完全なバックアップ後により多くのデータが変更または追加のサイズが大ききます。

すべて 4 GB ですべてのデータ ファイルがあるの GAM 間隔 (セクションは 4 GB セクションのどの部分 (エクステントと呼びます) が変更またはデータベースに追加されたデータを示す最後の完全バックアップ、以降に変更を追跡する差分ビットマップと呼ばれる特殊なデータベース ページです。 (がいくつかのアロケーション ビットマップ、すぎます、および自分のブログ記事でこれらの詳細について」 記憶域エンジン: 内部 GAM、SGAM、PFS およびその他のアロケーション マップ").

差分バックアップは、これらのビットマップをスキャンし、変更済みとしてマークされているファイルのエクステント データをのみバックアップします。 見えるようにがますます増えてデータベースの変更ののマークされます、差分のビットマップで、大きなと大きな連続の差分バックアップになります、ビットマップは、次の完全バックアップによってリセットされます。 最終的に、ほとんどのデータベースが変更されて、差分バックアップになるの完全バックアップと同じ大きさ場合があります。 大きさ、次の差分バックアップが使用するスクリプトを記述する自分のブログ記事から利用わかりますとしています" 新しいスクリプト: 程度、データベースの方法が、前回バックアップ以降に変更完全でしょうか。." ちなみに、このスクリプトでも使えますデータベース チャーン率のアイデアを取得する (たとえば、SharePoint コンテンツ データベースにします。

ミニ ノート] として、ad hoc 完全バックアップを実行するし、差分のビットマップ、リセット、いない使わなければなりません BACKUP ステートメントで、WITH COPY_ONLY オプション。 これは非常に便利なとしてそれ以外の場合は、次の差分バックアップはに基づいて、ad hoc 完全バックアップを行ったの代わりに、通常の (スケジュールされた可能性があります) の完全バックアップにします。 可能性の大きな問題に、障害の状況で、復元するときがあります。

これが理由の差分バックアップに便利です。 高 [バックアップ] セクションで詳しく説明と差分バックアップ実際速ことができます復元操作によって多数のトランザクション ログのバックアップ、復元プロセスでスキップします。 時間には多数のトランザクション ログ レコードを再生するよりも差分バックアップを使用して時間で同じポイントに取得するには、前方をジャンプ本質的にかなり高速です。

トランザクション ログのバックアップ

トランザクション ログのバックアップは完全または一括ログ復旧モデルでのみ可能な限りは完全および差分バックアップは、単純復旧モデルでもは。

トランザクション ログのバックアップの最後のログ バックアップ以降に生成されたすべてのトランザクションのログ レコードを含む (または完全バックアップ、ログ バックアップ チェイン起動) する時間 (通常は、時間、障害発生前に、右) で特定のポイントに復元するデータベースを許可する使用されます。 つまり、これらは累積的な差分バックアップとは異なり、増分です。 これらは、増分、時間の特定のポイントにデータベースを復元したい場合ためするすべてのトランザクション ログ レコードまでデータベースに対して行った変更を再生する必要の時点に必要があります。 ログ バックアップ チェーンに含ま。

ログ バックアップ チェーンは、連続した一連ログのバックアップを含むすべてのトランザクション ログ レコードのポイントにデータベースの復旧に必要なのです。 チェーン始まり、データベース全体のバックアップしたがって別の完全または差分バックアップが行われたまで実行される複数のログ バックアップを妨げる、チェーンが中断ものまで続けられます。

ログ バックアップ チェーンを分割する操作には、単純復旧モデルへの切り替えをデータベース スナップショットから元に戻すおよび強制的に WITH NO_LOG または TRUNCATE_ONLY オプション (これは SQL Server 2008 には使用できません) を使用して、ログを消去します。 実行する別の (大きいフォント可能性があります) の完全バックアップを強制するよう、ログ バックアップ チェーンを中断する inadvisable は。

ログ バックアップ チェーンは、完全バックアップに拡大は必ずしも必要はありません復旧中にすべてのログ バックアップを復元します。 行った場合、完全バックアップ、および水曜日の夜、日曜の夜、以降のすべての 30 分のログ バックアップと日曜の夜に言う金曜日障害発生後データベースを復元し使えます水曜日の完全バックアップと以降のすべてのログ バックアップまで移動することがなく水曜日夜日曜の夜の完全バックアップに戻します。 (マイクロソフト系列構成される資料の第 2 は隊形深いここ。)

ログのバックアップには、トランザクション ログのサイズを管理する必要がもあります。 完全または一括ログ復旧モデルで、ログのバックアップが実行されるまで (どのようなログのクリア方法の詳細については、2 月、記事を参照)、ログ ファイルのコントロールからの成長を防止する定期的なログのバックアップを実行しなければため、ログは消去されません。 ログをオフにできない場合、ログは領域がなくなるまで拡張されます。 そのため、ポイント-日時の復旧ログのバックアップを使用するしたくない場合、単純復旧モデルにして、完全または一括ログ復旧モデルを使用しない最も簡単なオプションは。 これについて、ブログの投稿で詳しく説明" 適切なトランザクション ログのサイズ管理の重要性."

ログをいくつかの操作として実行する最低限-ログ記録操作をページの割り当てのみが記録されるデータの実際の挿入されませんによってパフォーマンスを向上させるのには特殊なケースがあります。 これはパフォーマンスが向上一括ロードなどの操作のしできるインデックスを再構築します。 このような場合は、操作に関するすべていないが記録されます、ので、ログのバックアップ レコード、操作を完全に再生するための情報を含まない。 その場合は、できます復元と回復可能性がありますしくみための十分な情報がない場合

その答えは一部データが、最小限のログに記録の操作を次の最初のログ バックアップが含まれてもいるです。 前述した差分のビットマップと同様、最小限のログに記録ビットマップ (一括変更マップとも呼ばれます) と呼ばれる別のビットマップがあります。 このビットマップ追跡最小限記録操作のためのデータ ファイルのどのエクステントが変更されました。

最小限記録の操作を次のログ バックアップはこれらのビットマップをスキャンしもその変更としてマークされているデータ エクステントをバックアップします。 これらのビットマップがスキャン後に消去されます。 つまり、ログのバックアップが、ログのバックアップが復元された場合、データベース内に、最低でもログに記録操作の影響を完全に再生するための情報。 ところ、ひねりただし: が何もそのログのバックアップ、特定のデータ範囲が変更されたときというのです。 対象期間の時間の末尾以外の時間内の任意の位置にも、最小ログ操作からデータを含む、ログ バックアップを復元できませんように (または、ログのバックアップがから復元しているログ バックアップ チェーンの一部である場合だけ、)。 そのため、パフォーマンスの向上を取得できます、一括ログ復旧モデルに切り替えたときに、必要があります変更する必要に一時的な操作として)、バッチ処理を向上させるだけして完全に切り替えるし、ログ バックアップをできるだけ早く実行する必要があります、バッチ処理が完了します。

データ ファイルの破損を障害発生後、バックアップ、ログを許可する特別なケース ログ バックアップもあります。 これは、尾部の-、-ログ (またはログ末尾の) のバックアップを場所、データ ファイルが破損しているまたはことができます破棄しますが、障害ポイントまでに至るすべてのトランザクション ログをバックアップできます呼び出されます。 これにより、最小限の作業が失われる (最新の回復と呼びます)、データベースが後に復元されたとき、ただし、サポートされて、データベースは、完全復旧モデルで実行する場合にのみです。 これらの詳細および最小ログ操作に制限は、Books Online のトピックで確認できます" 登録ログのバックアップ." 最初の画面では、この記事に付属のキャストは尾部-の-、-ログのバックアップを示す通知を示しています。

バージョンの SQL Server 2005 の前に SQL Server は、トランザクション ログのバックアップ実行できなかったデータベース全体または差分データベース バックアップと同時に) は、データベース レベルのバックアップを完了するまでブロックされます。 ファイルとファイル グループ ベースのバックアップをブロックするログのバックアップを行いません。 ファイルとファイル グループ バックアップの回復プロセスを複雑この中に、付けたに利点でブロックしていないログのバックアップ。 SQL Server 2005 では (コンポーネント) にかかわらずすべての完全および差分のバックアップと同じ方法で操作します。 動作は、同時実行トランザクション ログのバックアップが完了したら、ことが、完全なまで、トランザクション ログはオフまたは (つまり、ログが必要) の差分バックアップも完了に今すぐです。

バックアップ戦略の計画

3 種類のバックアップとそのしくみについての知識、できた説明する方法が配置するまとめてバックアップ戦略にします。

表示される一般的な質問は、バックアップ ストラテジの考え方を開始する方法です。 常にしたいバックアップ戦略の設計いけないことを言います。 復元戦略の設計する必要があります) ため、データを引き続き維持しながら、ダウンタイムはできるだけ小さくの障害に備えてできるだけ復元することができます。 出力が作業した後必要などのようなバックアップ、復元を実行できるようにする機能します。 言い換えると、バックアップ計画する必要がありますできます、回復時の目的 (RTO) と回復ポイント目標 (RPO) を満たします。

完全バックアップのみを含む戦略と多少復元を実行できる操作で制限しています。 基本的に、 図 2 で、それぞれの完全バックアップの時刻に復元できるのみ。 障害土曜日 23時 59分で発生する場合、次回の完全バックアップがスケジュールされて、直前に、前回の完全バックアップ以降のすべての作業が失われます。 このような理由から、データの損失を回避できるならないし、データを再作成することはできません、ログのバックアップも含まれています、 図 3 に示すように。

fig02.gif

図 2 の 完全バックアップのみがバックアップ計画

fig03.gif

図 3 完全とログのバックアップのバックアップ計画

ログのバックアップは 30 分ごとに実行されていることとします。 すべてのバックアップが利用可能な限り、データベースを時間内の任意の位置に復元できることがつまり。 ただし、これができない最適な方法。 場合障害発生 23時 59分で土曜日にこのインプレース方針を採用しますか。 尾部-の-、-ログ バックアップ受け取りし復元を開始するにはまず挙げられます。

までデータベースを復元 (つまり 1 日、および土曜日 47 あたり 48 ログのバックアップと、尾部-の-ログのバックアップの 6 日間の) 最後の日曜日の完全バックアップと 336 ログのバックアップを復元、障害のポイントは意味します。 どの程度チャーンに応じてがデータベースに膨大な容量を再生する非常に長い時間がかかるトランザクション ログのある 1 週間。 明確にない、最適な復元戦略などもこれは、一般的な戦略がフィールドに表示します。 このような戦略がある場合確認ここことまで実行しての障害に備えて、RTO を満たすことができるかどうかがわかるように、復元を行うしてください。

この問題を緩和するいくつかの方法はより頻繁に完全バックアップを使用。 — がこれら大きすぎる、毎日をたとえばかかる場合があります。 のみ、前回の完全バックアップ以降に変更が、データを含む、差分のバックアップを使用する場合はします。 図 4 にはその戦略を示します例の続き。

fig04.gif

図 4 完全、ログ、および差分バックアップでバックアップ計画

この戦略では、土曜日 23時 59分で、障害からの回復は、はるかに高速です。 差分バックアップは累積的な) ため、復元戦略は、日曜日の完全バックアップ、00時 00分の土曜日まで差分バックアップ、および土曜日からすべてのログのバックアップ。 前に、そのすべてのログのバックアップをスキップできます、すべての復元のネット-結果と同じログ バックアップと差分バックアップに含まれていることを意味土曜日 00時 00分から差分のバックアップします。

この、非常に単純かつ例例ですが各バックアップの種類の利点を明確に示します。 バックアップ戦略を設計した、確認、必要な復元を実行できることを確認するテストします。

ここで例顧客面数年に戻るを学習すること。 顧客が破損しているデータベースとゼロ データの損失を回復したいとします。 バックアップを使用するたがらないおり、データベースのコピーで修復を実行しようとしましたにそのバックアップを使用して強制的にデータを削除する必要があります。 わかりましたがいた 1 月から完全バックアップとログのバックアップを 4 月をすべて half-hour-5, 000 を超えるバックアップ テープすべてと合計に! 私はいる、目をローリングして確認がでしたファクトで、3 日にかかったただし、「はもちろん、機能していない」を考えて! 優れたバックアップ戦略が、顧客と考えられて-完全復旧モデルとログのバックアップなど、バックアップ戦略を希望する復元を行う許可しなかった。

バックアップの整合性

バックアップを持つこといる破損から復元するときに発見した場合のポイントのありません。 もちろん、バックアップの有効性は別のサーバーを復元することが SQL Server 2005 での新機能が導入されてをチェックするによってバックアップの整合性をできる最適な方法は実際にそれらを復元することがなく実行されるを調べます。 任意のさまざまな) のバックアップを取るときとチェックサムのオプション使用できます。

これにより、全体のバックアップ ストリーム、バックアップ自体に格納されている上、チェックサム作成されます。 原因となるデータベース ページ チェックサムを有効になっているは、バックアップは、完全または差分、[このオプションもあります、バックアップ処理は、ページを読み取るようにテストされるすべての既存のページ チェックサム。 不良ページ チェックサムが見つかった場合は、バックアップ操作は失敗します。 これは、誤って既に何らかの理由で破損しているデータベースのバックアップの優れた防御提供します。 (することができます詳細についてページのチェックサムの「上位のヒントの有効なデータベース メンテナンス」記事で 2008 年 8 月から。)

バックアップが完了後、次のようなコマンドを使用検証できます。

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

全体のバックアップのストリームを介して、チェックサムを再計算をバックアップに格納される 1 つと比較します。 完全および差分バックアップをそれがもテスト ページで、ページのチェックサム バックアップにします。 問題が見つかった場合わかりますそのバックアップが何らかの理由で破損しています。

当然は、例外があります、ルールに (だけたとえば修復を実行するを実行しては、データベースのコピーの) 場合に破損しているデータベースをバックアップ先があります。 その場合は、バックアップで CONTINUE_AFTER_ERROR オプションを使用して完了を強制的にできます。

[詳細をバックアップの検証を確認することができます。 ブログでバックアップの検証についてこの記事に付属キャスト 2 番目の画面でのバックアップの検証の一部を示す通知もウォッチ.

結果

任意の複雑なトピックと同様多数のバックアップをカバーする領域がなかったの領域はありますが一部の深いについてオンライン ブックとブログ リンクにについて説明できる基礎については、これで。 Books Online で起動する方法は、トピック" バックアップの概要 (SQL Server)." 開始できます、筆者のブログには バックアップ/復元のカテゴリ.

考えを 1 つの領域が conspicuous でその休暇はバックアップの圧縮します。 説明はカバー、SQL Server 2008 でのすべての新しい圧縮テクノロジの記事の年の後半これは意図的です。 間、Books Online を参照して、チェックアウトできます」 バックアップの圧縮 (SQL Server)"ともに 筆者のブログ.

3 つの箇条書きでここまでの合計にあった場合、なります。

  • バックアップを確認します。
  • 有効なバックアップを確認します。
  • 右のバックアップを確認します。

言い換えるがバックアップ行う場合、データベースを復元するにを実行何か、バックアップは、必要なし、バックアップから復元できます確認わかってように RPO、RTO を満たす。

次の記事で、バックアップから復元、異なる種類の復元操作とそのしくみを含む、複数のバックアップ、および部分的なデータベースの可用性からの復元に関するすべてについて説明します。

間、およびとして、常に、フィードバックや質問が削除する行 Paul@SQLskills.com で。

Paul 南 Randal は、管理するディレクターの SQLskills.com、SQL Server の MVP、および Microsoft の [地域のディレクターです。 SQL Server ストレージ エンジン チームの Microsoft 1999 から 2007年に働いて。 Paul は SQL Server 2005 の DBCC CHECKDB または修復を記述し、SQL Server 2008 の開発中に、コア ストレージ エンジンに担当でした。 Paul は、専門家で障害回復、高可用性、およびデータベース メンテナンスはであり、世界のカンファレンスで定期的に発表です。 彼のブログで SQLskills.com/blogs/paul.