適用対象:
SQL Server
この記事では、SQL Serverデータベースのバックアップの利点を説明し、基本的なバックアップと復元の用語を紹介し、SQL Serverのバックアップおよび復元戦略とセキュリティ上の考慮事項を解説します。
注
この記事では SQL Server のバックアップについて説明します。 SQL Server データベースをバックアップする具体的な手順については、「バックアップの作成」を参照してください。
SQL Serverのバックアップ&リストアコンポーネントは、SQL Serverデータベースに保存された重要なデータの重要な保護策を提供します。 壊滅的なデータ損失のリスクを最小限に抑えるために、データの修正を保存するために定期的にデータベースをバックアップしてください。 よく計画されたバックアップと復元戦略は、さまざまな障害によるデータ損失からデータベースを守るのに役立ちます。 バックアップを復元し、データベースを復旧して、災害対応の準備を整えましょう。
ローカルストレージに加え、SQL ServerはAzure Blob Storageへのバックアップおよび復元もサポートしています。 詳細については、「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データベースのバックアップ、バックアップのテスト復元手順の実行、バックアップのコピーを安全なオフサイトに保存することで、壊滅的なデータ損失から身を守ることができます。 バックアップは、データを保護できる唯一の方法です。
データベースの有効なバックアップがあれば、次に示したようなさまざまな障害からデータを復旧することができます。
メディアの障害
ユーザー エラー (テーブルの誤削除など)
ハードウェア障害 (ディスク ドライブの損傷や、復旧の可能性のないサーバー障害など)
自然災害。 SQL Server Backup to Azure Blob Storageを使うことで、オンプレミスとは異なる地域にオフサイトバックアップを作成でき、自然災害でオンプレミスに影響を受けた場合に利用できます。
また、データベースのバックアップは、サーバー間でのデータベースのコピー、Always On 可用性グループやデータベース ミラーリングの設定、およびアーカイブなど、日常的な管理作業を行ううえでも便利です。
バックアップの用語集
バックアップと復元の方法
環境や利用可能なリソースに合わせてバックアップと復元戦略をカスタマイズしなければなりません。 信頼できる復旧にはバックアップと復元戦略が必要です。 よく設計された戦略は、最大のデータ可用性と最小限のデータ損失というビジネス要件と、バックアップの維持・保存コストとのバランスを取る必要があります。
バックアップと復元のストラテジには、バックアップに関する部分と復元に関する部分があります。 バックアップ部分では、バックアップの種類と頻度、必要なハードウェアの種類と速度、バックアップのテスト方法、バックアップメディアの保存場所と方法(セキュリティ上の考慮を含む)が定義されています。 復元部分では、誰が復元を実行するか、データベースの可用性と最小限のデータ損失を達成するための復元方法、復元のテスト方法を定義しています。
効果的なバックアップと復元戦略には、綿密な計画、導入、テストが必要です。 テストが必要です。 復元戦略に含まれるすべての組み合わせでバックアップを成功裏に復元し、復元した各データベースの物理的な整合性をテストするまで、バックアップ戦略は成立しません。 以下のようないくつかの要素を考慮してください:
運用データベースに関する組織の目標、特に可用性とデータの損失や損傷からデータを保護するための要件。
各データベースの性質。サイズ、使用パターン、内容の性質、保持しているデータの要件など。
ハードウェア、担当者、バックアップ メディアを格納するための領域、格納されているメディアの物理的なセキュリティなどのリソースに対する制約。
ベスト プラクティスの推奨事項
バックアップや復元操作を行うアカウントに必要以上の権限を与えないでください。 詳細については、 バックアップ と 復元 の詳細な権限をご参照ください。 データベースのバックアップを暗号化し、可能であれば圧縮してください。
バックアップの特定や管理を容易にするために、一貫したファイル拡張子を使いましょう。 SQL Serverはこれらの拡張機能を必須または強制しませんが、一貫性はバックアップファイルのアンチウイルス除外設定などの運用作業に役立ちます。 詳細については、「 SQL Server で動作するようにウイルス対策ソフトウェアを構成する」を参照してください。
- データベースのバックアップファイルは
.BAKの拡張子を持つべきです。 - ログのバックアップ ファイルには
.TRNの拡張子が必要です。
別々のストレージを使いましょう
データベースのバックアップは、データベースファイルとは別の物理的な場所や別のデバイスに配置してください。 データベースを保存する物理ドライブが故障またはクラッシュした場合、復旧はバックアップを保存した別のドライブやリモートデバイスにアクセスできるかどうかに依存します。 同じ物理ディスクドライブから複数の論理ボリュームやパーティションを作成できます。 バックアップのストレージ場所を選ぶ前に、ディスクパーティションと論理ボリュームのレイアウトをよく確認してください。
適切な復旧モデルを選択する
バックアップ操作および復元操作は、復旧モデルのコンテキストで発生します。 復旧モデルは、トランザクション ログの管理方法を制御するデータベース プロパティです。 したがって、データベースの回復モデルによって、そのデータベースがサポートするバックアップおよび復元のシナリオの種類と、トランザクション ログ バックアップのサイズが決まります。 通常、データベースでは、単純復旧モデルまたは完全復旧モデルが使用されます。 一括操作の前に一括ログ復旧モデルに切り替えることで、完全復旧モデルを拡張できます。 これらの復旧モデルの概要と、それらがトランザクション ログ管理に与える影響については、 トランザクション ログを参照してください。
最適なデータベース復旧モデルの選択は、あなたのビジネス要件によります。 トランザクション ログの管理を不要にし、バックアップと復元を簡単にするには、単純復旧モデルを使用します。 管理オーバーヘッドのコストで作業損失の露出を最小限に抑えるには、完全復旧モデルを使用します。 バルクログ作業中のログサイズへの影響を最小限に抑えつつ、その作業の復旧を可能にするために、バルクログ復元モデルを用いましょう。 リカバリーモデルがバックアップと復元に与える影響については、バックアップ概要(SQL Server)を参照してください。
バックアップ戦略を設計する
特定のデータベースに対するビジネス要件に合った回復モデルを選択したら、それに合ったバックアップ戦略を計画し実行してください。 最良のバックアップ戦略は複数の要因に依存します。 以下の要素が特に重要です。
アプリケーションは1日に何時間データベースにアクセスする必要がありますか?
予測可能なオフピーク時間帯がある場合は、その期間に完全なデータベースバックアップをスケジュールすべきです。
変更や更新はどの程度の頻度で行われるか。
頻繁に変更がある場合は、以下を考えてみてください。
シンプルなリカバリーモデルでは、完全なデータベースバックアップ間で差分バックアップをスケジュールできます。 差分バックアップは、データベースの最後の完全バックアップ以降の変更だけをキャプチャします。
フルリカバリーモデルでは、頻繁にログバックアップをスケジュールできます。 完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。
変化はデータベースのごく一部だけに起こる可能性が高いのか、それとも大部分で起こるのか?
変更がファイルやファイルグループの一部の部分に集中する大規模なデータベースでは、部分バックアップや完全なファイルバックアップが有用です。 詳細については、「 部分バックアップ (SQL Server) 」および「 完全ファイル バックアップ (SQL Server)」を参照してください。
完全なデータベースバックアップにはどれくらいのディスク容量が必要ですか?
これまで、どの程度ビジネスでバックアップを維持する必要があったか。
アプリケーションのニーズやビジネス要件に合った適切なバックアップスケジュールを確保しましょう。 バックアップが古くなるにつれて、故障点までのデータをすべて再生する方法がなければデータ損失のリスクは高まります。 ストレージ制限のために古いバックアップを処分する前に、その過去の復旧が必要かどうかをよく考えてください。
データベースの完全バックアップのサイズの推計
バックアップと復元戦略を実行する前に、フルデータベースバックアップがどれくらいのディスク容量を使うかを見積もってください。 バックアップ操作では、データベース内のデータをバックアップ ファイルにコピーします。 バックアップにはデータベース内の実際のデータのみが含まれており、未使用の領域は含まれていません。 そのため、通常、バックアップはデータベースそのものよりも小さくなります。 完全なデータベースバックアップのサイズを推定するには、 sp_spaceused システムのストアドプロシージャを使用します。 詳しくは、「sp_spaceused」を参照してください。
バックアップのスケジュール
バックアップ操作はトランザクション実行にほとんど影響を与えないため、通常の操作中にバックアップを実行することができます。 実稼働ワークロードへの影響は最小限にとどめて SQL Server バックアップを実行できます。
注
バックアップ中のコンカレンシーの制限については、「 バックアップの概要 (SQL Server)」を参照してください。
どの種類のバックアップが必要で、どのくらいの頻度で実行するかを決めたら、データベースのメンテナンス計画の一環として定期的なバックアップをスケジュールしてください。 メンテナンス プランと、データベース バックアップおよびログ バックアップ用のメンテナンス プランの作成方法については、「 Use the Maintenance Plan Wizard」を参照してください。
バックアップをテストする
バックアップをテストするまで、復元戦略はありません。 各データベースのバックアップ戦略を徹底的にテストし、データベースのコピーをテストシステムに復元してください。 使用するすべての種類のバックアップの復元をテストする必要があります。 バックアップを復元した後、データベースで DBCC CHECKDB を実行してバックアップメディアが損傷していないか確認してください。
メディアの安定性と一貫性を確認する
バックアップユーティリティが提供する検証オプション(BACKUPT-SQLコマンド、SQL Serverメンテナンスプラン、バックアップソフトウェアやソリューションなど)を活用してください。 例として、 RESTORE ステートメント - VERIFYONLY を参照してください。
BACKUP CHECKSUMなどの高度な機能を活用して、バックアップメディア自体の問題を検出しましょう。 詳細については、「バックアップと復元中のPossible メディア エラー (SQL Server)を参照してください。
ドキュメントのバックアップ/復元戦略
バックアップや復元手順を文書化し、そのコピーをランブックに保管してください。
また、各データベースごとに運用マニュアルを用意しておくべきです。 この運用マニュアルには、バックアップの場所、バックアップデバイス名(あれば)、テストバックアップの復元に必要な時間が記載されるべきです。
信頼されていないソースからバックアップを復元するセキュリティ リスク
このセクションでは、オンプレミス、Azure SQL Managed Instance、Azure Virtual Machines (VM) 上の SQL Server、その他の環境など、信頼されていないソースから任意の SQL Server 環境へのバックアップの復元に関連するセキュリティ リスクについて説明します。
この重要性について
SQL バックアップ ファイル (.bak) を復元すると、バックアップが信頼されていないソースから発生した場合、潜在的なリスクが発生します。 SQL Server 環境に複数のインスタンスがある場合、脅威の領域が増幅されるため、セキュリティ リスクはさらに悪化します。 信頼された境界内に残っているバックアップはセキュリティの問題を引き起こすことはありませんが、悪意のあるバックアップを復元すると、環境全体のセキュリティが損なわれる可能性があります。
悪意のある .bak ファイルは次のことができます。
- SQL Server インスタンス全体を引き継ぐ。
- 権限をエスカレートし、基になるホストまたは仮想マシンへの未承認のアクセス権を取得します。
この攻撃は、検証スクリプトまたはセキュリティ チェックを実行する前に発生し、非常に危険です。 信頼されていないバックアップの復元は、重要なサーバーまたは仮想マシンで信頼されていないアプリケーションを実行し、任意のコード実行を環境に導入することと同じです。
ベスト プラクティス
次のバックアップ セキュリティのベスト プラクティスに従って、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
エクステンデッドイベントからのサンプル出力
バックアップ タスクの詳細
- メンテナンス プランを作成する
- SQL Server Management Studio で SQL Server エージェント ジョブを作成する
- SQL Server エージェント ジョブのスケジュールを構成する
バックアップ デバイスとバックアップ メディアの操作
- ディスク ファイルの論理バックアップ デバイスを定義する (SQL Server)
- テープ ドライブの論理バックアップ デバイスを定義する (SQL Server)
- ディスクまたはテープのバックアップ先を指定する (SQL Server)
- バックアップ デバイスを削除する (SQL Server)
- バックアップの有効期限を設定する (SQL Server)
- バックアップ テープまたはバックアップ ファイルの内容を表示する (SQL Server)
- バックアップ セット内のデータ ファイルとログ ファイルを表示する (SQL Server)
- 論理バックアップ デバイスのプロパティと内容を表示する (SQL Server)
- デバイスからバックアップを復元する (SQL Server)
バックアップを作成する
部分的なバックアップやコピーのみのバックアップについては、Transact-SQL BACKUP 文とそれぞれ PARTIAL または COPY_ONLY のオプションを使いましょう。
SSMS の使用
T-SQL を使用する
- バックアップ圧縮でCPU使用量を制限するためにResource Governorを使います
- データベースが破損したときにトランザクション ログをバックアップする (SQL Server)
- バックアップまたは復元中にバックアップ チェックサムを有効または無効にする (SQL Server)
- バックアップまたは復元を指定して、エラー後に続行または停止する
データのバックアップを復元する
SSMS の使用
- SSMS を使用してデータベース バックアップを復元する
- データベースを新しい場所に復元する (SQL Server)
- データベースの差分バックアップを復元する (SQL Server)
- ファイルとファイルグループの復元(SQL Server)
T-SQL を使用する
- シンプルリカバリーモデルでデータベースバックアップを復元する
- 障害発生時にデータベースを復元する - 完全復旧
- 既存ファイル上のファイルとファイルグループを復元する(SQL Server)
- ファイルを新しい場所に復元する(SQL Server)
- マスターデータベースの復元
トランザクション ログの復元 (完全復旧モデル)
SSMS の使用
- マークされたトランザクションにデータベースを復元する (SQL Server Management Studio)
- トランザクション ログ バックアップを復元する (SQL Server)
- SQL Serverデータベースをある時点に復元する(完全なリカバリーモデル)