ログ配信を使用してSQL Serverのディザスタリカバリを構成する方法を学びます。これは、バックアップサーバーを維持し、障害発生時にデータベースの高可用性を確保するためのシンプルで効率的な方法です。
Updated by 佐藤健 on 2025/12/12
現在、業界にはディザスタリカバリ（DR）技術が多数存在しており、データベースミラーリングやクラスタリング、レプリケーションソリューションなどが含まれます。しかし、ログ配信はよりシンプルで構成やメンテナンスが容易な方法です。この記事では、ログ配信を使用したSQL Serverのディザスタリカバリ手順について説明します。
ログ配布は主にセカンダリサーバーにバックアップを保持し、必要に応じてプライマリサーバーの処理を引き継ぐことで、データベース全体の可用性を高めます。つまり、災害などによりプライマリデータベースが利用不能になった場合、セカンダリデータベースを手動でオンラインにすることでサービスを継続できます。
データベースのログ配布を構成する場合、SQL Server は次の 3 つのエージェント ジョブを作成して、バックアップ、コピー、および復元操作を自動化します:
最初のジョブはプライマリインスタンスで実行されます。プライマリデータベース上でトランザクションログをバックアップします。
2番目のジョブはセカンダリサーバーで実行されます。これは、プライマリサーバーからセカンダリサーバーへログバックアップをコピーします。
3番目のジョブもセカンダリ サーバーで実行されます。これはログ バックアップを復元し、セカンダリ データベースのログ エントリを更新します。
ログ配信の構成はそれほど難しくありませんが、実装する前にいくつか検討すべき事項があります：
データベースレベルの保護： 災害時に少数のデータベースのみを保護する必要がある場合は、このレベルで十分です。ただし、SQL Serverインスタンスレベルで複数のデータベースを保持したい場合、スタンドアロンのログ配布ソリューションでは不十分です。
セカンダリ サーバーでの手動フェールオーバー：ロギング シッピングのみでは、プライマリ サーバーからセカンダリ サーバーへの自動的なフェールオーバーは実行できません。セカンダリ データベースを手動でオンラインにする必要があります。
手動でのSQLログイン構成：SQLログインはプライマリサーバーからセカンダリサーバーに自動的に転送されません。ログイン資格情報をプライマリサーバーインスタンスからセカンダリサーバーインスタンスへ転送して、ログインの同期を行う必要があります。さらに、セカンダリサーバー上で各種メンテナンス計画やリンクサーバー、およびSSIS（SQL Server統合サービス）パッケージを手動で作成する必要がよくあります。
データ損失のリスク： 通常、プライマリデータベースが使用できなくなると、最後のトランザクションログバックアップのみを復元できます。これは、最後のログバックアップがセカンダリサーバーに送信された後に発生したすべてのトランザクションは失われることを意味します。例えば、プライマリサーバーが午前9時に障害が発生し、最後のバックアップが午前8時45分にセカンダリサーバーインスタンスBにコピーされた場合、午前8時45分から午前9時の間のすべてのデータが失われます。
リバース・ログ・シャイピング： これは、フルデータベースバックアップを行わずにサーバーロールを切り替える際に役立ちます。たとえば、大きなバックアップがあり、セカンダリサーバーからリモートのプライマリサーバーへデータを転送する必要がある場合、全体をコピーするのに非常に時間がかかる可能性があります。
一般的に、ログ配信の設定プロセスは明確に分けて2つのステップに分けることができます：
ステップ 1 – セカンダリ サーバーでデータベースを初期化する
プライマリ サーバー インスタンスに2つのデータベースがあると仮定し、TestDB1のログを、最初はデータベースが存在しないセカンダリ サーバーに送信する必要があります。ログ送信を構成するには、データベースをFULLまたはBULK-LOGGEDの復元モデルにする必要があることに注意することが重要です。データベースがSIMPLE復元モデルの場合、トランザクション ログのバックアップを使用できないため、ログ送信は失敗します。
1. 最初に、完全データベース バックアップとトランザクション ログ バックアップを実行する必要があります。次の T-SQL クエリを実行して、「完全」 および「トランザクション ログ」 バックアップを作成できます。
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak' backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. 次に、セカンダリ サーバーでバックアップを復元します。
3. 「データベースの復元」インターフェースで、データソースとしてデバイスを選択し、そのアイコンをクリックします。
4. 「バックアップ デバイスの選択」ダイアログ ボックスで、追加をクリックします。
5. 復元するバックアップファイルを選択し、OK をクリックします。
6. TestDB1のバックアップを復元します。
7. ページの選択をクリックし、必要に応じてファイルに移動して物理データベースファイルの保存場所を変更します。
8. 次に、左側の オプション をクリックします。オプション ページで、リカバリー状態 のドロップダウンリストから スタンバイ状態で復元 を選択します。なお、スタンバイ状態で復元 を選択するとデータベースが読み取り専用状態のままであることを確認してください。ノーリカバリーで復元 を選択すると、データベースにアクセスできなくなります。
9. 適切な復旧状態を選択した後、 OK をクリックして正常な復元を確実に実行してください。これにより、TestDB1 がセカンダリ サーバーインスタンス上でスタンバイ（読み取り専用）モードで復元されます。
この時点で、データベースはセカンダリ サーバー上で正常に初期化されました。
ステップ 2 – プライマリデータベースを有効にする
1. プライマリ サーバー インスタンス上で TestDB1 を右クリックし、プロパティ をクリックします。
2. 「ログ配布構成でプライマリデータベースとしてこの機能を有効にする」を選びます。
3. [追加] をクリックしてセカンダリ データベースを設定します。システムがセカンダリ サーバー インスタンスへの接続を求めてメッセージを表示します。
4. ステップ1で構成したように、セカンダリデータベース設定インターフェースで、いいえ、セカンダリデータベースは初期化されています。 を選択します。
5. セカンダリ サーバーのバックアップ・フォルダの場所を指定し、バックアップ頻度を設定して OK をクリックします。
6. トランザクション ログの復元 インターフェースで、データベース状態を スタンバイ モード に設定し、バックアップの復元時にデータベースのユーザーを切断する をチェックします。バックアップ間隔を設定後、[OK] をクリックします。
7. セカンダリ サーバー インスタンスとデータベースを追加するには、 OK をクリックしてSQL Serverエージェント ジョブを作成します。
プライマリ サーバー上の SQL Server エージェントの下には、トランザクション ログのバックアップ ジョブが含まれています。
セカンダリ サーバーの SQL Server エージェントの下には、新たに作成された 2 つのジョブが見つかります。1 つはプライマリ データベースからトランザクション ログのバックアップをコピーするものであり、もう 1 つはセカンダリ データベースにトランザクション ログのバックアップを復元するものです。
8. この時点で、ログ配布を使用したディザスタリカバリソリューションの構成は完全になります。プライマリデータベースに障害が発生した場合は、すぐにセカンダリ データベースをオンラインにできます。また、次のクエリを実行して、セカンダリ データベースがスタンバイモードから抜け出していることを確認することもできます。
Select * from Products RESTORE DATABASE TestDB1 WITH RECOVERY
9. データベースを更新することで、セカンダリ サーバー上のTestDB1がオンラインになったことが確認できます。
ログ配信などのディザスタリカバリソリューションを実装する一方で、企業はより包括的かつ効率的なデータ保護戦略を必要とすることがよくあります。Vinchin Backup & Recoveryは、VMやSQL Serverなどのデータベースに特化した自動バックアップおよびリカバリソリューションを提供し、フルバックアップ、増分バックアップ、差分バックアップをサポートしています。搭載された重複排除および圧縮技術により、ストレージ消費量とバックアップ時間を大幅に削減します。
さらに、Vinchinのバックアップソリューションは複雑な手動操作を必要としなくなり、自動データベース保護を実現しつつ、クロスプラットフォームの移行やクラウドストレージにも対応します。SQL Serverに障害が発生した場合、Vinchinは管理者が迅速にデータベースを復元できるように支援し、データ損失や長時間のダウンタイムを防ぎ、企業に対してより包括的なディザスタリカバリの保証を提供します。
SQL Serverデータベースのバックアップジョブを作成するには、物理バックアップ > データベースバックアップ > バックアップ ページに移動してください：
1. バックアップが必要なデータベースを選択します。
2. バックアップ データを処理および保存するためのバックアップ ノードを選択します。
3. 必要に応じてバックアップ戦略を構成します。
4. 設定を確認して確認してください。
効率的で信頼性の高いデータバックアップおよび回復ソリューションを体験するために、以下のボタンをクリックしてVinchinの60日間無料トライアルをお試しください！
1. 高可用性（HA）とディザスタ復旧（DR）の違いは何ですか？
HAは、フェールオーバークラスタリング、Always On可用性グループ、またはデータベースミラーリングを使用して最小限のダウンタイムを確保します。一方、DRは、サイト外のバックアップやセカンダリデータセンターを活用して、重大な障害後のサービス復旧に焦点を当てます。
2. SQL Server フェールオーバー クラスター インスタンス (FCI) とは何ですか。また、DR にどのように役立ちますか?
FCIは、Windows Server フェールオーバークラスタリング（WSFC）を使用してSQL Serverインスタンスレベルで自動フェールオーバーを提供する高可用性ソリューションです。 共有ストレージ（SAN、Storage Spaces Direct、またはクラウドベースのソリューション）が必要です。 サイト全体の障害に対応できないため、DRソリューションとしては単独では適していませんが、オンプレミスの高可用性には最適です。
ログ転送は、SQL Server に対して経済的で効率的かつ簡単なディザスタリカバリソリューションです。これは、データベースレベルのディザスタリカバリにおいて理想的な選択肢です。ただし、インスタンスレベルのディザスタリカバリの場合は、データベースミラーリングやフェールオーバークラスタリングなどの他のDR技術を検討する必要があります。さらに、ログ転送ではデータ損失が発生する可能性があります。破損したSQLデータベースから削除またはアクセス不能になったデータを復旧する必要がある場合は、プロフェッショナルなSQLリカバリツールの利用を検討してください。
共有:
