SQL Server のバックアップと復元のストラテジの概要
SQL Server バックアップを作成する目的は、破損したデータベースを復旧できるようにすることです。ただし、データのバックアップと復元は、特定の環境向けにカスタマイズし、使用可能なリソースと連動させる必要があります。したがって、信頼性が確保された状態でバックアップと復元を使用して復旧するには、バックアップと復元のストラテジが必要です。バックアップと復元のストラテジ設計が良ければ、特定のビジネス要件を考慮しながら、データの可用性を最大にし、データ損失を最小限に抑えることができます。
.gif "重要な注意事項") 重要 |
|---|
データベースとバックアップは異なるデバイスに置いてください。そうしないと、データベースを置いているデバイスに障害が発生した場合、バックアップも使用できなくなります。データとバックアップを異なるデバイスに置くと、バックアップの書き込みでもデータベースの運用でも I/O パフォーマンスが向上します。 |
バックアップと復元のストラテジには、バックアップに関する部分と復元に関する部分があります。ストラテジで扱うバックアップ部分では、バックアップの種類と頻度、バックアップに必要なハードウェアの性質と速度、バックアップのテスト方法、およびバックアップ メディアの保管場所と保管方法 (セキュリティ上の考慮事項も含む) を定義します。ストラテジで扱う復元部分では、復元の実行責任者と、データベースの可用性とデータ損失の最小化という目標を達成するためにどのように復元を実行するのかを定義します。バックアップと復元の手順をドキュメント化し、そのドキュメントを運用手順書に含めて保管することをお勧めします。
バックアップと復元について効果的なストラテジをデザインするには、慎重に計画、実装、およびテストする必要があります。テストは必ず行ってください。復元ストラテジに含まれるすべての組み合わせでバックアップを正常に復元できるようになって初めて、バックアップ ストラテジは完成します。さまざまな要因を検討する必要があります。その一部を次に示します。
組織がそのデータベースに求める生産目標。特に、可用性とデータ損失からの保護に関する要件。
各データベースの性質。サイズ、使用パターン、内容の性質、保持しているデータの要件など。
リソースについての制約。ハードウェア、スタッフ、バックアップ メディアを保管する場所、保管されたメディアの物理的なセキュリティなど。
.gif "注意")
注SQL Server のディスク上ストレージ形式は、64 ビット環境でも 32 ビット環境でも同じです。このため、バックアップと復元は 32 ビット環境と 64 ビット環境の間でも機能します。一方の環境で実行中のサーバー インスタンスで作成したバックアップは、他方の環境で実行中のサーバー インスタンスで復元できます。
バックアップおよび復元に対する復旧モデルの影響
バックアップ操作および復元操作は、復旧モデルのコンテキストで発生します。復旧モデルは、トランザクション ログの管理方法を制御するデータベース プロパティです。また、データベースの復旧モデルでは、そのデータベースでサポートされるバックアップの種類および復元シナリオが判断されます。通常、データベースは単純復旧モデルまたは完全復旧モデルを使用します。完全復旧モデルを補完するには、一括操作を行う前に一括ログ復旧モデルに切り替えます。これらの復旧モデルの概要とトランザクション ログの管理への影響については、「復旧モデルとトランザクション ログの管理」を参照してください。
データベースに対する復旧モデルの最善の選択は、ビジネス要件によって異なります。トランザクション ログの管理を不要にし、バックアップと復元を簡単にするには、単純復旧モデルを使用します。作業損失の可能性を最小に抑えるには、管理のオーバーヘッドが発生するという犠牲を払っても、完全復旧モデルを使用します。バックアップおよび復元に対する復旧モデルの影響については、次のトピックを参照してください。
バックアップ ストラテジの設計
特定のデータベースに対するビジネス要件を満たす復旧モデルを選択した後、対応するバックアップ ストラテジを計画して実装する必要があります。最適なバックアップ ストラテジはさまざまな要因に依存しますが、その中でも以下の要因が特に重要です。
アプリケーションがデータベースにアクセスする必要があるのは 1 日に何時間か。
オフピーク時間が予測できる場合は、その時間にデータベースの完全バックアップをスケジュールすることをお勧めします。
変更や更新はどの程度の頻度で行われるか。
変更が頻繁に行われる場合は、次のことを考慮してください。
単純復旧モデルでは、データベースの完全バックアップの合間に差分バックアップをスケジュールすることを検討します。差分バックアップは、データベースの最後の完全バックアップ以降の変更だけをキャプチャします。
完全復旧モデルでは、ログ バックアップを頻繁に行うようスケジュールする必要があります。完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。
変更は、データベースの一部分でのみ行われるか、データベースの大部分で行われるか。
ファイルまたはファイル グループの一部分に変更が集中する大規模なデータベースでは、部分バックアップまたはファイル バックアップが有効です。詳細については、「部分バックアップ」および「ファイルの完全バックアップ」を参照してください。
データベースの完全バックアップにはどの程度のディスク領域が必要か。
詳細については、このトピックの「データベースの完全バックアップのサイズの推計」を参照してください。
データベースの完全バックアップのサイズの推計
バックアップと復元のストラテジを実装する前に、データベースの完全バックアップで使用するディスク領域を推計する必要があります。バックアップ操作では、データベース内のデータをバックアップ ファイルにコピーします。バックアップにはデータベース内の実際のデータだけが入っており、未使用の領域は入っていません。そのため、通常、バックアップはデータベースそのものよりも小さくなります。データベースの完全バックアップのサイズは、sp_spaceused システム ストアド プロシージャを使用して推計することができます。詳細については、「sp_spaceused (Transact-SQL)」を参照してください。
バックアップのスケジュール
必要なバックアップの種類、および各種類のバックアップを実行する必要のある頻度を決定した後、データベースに対するデータベース メンテナンス プランの一部として、定期的なバックアップをスケジュールすることをお勧めします。メンテナンス プランと、データベース バックアップおよびログ バックアップ用のメンテナンス プランの作成方法については、「データベースのメンテナンス (データベース エンジン)」および「メンテナンス プラン ウィザード」を参照してください。
メンテナンス プランを作成するには
ジョブを作成してスケジュールするには
バックアップのテスト
バックアップをテストするまでは、復元ストラテジが完成したことにはなりません。データベースのコピーをテスト システムに復元することで、各データベースに対するバックアップ ストラテジを十分にテストすることが重要です。使用するすべての種類のバックアップの復元をテストする必要があります。
データベースごとに操作マニュアルを用意しておくことをお勧めします。この操作マニュアルには、バックアップの場所、バックアップ デバイス名 (ある場合)、およびテスト バックアップの復元に必要な時間を記載しておきます。