Cloud Backup：Database Backup常見問題

在执行历史中發現狀態為错误。

建議您按照以下步驟處理：

1. 登入ECS執行個體或者本機伺服器，查看MySQL服務狀態。參考命令為systemctl status mysqld，正常的服務狀態為active，inactive為不正常狀態。若為inactive，建議重啟後嘗試。

2. 確認資料庫使用者名稱和密碼及其許可權配置是正確的。密碼到期、使用者權限變更後許可權不足，也會導致此問題。

   您註冊資料庫時輸入的数据库用户名不正確、許可權不足或者密碼錯誤，確認使用者名稱和密碼正確後，請為該備份帳號添加足夠的許可權。建議您建立專門用於備份的使用者。

   該使用者所具備的最小許可權集為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，則版本29292的MySQL備份用戶端在執行恢複任務時，會因磁碟空間不足而失敗。增量備份的檔案需要恢複到緩衝，可以通過建立軟連結的方式把儲存路徑指向其他磁碟，以緩解空間不足的情況。

   • 當控制台上顯示記錄備份狀態為“錯誤”，且日誌出現@LM_ERROR@agent|To backup binlog in slave node needs to set log_slave_updates to ON關鍵字，表示備份的節點是從庫（slave 節點）。為了正常進行記錄備份，需要設定配置項 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環境變數未設定或設定錯誤導致無法串連Oracle，您可以通過sqlplus命令並使用sysdba許可權嘗試登入。正確配置ORACLE_SID環境變數後，如果能夠成功登入，則問題得到解決。

   • 如果出現sbtclose2 returned error-failed to close file關鍵字，則是本地時間和伺服器時間相差過大，或者系統時區設定不正確。建議您修改資料庫所在伺服器的時間，然後重啟dbackup3-agent服務，重啟步驟，請參見如何查看用戶端的進程狀態，日誌路徑，以及如何重啟用戶端。

   • 如果出現Failed to probe oracle instances關鍵字，則可能有兩個原因：

     • 安裝用戶端時Oracle執行個體未啟動。

       建議您重啟dbackup3-agent服務。重啟步驟，請參見如何查看用戶端的進程狀態，日誌路徑，以及如何重啟用戶端

     • ORACLE_HOME環境變數配置不正確。

       1. 針對Linux系統：/etc/init.d/dbackup3-agent config oracle 然後輸入實際$ORACLE_HOME路徑。

       2. 重啟dbackup3-agent服務。重啟步驟，請參見如何查看用戶端的進程狀態，日誌路徑，以及如何重啟用戶端。

   • 如果出現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關鍵字，則是因為安裝雲備份用戶端的伺服器時間與雲備份伺服器的時間不一致。

     解決方案：

     1. 檢查和同步時間：為了確保伺服器時間與國際標準時間（UTC）同步，建議使用NTP（網路時間協議）服務進行自動同步。在Linux系統上，您可以使用ntpdate或chrony命令來同步時間，可以通過sudo ntpdate pool.ntp.org命令進行手動同步。

     2. 檢查時區設定：為確保時區設定正確，可以使用命令timedatectl 來查看和設定時區。

     3. 請重啟備份用戶端，然後在雲備份控制台中重新執行備份操作。重啟步驟，請參見如何查看用戶端的進程狀態，日誌路徑，以及如何重啟用戶端。

使用Cloud Backup備份SQL Server時，備份失敗。建議您按照以下步驟處理：

1. 登入伺服器，查看備份日誌。

   Windows用戶端日誌路徑位於：C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. 在日誌中，根據控制台上報錯記錄對應的時間段列（即開始時間和結束時間），尋找並分析失敗任務發生時間附近的日誌。備份日誌中若出現以下報錯提示，請參考以下方案進行處理：

   • 報錯：該登入名稱沒有足夠的許可權。

     問題分析：SQL Server備份使用者權限不足。

     解決方案：請檢查備份帳號及許可權。具體操作，請參見步驟二：建立備份帳號和配置許可權。

   • 報錯：使用者 'xxx' 登入失敗。

     問題分析：SQL Server備份使用者的密碼已到期 (Error Code: 18487, SQL State: 28000)。

     解決方案：在SQL Server中修改備份使用者的密碼，然後登入雲備份控制台，在對應資料庫的操作列，選擇更多>重新激活。

     

   • 報錯：無法覆蓋檔案。

     問題分析：SQL Server資料庫復原路徑被其他資料庫佔用。

     解決方案：建立恢複任務，按指定備份恢複時，雙擊修改復原路徑。

     

   • 報錯：目標SQL Server資料庫不存在。請確保正確地輸入該名稱。

     問題分析：目標SQL Server資料庫不存在。

     解決方案：請確認目標資料庫是否存在。如果資料庫已經不存在，請編輯備份計劃，移除對應資料庫。

   • 報錯：因為該資料庫參與了資料庫鏡像會話或可用性群組。某些操作不允許對正在參與資料庫鏡像會話或可用性群組的資料庫執行。

     問題分析：SQL Server資料庫啟用了SQL Server AlwaysOn。

     解決方案：目標執行個體沒有綁定AlwaysOn叢集，要選擇對應的叢集。

   • 報錯：因為該資料庫已配置用於資料庫鏡像或已串連到某一可用性群組。如果想要還原該資料庫，請使用ALTER DATABASE刪除鏡像或從其可用性群組中刪除該資料庫。

     問題分析：SQL Server資料庫啟用了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發送日誌），以擷取進一步的支援人員。

        • Cloud Backup支援人員群

          快速諮詢費用、功能和使用等問題。點擊加入雲備份線上諮詢（建議使用Chrome開啟）。請搜尋公開群組並加入，DingTalk群號：88650005148。

        • Cloud Backup專家支援

          技術專家現場分析，快速解決產品問題。點擊聯絡雲備份支援（建議使用Chrome開啟）。請添加DingTalk好友，DingTalk號：d37_g935gslgo。

1. 登入伺服器，查看備份日誌。

   Windows用戶端日誌路徑：C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. 在日誌中，查看失敗任務發生時間附近的日誌。備份日誌中若出現以下報錯提示，請參考以下方案進行處理：

   • 如果出現 RestoreContainer::ValidateTargetForCreation關鍵字，則表示您在恢複同名庫時，僅修改了路徑而未更改庫名，導致庫名衝突，從而使恢複操作失敗。為成功恢複，建議同時修改庫名和路徑。