SQL Server の復旧：データベースの復元に関するベストプラクティス

DBAが考える「復元の成功」の定義

以前一緒に仕事をしたあるDBAが、復元の成功について次のように定義してくれました。「データベースが稼働しており、アプリケーションからクエリを実行でき、その状態に至るまでにバックアップベンダーのサポートチームに頼る必要がなかったこと。」 これは、ほとんどのベンダーのデモが満たす水準よりも高い基準です。

バックアップベンダーが「SQL Serverの復旧」と呼ぶものと、DBAが実際に必要としているものとの間のギャップは、この業界で長年にわたり続いている齟齬の一つです。 ベンダーはバックアップファイルについて語ります。一方、DBAには、適切な復旧状態、アプリケーションのメタデータ、インスタンス構成を備えた、クエリを実行できる実用的なデータベースが必要です。 これらは同じものではなく、その違いは、プレッシャーのかかる状況下で復元を行う際に最も重要になります。

この記事は、2026年にSQL Serverの復旧についてどのように考えるべきか尋ねてくる同僚に対して、私が成功を収めたチームや、数週間の遅れを招いた失敗例から得た経験をもとに、伝えたい内容です。 

バックアップ、復元、リカバリ：3つの用語、3つの概念

バックアップとは、ある時点におけるデータベースのコピーを取得する行為のことです。 フル、差分、トランザクション・ログ、またはファイル・グループなどです。

復元とは、バックアップをSQL Serverインスタンスに書き戻し、適切なバックアップ・チェーンを適用して、データベースをオンライン状態にする行為です。

リカバリとは、運用上の成果のことです。データベースはオンライン状態で、トランザクションの一貫性が保たれ、クエリを正しく処理しています。 バックアップと復元は仕組みです。リカバリは結果です。

存在はするものの復元できないバックアップは、バックアップとは言えません。復元は完了したものの、データベースが使用不能なままになる場合は、リカバリとは言えません。SQL ServerのDBAは、これらを慎重に区別します。その違いこそが、インシデントの解決と長期にわたるサービス停止との違いだからです。 

リカバリモデルとその機能

SQL Server には 3 つのリカバリモデルがあります。どのモデルを選択するかによって、利用可能な復元オプションが決まります。誤った選択は、「実際にはその時点まで復元できない」という議論が生じる最も一般的な原因の一つです。 

トランザクション処理が活発な本番データベースでは、通常「完全」モードで実行されます。 大規模なデータ損失を許容できるレポート用データベースでは、多くの場合「シンプル」モードで実行されます。リカバリ モデルはインスタンス単位ではなく、データベース単位で設定されます。モデル データベースのデフォルト設定は、SQL Server のエディションやインストール時の選択によって異なるため、すべての本番データベースで明示的に確認してください。 

DBAが実際に直面する4つの復元シナリオ

本番環境におけるSQL Serverの復元のほとんどは、以下の4つのシナリオのいずれかに該当します。復元準備が整っているとは、それぞれについてテスト済みの手順を用意していることを意味します。

元のインスタンスへのデータベース全体の復元

最も単純なケースです。 データベースを、バックアップ元と同じインスタンスに復元する必要があります。これは通常、破損、ランサムウェア、または重大なデータ損失からの復旧を目的としています。復元チェーンは、フルバックアップに加え、最新の差分バックアップ、およびその後のすべてのトランザクション ログ バックアップで構成されます。ソースが復元可能な場合は、データ損失を最小限に抑えるために、まずテール ログ バックアップを取得してください。 

特定時点への復旧（PITR）

誤って別のデータベースに対してTRUNCATE TABLEを実行してしまった場合、破壊的なスクリプトを実行してしまったデプロイメントの不具合、あるいはランサムウェアによる暗号化事象などが該当します。これらは、単に最後のフルバックアップ時点ではなく、特定の時点への復旧が必要となります。 PITR には、フルまたはバルクログ回復モデルと、復旧時点まで遡る完全なトランザクションログチェーンが必要です。多くの組織が必要な時点まで復旧できない理由は、バックアップのギャップではありません。 原因は、ログチェーンの断絶、あるいは誤ってデータベースが「シンプル」リカバリモデルに設定されたままになっていることです。

別のSQL Serverインスタンスへの復元

元のインスタンスがハードウェア障害やインフラの侵害により利用できない場合、あるいはDBAが本番環境に影響を与えずに並行環境へデータベースを復元する必要がある場合に必要となります。 復元先は、同じサーバー上の別のインスタンス（DEV、UAT、PROD）でも、別の物理サーバーでも構いません。 ログイン、ジョブ、およびインスタンスレベルのオブジェクトはデータベースのバックアップには含まれないため、別途処理する必要があります。

開発、テスト、またはフォレンジック分析のために別の環境に復元する

本番データは、開発、テスト、またはインシデント発生後のフォレンジック分析のために、下位の環境に移す必要があります。 復元先は、本番環境から意図的に分離されており、別のサーバーや別のネットワークに配置され、多くの場合、復元後にPIIのマスキングが適用されます。 ソースに影響を与えることなく、本番データのアプリケーション一貫性のあるコピーを作成するクローン機能こそが、適切なパターンです。

VMレベルのバックアップがデータベース復旧ではない理由

一般的なVMバックアップツールの多くは、SQL Serverの保護機能を謳っています。 しかし、実際に提供されるのは、クラッシュ一貫性またはVSS連携のスナップショットを用いたVMレベルのバックアップと、復元のための一連の回避策に過ぎません。一般的な例としては、

「バックアップデータからのVM即時復元が可能です。SQL VMを起動して、お好きなようにデータをご利用ください。」 

「バックアップ先からデータベースファイルをSMB共有できますので、それらをマウントして、お好きなようにご利用いただけます。」

どちらもデータへのアクセスを可能にします。 しかし、どちらもデータベースを復元するものではありません。.mdf と .ldf のペアを SQL Server インスタンスにマウントすることは、一部のシナリオでは機能する場合もありますが、正しいバックアップチェーン、リカバリ状態、およびアプリケーションメタデータを用いた適切なデータベース復元とは異なります。ここに有用な視点があります。それは、「データを見つけること」と「データを保存すること」の違いです。 ファイルにアクセスできるようにすることと、データベースを正常な状態で復元し、クエリを処理できるようにすることの違いです。

アプリケーション対応のバックアップは、SQL Server を理解しています。どのデータベースがどの仮想マシン上に存在するか、それぞれがどのリカバリモデルを使用しているか、アプリケーション一貫性のあるスナップショットを作成するために SQL Server VSS ライターとどのように連携するか、そして正しいデータベース状態を持つ正しいインスタンスにどのように復元するかを把握しています。 このアーキテクチャ上の違いは、復元の複雑さに現れます。アプリケーション対応のツールはデータベースを提供します。VM対応のツールはファイルを提供します。

信頼性の高い復元とインシデントの発見を分ける6つの実践

数多くのSQL Serverの復元作業を観察すると、プレッシャー下でもスムーズに復元を行うすべてのチームに、同じ6つの実践が見られます。 これらは特別なものではありません。単に一貫して適用されているだけです。

特別な理由がない限り、すべての本番データベースを「完全回復モデル」に設定してください。「簡易回復モデル」では、特定時点への復旧（PITR）は不可能です。データベースが本当にPITRを必要としない場合は、その決定を文書化してください。 決して偶然に任せてはいけません。

RPOが実際に要求する頻度でトランザクションログのバックアップを実行してください。ティア1システムでは、15分ごとのログバックアップが一般的です。 ほとんどの本番データベースでは、1時間ごとのバックアップが最低限の基準となります。ログチェーンこそが、PITRを可能にするものです。

RESTORE VERIFYONLY または同等のプラットフォームチェック機能を使用して、バックアップを検証してください。復元できないバックアップは、保護とは言えません。検証を行うことで、破損、ファイルの欠落、チェーンの断絶などを、復元失敗につながる前に検出できます。 

ソースにアクセス可能な場合は、復元前にテールログのバックアップを取得してください。元のデータベースファイルがまだ読み取り可能な場合、復元前にログの末尾をキャプチャすることで、データ損失を数秒に抑えることができます。

クラッシュ一貫性のあるスナップショットではなく、アプリケーション一貫性のあるスナップショットを使用してください。 アプリケーション一貫性のあるバックアップは、SQL Server VSS ライターと連携し、データベースを適切に静止状態に保ち、スナップショットがトランザクション一貫性のある時点で取得されることを保証します。 クラッシュ一貫性のあるバックアップでは、復元後に復旧作業が必要となり、稼働中のデータベースでは完全に失敗する可能性があります。

四半期ごとに、別のインスタンスまたはサーバーへの復元テストを実施してください。バックアップの整合性をテストすることと、復元をテストすることは別物です。復元が機能するかどうかを確認する唯一の方法は、実際に実行することです。理想的には、定義されたスケジュールに従って、本番データベースを非本番環境に復元することです。 復元時間を主要な指標として追跡してください。

エージェント方式とエージェントレス方式：アーキテクチャ上のトレードオフ

従来の SQL Server バックアップアーキテクチャでは、保護対象の各サーバーにエージェントがインストールされていました。エージェントは、SQL 対応のバックアップ、VSS との連携、および復元の調整を処理していました。これは機能していましたが、運用上の負担を生み出していました。 保護対象のすべてのサーバーにおいて、エージェントのインストール、更新、パッチ適用、トラブルシューティングを行う必要がありました。数百台のSQL VMが存在する環境では、エージェントのメンテナンスは実質的な継続的なコストとなります。最新の状態ではないエージェントは、誰にも気づかれないセキュリティ上の脆弱性となります。 

エージェントレスアーキテクチャでは、ハイパーバイザーレベルのAPIとプラットフォーム統合を通じてSQL Serverのバックアップおよび復元を処理するため、保護対象のVMにソフトウェアをインストールする必要がありません。その利点は、大規模な環境における運用上の簡素化です。インストールするものはなく、アップグレードする必要もなく、パッチチューズデーに不具合が発生する心配もありません。エージェントレスアプローチにおける課題は、従来、アプリケーションの認識能力にありました。 純粋なVMレベルのバックアップはアプリケーションを認識せず、前述したような回避策に頼らざるを得ません。

最新のエージェントレスプラットフォームは、ハイパーバイザーおよびストレージAPIと直接統合し、アプリケーションの一貫性を確保するためにSQL ServerのVSSライターと連携し、SQL Server VM自体にソフトウェアを一切インストールすることなくデータベースレベルの認識を維持することで、この認識の問題を解決しています。 その結果、エージェントのメンテナンスを必要とせずに、SQL 対応のバックアップおよび復元が可能となり、特定時点への復旧、別のインスタンスへの復元、別のサーバーへの復元が行えます。

復旧手順のテスト

SQL Server の復旧に失敗する最も一般的な原因は、バックアップの失敗ではありません。それは手順の失敗です。 2年間、毎晩バックアップジョブは正常に完了していましたが、文書化された復元手順を実際に最初から最後まで実行した人は誰もいませんでした。インシデントが発生した際、手順が間違っていたり、依存関係が欠けていたり、あるいは復元先がワークロードに見合ったサイズに設定されていなかったりしました。

機能するSQL Server復旧テストプログラムには、3つの構成要素があります。 本番データベースを非本番環境へ復元する定期的なテスト（四半期に1回以上、ティア1システムの場合は毎月実施）。 RTO（復旧目標時間）の計画に反映される、復元時間のメトリクスの追跡。そして、エスカレーション手順、コミュニケーション、意思決定といった人的な手順を含む、机上演習または実地演習。単なる技術的な復元作業だけではありません。

もし、チームが最大の本番データベースの完全な復元にどれくらいの時間がかかるかを自信を持って答えられないのであれば、そのRTOはあくまで理論上のものに過ぎません。 それを確認する最も手っ取り早い方法は、実際に実行してみることです。

SQL Serverの復旧に関するよくある質問

SQL Serverのバックアップと復旧の違いは何ですか？

バックアップとは、コピーを作成することです。 復元とは、そのコピーを書き戻すことです。リカバリとは、その結果として、使用可能でクエリを実行できるデータベースの状態になることです。バックアップが成功しても、使用可能なデータベースに復元できない場合は、保護とは言えません。

どのバックアップツールでもポイント・イン・タイム・リカバリ（PITR）は可能ですか？ 

いいえ。PITR を行うには、データベースがフルまたはバルクログ回復モデルであること、対象の復旧期間をカバーする完全なトランザクション ログ バックアップの連鎖、およびその連鎖を適用する方法を理解しているバックアップ ツールが必要です。クラッシュ一貫性のある VM スナップショットは、スナップショットが作成された時点の状態を提供するものであり、その間の任意の時点の状態を提供するものではありません。 

SQL Server をバックアップするために、すべてのサーバーにエージェントをインストールする必要がありますか？

最新のエージェントレスプラットフォームであれば、その必要はありません。エージェントレスアーキテクチャは、ハイパーバイザーおよびストレージ API を通じて SQL Server VSS ライターと連携し、保護対象の VM にソフトウェアをインストールすることなく、アプリケーションを意識したバックアップとデータベースレベルの復元を実現します。 

SQL Serverデータベースを別のサーバーやインスタンスに復元することはできますか？

はい、適切なツールがあれば可能です。データベースのバックアップは、インスタンスやサーバー間で移植可能です。インスタンスレベルのオブジェクト（ログイン、ジョブ、リンクされたサーバー）はデータベースのバックアップには含まれないため、別途移行する必要があります。 

ご自身の環境で試してみてください

HYCUは、Nutanix AHV、VMware ESXi、およびNutanix-on-VMwareにおいて、エージェントレスでアプリケーションを意識したSQL Serverバックアップを提供します。 特定時点への復旧、別のインスタンスやサーバーへの復元、開発やテスト用のクローン作成など、すべて保護対象のVMにエージェントをインストールすることなく実行できます。 試用版はこちら hycu.com/trialでご利用いただけます。