次の方法で共有


SQL Server データベースのバックアップと復元

このトピックでは、SQL Server データベースのバックアップの利点、基本的なバックアップと復元の用語について説明し、バックアップと復元のSQL Serverとセキュリティに関する考慮事項について説明SQL Server。

SQL Server のバックアップと復元コンポーネントは、 SQL Server データベースに格納されている大切なデータを保護するうえで不可欠な保護対策を提供します。 致命的なデータ損失のリスクを最小限に抑えるには、データベースを定期的にバックアップして、データの変更を保持する必要があります。 十分に計画されたバックアップおよび復元戦略は、さまざまな障害が原因で発生するデータ損失からデータベースを保護します。 一連のバックアップの復元とデータベースの回復を実行することでご自分の戦略をテストして、災害に効率的に対応するための準備を整えてください。

バックアップを格納するローカル ストレージに加えて、SQL Server では、バックアップおよび Azure Blob Storage サービスからの復元がサポートされます。 詳細については、「 Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」をご覧ください。

メリット

  • SQL Server データベースをバックアップしたり、既存のバックアップの復元テストを実行したりできるほか、離れた安全な場所にバックアップのコピーを保管することによって、致命的な損失からデータを保護することができます。

    重要

    これは、SQL Server データを確実に保護する唯一の方法です。

    データベースの有効なバックアップがあれば、次に示したようなさまざまな障害からデータを復旧することができます。

    • メディアの障害

    • ユーザー エラー (テーブルの誤削除など)

    • ハードウェア障害 (ディスク ドライブの損傷や、復旧の可能性のないサーバー障害など)

    • 自然災害。 Azure Blob Storage サービスへの SQL Server バックアップを使用すると、オンプレミスの場所に影響する自然災害が発生した場合に使用できるように、オンプレミスの場所とは異なるリージョンにオフサイト バックアップを作成できます。

  • さらに、データベースのバックアップは、あるサーバーから別のサーバーにデータベースをコピーしたり、可用性グループまたはデータベース ミラーリングAlways On設定したり、アーカイブしたりするなどの日常的な管理目的に役立ちます。

コンポーネントおよび概念

バックアップ (back up) (動詞)
SQL Server データベースまたはそのトランザクション ログからバックアップ デバイス (ディスクなど) にデータまたはログ レコードをコピーすることによって、データ バックアップまたはログ バックアップを作成します。

バックアップ (backup) (名詞)
障害の発生後、データの復元と復旧に使用できるデータのコピー。 データベースのバックアップを使用して、コピー (データベース) を新しい場所に復元することもできます。

バックアップ デバイス (backup device)
SQL Server バックアップの書き込みと復元に使用されるディスクまたはテープ デバイス。 SQL Server のバックアップは、Azure Blob Storage サービスに書き込むこともできます。バックアップ先とバックアップ ファイルの名前を指定するには URL 形式を使用します。 詳細については、「 Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」をご覧ください。

バックアップ メディア (backup media)
バックアップの書き込み先となる 1 つまたは複数のテープまたはディスク ファイル。

データ バックアップ (data backup)
データのバックアップ。データベース全体 (データ バックアップ)、データベースの一部 (部分バックアップ)、または一連のデータ ファイルやファイル グループ (ファイル バックアップ) の形式で存在します。

データベース バックアップ (database backup)
データベースのバックアップ。 データベースの完全バックアップは、バックアップが完了した時点のデータベース全体を表します。 差分データベース バックアップには、最新の完全バックアップ以降に行われたデータベースへの変更のみが含まれます。

差分バックアップ (differential backup)
データベース全体、データベースの一部、または一連のデータ ファイル (またはファイル グループ) の最新の完全バックアップ (差分ベース) をベースとし、その差分ベース以後に変更されたデータのみを含んだデータ バックアップ。

完全バックアップ (full backup)
特定のデータベース (または一連のファイルやファイル グループ) 内のデータがすべて含まれ、さらに、データを復旧するために必要なログも含んだデータ バックアップ。

ログ バックアップ (log backup)
前回のログ バックアップでバックアップされなかったすべてのログ レコードを含むトランザクション ログのバックアップ (完全復旧モデル)。

recover
安定し一貫した状態にデータベースを戻すこと。

復旧 (recovery)
データベースをトランザクションの一貫性が保たれた状態にする、データベース起動時または RESTORE WITH RECOVERY 時のフェーズ。

復旧モデル (recovery model)
データベースのトランザクション ログのメンテナンスを制御するデータベース プロパティ。 復旧モデルの種類は、単純、完全、および一括ログの 3 種類です。 データベースのバックアップと復元の要件は、その復旧モデルによって決まります。

復元
データを直近の状態まで戻す複数フェーズから成る処理。指定された SQL Server バックアップからすべてのデータおよびログ ページを指定されたデータベースにコピーするフェーズと、バックアップにログとして記録されているすべてのトランザクションをロールフォワード (ログに記録されている変更を適用) するフェーズとで構成されます。

バックアップと復元のストラテジの概要

データのバックアップと復元は、特定の環境向けにカスタマイズし、使用可能なリソースと連動させる必要があります。 したがって、信頼性が確保された状態でバックアップと復元を使用して復旧するには、バックアップと復元のストラテジが必要です。 バックアップと復元のストラテジ設計が良ければ、特定のビジネス要件を考慮しながら、データの可用性を最大にし、データ損失を最小限に抑えることができます。

重要

データベースとバックアップは異なるデバイスに置いてください。 そうしないと、データベースを置いているデバイスに障害が発生した場合、バックアップも使用できなくなります。 データとバックアップを異なるデバイスに置くと、バックアップの書き込みでもデータベースの運用でも I/O パフォーマンスが向上します。

バックアップと復元のストラテジには、バックアップに関する部分と復元に関する部分があります。 ストラテジで扱うバックアップ部分では、バックアップの種類と頻度、バックアップに必要なハードウェアの性質と速度、バックアップのテスト方法、およびバックアップ メディアの保管場所と保管方法 (セキュリティ上の考慮事項も含む) を定義します。 ストラテジで扱う復元部分では、復元の実行責任者と、データベースの可用性とデータ損失の最小化という目標を達成するためにどのように復元を実行するのかを定義します。 バックアップと復元の手順をドキュメント化し、そのドキュメントを運用手順書に含めて保管することをお勧めします。

バックアップと復元について効果的なストラテジをデザインするには、慎重に計画、実装、およびテストする必要があります。 テストは必ず行ってください。 復元ストラテジに含まれるすべての組み合わせでバックアップを正常に復元できるようになって初めて、バックアップ ストラテジは完成します。 さまざまな要因を検討する必要があります。 これらには、次のものが含まれます。

  • 組織がそのデータベースに求める生産目標。特に、可用性とデータ損失からの保護に関する要件。

  • 各データベースの性質。サイズ、使用パターン、内容の性質、保持しているデータの要件など。

  • リソースについての制約。ハードウェア、スタッフ、バックアップ メディアを保管する場所、保管されたメディアの物理的なセキュリティなど。

    注意

    SQL Serverディスク上のストレージ形式は、64 ビット環境と 32 ビット環境で同じです。 このため、バックアップと復元は 32 ビット環境と 64 ビット環境の間でも機能します。 一方の環境で実行中のサーバー インスタンスで作成したバックアップは、他方の環境で実行中のサーバー インスタンスで復元できます。

バックアップおよび復元に対する復旧モデルの影響

バックアップ操作および復元操作は、復旧モデルのコンテキストで発生します。 復旧モデルは、トランザクション ログの管理方法を制御するデータベース プロパティです。 また、データベースの復旧モデルでは、そのデータベースでサポートされるバックアップの種類および復元シナリオが判断されます。 通常、データベースは単純復旧モデルまたは完全復旧モデルを使用します。 完全復旧モデルを補完するには、一括操作を行う前に一括ログ復旧モデルに切り替えます。 これらの復旧モデルの概要と、それらがトランザクション ログ管理にどのように影響するかについては、「トランザクション ログ (SQL Server)」を参照してください。

データベースに対する復旧モデルの最善の選択は、ビジネス要件によって異なります。 トランザクション ログの管理を不要にし、バックアップと復元を簡単にするには、単純復旧モデルを使用します。 作業損失の可能性を最小に抑えるには、管理のオーバーヘッドが発生するという犠牲を払っても、完全復旧モデルを使用します。 バックアップと復元に対する復旧モデルの影響については、「バックアップの概要 (SQL Server)」を参照してください。

バックアップ ストラテジの設計

特定のデータベースに対するビジネス要件を満たす復旧モデルを選択した後、対応するバックアップ ストラテジを計画して実装する必要があります。 最適なバックアップ ストラテジはさまざまな要因に依存しますが、その中でも以下の要因が特に重要です。

  • アプリケーションがデータベースにアクセスする必要があるのは 1 日に何時間か。

    オフピーク時間が予測できる場合は、その時間にデータベースの完全バックアップをスケジュールすることをお勧めします。

  • 変更や更新はどの程度の頻度で行われるか。

    変更が頻繁に行われる場合は、次のことを考慮してください。

    • 単純復旧モデルでは、データベースの完全バックアップの合間に差分バックアップをスケジュールすることを検討します。 差分バックアップは、データベースの最後の完全バックアップ以降の変更だけをキャプチャします。

    • 完全復旧モデルでは、ログ バックアップを頻繁に行うようスケジュールする必要があります。 完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。

  • 変更は、データベースの一部分でのみ行われるか、データベースの大部分で行われるか。

    ファイルまたはファイル グループの一部分に変更が集中する大規模なデータベースでは、部分バックアップまたはファイル バックアップが有効です。 詳細については、「部分バックアップ (SQL Server)」および「完全ファイル バックアップ (SQL Server)」を参照してください。

  • データベースの完全バックアップにはどの程度のディスク領域が必要か。

    詳細については、このセクションの「データベースの完全バックアップのサイズの推計」を参照してください。

データベースの完全バックアップのサイズの推計

バックアップと復元のストラテジを実装する前に、データベースの完全バックアップで使用するディスク領域を推計する必要があります。 バックアップ操作では、データベース内のデータをバックアップ ファイルにコピーします。 バックアップにはデータベース内の実際のデータだけが入っており、未使用の領域は入っていません。 そのため、通常、バックアップはデータベースそのものよりも小さくなります。 データベースの完全バックアップのサイズは、 sp_spaceused システム ストアド プロシージャを使用して推計することができます。 詳細については、「 sp_spaceused (Transact-SQL)」を参照してください。

バックアップのスケジュール

バックアップの実行によって、実行中のトランザクションが受ける影響はわずかです。したがってバックアップは、通常の運用時に実行できます。 実稼働ワークロードへの影響は最小限にとどめて SQL Server バックアップを実行できます。

Note

バックアップ中のコンカレンシー制限の詳細については、「バックアップの概要 (SQL Server)」を参照してください。

必要なバックアップの種類、および各種類のバックアップを実行する必要のある頻度を決定した後、データベースに対するデータベース メンテナンス プランの一部として、定期的なバックアップをスケジュールすることをお勧めします。 メンテナンス プランと、データベース バックアップおよびログ バックアップ用のメンテナンス プランの作成方法については、「 Use the Maintenance Plan Wizard」を参照してください。

バックアップのテスト

バックアップをテストするまでは、復元ストラテジが完成したことにはなりません。 データベースのコピーをテスト システムに復元することで、各データベースに対するバックアップ ストラテジを十分にテストすることが重要です。 使用するすべての種類のバックアップの復元をテストする必要があります。

データベースごとに操作マニュアルを用意しておくことをお勧めします。 この操作マニュアルには、バックアップの場所、バックアップ デバイス名 (ある場合)、およびテスト バックアップの復元に必要な時間を記載しておきます。

Related Tasks

バックアップ ジョブのスケジュール設定

バックアップ デバイスとバックアップ メディアの操作

バックアップの作成

Note

部分バックアップまたはコピーのみのバックアップの場合は、それぞれ PARTIAL または COPY_ONLY オプションを指定して Transact-SQLBACKUP ステートメントを使用する必要があります。

SQL Server Management Studio の使用

Transact-SQL の使用

データ バックアップの復元

SQL Server Management Studio の使用

Transact-SQL の使用

トランザクション ログを復元する (完全復旧モデル)

SQL Server Management Studio の使用

Transact-SQL の使用

その他の復元タスク

Transact-SQL の使用

参照

Backup Overview (SQL Server)
復元と復旧の概要 (SQL Server)
BACKUP (Transact-SQL)
RESTORE (Transact-SQL)
Analysis Services データベースのバックアップと復元
フルテキスト カタログとフルテキスト インデックスのバックアップおよび復元
レプリケートされたデータベースのバックアップと復元
トランザクション ログ (SQL Server)
復旧モデル (SQL Server)
メディア セット、メディア ファミリ、およびバックアップ セット (SQL Server)