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

実行履歴 タブで、MySQL データベースバックアップジョブのステータスが エラー です。

エラーを解決するには、次の手順を実行することをお勧めします。

1. ECS インスタンスまたはオンプレミスサーバーにログインし、MySQL データベースサービスのステータスを確認します。たとえば、systemctl status mysqld コマンドを実行して、サービスステータスを確認できます。値 active は、サービスステータスが正常であることを示します。値 inactive は、サービスステータスが異常であることを示します。サービスステータスが inactive の場合は、サービスを再起動して、サービスステータスをもう一度確認することをお勧めします。

2. データベースのユーザー名とパスワード、および関連するユーザー権限が正しく構成されていることを確認します。パスワードの期限が切れているか、ユーザー権限が変更されて不十分になっている場合、MySQL データベースバックアップの失敗が発生する可能性があります。

   データベースを登録するときに、数据库用户名 または [パスワード] に指定した値が正しくないか、必要な権限がありません。指定したユーザー名とパスワードが正しいことを確認した後、バックアップアカウントに必要な権限を付与してください。専用のバックアップアカウントを作成することをお勧めします。

   ユーザーの最小権限セットは、RELOAD、LOCK TABLES、REPLICATION、および PROCESS です。

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

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

   • uploadPart SecurityTokenExpired が表示された場合は、ローカル時間が正しくないため、修正する必要があります。

   • ib_logfile0 が表示された場合は、復元ジョブが完了していないときに復元操作が再実行されます。その結果、ib_logfile0 は削除されますが再構築されず、後続のバックアップは失敗します。

   • Error: failed to execute query LOCK TABLES FOR BACKUP: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation が表示された場合は、バックアップアカウントに必要な権限がありません。バックアップジョブを実行するには、少なくとも RELOAD、LOCK TABLES、REPLICATION、および PROCESS の権限が必要です。MySQL 8.0 では、BACKUP_ADMIN 権限も必要です。

   • no space left on device が表示された場合は、ディスク容量不足のため、MySQL バックアップ用のバージョン 29292 の Cloud Backup クライアントでの復元ジョブが失敗します。増分バックアップファイルをキャッシュに復元する必要があります。ストレージパスを他のディスクにポイントするシンボリックリンクを確立して、ディスク容量を節約できます。

   • コンソールでログバックアップステータスがエラーで、ログに @LM_ERROR@agent|To backup binlog in slave node needs to set log_slave_updates to ON が表示された場合は、バックアップノードはスレーブノードです。ログバックアップを正しく実行するには、設定項目 log_slave_updates=1 を設定して、この項目を有効にする必要があります。設定項目を設定した後、ログバックアップを実行する前に完全バックアップを実行することをお勧めします。

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

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

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

2. ジョブが失敗した時刻前後に生成されたログを表示します。対応する解決策に基づいてエラーを解決します。

   • ORA-12560: TNS:protocol adapter error が表示された場合は、ORACLE_SID 環境変数が設定されていないか、正しく設定されていないかを確認します。sqlplus コマンドを実行し、sysdba 権限を使用して Oracle データベースにログインしてみてください。ORACLE_SID 環境変数を正しく構成した後に Oracle データベースにログインできる場合は、問題は解決しています。

   • sbtclose2 returned error-failed to close file が表示された場合は、ローカル時間とサーバー時間の差が大きい、またはシステムタイムゾーンが正しく設定されていません。データベースが存在するサーバーの時刻を変更してから、dbackup3-agent サービスを再起動することをお勧めします。サービスの再起動方法の詳細については、「Cloud Backup クライアントのプロセスステータスとログパスを表示し、クライアントを再起動するにはどうすればよいですか?」をご参照ください。

   • Failed to probe oracle instances が表示された場合は、次の原因が考えられます。

     • クライアントのインストール中に Oracle インスタンスが起動されていません。

       dbackup3-agent サービスを再起動します。サービスの再起動方法の詳細については、「Cloud Backup クライアントのプロセスステータスとログパスを表示し、クライアントを再起動するにはどうすればよいですか?」をご参照ください。

     • ORACLE_HOME 環境変数が正しく設定されていません。

       1. Linux では、/etc/init.d/dbackup3-agent config oracle ファイルに実際の $ORACLE_HOME パスを入力します。

       2. dbackup3-agent サービスを再起動します。サービスの再起動方法の詳細については、「Cloud Backup クライアントのプロセスステータスとログパスを表示し、クライアントを再起動するにはどうすればよいですか?」をご参照ください。

   • ORA-12154: TNS:could not resolve the connect identifier specified が表示された場合は、パスワードに特殊文字が含まれています。その結果、検証が失敗し、バックアップが失敗します。

   • ORA-01017: invalid username/password; logon denied が表示された場合は、正しいユーザー名とパスワードを使用してデータベースを再アクティブ化してから、バックアップを実行します。

   • The difference between the request time and the current time is too large が表示された場合は、Cloud Backup クライアントがインストールされているサーバーの時刻と Cloud Backup サーバーの時刻が一致していません。

     解決策:

     1. 時刻を確認して同期する: サーバー時刻が協定世界時 (UTC) と同期していることを確認するには、Network Time Protocol (NTP) を使用して時刻を自動的に同期することをお勧めします。Linux では、ntpdate または chrony コマンドを実行して時刻を同期できます。sudo ntpdate pool.ntp.org コマンドを実行して、手動で時刻を同期することもできます。

     2. タイムゾーン設定を確認する: タイムゾーンが正しく設定されていることを確認するには、timedatectl コマンドを実行してタイムゾーンを表示および設定します。

     3. Cloud Backup クライアントを再起動し、Cloud Backup コンソールでバックアップを再実行します。サービスの再起動方法の詳細については、「Cloud Backup クライアントのプロセスステータスとログパスを表示し、クライアントを再起動するにはどうすればよいですか?」をご参照ください。

Cloud Backup を使用して SQL Server データベースをバックアップすると、バックアップが失敗します。エラーを解決するには、次の手順を実行することをお勧めします。

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

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

2. エラーレコードの関連する時間範囲 (開始時刻と終了時刻を含む) に基づいて、ジョブが失敗した時刻前後に生成されたログを表示します。対応する解決策に基づいてエラーを解決します。

   • エラーメッセージ: アカウントに必要な権限がありません。

     原因: アカウントに SQL Server データベースをバックアップするために必要な権限がありません。

     解決策: バックアップアカウントとアカウントの権限を確認します。詳細については、「手順 2: バックアップアカウントを作成し、権限を構成する」をご参照ください。

   • エラーメッセージ: ユーザー xxx のログインに失敗しました。

     原因: SQL Server データベースバックアップのユーザーのパスワードの期限が切れています (エラーコード: 18487、SQL 状態: 28000)。

     解決策: SQL Server でユーザーのパスワードを変更します。次に、Cloud Backup コンソールにログインし、データベースの [アクション] 列で [その他] > 重新激活 を選択します。

     

   • エラーメッセージ: ファイルを上書きできません。

     原因: SQL Server データベースのリカバリパスが別のデータベースによって使用されています。

     解決策: 復元ジョブを作成し、[バックアップポイントタイプ] を [スナップショット別] に設定します。次に、リカバリパスをダブルクリックして変更します。

     

   • エラーメッセージ: SQL Server データベースが存在しません。有効なデータベース名を入力してください。

     原因: SQL Server データベースが存在しません。

     解決策: 指定したデータベースが存在するかどうかを確認します。データベースが存在しない場合は、バックアッププランを変更してデータベースを削除します。

   • エラーメッセージ: データベースはデータベースミラーリングセッションまたは可用性グループに含まれています。データベースミラーリングセッションまたは可用性グループに含まれているデータベースでは、一部の操作を実行できません。

     原因: SQL Server データベースで SQL Server AlwaysOn が有効になっています。ただし、SQL Server データベースは AlwaysOn クラスタに関連付けられていません。

     解決策: 必要な AlwaysOn クラスタを選択します。

   • エラーメッセージ: データベースはデータベースミラーリング用に構成されているか、可用性グループに追加されています。データベースを復元する場合は、ALTER DATABASE ステートメントを実行してイメージを削除するか、可用性グループからデータベースを削除します。

     原因: SQL Server データベースで SQL Server AlwaysOn が有効になっています。ただし、SQL Server データベースは AlwaysOn クラスタに関連付けられていません。

     解決策: 必要な AlwaysOn クラスタを選択します。

   • エラー:

     バックアップジョブが失敗し、コンソールに次のエラーメッセージが表示されます。ジョブが失敗しました。エラー: -1 データベース ""xxx"" のバックアップまたは復元に失敗しました。VDI エラー: "0x80770004"。

     トラブルシューティング:

     1. C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log ディレクトリに切り替え、ログファイルを開きます。エラーレコードの関連する時間範囲 (開始時刻と終了時刻を含む) に基づいて、ジョブが失敗した時刻前後に生成されたログを表示します。

     2. ログに「Failed to receive WebSocket data from x.x.x.x:60305, errno=10054, connection reset」または「Failed to open socket x.x.x.x:60305, errno=10060, connection timed out」が存在する場合は、クライアントとサーバー間の接続が中断されています。ネットワーク接続が正常かどうかを確認します。

     3. 後続のログに「Channel xxxxxxxxxxxxxx is registered」が存在する場合は、クライアントはサーバーに再接続されています。この場合は、新しいバックアップジョブを実行するか、次のジョブスケジューリングが完了するまで待ってから、バックアップジョブを正しく実行できるかどうかを確認します。

     4. バックアップジョブがまだ失敗するか、別の例外が発生する場合は、テクニカルサポート DingTalk グループに参加するか、サービススペシャリストに連絡してください (DingTalk でログを送信できます)。

        • Cloud Backup DingTalk グループ

          相談料、機能、および使用方法の詳細については、クリックして DingTalk グループに参加してください。Chrome を使用することをお勧めします。グループ ID 88650005148 を入力し、[公開グループを検索] をクリックして DingTalk グループを検索して参加することもできます。

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

          オンサイトのテクニカルサポートを受けて、質問を迅速に解決します。クリックして Cloud Backup テクニカルサポートに連絡してください。Chrome を使用することをお勧めします。DingTalk アカウント ID d37_g935gslgo を検索して連絡先を追加することもできます。

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

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

2. ジョブが失敗した時刻前後に生成されたログを表示します。対応する解決策に基づいてエラーを解決します。

   • RestoreContainer::ValidateTargetForCreation が表示された場合は、同じ名前のデータベースを復元するときにパスは変更されますが、データベース名は変更されていません。その結果、データベース名の競合が発生し、復元は失敗します。復元を成功させるには、データベース名とパスの両方を変えることをお勧めします。