Cloud Backup:データベースバックアップに関するよくある質問

データベースインスタンスに関する問題

• Database Backup のインスタンス登録に失敗した場合の解決方法

• データベースインスタンスのステータスが「非アクティブ」の場合の解決方法

• データベースインスタンスのステータスが「DB オフライン」の場合の解決方法

• インスタンス登録後に [ECS データベースインスタンス] タブに複数のデータベースインスタンスが表示される理由

• インスタンス登録後にデータベースステータスの取得に失敗した場合の解決方法

クライアントに関する問題

• クライアントプロセスのステータス確認、ログパスの検索、クライアントの再起動方法

• データベースクライアントのステータスが「オフライン」の場合の解決方法

• ローカル SQL Server のバックアップクライアントインストール時に「Failed to run install script: exit status 4」エラーが発生した場合の解決方法

• ローカル SQL Server のバックアップクライアントインストールに失敗した場合の解決方法

• ECS インスタンスで Database Backup クライアントのインストールに失敗した場合の解決方法

バックアップに関する問題

• ローカルデータベースバックアップの無料トライアルの入手方法

• ローカルデータベースバックアップのネットワーク要件

• リアルタイムバックアップの最小間隔と増分バックアップとの併用設定について

• データベースバックアップのユーザー名とパスワードの変更方法

• データベースバックアップに失敗した場合の解決方法

• Oracle の増分バックアップが完全バックアップと同等かそれ以上の時間がかかる場合の解決方法

• Oracle の増分バックアップ中に RMAN が致命的でないエラーを報告する場合

• SQL Server 2019 のバックアップ中にデータベース詳細の参照に失敗した場合の解決方法

• Cloud Backup コンソールでローカル SQL Server の IP アドレスが正しくない場合の解決方法

• TDE (透過的データ暗号化) を有効にした後、SQL Server データベースを Alibaba Cloud にバックアップできますか？

• SQL Server のランサムウェア対策を展開後にクライアントがオフラインになり、アンインストールやランサムウェア対策ポリシーの削除ができない問題の解決方法

• ECS インスタンスを新しいアカウントに移行後、Database Backup のインストールまたは使用に失敗した場合の解決方法

• バックアップ対象の MySQL データベースのバージョンとオペレーティングシステムに制限はありますか？

• MySQL で新しく作成したデータベースをバックアップする方法

• データベースバックアップのキャンセル方法

• バックアップ履歴に重複した、または予期しない時刻のレコードが表示される理由

• バックアップが失敗し、バックアッププランのステータスが「エラー」と表示される理由

• アラート時刻と実際のエラー時刻が異なる理由

• 失敗のアラートメールやショートメッセージを受信したのに、バックアップ履歴に成功と失敗の両方のレコードが同時に表示される理由

復元に関する問題

• 「オフラインインスタンスのみ表示」機能とは

• SQL Server データベースの復元に失敗した場合の解決方法

• エージェントログにファイル初期化エラーが示された場合の SQL Server リカバリ失敗の解決方法

• ローカルデータベースと ECS データベース間でクロスデータベース復元を実行する方法

バックアップボールトに関する問題

• データベースバックアップボールトとは

• データベースバックアップボールトでの期限切れバックアップの消去方法

• バックアップデータサイズとバックアップボールト使用量の確認方法、および課金の基準

Database Backup のインスタンス登録に失敗した場合の解決方法

まず、Database Backup クライアントがサーバー (ローカルサーバーまたは ECS インスタンス) にインストールされているか確認します。インストールされている場合は、「クライアントのアンインストール」をご参照いただき、クライアントをアンインストールして設定ファイルをクリアしてください。その後、再度インスタンスの登録を試みます。

データベースインスタンスのステータスが「非アクティブ」の場合の解決方法

データベースインスタンスのステータスが「データベースがオンラインではありません」の場合の解決方法

インスタンス登録後に [ECS データベースインスタンス] タブに複数のデータベースインスタンスが表示される理由

ECS インスタンスに複数のデータベースインスタンスがデプロイされている場合、Cloud Backup コンソールは登録時にそれらすべてをスキャンして表示します。

インスタンス登録後にデータベースステータスの取得に失敗した場合の解決方法

• 現象

  データベースインスタンスを登録した後、Cloud Backup コンソールがデータベースのステータスを取得できません。

• 原因

  オペレーティングシステムがデータベースでサポートされていません。

• ソリューション

  サポートされているオペレーティングシステムに切り替えて、再試行してください。

クライアントプロセスのステータス確認、ログパスの検索、クライアントの再起動方法

• Linux

  1. バックアップクライアントのプロセスステータスを確認します。

     systemctl status dbackup3-agent または service dbackup3-agent status コマンドを実行して、Database Backup クライアントのプロセスステータスを確認します。

     ステータスが active または dbackup3-agent is running... の場合、クライアントは正常に実行されています。

     ● dbackup3-agent.service - dbackup3 agent daemon
        Loaded: loaded (/usr/lib/systemd/system/dbackup3-agent.service; enabled; vendor preset: disabled)
        Active: active (running) since Mon 2023-12-11 13:47:34 CST; 1min 13s ago
      Main PID: 22192 (dbackup3-agent)
        CGroup: /system.slice/dbackup3-agent.service
                └─22192 /opt/scutech/dbackup3/bin/dbackup3-agent -f /etc/opt/scutech/dbackup3/agent/svc.conf.d
     
     Dec 11 13:47:34 iZbp1******gktZ systemd[1]: Started dbackup3 agent daemon.

  2. バックアップクライアントを再起動します。

     systemctl restart dbackup3-agent または service dbackup3-agent restart コマンドを実行して、クライアントプロセスを再起動します。コンソールでデータベースの [クライアントステータス] が [インストール済み] になると、クライアントのステータスは正常に戻ります。

     

  クライアントのログパスは /var/log/dbackup3/agent.log です。

• Windows

  1. Win + R を押して、「ファイル名を指定して実行」ダイアログボックスを開きます。

  2. services.msc と入力し、Enter キーを押して「サービス」インターフェイスを開きます。

  3. サービス一覧から dbackup3-agent サービスを見つけます。

  4. サービスのステータスが「実行中」であるか確認します。そうでない場合は、dbackup3-agent サービスを右クリックし、「再起動」を選択して開始します。

  クライアントのログパスは C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log です。

データベースクライアントのステータスが「オフライン」の場合の解決方法

• 現象

  データベースの [クライアントステータス] が [オフライン] になります。

  

• 原因

  「オフライン」ステータスは、Cloud Backup がクライアントプロセスからハートビート信号を受信していないことを示します。これは、メモリ不足エラーによるクライアントの自動停止や、クライアントが配置されているデバイスのシャットダウンなど、いくつかの理由で発生する可能性があります。

• ソリューション

  「クライアントプロセスのステータス確認、ログパスの検索、クライアントの再起動方法」の手順に従って、クライアントを確認し、再起動してください。クライアントのステータスが [実行中] に変わった後、コンソールでデータベースの [クライアントステータス] が [インストール済み] と表示されるのを待ちます。これは、クライアントが正常に戻ったことを示します。

ローカル SQL Server のバックアップクライアントインストール時に「Failed to run install script: exit status 4」エラーが発生した場合の解決方法

このエラーは、ローカルセキュリティポリシー設定「組み込み Administrator アカウントのための管理者承認モード」が有効になっていないために発生します。このポリシーは [有効] に設定する必要があります。

1. Win+R を押して「ファイル名を指定して実行」ダイアログボックスを開き、gpedit.msc と入力してローカルグループポリシーエディターを実行します。

2. ローカルグループポリシーエディターのペインで、[コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカルポリシー] > [セキュリティオプション] に移動します。右側のペインで、[ユーザーアカウント制御: 組み込み Administrator アカウントのための管理者承認モード] を見つけ、そのステータスを [有効] に変更します。

ローカル SQL Server のバックアップクライアントインストールに失敗した場合の解決方法

1. サーバーにログインし、バックアップログを表示します。

   Windows クライアントのログパス：C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. ログで、タスクが失敗した時刻周辺のエントリを確認します。

   バックアップログにエラーメッセージ Failed to install dbackup3-agent service, errno=1783, The stub received bad data が含まれている場合、システムがインストールを拒否した可能性があります。ウイルス対策ソフトウェアやセキュリティソフトウェアがインストールをブロックしていないか確認し、ブロック記録を確認してください。インストールプログラムをホワイトリストに追加するか、セキュリティソフトウェアを一時的に無効にしてから、再度インストールを試みてください。

ECS インスタンスで Database Backup クライアントのインストールに失敗した場合の解決方法

クライアントが正常にインストールされるように、次の 2 つの項目を確認してください：

1. クラウドアシスタントのステータス：クラウドアシスタントが正しくインストールされ、実行されていることを確認します。

   インストールが失敗した場合、クラウドアシスタントコンソールで失敗したコマンドレコードを見つけます。コマンドをコピーし、ECS ホストで手動で実行します。手動インストール中に、ネットワーク接続の問題やシステムスクリプトの実行エラーが発生した場合、画面に特定のエラーメッセージが表示されます。これらのメッセージを使用して、ネットワーク設定の調整などの問題を解決します。

   すべての問題を解決し、スクリプトが正常に実行されると、クライアントがインストールされます。その後、コンソールで再度インストールをトリガーしてプロセスを完了します。

2. C ドライブの空き領域：C ドライブに十分な空き領域があることを確認します。空き領域が不足していると、クライアントがインストールされない可能性があります。

ローカルデータベースバックアップの無料トライアルの入手方法

ローカルデータベースバックアップの無料トライアルは、ECS データベースバックアップの無料トライアルと同じです。無料トライアルの詳細については、「30 日間の無料トライアル」をご参照ください。

ローカルデータベースバックアップのネットワーク要件

ローカルデータベースサーバーは、専用回線または VPN を介して Alibaba Cloud の VPC (Virtual Private Cloud) に接続する必要があります。ルーティングは、オンプレミスからクラウドの 100.64.0.0/10 または 100.64.0.0/11、100.96.0.0/11 に設定する必要があります。

リアルタイムバックアップの最小間隔と増分バックアップとの併用設定について

リアルタイムバックアップは、理論的には秒単位の目標復旧時点 (RPO) を達成でき、現在 MySQL と Oracle データベースをサポートしています。リアルタイムバックアップを有効にすると、従来のログバックアップを別途設定することはできません。ただし、増分バックアップと併用して、データ保護ポリシーをさらに強化することは可能です。

データベースバックアップのユーザー名とパスワードの変更方法

バックアッププロセス中に、パスワードの有効期限が切れた場合など、重新激活 を使用してバックアップ資格情報を変更します。再アクティブ化は既存のバックアッププランには影響しません。ただし、進行中のバックアップジョブには影響します。影響を最小限に抑えるには、次の操作を行います：

1. [バックアッププラン] タブで、リアルタイムログバックアップを一時停止します。

2. データベースの [操作] 列で、[その他] > 重新激活 を選択します。

Database Backup は暗号化されていますか？

Database Backup は、転送中のデータと保存データの両方で暗号化を使用します。これにより、クラウドでの潜在的なセキュリティリスクからデータを保護できます。

• 転送中の暗号化：デフォルトで SSL/TLS を使用した HTTPS を使用します。SSL/TLS は、通信する 2 つのアプリケーション間の機密性とデータ整合性を提供します。

• 保存データの暗号化：Cloud Backup は、AES-256 アルゴリズムと顧客管理キーを使用して、バックアップボールト内のバックアップデータを暗号化します。

データベースバックアップに失敗した場合の解決方法

Oracle の増分バックアップが完全バックアップと同等かそれ以上の時間がかかる場合の解決方法

• 症状

  増分バックアップとログバックアップにかかる時間が、完全バックアップの時間に近いか、それを超えることがあります。

• 解決策

  Oracle データベースでブロック変更トラッキング (BCT) を有効にします。BCT は、データブロックへの変更を追跡することで RMAN の増分バックアップを高速化する機能です。これにより、バックアップ時間が短縮されます。この設定はデフォルトで無効になっており、RMAN の増分バックアップを高速化する能力を活用するには、手動で有効にする必要があります。

  BCT の長所と短所

  長所

  短所

  RMAN 増分バックアップの高速化 BCT ファイルはデータブロックの変更を記録します。RMAN の増分バックアップ中、RMAN はデータベース全体をスキャンする必要がなく、BCT ファイルを通じて変更されたブロックを特定するだけです。大規模なデータベースの場合、これにより増分バックアップ時間が 90% 以上短縮されることがあります。たとえば、1 TB のデータベースの全表スキャンには 1 時間かかるかもしれませんが、BCT を使用すると数分で増分バックアップを完了できます。 I/O 負荷の軽減 物理的な読み取りを削減します。バックアッププロセス中、BCT ファイルが直接読み取られるため、全表スキャンを回避し、バックアップが本番環境に与える影響を軽減します。 低いリソース消費 追加のメモリオーバーヘッドはほとんどありません。BCT ファイルは通常、数百 MB しか必要としません (たとえば、1 TB データベースの BCT ファイルは約 100 MB から 200 MB です)。 互換性 すべての Oracle バージョン (10g R2 以降) をサポートします。Oracle 12c 以降では、冗長構成 (フォールトトレランスを向上させるための複数の BCT ファイルレプリカ) をサポートします。

  追加のディスク領域使用量 ファイルサイズ：数百 MB にすぎませんが、ストレージパスに十分なスペースがあることを確認してください。 冗長構成：複数のレプリカ (たとえば REDUNDANCY 2) を構成すると、ディスク使用量は 2 倍になります。 軽微なパフォーマンスへの影響 書き込み操作のオーバーヘッド：データブロックが変更されるたびに BCT ファイルを更新する必要があり、書き込み負荷の高いシステムではパフォーマンスにわずかな影響を与える可能性があります。 テストシナリオ：1 秒あたり数万のトランザクションを処理するオンライントランザクション処理 (OLTP) システムでは、BCT のパフォーマンスへの影響は通常無視できます。ただし、極端な高並行性シナリオでは監視が必要です。 ファイル破損のリスク 単一障害点：BCT ファイルが破損し、冗長性が構成されていない場合、増分バックアップが失敗する可能性があります。 修復の複雑さ：BCT を再有効化し、ファイルを再構築する必要があり、短いダウンタイムが必要になる場合があります。

  BCT を有効にすることが推奨されるシナリオ：

  • 頻繁な増分バックアップ：毎日または毎時 RMAN 増分バックアップを実行するシステム。

  • 大規模データベース：テラバイト規模のデータベースの増分バックアップ時間の最適化。

  • 高い可用性要件：高速なリカバリを必要とし、増分バックアップに依存する本番環境。

  BCT を慎重に有効にすべきシナリオ：

  • 非常に小規模なデータベース：1 GB 未満のデータベースでは、BCT の利点はそれほど大きくない場合があります。

  • 極端な高書き込み負荷：1 秒あたり数万のトランザクションを処理する OLTP システムでは、パフォーマンスへの影響を考慮する必要があります。

  • 限られたストレージスペース：ディスクスペースが限られている場合、BCT ファイルのストレージ要件を評価する必要があります。

Oracle の増分バックアップ中に RMAN が致命的でないエラーを報告する場合

• 現象

  Oracle の完全バックアップは成功しますが、増分バックアップは一貫して失敗します。次のエラーメッセージが報告されます：

  oracle.phxxdb.18472|RMAN reports a non-fatal error:
  ORA-19505: failed to identify file "/arch/1_5137021_976544044.dbf"
  ORA-27037: unable to obtain file status
  Linux-x86_64 Error: 2: No such file or directory
  Additional information: 3

• 原因

  必要なアーカイブ済みログが見つかりません。この問題は、別のスクリプトまたはバックアップジョブがアーカイブ済みログを移動した場合に発生する可能性があります。他のバックアップスクリプトまたはソフトウェアが Cloud Backup と同時に実行されると、これらの外部プロセスがアーカイブ済みログの場所を変更する可能性があります。これにより、Cloud Backup の増分バックアップは必要なファイルを見つけられないため失敗します。

• ソリューション

  Cloud Backup を他のバックアップソフトウェアやスクリプトと同時に使用しないでください。これにより、バックアップが失敗したり、回復不能になったりする可能性があります。

SQL Server 2019 のバックアップ中にデータベース詳細の参照に失敗した場合の解決方法

• 現象

  SQL Server 2019 のバックアッププランを作成または編集し、データベースインスタンスを選択すると、コンソールに「Failed to list unibackup instance detail」というエラーメッセージが表示されます。

• 原因

  SQL Server 2019 をバックアップする際、他のバックアップソフトウェアやスクリプトが同時にバックアップ操作を実行していると、バックアッププランの作成または編集時にデータベースインスタンスを選択してデータベースの詳細を閲覧すると失敗することがあります。

• ソリューション

  1. C:\ProgramData\scutech\dbackup3\agent\mssql\(local)\data.db ファイルを削除します。

  2. services.msc で、dbackup3-agent サービスを見つけて再起動します。

Cloud Backup コンソールでローカル SQL Server の IP アドレスが正しくない場合の解決方法

• 現象

  ローカルの SQL Server データベースを Cloud Backup に登録した後、Cloud Backup コンソールに表示される IP アドレスがローカルマシンの IP アドレスと一致しません。この問題は、ローカルクライアントのステータスが正常で、ローカルマシンの IP アドレスが変更されていない場合でも発生する可能性があります。

• 原因

  この問題は、複数のネットワークインターフェースカードがある環境で発生します。なぜなら、Cloud Backup が未使用のネットワークインターフェースカードから IP アドレスを取得するためです。

• ソリューション

  未使用のネットワークインターフェースカードを無効にしてから、クライアントを再インストールしてください。

TDE (透過的データ暗号化) を有効にした後、SQL Server データベースを Alibaba Cloud にバックアップできますか？

なし。

SQL Server のランサムウェア対策を展開後にクライアントがオフラインになり、アンインストールやランサムウェア対策ポリシーの削除ができない問題の解決方法

• 現象

  SQL Server データベースにランサムウェア対策サービスを展開した後、クライアントがオフラインになり、ランサムウェア対策ポリシーが削除できず、クライアントもアンインストールできません。

  この時点で、Windows タスクマネージャーの dbackup3-agent サービスは停止しており、エージェントログには「Stopping all jobs」のようなエントリが含まれています。

  

• 原因

  クライアントがウイルス対策ソフトウェアによってブロックされています。対応する時刻にウイルス対策ソフトウェアに関連するブロック記録がないか確認してください。

• ソリューション

  ウイルス対策ソフトウェアの信頼リストにクライアントを追加し、クライアントサービスを再起動するか、クライアントを再インストールしてください。

ECS インスタンスを新しいアカウントに移行後、Database Backup のインストールまたは使用に失敗した場合の解決方法

ECS インスタンスを元の Alibaba Cloud アカウントから新しいアカウントに移行しても、ECS メタデータは Cloud Backup サービスに自動的に同期されません。機能をインストールして使用する前に、まず Cloud Backup サービスのバックエンドで同期を完了する必要があります。具体的な手順については、「Cloud Backup サポート」に連絡するか、「Cloud Backup オンラインサポート」DingTalk グループに参加して支援を求めてください。

• Cloud Backup テクニカルサポートグループ

  コスト、機能、使用方法に関する質問に迅速に回答を得られます。公開 DingTalk グループを検索して参加してください。DingTalk グループ番号は 88650005148 です。

• Cloud Backup エキスパートサポート

  技術専門家がオンサイト分析を提供し、製品の問題を迅速に解決します。Cloud Backup サポートに連絡するにはクリックしてください。Chrome を使用してください。DingTalk の連絡先を追加してください。DingTalk ID は d37_g935gslgo です。

バックアップ対象の MySQL データベースのバージョンとオペレーティングシステムに制限はありますか？

はい、あります。サポートされるデータベースのバージョン、オペレーティングシステム、バックアップ機能には制限が適用されます。たとえば、Windows にデプロイされた MySQL データベースはサポートされていません。詳細については、「互換性リストと制限事項」をご参照ください。

MySQL で新しく作成したデータベースをバックアップする方法

MySQL のバックアップはデータベースインスタンスレベルで実行されます。新しいデータベースに対して手動でバックアップを設定する必要はありません。次回のバックアップで新しいデータベースが自動的に含まれます。

データベースバックアップのキャンセル方法

バックアップ履歴に重複した、または予期しない時刻のレコードが表示される理由

この問題は通常、Database Backup クライアントがインストールされているサーバー (ローカルサーバーまたは ECS インスタンス) がクローンされた場合、または同じバックアップクライアントを含むイメージから新しい ECS インスタンスまたはローカルサーバーが作成された場合に発生します。クローンされたサーバーは元のサーバーのクライアント情報の一部を保持しているため、重複したバックアップレコードが生成される可能性があります。この問題を解決するには、クローンされたサーバーにログインし、クライアントをアンインストールします。バックアップクライアントのアンインストール方法の詳細については、次の手順をご参照ください：

バックアップが失敗し、バックアッププランのステータスが「エラー」と表示される理由

バックアッププランのステータスが「エラー」でバックアップが失敗した場合、まずクライアントがインストールされているサーバー (ローカルサーバーまたは ECS インスタンス) がクローンされたか、オペレーティングシステムが再インストールされたか、システムディスクがリセットされたかを確認してください。これらの操作により、バックアッププランとクライアントの関連付けが無効になる可能性があります。この問題を解決するには、次の手順に従ってください：

1. クローンされたサーバーからクライアントとその設定ファイルをアンインストールしたことを確認してください。詳細については、「クライアントのアンインストール」をご参照ください。

2. 現在のサーバーのクライアントステータスが「インストール済み」であることを確認してください。

   

3. 上記の手順を完了した後、コンソールから元のバックアッププランを削除し、新しいバックアッププランを作成してください。

アラート時刻と実際のエラー時刻が異なる理由

ショートメッセージアラートには夜間抑制機能があり、午後 8 時から翌朝 8 時までにトリガーされたアラートは、午前 8 時以降まで遅延されます。メールアラートはこの機能の影響を受けず、すぐに送信されます。

失敗のアラートメールやショートメッセージを受信したのに、バックアップ履歴に成功と失敗の両方のレコードが同時に表示される理由

この問題は通常、Database Backup クライアントがインストールされているサーバー (ローカルサーバーまたは ECS インスタンス) がクローンされた場合、または同じバックアップクライアントを含むイメージから新しい ECS インスタンスまたはローカルサーバーが作成された場合に発生します。クローンされたサーバーは元のサーバーのクライアント情報の一部を保持しているため、重複したバックアップレコードが生成される可能性があります。この問題を解決するには、クローンされたサーバーにログインし、クライアントをアンインストールします。バックアップクライアントのアンインストール方法の詳細については、次の手順をご参照ください：

「オフラインインスタンスのみ表示」機能の説明

[オフラインインスタンスのみ表示] 機能は、クライアントが元のインスタンスサーバーに接続できなくなったり、バックアップデータを復元できなくなったりした場合に役立ちます。これは、クライアントマシンのオペレーティングシステムが再インストールされた場合や、悪意のあるソフトウェアによってクライアントプロセスと設定が削除された場合に発生する可能性があります。このような状況で新しいクライアントをインストールすると、システムは新しいインスタンス ID を割り当て、新しいクライアントをオフラインのクライアントと区別して混乱を防ぎます。その後、オフラインインスタンスから新しいクライアントインスタンスにデータを復元します。復元の手順の詳細については、「MySQL の復元」、「Oracle の復元」、「SQL Server の復元」をご参照ください。

SQL Server データベースの復元に失敗した場合の解決方法

1. サーバーにログインし、バックアップログを表示します。

   Windows クライアントのログパス：C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. ログで、タスクが失敗した時刻周辺のエントリを確認します。

   バックアップログにキーワード RestoreContainer::ValidateTargetForCreation が含まれている場合、同じ名前のデータベースを復元する際に、パスのみを変更し、データベース名を変更しなかったことを示します。これにより、名前の競合が発生し、復元操作が失敗しました。データベースを正常に復元するには、データベース名とパスの両方を変更する必要があります。

エージェントログにファイル初期化エラーが示された場合の SQL Server リカバリ失敗の解決方法

• 現象

  SQL Server のリカバリが失敗すると、エージェントログにファイルが初期化に失敗したことが示されます。ログには次の詳細が含まれています：

  2025-11-10 11:25:53.967@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: 100 percent processed.
  2025-11-10 11:25:53.968@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 51595000 pages for database 'xxx', file 'xxx' on file 1.
  2025-11-10 11:25:53.985@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 3865 pages for database 'xxx', file 'xxx_log' on file 1.
  2025-11-10 11:25:53.987@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: File "xxx_log" failed to initialize correctly. See the error log for details.
  2025-11-10 11:25:53.989@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: RESTORE DATABASE is terminating abnormally.

  さらに、SQL Server のエラーログには the file "xxx_log" failed to initialize correctly というメッセージが報告されます。

  

• 原因

  SQL Server 2008 R2 上のソースデータベースが以前に暗号化されていた場合、暗号化を無効にしても残留情報が残る可能性があります。このデータベースをバックアップし、バックアップセットを別のインスタンスに復元すると、初期化エラーが発生します。分析プロセスは次のとおりです：

  説明

  ソースデータベースが SQL Server 2008 R2 で、TDE (透過的データ暗号化) が有効になっている場合、ターゲットインスタンスが SQL Server 2014 などの新しいバージョンであってもリカバリ操作は失敗します。「証明書が見つかりません」というエラーメッセージが返されます。リカバリを完了するには、証明書と秘密鍵を手動で復元する必要があります。

  1. SQL Server のエラーログからデータベースのバージョンを確認します。

     

  2. この問題は TDE に関連している可能性が高いです。ソースデータベースで TDE が有効になっているかどうかを確認します。また、最近暗号化の無効化などの操作が実行されたかどうかも確認します。

     ソースデータベースで次の SQL 文を実行します。クエリ結果の key_algorithm および key_length フィールドが NULL でない場合、データベースは過去に暗号化されていた可能性が高いです。

     USE master;
     SELECT 
         d.name,
         d.is_encrypted,
         drs.database_id,
         drs.encryption_state,
         drs.percent_complete,
         drs.key_algorithm,
         drs.key_length
     FROM sys.databases AS d
     LEFT JOIN sys.dm_database_encryption_keys AS drs
         ON d.database_id = drs.database_id;

     次の図は、クエリ結果のサンプルを示しています。

     

• ソリューション

  • ソースデータベースを新しいバージョンにアップグレードし、新しいバックアップを作成します。新しいバックアップセットを使用してリカバリを実行します。以前のバックアップセットは無効です。

  • ソースインスタンスからターゲットインスタンスに秘密鍵と証明書を復元し、リカバリ操作を実行します。

    リカバリが完了したら、ターゲットインスタンスから TDE 暗号化証明書とデータベース暗号化キーを削除します。その後、ターゲットインスタンスをバックアップします。ターゲットインスタンスでの後続のバックアップおよびリカバリ操作は正常に機能します。

    説明

    TDE が無効になった後に作成されたデータバックアップであっても、リカバリプロセスには秘密鍵と証明書が必要です。これらは、バックアップ内の残留暗号化メタデータを処理するために必要です。ただし、復元されたデータベースは暗号化されていません。その後、データベースは証明書なしで正常に実行できます。

    # ソースインスタンスで次の操作を実行します
    USE master;
    
    # 1. TDE 暗号化データベースの証明書名をクエリします
    SELECT d.name AS DatabaseName,
           k.encryption_state,
           c.name AS CertificateName
    FROM sys.dm_database_encryption_keys AS k
    JOIN sys.certificates AS c
        ON k.encryptor_thumbprint = c.thumbprint
    JOIN sys.databases AS d
        ON k.database_id = d.database_id
    
    # 結果の CertificateName が TDECert であると仮定します。TDE 証明書と秘密鍵をカスタムパスにバックアップします。
    BACKUP CERTIFICATE TDECert
       TO FILE = 'C:\Backup\TDECert.cer'  -- カスタムファイルパスを指定します
       WITH PRIVATE KEY (
            FILE = 'C:\Backup\TDECert_PrivateKey.pvk',    -- カスタムファイルパスを指定します
            ENCRYPTION BY PASSWORD = 'Strong_Password_123!'    -- このパスワードを覚えておいてください
       );
    
    -- 上記のパスから証明書と秘密鍵をターゲットインスタンスにコピーします
    
    # 2. ターゲットインスタンスで次の操作を実行します
    USE master;
    
    # マスターキーを復元します。「マスターキーはデータベースに既に存在します。このステートメントを実行する前にマスターキーを削除してください。」というメッセージが返された場合は、この手順をスキップします。
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Another_Strong_Password_456!';
    
    # TDE 証明書を復元します
    CREATE CERTIFICATE TDECert -- カスタム証明書名を指定します。後で削除に使用します。
        FROM FILE = 'C:\TDE_Test\TDECert.cer' -- コピーしたファイルがあるパス
        WITH PRIVATE KEY (
            FILE = 'C:\TDE_Test\TDECert_PrivateKey.pvk',
            DECRYPTION BY PASSWORD = 'Strong_Password_123!'  -- 秘密鍵のバックアップに使用したパスワード
        );
    
    
    # 3. Cloud Backup コンソールで通常どおりリカバリ手順を実行します
    
    
    # 4. リカバリ後、データベース暗号化キーを削除します
    USE TDE_TestDB_Restore -- ターゲットデータベースの名前
    DROP DATABASE ENCRYPTION KEY;
    
    # 5. 証明書を削除します
    USE master;
    DROP CERTIFICATE TDECert;

ローカルデータベースと ECS データベース間でクロスデータベース復元を実行する方法

直接の相互復元はサポートされていません。ECS インスタンス上のデータベースをローカルデータベースインスタンスとして登録します。登録後、異なるローカルデータベースインスタンス間でデータを復元します。

データベースバックアップボールトとは

データベースバックアッププランを作成する前に、データベースバックアップボールトを作成する必要があります。

データベースバックアップボールトは、データベースのバックアップデータを保存するストレージボールトです。データベースバックアップのコストは、ボールトのレンタル料金とボールトの容量によって決まります。詳細については、「課金方法と課金項目」をご参照ください。

データベースバックアップボールトでの期限切れデータの消去方法

増分バックアップ、累積増分バックアップ、およびログバックアップは、先行する完全なバックアップチェーンに依存します。バックアップチェーンには、先行する完全バックアップと、任意の増分、累積増分、またはログバックアップが含まれます。完全バックアップと増分、累積増分、およびログバックアップを含むバックアップチェーンでは、完全なバックアップチェーンが依存するすべてのバックアップは、チェーンの最後のバックアップが期限切れになるまでバックアップボールトに保持され、バックアップスペースを占有します。バックアップサイクルと有効期限を合理的に設定する必要があります。

たとえば、9 月 1 日に完全バックアップを実行し、9 月 2 日から 9 月 7 日まで毎日増分バックアップを実行します。保持期間は 7 日間です。9 月 1 日から 9 月 7 日までの 7 つのバックアップは、すべてのデータが 9 月 14 日に期限切れになった後、自動的に削除されます。

バックアップデータサイズとバックアップボールト使用量の確認方法、および課金の基準

[ソースデータサイズ] は、バックアップされたデータの総量です。たとえば、1 TB のファイルを 2 回バックアップした場合、ソースデータサイズは 2 TB になります。Cloud Backup は、重複排除と圧縮を使用してバックアップボールトの使用量を削減し、コストを低減します。課金は、実際の [ストレージボールトデータサイズ] に基づいて行われます。データベースバックアップボールトの [ソースデータサイズ] と [ストレージボールトデータサイズ] は、[ボールト管理] ページで確認できます。