ここでは、SQL Server のバックアップの種類とその組み合わせ方について解説し、リカバリモデルとその目的について説明するとともに、データを保護するためのベストプラクティスについても紹介します。
SQL Server のバックアップの種類
Microsoft SQL Server では、いくつかの種類のバックアップがサポートされています。本記事では、最も一般的な「完全(フル)バックアップ」、「差分バックアップ」、および「トランザクション ログ バックアップ」に焦点を当てます。
完全バックアップ
完全バックアップとは、SQL Server データベースの完全なバックアップのことです。データベース内のすべてのオブジェクト（テーブル、プロシージャ、関数、ビュー、インデックスなど）がバックアップされます。
SQL Server Management Studio、Transact-SQL、またはPowerShellを使用して、SQL Server データベースの完全バックアップを作成できます（Microsoft はこのガイドで詳細を解説しています）。
完全バックアップを使用すれば、バックアップ終了時点とまったく同じ状態でデータベースを復元することができます。完全バックアップは、差分バックアップおよびトランザクション ログ バックアップの基盤となります。これらのバックアップの種類を実行するには、少なくとも一度は完全バックアップを実行しておく必要があります。
差分バックアップ
差分バックアップには、前回の完全データベース バックアップ作成以降に変更されたデータのみが含まれます。すべてをバックアップするのではなく、変更されたデータのみをバックアップするため、差分バックアップの作成には通常、完全バックアップよりも短い時間で済みます。
ただし、差分バックアップを複数作成すると、後続の各差分バックアップには追加の変更データが含まれる可能性があり、最終的には完全バックアップと同等のサイズに近づくことがあります。その結果、復元時間が長くなります（完全バックアップと差分バックアップの両方を復元する必要があるため）。バックアップ時間の長期化を防ぎ、差分バックアップが過度に大きくなるのを防ぐには、定期的に新しい完全バックアップを実行する必要があります。
データベースの復元が必要な場合は、まず完全バックアップを復元し、次に問題が発生する前に作成された最新の差分バックアップを復元してください。最新の差分バックアップには、その完全バックアップ以降のすべての変更が含まれているため、それより古い差分バックアップは無視してもかまいません。
トランザクション・ログのバックアップ
トランザクション・ログ（T-log）のバックアップは、SQL Server において最も粒度の細かいバックアップの種類です。これは、前回のトランザクション・ログのバックアップ以降に SQL Server データベースに加えられた変更のみを含むトランザクション・ログをバックアップするからです。実質的には増分バックアップとなります。
トランザクション・ログのバックアップは数分おきに実行することも可能であり、これにより特定時点での復元が可能になり、データ損失を最小限に抑えることができます。
特定時点での復元
定期的なトランザクション・ログのバックアップを実行している場合、テーブル内のデータの誤った削除や更新など、問題となるトランザクションが発生する直前の時点まで復元することができます。特定時点での復元を行うには、以下の手順を実行する必要があります。
１．最新の フル バックアップを復元します。
２．（オプション）障害発生時点に最も近い 差分 バックアップを復元します。
３．トランザクション ログ バックアップを、作成された順序で復元します。この際、前回のフル バックアップ（または、使用している場合は前回の差分バックアップ）から障害発生時点までの期間をカバーするようにします。
SQL Server のリカバリモデル
SQL Server のデータベースリカバリモデルには、「シンプル」、「フル」、「バルクログ」の 3 種類があります。データベースリカバリモデルによって、以下の事項が決まります。
- ・トランザクションログの管理方法
- ・実行可能なバックアップの種類
- ・実行可能なデータベース復元の種類
シンプル回復
シンプル回復モデルを使用するデータベースの場合、SQL Server はトランザクション ログを使用しますが、トランザクション ログのバックアップはサポートされていません。ログの非アクティブな部分は自動的に切り捨てられ、追加のトランザクションのためのスペースが確保されます。このクリーンアップでは、削除されたログ レコードのバックアップは保存されません。
このモデルでは、トランザクション ログの管理負担は軽減されますが、データベースの特定時点への復元を行うことはできなくなります。データが頻繁に変更され、完全バックアップや差分バックアップの実行頻度が低い場合、データベースを復元する必要が生じた際に許容できないデータ損失につながる可能性があります。
簡易リカバリでは、データの復元には完全バックアップと差分バックアップに依存します。たとえば、1日に1回だけ完全バックアップを実行する場合に比べ、4時間ごとに差分バックアップを実行すれば、より新しいデータを復元できるようになります。データ損失の程度は、これらのバックアップを実行する頻度に大きく依存します。
完全復旧
完全復旧モデルでは、トランザクションログのバックアップを実行するまで、トランザクションレコードはトランザクションログファイル内に保持されます。ログが膨大なサイズに肥大化し、ディスクドライブを満杯にしてしまうのを防ぐため、これらのバックアップを定期的に実行する必要があります。トランザクションログのバックアップが完了すると、使用されていないログ領域は新しいトランザクションのために再利用されます。
これらのログ・バックアップにより、特定時点への復旧も可能になります。前述のように、フル・バックアップを復元し、使用されている場合は最新の差分バックアップを適用した後、選択した復旧時点（たとえば、削除または更新ステートメントによってデータベースのデータが誤って変更される直前の時点）までのトランザクション・ログ・バックアップを復元します。
ログ領域の再利用によって、ディスク上のログ・ファイルのサイズが縮小されるわけではありません。トランザクション・ログは、予想されるアクティビティに基づいて事前にサイズを設定しておく必要があり、予防措置として、トランザクション・ログの空き領域が使い果たされた場合に自動的に拡張されるように設定することもできます。絶対に必要でない限り、SQL ServerのT-SQLコマンドを使用してこれらのファイルを縮小することは避けるべきです。
バルクログ回復
バルクログ回復モデルはフル回復モデルに似ており、やはり定期的なトランザクション・ログのバックアップが必要です。違いは、特定の一括操作がトランザクション・ログに完全に記録されない点にあります（これは「最小ログ記録」と呼ばれます）。SELECT INTO や BULK import、TRUNCATE などの操作は、最小ログ記録の対象となります。バルクログ回復モデルでは、トランザクション・ログのサイズがフル回復モデルの場合ほど大きくならない可能性があります。インポートされたデータは依然として完全ですが、ログへの書き込み情報を減らすことで、これらの一括操作の実行速度向上にもつながります。
ただし、欠点として、バルクログ記録操作が含まれるログバックアップ内では、特定の時点への復元（ポイント・イン・タイム・リストア）を行うことができません。そのバックアップは最後まで復元する必要があります。そのため、データ損失のリスクが高まる可能性があります。バルクログ記録がご自身のニーズに適した回復モデルであるか確信が持てない場合は、フル回復モデルを使い続けることをお勧めします。
SQL Server バックアップのベストプラクティス
データ損失のリスクを最小限に抑えるために、バックアップおよび復元戦略を策定する際は、以下の推奨事項を念頭に置いてください。
ビジネス要件に基づいたバックアップスケジュールを策定する
データは定期的にバックアップする必要があります。たとえば、週 1 回のフルバックアップと毎日の増分バックアップをスケジュールすることができます。フルまたはバルクログ回復モデルを使用する場合は、RTO および RPO に基づいてトランザクション ログのバックアップ頻度をスケジュールしてください。30 分を超えるデータベースの変更が失われることが問題となる場合は、トランザクション ログのバックアップを少なくとも 30 分ごとにスケジュールするようにしてください。
バックアップの自動化と検証を実施する
すべてのSQL Serverデータベースのバックアップルーチンを作成するには、複数のバックアップジョブやスケジュールの作成に加え、バックアップファイルの保持期間管理が必要になる場合があります。これは複雑になりやすく、多くの管理作業を要します。SQL Serverの組み込みツールを使用することもできますが、多くの場合、サードパーティ製製品を活用することでこれらのタスクを自動化できます。
テスト環境にバックアップを復元して、定期的にテストを行うことです。復元されたデータベースにエラーがないか確認し、復旧にかかる時間を測定して、復旧時間目標（RTO）を満たしていることを確認してください。
すべてのバックアップファイルを本番データベースと同じサイトに保存しないでください
最適な災害復旧対策のため、データベースのローカルバックアップとオフサイト（クラウド）バックアップを保持してください。不変（イミュータブル）またはオフラインストレージを使用して、少なくとも1つのコピーを削除から保護し、バックアップへのアクセス権限を日常の本番アカウントとは分離してください。
RSSフィードを取得する
