適用対象:
SQL Server
この記事では、SQL Server データベースのバックアップの利点について説明し、基本的なバックアップと復元の用語について説明し、SQL Server のバックアップと復元に関するバックアップと復元の戦略と、SQL Server のバックアップと復元のセキュリティに関する考慮事項について説明します。
この記事では SQL Server のバックアップについて説明します。 SQL Server データベースをバックアップする具体的な手順については、「バックアップの作成」を参照してください。
SQL Server のバックアップと復元コンポーネントは、SQL Server データベースに格納されている重要なデータを保護するために不可欠なセーフガードを提供します。 致命的なデータ損失のリスクを最小限に抑えるには、データベースを定期的にバックアップして、データの変更を保持する必要があります。 十分に計画されたバックアップおよび復元戦略は、さまざまな障害が原因で発生するデータ損失からデータベースを保護します。 一連のバックアップの復元とデータベースの回復を実行することでご自分の戦略をテストして、災害に効率的に対応するための準備を整えてください。
バックアップを格納するローカル ストレージに加えて、SQL Server では、バックアップおよび Azure Blob Storage からの復元がサポートされます。 詳細については、「 Microsoft Azure Blob Storage を使用した SQL Server のバックアップと復元」を参照してください。 Azure Blob Storage を使用して格納したデータベース ファイルの場合、SQL Server 2016 (13.x) では、Azure スナップショットを使用してほぼ瞬時にバックアップし、迅速に復元するためのオプションが用意されています。 詳細については、「 Azure のデータベース ファイルのファイル スナップショット バックアップ」を参照してください。 Azure では、Azure VM で実行されている SQL Server 向けのエンタープライズ クラスのバックアップ ソリューションも提供されています。 フル マネージドの バックアップ ソリューションで、Always On 可用性グループ、長期保有、特定の時点に復旧、一元的な管理と監視がサポートされています。 詳細については、「 Azure VM での 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 形式を使用します。 詳細については、「 Microsoft Azure Blob Storage を使用した SQL Server のバックアップと復元」を参照してください。
バックアップ メディア (backup media)
バックアップの書き込み先となる 1 つまたは複数のテープまたはディスク ファイル。
データ バックアップ (data backup)
データのバックアップ。データベース全体 (データベース バックアップ)、データベースの一部 (部分バックアップ)、または一連のデータ ファイルやファイルグループ (ファイル バックアップ) の形式で存在します。
データベース バックアップ (database backup)
データベースのバックアップ。 データベースの完全バックアップは、バックアップが完了した時点のデータベース全体を表します。 差分データベース バックアップには、最新の完全バックアップ以降に行われたデータベースへの変更のみが含まれます。
差分バックアップ (differential backup)
データベース全体、データベースの一部、または一連のデータ ファイル (またはファイル グループ) の最新の完全バックアップ (差分ベース) をベースとし、その差分ベース以後に変更されたデータのみを含んだデータ バックアップ。
完全バックアップ (full backup)
特定のデータベース (または一連のファイルやファイル グループ) 内のデータがすべて含まれ、さらに、データを復旧するために必要なログも含んだデータ バックアップ。
ログ バックアップ (log backup)
以前のログ バックアップ (完全復旧モデル) でバックアップされなかったすべてのログ レコードを含むトランザクション ログのバックアップ。
recover
安定し一貫した状態にデータベースを戻すこと。
復旧 (recovery)
データベースをトランザクションの一貫性が保たれた状態にする、データベース起動時または RESTORE WITH RECOVERY 時のフェーズ。
復旧モデル (recovery model)
データベースのトランザクション ログのメンテナンスを制御するデータベース プロパティ。 単純、完全、一括ログの 3 つの復旧モデルがあります。 データベースの復旧モデルによって、バックアップと復元の要件が決まります。
復元 (restore)
指定した SQL Server バックアップから指定したデータベースにすべてのデータページとログ ページをコピーし、ログに記録された変更を適用してデータを転送することで、バックアップに記録されたすべてのトランザクションをロールフォワードするマルチフェーズ プロセス。
バックアップと復元の方法
データのバックアップと復元は、特定の環境向けにカスタマイズし、使用可能なリソースと連動させる必要があります。 そのため、復旧のためにバックアップと復元を確実に使用するには、バックアップと復元の戦略が必要です。 適切に設計されたバックアップと復元の戦略では、バックアップの維持と保存のコストを考慮しながら、最大データ可用性と最小限のデータ損失に関するビジネス要件のバランスが取られます。
バックアップと復元のストラテジには、バックアップに関する部分と復元に関する部分があります。 この戦略のバックアップ部分では、バックアップの種類と頻度、必要なハードウェアの性質と速度、バックアップのテスト方法、バックアップ メディアの保存場所と方法 (セキュリティに関する考慮事項を含む) を定義します。 この戦略の復元部分では、復元を実行する担当者、データベースの可用性とデータ損失の最小化の目標を満たすために復元を実行する方法、復元のテスト方法を定義します。
バックアップと復元について効果的なストラテジをデザインするには、慎重に計画、実装、およびテストする必要があります。 テストが必要です。復元戦略に含まれるすべての組み合わせでバックアップを正常に復元し、復元されたデータベースの物理的な整合性をテストするまで、バックアップ戦略はありません。 さまざまな要因を検討する必要があります。 これには以下が含まれます。
運用データベースに関する組織の目標、特に可用性とデータの損失や損傷からデータを保護するための要件。
各データベースの性質。サイズ、使用パターン、内容の性質、保持しているデータの要件など。
ハードウェア、担当者、バックアップ メディアを格納するための領域、格納されているメディアの物理的なセキュリティなどのリソースに対する制約。
ベスト プラクティスの推奨事項
バックアップ操作または復元操作を実行するアカウントには、必要以上の特権を付与しないでください。 特定のアクセス許可の詳細については、バックアップと復元を確認してください。 バックアップは暗号化し、可能であれば圧縮することをおすすめします。
セキュリティ確保のため、バックアップ ファイルには適切な規則に従う拡張子が必要です。
- データベースのバックアップ ファイルには
.BAKの拡張子が必要です。 - ログのバックアップ ファイルには
.TRNの拡張子が必要です。
別のストレージを使用する
重要
データベースのバックアップは、必ずデータベース ファイルとは物理的に別の場所または別のデバイスに置いてください。 データベースを格納する物理ドライブが誤作動またはクラッシュした場合、復旧できるかできないかは、復元を実行するためにバックアップを格納した別のドライブまたはリモート デバイスにアクセスできるかできないかで決まります。 同じ物理ディスク ドライブから論理ボリュームまたはパーティションを複数作成できることを覚えておきましょう。 バックアップの保存場所を選ぶ前に、ディスク パーティションと論理ボリュームのレイアウトについて慎重に検討してください。
適切な復旧モデルを選択する
バックアップ操作および復元操作は、復旧モデルのコンテキストで発生します。 復旧モデルは、トランザクション ログの管理方法を制御するデータベース プロパティです。 したがって、データベースの復旧モデルによって、データベースでサポートされるバックアップと復元シナリオの種類と、トランザクション ログ バックアップのサイズが決まります。 通常、データベースでは、単純復旧モデルまたは完全復旧モデルが使用されます。 一括操作の前に一括ログ復旧モデルに切り替えることで、完全復旧モデルを拡張できます。 これらの復旧モデルの概要と、それらがトランザクション ログ管理に与える影響については、 トランザクション ログを参照してください。
データベースに対する復旧モデルの最善の選択は、ビジネス要件によって異なります。 トランザクション ログの管理を不要にし、バックアップと復元を簡単にするには、単純復旧モデルを使用します。 管理オーバーヘッドのコストで作業損失の露出を最小限に抑えるには、完全復旧モデルを使用します。 一括ログ記録操作中にログ サイズへの影響を最小限に抑えるのと同時にこれらの操作の復旧を可能にするには、一括ログ復旧モデルを使用します。 バックアップと復元に対する復旧モデルの影響については、「バックアップの 概要」を参照してください。
バックアップ戦略を設計する
特定のデータベースのビジネス要件を満たす復旧モデルを選択したら、対応するバックアップ戦略を計画して実装する必要があります。 最適なバックアップ ストラテジはさまざまな要因に依存しますが、その中でも以下の要因が特に重要です。
アプリケーションがデータベースにアクセスする必要があるのは 1 日に何時間か。
予測可能なオフピーク期間がある場合は、その期間のデータベースの完全バックアップをスケジュールすることをお勧めします。
変更や更新はどの程度の頻度で行われるか。
変更が頻繁に行われる場合は、次のことを考慮してください。
単純復旧モデルでは、データベースの完全バックアップの合間に差分バックアップをスケジュールすることを検討します。 差分バックアップは、データベースの最後の完全バックアップ以降の変更だけをキャプチャします。
完全復旧モデルでは、ログ バックアップを頻繁に行うようスケジュールする必要があります。 完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。
変更は、データベースの一部分でのみ行われるか、データベースの大部分で行われるか。
ファイルまたはファイル グループの一部分に変更が集中する大規模なデータベースでは、部分バックアップまたはフル ファイル バックアップが有効です。 詳細については、「 部分バックアップ (SQL Server) 」および「 完全ファイル バックアップ (SQL Server)」を参照してください。
データベースの完全バックアップにはどの程度のディスク領域が必要か。
これまで、どの程度ビジネスでバックアップを維持する必要があったか。
アプリケーションやビジネス要件のニーズに応じて、適切なバックアップ スケジュールが設定されていることを確認します。 障害の発生時点まですべてのデータを再生成する方法がない限り、バックアップが古くなるにつれてデータ損失のリスクが高くなります。 ストレージ リソースの制限により古いバックアップを破棄することを選択する前に、これまで回復性が必要かどうかを検討してください。
データベースの完全バックアップのサイズの推計
バックアップと復元のストラテジを実装する前に、データベースの完全バックアップで使用するディスク領域を推計する必要があります。 バックアップ操作では、データベース内のデータをバックアップ ファイルにコピーします。 バックアップにはデータベース内の実際のデータだけが入っており、未使用の領域は入っていません。 そのため、通常、バックアップはデータベースそのものよりも小さくなります。
sp_spaceused システム ストアド プロシージャを使用して、データベースの完全バックアップのサイズを見積もることができます。 詳細については、「sp_spaceused(Transact-SQL)」を参照してください。
バックアップのスケジュール
バックアップ操作の実行は、実行中のトランザクションに対する影響を最小限に抑えます。そのため、通常の操作中にバックアップ操作を実行できます。 実稼働ワークロードへの影響は最小限にとどめて SQL Server バックアップを実行できます。
バックアップ中のコンカレンシーの制限については、「 バックアップの概要 (SQL Server)」を参照してください。
必要なバックアップの種類、および各種類のバックアップを実行する必要のある頻度を決定した後、データベースに対するデータベース メンテナンス プランの一部として、定期的なバックアップをスケジュールすることをお勧めします。 メンテナンス プランと、データベース バックアップおよびログ バックアップ用のメンテナンス プランの作成方法については、「 Use the Maintenance Plan Wizard」を参照してください。
バックアップをテストする
バックアップをテストするまで、復元戦略はありません。 データベースのコピーをテスト システムに復元することで、各データベースのバックアップ戦略を徹底的にテストすることが非常に重要です。 使用するすべての種類のバックアップの復元をテストする必要があります。 また、バックアップを復元したら、データベースの DBCC CHECKDB を使用してデータベースの整合性チェックを実行して、バックアップ メディアが破損していないことを検証することをお勧めします。
メディアの安定性と一貫性を確認する
バックアップ ユーティリティによって提供される検証オプション (BACKUP T-SQL コマンド、SQL Server メンテナンス プラン、バックアップ ソフトウェアまたはソリューションなど) を使用します。 例については、 RESTORE ステートメント - VERIFYONLY を参照してください。
BACKUP CHECKSUMなどの高度な機能を使用して、バックアップ メディア自体の問題を検出します。 詳細については、「 バックアップと復元中に発生する可能性のあるメディア エラー 」を参照してください (SQL Server)
ドキュメントのバックアップ/復元戦略
バックアップと復元の手順をドキュメント化し、そのドキュメントを運用手順書に含めて保管することをお勧めします。 また、データベースごとに操作マニュアルを用意しておくことをお勧めします。 この操作マニュアルには、バックアップの場所、バックアップ デバイス名 (ある場合)、およびテスト バックアップの復元に必要な時間を記載しておきます。
XEvent を使用して進行状況を監視する
バックアップと復元の操作は、関連するデータベースのサイズと処理の複雑さによって、相当の時間がかかる場合があります。 いずれかの操作で問題が発生した場合は、 backup_restore_progress_trace 拡張イベントを使用して、進行状況をライブで監視できます。 拡張イベントの詳細については、「 拡張イベントの概要」を参照してください。
警告
backup_restore_progress_trace拡張イベントを使用すると、パフォーマンスの問題が発生し、大量のディスク領域が消費される可能性があります。 使用するのは短時間にし、慎重に実行し、実稼働環境で実装する前には徹底的なテストを行ってください。
-- Create the backup_restore_progress_trace extended event session
CREATE EVENT SESSION [BackupRestoreTrace] ON SERVER
ADD EVENT sqlserver.backup_restore_progress_trace
ADD TARGET package0.event_file(SET filename=N'BackupRestoreTrace')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
-- Start the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = start;
GO
-- Stop the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = stop;
GO
拡張イベントからの出力例
バックアップ タスクの詳細
バックアップ デバイスとバックアップ メディアの操作
バックアップを作成する
Note
部分バックアップまたはコピーのみのバックアップの場合は、Transact-SQL BACKUP ステートメントを PARTIAL または COPY_ONLY オプションと共に使用する必要があります。