已知問題

以下為本版中已知存在的問題：

瀏覽器相關

• 如果您使用 Windows 10 Edge 網頁瀏覽器，則您按一下 [還原] 或 [登入代理程式] 時，而且如果通訊協定為 HTTPS，您可能無法從主控台登入 Windows 或 Linux 代理程式。使用其他瀏覽器登入。

與主控台相關

• 如果 Arcserve Backup 伺服器已安裝在 Windows 2008 x86 或較舊版本的 x86 作業系統上，這類 Arcserve Backup 伺服器無法新增到主控台。
• 如果工作正在進行，而且個別代理程式已重新開機，則主控台不會顯示進行中工作的任何工作歷程。
• 執行自動搜索時，[虛擬層] 欄的 VM 資訊會持續變更。

  症狀

  如果兩台虛擬機器 (VM1 及 VM2) 在 ESXi 主機中有相同的 GUID，而且這兩台 VM 分別由不同 vCenter (VC1 及 VC2) 管理。您將 VM1 匯入主控台 (您無法匯入這兩台 VM，因為主控台不會讓相同 GUID 的節點)。不過，您也 從 vCenter VC2 匯入 VM。自動搜索執行時，首先會連線至 VC1，並按照 GUID 偵測 VM1，然後 [虛擬層] 欄會更新為 VC1 的資訊。然後，它連線到 VC2 時，會按照 GUID 偵測 VM2，然後 [虛擬層] 欄會更新為 VC2 的資訊。

  解決方案

  兩台 VM 很少有相同的 GUID。在最嚴重的情況下，如果發生這種情形，主機型無代理程式備份可能會備份錯誤的 VM，因為 Arcserve UDP 使用 GUID 識別 VM。若要解決此問題，您可以手動變更其中一個 VM 的 GUID。如需如何進行此動作的詳細資訊，請參閱《解決方案指南》中的相關主題。

與 Arcserve UDP 復原點檢視相關

• 在切換成 [Arcserve UDP 復原點檢視] 後，將無法裝載備份工作階段中裝載於檔案路徑下的磁碟區。

  症狀

  如果仍然裝載磁碟區，則 [Arcserve UDP 復原點檢視] 會直接開啟由作業系統 (而非備份工作階段) 所裝載的磁碟區。

  如果已卸載磁碟區，則在該檔案路徑下的 [Arcserve UDP 復原點檢視] 會顯示空白。

  解決方案

  使用 [裝載復原點] 來裝載此類型的磁碟區。

與 Arcserve UDP Agent (Linux) 相關

• 如果您在 Google Chrome 中開啟 Arcserve UDP Agent (Linux)，則 [工作狀態] 索引標籤中的列不會與對應的欄標題對齊。
• 不支援加密的磁碟區。您無法備份加密的磁碟區。
• BMR 不支援 FakeRAID。如果您的備份節點是 RHEL 6.4 或更新版本、CentOS 6.4 或更新版本、Oracle Linux Server 6.4 或更新版本，且備份節點包含 Linux 軟體 RAID，則要從這類復原點執行 BMR 時，必須使用 CentOS 型 Live CD。
• 當您使用 RHEL 6.x 或 CentOS 6.x D2D 伺服器從 RHEL 5.x 或 CentOS 5.x 復原點還原檔案，可能無法還原部份 SELinux (加強安全的 Linux) 屬性。
• 當您將這兩個安裝套件檔案下載到本機資料夾時，這個本機資料夾的完整路徑不得包含任何特殊字元 (空格除外)，且路徑只能包含下列字元：a-z、A-Z、0-9 及 _。
• 如果您提交一個檔案層級還原工作，或使用 [本機] 作為備份目標的 BMR 工作，而您想要將備份目標修改為 NFS 共用區或 CIFS 共用區，您必須先將 NFS 共用區或 CIFS 共用區新增到備份儲存區中。新增 NFS 共用區或 CIFS 共用區後，請開啟 [還原精靈] 並從 [工作階段位置] 下拉式清單中選取 NFS 共用區或 CIFS 共用區，然後再次提交工作。
• 只有 Red Hat 相容核心支援 Oracle Linux。您必須選取 Red Hat 相容核心做為預設的開機核心。不支援 Oracle Unbreakable 核心，且它不應該做為預設的開機核心。
• 如果使用 Live CD 在 Citrix XenServer 6.x 中啟動 PVM，在 Live CD 中不會有 Arcserve UDP Agent (Linux) 伺服器。

與備份相關

• 升級到 Windows 10 之後，系統會移除磁碟區的追蹤驅動程式上層篩選器。BLI 驅動程式無法追蹤磁碟區中的任何變更。因此，[遞增備份] 工作會轉換為 [驗證備份] 工作。
• 操作 VSS 時備份或還原可能失敗。事件 ID 10006、1503 或 6287 可能會顯示在 Windows 事件日誌中。

  症狀

  您可以在事件日誌中找到下列訊息：「在登錄機碼上嘗試的非法作業已標示刪除」或「Windows 已偵測到您的登錄檔案仍然由其他應用程式或服務使用中。將立即卸載檔案。稍後包含您的登錄檔案的應用程式或服務可能無法正常運作」。

  解決方案

  如需原因和解決方案的詳細資訊，請參閱 Microsoft KB 文章 2287297。

• 裝載磁碟區失敗，並出現訊息「Failed to mount recovery point to path:"Z:".Incorrect function." (無法將復原點裝載至路徑 "Z:"。功能不正確)。

  症狀

  將工作階段裝載至磁碟機代號失敗。

  當目標是本機資料夾且是在 FAT32 磁碟區時，就會發生此情況。裝載磁碟機僅支援在 NTFS 磁碟區上建立快取檔案。

  解決方案

  新增登錄機碼，自訂快取檔案路徑為其他磁碟區。

  請按照下列步驟操作：

  1. 在 HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine 上建立機碼 "AFStorHBAMgmt"。
  2. 建立字串值 "CacheFilePath"。

  更多資訊：

  在已裝載可寫入磁碟區的情形下，裝載磁碟機就會建立快取檔案。若是細微還原目錄/還原工作，則會建立可寫入磁碟區。如果工作階段是要備份 Windows 8、Windows 2012 或更新作業系統上的磁碟區，當您將工作階段裝載至磁碟機代號時，請一定要裝載可寫入磁碟區。

• 當您從 Arcserve UDP Agent (Windows) UI 提交備份工作，若備份目標是使用 [復原點伺服器] 上的資料儲存區，備份工作可能不會啟動。

  症狀

  提交的備份會成功顯示，但從 Arcserve UDP Agent (Windows) UI 上看不到任何工作監控器。這是因為備份工作達到資料儲存區的並行節點計數上限設定。備份工作會被放入等候佇列中。

  解決方案

  開啟 Arcserve UDP 主控台，節點檢視中將顯示擱置的工作監控器。

• 如果 Arcserve UDP Agent (Windows) 機器重開機時有備份工作正在執行，在 Arcserve UDP Agent (Windows) 首頁上會將此工作標示為「毀損」，但在 Arcserve UDP 主控台上則沒有此工作的工作歷程。這是因為工作歷程項目是在工作結束時傳送至 Arcserve UDP 主控台，但在重開機的情況下，沒有機會將工作歷程從代理程式傳送到伺服器。
• 工作監控器上以主機為基礎的無代理程式驗證備份工作的壓縮百分比不正確。

  症狀

  以主機為基礎的無代理程式驗證備份工作執行時，如果已經在計劃中啟用壓縮，工作監控器上顯示的壓縮百分比將高於實際百分比。

  其他所有備份工作不會有這個問題，包括代理程式備份工作和以主機為基礎的無代理程式完整/遞增備份工作。

  解決方案

  活動日誌中顯示的壓縮百分比正確無誤。請在以主機為基礎的無代理程式驗證備份工作後加以查閱。

與 BMR 相關

• 建立開機套件失敗，發生下列錯誤：

  「無法將語言套件整合到 BMR ISO 映像中」。

  症狀

  此問題是協力廠商防毒軟體 (McAfee) 篩選驅動程式所造成的，但也有可能會發生在其他協力廠商篩選器。

  解決方案

  停用您的防毒軟體，並再次嘗試開機套件的建立。

• 執行 BMR 之後無法啟動伺服器。

  症狀

  若來源機器是執行 BMR 到含有不同硬體的實體機器，或是到 Hyper-V 伺服器上虛擬機器的 Active Directory 伺服器，該伺服器就不會啟動，並會出現一個藍色畫面來顯示下列訊息：

  停止：c00002e2 目錄服務因發生下列錯誤而無法啟動：附加到系統的裝置並未運作。錯誤狀態：0xc0000001。

  解決方案

  將系統重新啟動為 BMR PE 環境、將 C:\Windows\NTDS 資料夾中的所有 *.log 檔案重新命名，然後重新啟動系統。例如，將 edb.log 檔案重新命名為 edb.log.old，然後重新啟動系統。

• 無法在 BMR 期間將來源磁碟對應到目標磁碟，即使這兩個磁碟的大小完全相同也不例外。

  症狀

  當目標機器是虛擬機器，且其 IDE 磁碟位於 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上時，您可能無法在 BMR 期間對應磁碟/磁碟區。

  如果使用 BMR 將資料還原到其 IDE 磁碟位於 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上的虛擬機器，則系統無法將來源磁碟/磁碟區對應到目標磁碟/磁碟區，即使這兩個磁碟的大小看似完全相同也不例外。這是因為當您在 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上建立 IDE 磁碟時，實際的磁碟大小會小於您所指定的大小。

  解決方案

  在 VM 上建立較大的磁碟。例如，如果您要還原 25 GB 磁碟的資料，建議您在目標 VM 上建立 26 GB 的磁碟。

• 如果您使用 Windows ADK 8.1 來建立 BMR ISO，在使用此 ISO 重新開機之後，可能會發現 PE 系統中偵測不到磁碟。

  症狀

  這是在 VMWare ESX Server 上觀察到的現象。對於 Windows 2003 VM，預設磁碟控制器是 LSI Logic SCSI 介面卡，此 SCSI 介面卡類型的驅動程式未包含在 Windows ADK 8.1 中。您也可能會在部份具有舊 SCSI 介面卡的舊伺服器上觀察到這個情形。

  解決方案

  若要解決此問題，從硬體廠商網站取得驅動程式，並且從 BMR 使用者介面載入驅動程式。

Express 資源配置精靈相關：

• 如果使用 Express 資源配置精靈建立計劃，需要工作階段密碼才能成功建立計劃。如果從一般的計劃建立 UI 建立計劃，可選擇是否使用工作階段密碼。

檔案複製和檔案封存相關

• 「檔案複製」與「檔案封存」工作不支援複製 4 KB 磁碟上的檔案。

與硬體快照相關

• 如果 VMware VM 備份工作使用的是硬體快照，您將會在偵錯日誌中看到以下訊息中的多個項目。訊息重複出現多次會使得安裝 Arcserve UDP 之磁碟區的磁碟空間用量增加。

  [VDDKLOG] SSLCheckLockingCallback: locking callback overwritten!Expected 7FEE3A836E0, saw 113C2420
  

  若要解決這個問題，請將以下路徑中的 VDDKLogLevel 登錄機碼設成 0：

  \HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
  

• 如果 Hyper-V VM 屬於叢集共用磁碟區 (CSV)，且 CSV 磁碟擁有者與 Hyper-V VM 的擁有者不同，則不會將可傳輸快照從儲存陣列中刪除。可傳輸快照未被刪除是 NetApp 的問題。
• CSV 可傳輸快照有時候可能會失敗，並且回復為軟體快照。硬體提供者多次重新試著建立可傳輸快照後，就會發生此情況。您可以在 Windows 事件檢視器中找到下列錯誤：

  以「10」秒為間隔重試「100」次後，仍無法在儲存系統「xxx」的多個磁碟區建立快照複本「{xxx}_backup」。
  

• 若是 Hyper-V VM，在使用可傳輸快照時，應用程式一致備份有時可能會損毀。

主機型 VM 備份相關資訊

• 啟用 [已變更區塊追蹤] 而且在 ESXi 6.0 或 ESXi 6.0 上執行的情況下備份 VMware VM 時，偵測到潛在問題。

  症狀

  VMware 最近發佈的知識庫文章指出，在 ESXi 6.0 或 ESXi 6.0.x 中，已變更區塊追蹤 (CBT) 出現錯誤，這會造成 CBT 傳回錯誤的已變更磁區清單。Arcserve UDP 可能受到此問題所影響，這會導致不一致的虛擬機器備份 (完整與遞增)。如需詳細資訊，請參閱 VMware 知識庫。

  若發生問題，目錄工作可能失敗，而且檢查復原點可能會報告錯誤。

  解決方案

  VMware 已發行這個問題的修補程式。在 ESXi 主機上套用這個修補程式。如需詳細資訊，請參閱 VMware 知識庫文章或 Arcserve 知識庫文章。

• Hyper-V 的 SUSE Linux Enterprise Server 12 VM 無代理程式備份失敗，而且 VM 客體作業系統在備份後當機。

  症狀

  如果 Hyper-V 主機是 Windows 2012 R2，而且 VM 的客體作業系統是 SUSE Linux Enterprise Server (SLES) 12 執行層級 5 (使用圖形介面)，則會發生這個問題。在此情況下，無代理程式備份工作將在「擷取快照」階段期間當機，最後造成失敗。此後，VM 客體作業系統毫無回應。

  解決方案

  這不是 Arcserve UDP 的問題，而是 Windows 和 SUSE 的相容性問題。在 Hyper-V 主機中使用 diskshadow 指令建立 VSS 快照時，會發生相同的問題。遵循下列步驟以驗證問題：

  1. 登入 Hyper-V 伺服器。
  2. 以管理員身分開啟 Windows 命令列。
  3. 從命令列輸入下列命令。
     1. 鍵入 "diskshadow" 並按下 Enter。
     2. 輸入「add volume X:」並按下 Enter。(X：VM 的虛擬磁碟檔案及配置檔所在的磁碟區。如果 VM 的磁碟檔案或配置檔位於不同的磁碟區，請重複此指令，以新增所有磁碟區。)
     3. 鍵入 "create" 並按下 Enter。
     4. 快照建立完成後 (這可能需要些時間)，輸入 "end backup" 並按下 Enter。
     5. 鍵入 "exit" 並按下 Enter。
  4. 檢查 VM 客體作業系統是否當機。
  5. 檢查 Windows 事件日誌、應用程式和服務日誌、Microsoft、Hyper-V VMM、管理。應該有一個錯誤日誌指出快照建立期間的 VM 失敗。

  目前沒有暫時解決方法。我們建議您藉由 Microsoft 解決根本原因。或者，您可以嘗試將 SLES 12 的執行層級從 5 變更為 3 (無圖形介面)，但是不保證能否解決。

• 對於 VMware VM，預先檢查 (PFC) 報告「無法存取虛擬機器」。

  症狀

  對於 VMware VM，即使您提供正確的憑證，預先檢查 (PFC) 都報告資料一致性檢查的下列警告訊息。

  未執行驗證，因為應用程式無法存取虛擬機器。確認使用者憑證正確無誤，而且擁有管理員權限。 
  

  解決方案

  只有 PFC for VMware VM 會發生這個問題。備份之類的其他功能不受影響。暫時的解決方法是在已安裝 Arcserve UDP 主控台的機器上安裝 Arcserve UDP 代理程式 (代理程式服務不需要啟動)。

• 對於 ESXi 5.5 或更早版本上的 VM，使用 SAN 傳輸容錯移轉備份，並還原至非 SAN 傳輸模式。

  症狀

  雖然可以使用 SAN 傳輸模式，不過備份和還原工作仍使用熱新增、NBD 或 NBDSSL 傳輸模式。

  解決方案

  這是 VMware VDDK 6.0.1 的已知問題。現在沒有 VMware 的解決方案。如需詳細資訊，請參閱 VDDK 6.0.1 已知問題版本說明。

• VM 虛擬磁碟的佈建大小為 4 TB 或 4 TB 的倍數時，使用 SAN 傳輸容錯移轉備份，並還原至非 SAN 傳輸模式。

  症狀

  即使可以進行 SAN 傳輸模式，VM 虛擬磁碟的佈建大小 4TB 或 4 TB 的倍數時，備份與還原工作仍會使用熱新增、NBD 或 NBDSSL 傳輸模式。

  解決方案

  這是 VMware 已知問題。暫時解決方法是避免使用 4 TB 倍數的佈建大小。例如，不使用 4TB 或 8 TB；改為使用 3.9 TB 或 8.1 TB。

• VMware 系統的無代理程式備份會備份已損毀的快照。

  症狀

  當您靜止 VMware VM 時，快照包含損毀的資料。備份會從快照讀取資料，因此備份的資料也會損毀。如需這個問題的詳細資訊，請參閱 VMware 知識庫文章。

  附註：  所有 VMware ESXi 版本及使用客體作業系統 Windows 2008 R2 SP1 和 Windows 2012 的 VM 會發生這種問題。Arcserve UDP 無法偵測資料損毀問題，因為發生此情況時 VMware 不會傳回錯誤。直到您嘗試還原資料時，才可能發現問題。

  解決方案

  VMware 建議的暫時解決方法是按照 VMware 資料庫文章停用 MSSearch 服務編寫器 (若未安裝則忽略) 和陰影複製最佳化編寫器 (每台 Windows VM 一般都有)。或者，您也可以執行下列工作以偵測並解決問題：

  執行下列工作以偵測並解決問題：

  • 復原點檢查 - 從復原點裝載磁碟區，並在備份工作結束時執行 Microsoft 工具 CHKDSK 來驗證資料的一致性。如需 chkdsk 工具的詳細資訊，請參閱《Arcserve UDP 解決方案指南》。chkdsk 工具的執行時間可能會變長。最佳的做法是為每週或每月的備份工作啟用此選項。
  • VMware 快照靜止方式 - 如果 復原點檢查 偵測到問題，請執行 Arcserve 知識庫文章中的「如何檢查您是否會受到此程式錯誤影響」中所述的步驟。如果確定問題是起源於這個 VMware 已知問題，您可以使用 [ VM 內部的 Microsoft VSS ]　快照靜止選項來解決問題。如需詳細資訊，請參閱《Arcserve UDP 解決方案指南》。
• 將叢集 VM 復原到原始 Hyper-V 叢集後，網路介面卡無法連線至虛擬交換器，而且在活動日誌中會出現警告訊息：

  無法將網路介面卡 <<adapter name>> 連線至虛擬交換器。
  

  症狀

  備份 VM 時，在建立快照之前，叢集 VM 發生容錯移轉。這個容錯移轉會造成備份工作階段中記錄的 Hyper-V 主機與 VM 配置不一致。

  解決方案

  您可以手動將網路介面卡連線至其 Hyper-V 主機上的虛擬交換器，或使用可供設定 VM 還原配置的 [還原至替代位置] 選項來復原 VM。

• 在 Hyper-V 2012 (含) 以上版本中，雖然此虛擬機器的無代理程式主機型備份工作已完成，不過虛擬機器仍維持「備份」狀態。

  症狀

  雖然其中一個虛擬機器的備份工作已經完成，Hyper-V 管理員中的虛擬機器狀態仍然是「備份」。因此，如果此 VM 的另一個備份工作此時開始，將由於錯誤「Hyper-V VSS 寫入器處理此虛擬機器時發生錯誤」而失敗。此外，您無法執行一些作業，例如，在該時間點於 [Hyper-V 管理員] 中開啟/關閉 VM 的電源。如果 VM 是 Hyper-V 叢集，您將無法為該 VM 執行即時移轉。

  此問題會在下列情況時發生：

  • 有多個備份工作同時開始或在相近的時間 (在 1 分鐘內) 開始。
  • 一個或多個備份工作完成，但是仍然至少有一個備份工作正在進行中。

  解決方案

  雖然 VM 已「鎖定」，不過您仍然可以正常使用客體作業系統。因此，這不會影響客體作業系統的使用/可用性。但是，如果您有疑慮且希望避免發生這種情況，可以執行下列任一作業：

  • 在無代理程式的主機型備份作業之 [資源] 索引標籤上，使用 [Hyper-V 快照分離] 選項。如需詳細資訊，請參閱《Arcserve UDP 解決方案指南》。
  • 使用不同的計劃來保護大小不同的 VM。換句話說，在一個方案中納入類似大小的 VM，以便這些備份工作使用類似的時間長度，同時對於這些方案設定不同的排程。
• 當您為 VMware 虛擬機器執行遞增備份工作時，遞增備份工作備份的資料大小可能會大於預期。

  症狀

  這是一個已知的 VMware 問題，其中牽涉到「變更區塊追蹤」(CBT)。在使用應用程式層級的靜止時，「變更區塊追蹤」會誇大變更情形。

  解決方案

  在 VMware ESXi 5.5 或更新的版本，以及 VMware ESX 5.1 修補程式 02 中已修正此問題。若 VMware vCenter Server 5.5 管理任何 VMware ESXi 5.1 主機，則應對其套用修補程式。如需此修正程式的詳細資訊，請參閱 VMware 知識庫。

  若您仍會看到這個問題，請在 Proxy 伺服器上設定以下登錄：

  [HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM instance UUID>]

  "ResetCBT"=dword:00000001

  範例：

  [HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]

  "ResetCBT"=dword:00000001

  附註：設定登錄值後，下一次的遞增備份工作將轉換為驗證備份工作，而接下來的遞增備份工作便會繼續以適當大小執行。

• 由於 VMware 已知問題，當啟用儲存 DRS 且在備份工作進行中時發生儲存 vMotion，則備份工作會失敗。活動日誌指出下列訊息：「無法開啟 VMDK 檔。」VMware 報告以下錯誤：「找不到檔案」。

  如需相關資訊，請參閱 VMware 知識庫文件 2055943。

• 復原一個包含大於 2 TB 的 VMDK 的 VM 失敗，因為 VM 無法建立快照。

  症狀

  備份來源 VM 有一個大於 2 TB 的 VMDK，且 ESX/ESX(i) 伺服器的版本低於 5.5 版，只能支援最高為 2 TB 大小的虛擬磁碟。然而，VM 復原期間可能發生下列錯誤：

  • 在 vSphere 用戶端中：
    • "Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'"
    • "File is larger than the maximum size supported by datastore"
  • 在 ESX/ESXi 4.x 的 hostd 記錄檔中：
    • 「快照客體失敗：檔案太大，無法為檔案系統使用。」
  • 在 ESXi 5.0/5.1 的 hostd 記錄檔中：
    • 「無法執行快照操作：錯誤：(21) 檔案太大，無法為檔案系統使用。」

  解決方案

  這是一個 VMware 的限制。低於 5.5 版本的 VMware ESX/ESX(i) 伺服器支援的最大大小為 2 T-16 GB，亦即 2032 GB。

  建議使用 VMware ESX(i) 伺服器 5.5 版做為執行大型磁碟轉換的目的地。

  如需相關資訊，請參閱 VMware 知識庫文件 1012384。

• 在 ESXi 伺服器上執行的 Windows VM 的單一 SCSI 控制器若連接超過七個磁碟，快照建立會失敗。

  症狀

  當您在包含 SCSI 控制器及超過 7 個 VMDK 的虛擬機器上執行備份工作時，備份工作會失敗。備份工作失敗是因為 VMware 需要在特定 SCSI 控制器上有最大數量的可用插槽可供 VMDK 使用，才能建立快照。SCSI 控制器最多可以有 15 個插槽。例如，如果 SCSI 控制器有 7 個 VMDK，則可為每個 VMDK 建立快照。(總共使用 14 個插槽，還有 1 個可用插槽。)如果 SCSI 控制器有 8 個 VMDK，由於只有 15 個可用插槽而無法建立快照，所以備份工作失敗。

  附註：手動建立快照也會失敗。

  解決方案

  針對在單一 SCSI 控制器上有超過七個磁碟的虛擬機器，執行以下步驟：

  1. 關閉虛擬機器。
  2. 建立更多精簡虛擬磁碟以供新增更多 SCSI 控制器。
  3. 將現有磁碟分散到數個 SCSI 控制器。
  4. 開啟虛擬機器電源。

  現在就可以為每個 VMDK 建立快照。

  這個問題是 VMware 的限制所造成，在這項限制下，Arcserve Backup 只能支援將這個數目的 VMDK 磁碟用於備份。

  如需詳細資訊，請參閱下列 VMware 知識庫文件：http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181

• 當您使用 HTTP 通訊協定和連接埠 80 從 vCenter Server/ESXi 5.0 更新 3 及更高版本匯入 VMware 虛擬機器，連線會失敗。
  這是 VMware 的已知問題。下列連結會開啟 VMware 知識庫文章：http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069149
• 從 Hyper-V 伺服器匯入虛擬機器時，主機型無代理程式的 Hyper-V 虛擬機器還原工作會覆寫虛擬機器，使虛擬機器失去作用。虛擬機器會停用是因為還原後之虛擬機器的執行個體 GUID 與原始的執行個體 GUID 不同，後者是從 Hyper-V 伺服器匯入。虛擬機器的執行個體 GUID 無法回復為原始執行個體 GUID。

  若要解決這個問題，請移除 Central Protection Manager 中的舊虛擬機器，再匯入新的虛擬機器。

• 當 Arcserve UDP 工作執行時，出現 ESX/ESXi/vSphere 5.5 的紫色死當畫面。

  症狀

  這是 VMware 的已知問題，會影響使用 E1000 和 E1000e 虛擬網路介面卡的 ESXi 5.0、5.1、5.5 主機和虛擬機器。

  附註：在下列 VMware 更新中已解決此問題。

  • ESXi 5.0 修補程式版本 ESXi500-201401001。如需相關資訊，請參閱 VMware 知識庫。
  • ESXi 5.1 更新 2，可在 VMware 下載中取得。如需相關資訊，請參閱 VMware 知識庫。
  • ESXi 5.5 更新 1，可在 VMware 下載中取得。如需詳細資訊，請參閱《VMware ESXi 5.5 更新 1 版本資訊》。
  • ESXi 6.0 GA，可在 VMware 下載中取得。如需詳細資訊，請參閱《VMware ESXi 6.0 版本資訊》。

  解決方案

  改用 VMXNET3 介面卡。如需相關資訊，請參閱 VMware 知識庫文件 2059053。

• 在備份期間，Arcserve UDP 代理程式會將子磁碟的資料合併到對應的上層磁碟，建立單一磁碟映像。因此，虛擬機器備份後上下層關係不再存在。因此，只有上層磁碟被復原且「差異磁碟」配置會不見，但沒有資料遺失。您可以在 VM 復原後從合併後的單一磁碟擷取資料。
  這是無代理程式備份的預期行為。您可以在虛擬機器復原成功後手動配置「差異磁碟」。
• 當重複的虛擬機器執行個體 UUID 存在，匯入 VM 失敗。

  症狀

  將虛擬機器匯入節點檢視時，如果節點檢視中早已加入另一個擁有相同虛擬機器執行個體 UUID 的虛擬機器，匯入會失敗。

• 儲存主機型虛擬機器備份計劃時，當選取的 Proxy 機器是以 Arcserve D2D r16.5 安裝，儲存會失敗。

  症狀

  當主機型虛擬機器備份計數包含 Proxy 機器，且機器上安裝舊版的 Arcserve D2D (如 r16.5)，在儲存計劃時會出現錯誤訊息「找不到分配方法」。

  解決方案

  發生這個問題是因為最新版的 API 與舊版 Arcserve D2D 的 API 不相容。解決辦法是，您可以手動將 Arcserve D2D 更新至最新版的 Arcserve UDP Agent (Windows)。

• 主機型虛擬機器備份工作在虛擬機器的「啟動備份」階段時可能會當機。

  症狀

  以主機為基礎的 VM 備份工作會當機數小時之久，且無法繼續作業。

  解決方案

  根據活動日誌中的程序 ID 結束 afbackend.exe、移除 VM 快照 (若有的話)，及重新提交備份工作。

• 在執行以主機為基礎的 VM 備份 Hyper-V 虛擬機器 (VM) 的還原工作之後，磁碟 (除了已復原虛擬機器上的開機磁碟以外) 會是離線狀態。

  症狀

  依預設，作業系統的行為會建立離線狀態。

  Windows Server 2008 中引入 SAN 原則以保護多部伺服器存取的共用磁碟。來源 VM 的預設 SAN 原則是所有 SAN 磁碟為「離線共用」，開機磁碟除外。將此原則設為 [離線]，可讓 SAN 磁碟在啟動期間保持離線狀態。復原之後，便會建立 VM 的新磁碟。來自 VM 的磁碟檔案看起來是 SAN 磁碟，作業系統會將此磁碟視為離線狀態。一旦將離線磁碟設定回線上，即使將系統重新開機之後，磁碟仍會保持線上狀態。

  解決方案

  作為變通辦法，您可以指定 DISKPART.exe 命令：SAN POLICY=OnlineAll setting for the source VM before backup.因為可在其他伺服器之間共用磁碟，因此可能發生資料損毀。您必須使用正確的 SAN 原則來保護資料。

  DISKPART.EXE 命令列

  查詢 SAN 原則：

  DISKPART > san

  SAN 原則：離線共用

  變更 SAN 原則：

  DISKPART > san policy=OnlineAll

  DISKPART 便會順利變更目前作業系統的 SAN 原則。

• 將不會備份附加到 Hyper-V 虛擬機器的 iSCSI 硬碟。

  症狀

  備份 Hyper-V 虛擬機器後，還原 UI 中不會列出 iSCSI 裝置上的磁碟區。

  解決方案

  在 Arcserve UDP 中建立代理程式型備份計劃，或使用 Arcserve UDP Agent (Windows) 備份虛擬機器。

• 客體作業系統是 Windows Server 2003 時，Hyper-V VM 上以主機為基礎的無代理程式備份工作無法執行前置/後置命令。

  症狀

  對於 Hyper-V VM 上以主機為基礎的無代理程式備份工作，如果客體作業系統是 Windows Server 2003，則無法執行前置/後置命令。活動日誌顯示警告「虛擬機器名稱與預期不符。無法執行前置/後置命令」。

  解決方案

  Windows Server 2008、Windows Vista (含) 以上版本的作業系統沒有這個問題，因此應該採用。

與安裝/遠端部署相關 (代理程式)

• 安裝裝載驅動程式失敗，偵錯日誌中出現錯誤代碼 1460。

  症狀

  Windows 設定 API 報告錯誤 1460，意指逾時期限已經到期。更新裝置驅動程式的預設逾時值為 300 秒。

  解決方案

  若要調整逾時值，請遵循下列步驟：

  1. 在 [開始搜尋] 方塊中輸入 gpedit.msc，然後按 Enter。
  2. 出現 UAC 提示時，按一下 [繼續]。
  3. 導覽到下列原則位置：

     Computer Configuration\Administrative Templates\System\Device Installation

  4. 啟用下列原則設定：

     配置裝置安裝逾時。

  5. 指定新的逾時值 (以秒為單位)。

為 新增相關的即時虛擬機器

• 即時 VM 的名稱與位置與預期的結果不同。

  症狀

  您使用 ESX 資訊登入，並選取資源庫作為即時 VM 的位置時，即時 VM 位於 ESX 主機中，而不在資源庫中。如果您從主控台刪除即時 VM，並使用相同名稱重新建立即時 VM，則會將尾碼 (1) 新增到即時 VM 名稱，而並非如預期新增到時間戳記。

  解決方案

  這是因為 ESX 伺服器是由 vCenter 管理。使用 vCenter 登入資訊來建立即時 VM。

• 如果您建立無代理程式備份計劃，並指定本機路徑作為備份目標，則無法從這類復原點建立即時 VM。若要解決此問題，請使用共用的資料夾作為備份目標。
• 如果您使用 IP 位址新增節點，然後建立備份計劃，並指定一個共用的資料夾作為備份目標，則可能無法從節點清單檢視建立即時 VM。不過，您可以從目標檢視建立即時 VM。或者，您也可以使用主機名稱更新節點，然後再試一次建立即時 VM。
• 如果您建立備份計劃，並指定本機路徑作為備份目標，則無法從這類復原點建立即時 VM。
• 如果您使用 IP 位址新增節點，然後建立備份計劃，並指定一個共用的資料夾作為備份目標，則無法從節點清單檢視建立即時 VM。不過，您可以從目標檢視建立即時 VM。
• 若復原點有鏡映的系統磁碟區，且您使用該復原點建立即時虛擬機器 (即時 VM)，您可能會收到一些錯誤，例如黑色死當畫面。
• 重新啟動復原伺服器後，無法在 Hyper-V 中啟動即時 VM。

  症狀

  啟動即時 VM，接著重新啟動 Hyper-V 復原伺服器時，即時 VM 可能會無法開機。

  解決方案

  若要解決這個開機失敗，請重新啟動即時 VM。

• 使用 Windows Server 2012 時，在動態磁碟上建立 NFS 可能會失敗。若要避免此問題，請使用基本磁碟。您也可以套用修補程式，並解決此問題。如需修補程式的詳細資訊，請參閱來自 Microsoft 的知識庫文章
• 當復原伺服器上作為 VMware NFS 的 Windows 磁碟區進行格式化時，建立即時 VM 會失敗。

  症狀

  我已指派 Windows 磁碟區作為 NFS 共用資料夾，並提供此共用磁碟區路徑作為即時 VM 的檔案路徑。當我將 Windows 磁碟區格式化，然後試著建立即時 VM 時，並無法建立即時 VM。無法建立即時 VM 是因為 ESXi 主機無法新增 NFS 資料儲存區。VMware 顯示下列錯誤訊息：

  VMware 建立 VM 失敗。
  

  在 vmkernal.log 檔案中會顯示以下錯誤日誌：

  No underlying device for major, minor
  

  解決方案

  若要解決此問題，請對復原伺服器執行下列步驟。

  1. 依序開啟 [控制台]、[系統和安全性]、[系統管理工具]。

     [管理工具] 對話方塊隨即開啟。

  2. 連按兩下 [網路檔案系統 (NFS) 的服務]。
  3. [網路檔案系統的服務] 對話方塊隨即開啟。
  4. 以滑鼠右鍵按一下 [NFS 的伺服器]，然後按一下 [停止服務]。
  5. 以滑鼠右鍵按一下 [NFS 的伺服器]，然後按一下 [啟動服務]。
  6. 使用磁碟區重新建立即時 VM。

  已建立即時 VM。

與日誌檢視相關

• 當 NodeName 是 VM (主機名稱)，而且日誌檢視是透過按一下檢視日誌連結載入時，日誌篩選器不會有作用。

  症狀

  在日誌檢視中，如果受保護的 VM 沒有主機名稱，則其 NodeName 值將顯示為「VM(節點名稱)」。在此情況下，其他篩選器不會有作用。

  解決方案

  您可以手動將 NodeName 從 「VM (主機名稱)」 修改為主機名稱，如此所有篩選器即可正常運作。例如，將 NodeName "VM(xxxxx01-AB)" 修改為 "xxxxx01-AB"。

與 Microsoft Exchange 相關

• Exchange 資料庫還原失敗，發生錯誤：「無法加以掛載」。

  症狀

  當 Exchange 伺服器是安裝在虛擬機器之中，且執行 Arcserve UDP Agent (Windows) 來保護此虛擬機器時，就會發生這個情況。在備份執行一段時間後，如果虛擬機器回復為先前儲存的虛擬機器快照，且您嘗試將 Exchange 資料庫復原至原始位置，還原會失敗，並伴隨「Exchange 儲存群組/資料庫 [DB_Name] 已還原至其原始位置，但無法裝載它」錯誤。

  根本原因仍在研究中，但目前看來似乎與 Exchange 資料庫中記錄的時間戳記以及最新的交易日誌檔有關。

  解決方案

  可嘗試將 Exchange 資料庫復原至替代目錄，或是先卸載資料庫、移除目標資料夾中的所有檔案、再執行還原。

與 Microsoft SQL Server 相關

• 如果 Microsoft SQL Server 無法分配更多記憶體，Arcserve UDP 主控台的回應可能變慢。

  症狀

  Microsoft SQL Server 有可能需要分配更多記憶體去處理查詢，特別是當 Arcserve UDP 資料庫中有許多資料時。但是，如果因為記憶體無法使用或配置的記憶體上限，導致 Microsoft SQL Server 無法取得更多記憶體，查詢過程將變得很慢，進而影響 Arcserve UDP 主控台的回應。

  解決方案

  使用 [日誌/刪除] 刪除資料庫中的部份日誌，然後重新啟動 SQL 服務。

與復原點伺服器 (RPS)/資料儲存區相關

• 防毒軟體意外刪除資料儲存區檔案。

  症狀

  備份或複製工作失敗，具有錯誤：「系統找不到指定檔案」。

  檢查 Windows 事件日誌。McAfee 將資料儲存區檔案 (例如，P0000000042.data) 偵測為 Exploit-ScriptNull Trojan 病毒，並且加以刪除。

  解決方案

  配置防毒設定以在排除清單中設定復原點伺服器 (RPS) 資料儲存區位置。

  附註：部份防毒軟體需要您在伺服器端設定排除清單。

• 當目標是已刪除重複資料的資料儲存區時，取消複製工作可能得花上幾分鐘。

  症狀

  當您將網路節流設為極低頻寬，或是送至目標 RPS 伺服器的網路輸送量不高時，會發生這個情況。因此，需要數分鐘等待佇列中的資料傳送出去。

  解決方案

  等待複製工作結束。

• 如果下列兩個條件存在，則修改資料儲存區時，將不正確地顯示資料儲存區的雜湊記憶體：
  • RPS 伺服器的記憶體小於或等於 4 GB。
  • 您未在建立資料儲存區時選取雜湊記憶體的最大值。

復原點伺服器 (RPS)/從 Hyper-V 匯入/相關的節點

• 當嘗試根據 IP 位址或節點名稱新增節點時，會發生「需有管理員權限」錯誤，讓您無法新增節點。嘗試從 Hyper-V 匯入時可能發生「檢查該帳戶是否有這個 Hyper-V 伺服器的管理員權限」錯誤，造成您無法匯入虛擬機器。

  症狀

  當您嘗試根據 IP 位址或節點名稱在支援使用者帳戶控制 (UAC) 的 Windows 作業系統上新增節點 (Windows Vista 或更新版本)，或嘗試從支援 UAC 的 Hyper-V 伺服器匯入虛擬機器，且您使用的新 Windows 使用者帳戶是管理員群組的本機帳戶但不是內建管理員時，會顯示下列訊息：

  「需有管理員權限。」

  解決方案

  使用內建管理員或網域管理員。或者，可以停用遠端 UAC。

  這是預設 Windows 行為，稱為 UAC 遠端限制。如果您仍然要使用此帳戶來新增節點，請執行下列步驟以停用遠端 UAC：

  1. 按一下 [開始]，在 [搜尋程式及檔案] 欄位中輸入 regedit，然後按 Enter。

     [Windows 登錄編輯程式] 隨即開啟。

     附註：您可能需要提供管理憑證以開啟 [Windows 登錄編輯程式]。

  2. 尋找並按一下以下登錄機碼：

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
     

  3. 從 [編輯] 功能表，按一下 [新增]，然後按一下 [DWORD (32 位元) 值]。
  4. 指定 LocalAccountTokenFilterPolicy 作為新項目的名稱，然後按 Enter。
  5. 在 [LocalAccountTokenFilterPolicy] 上按一下滑鼠右鍵，然後按一下 [修改]。
  6. 在 [值] 資料欄位中指定 1，然後按一下 [確定]。
  7. 結束 [登錄編輯程式]。

  如需 Windows 行為的詳細資訊，請參閱文章 http://support.microsoft.com/kb/951016。

• 無法為節點移除指定的虛擬層。

  症狀

  這個版本沒有提供移除節點之虛擬層的功能。

  解決方案

  移除節點，然後再度新增節點。

• 當您嘗試將已由某個主控台管理的節點新增至另一個主控台時，不會顯示警告或快顯訊息。

  症狀

  Arcserve UDP 的 UI 可執行所有功能，使用者應該不需要使用多個 Arcserve UDP 主控台，因此，只有在舊伺服器淘汰時，才會發生要將代理程式從某個伺服器移至另一個伺服器的情形。

  解決方案

  將節點從某個主控台移至另一個主控台是很少見的情形。

與登錄相關

• 如果備份目標是 Windows Server 2012 上已啟用刪除重複資料的 NTFS 磁碟區，而且 Windows 2003 上已安裝 Arcserve UDP Agent (Windows)，則還原、合併或目錄工作可能失敗。此工作會失敗，並產生 Windows 錯誤代碼 50 和「不支援此要求」的訊息。

  症狀

  McAfee 或其他協力廠商軟體在安裝於 Windows Server 2012 上時，會在登錄中設定 EnableECP=1。

  解決方案

  在登錄中，將下列機碼下方的 EnableECP 值從 1 變更為 0：

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
  

  如需相關資訊，請參閱 http://support.microsoft.com/kb/2817216。

與複製相關

• 中止複製來源端的 RPSReplication.exe 程序可能造成第二個複製工作失敗。

  症狀

  第二個複製工作將停滯在「準備」狀態，並且在 10 分鐘後失敗。

  解決方案

  您不需要執行任何特定作業。第二個複製工作失敗後，將觸發補救工作。

與 Arcserve UDP Exchange 細微還原 (AEGR) 公用程式有關

• 您搜尋電子郵件，並從搜尋結果還原電子郵件時，電子郵件無法還原至信箱。如果您瀏覽信箱，然後選取要還原的電子郵件時，電子郵件將成功還原。
• Arcserve UDP Exchange 細微還原公用程式不支援日文搜尋。
• 在使用 Arcserve UDP Exchange 細微還原公用程式時，不會將所有項目還原至即時伺服器。

  症狀

  在完成還原工作後，可能無法正確還原下列項目內容：

  • InternetHeaders
  • RTFCompressed
  • Codepage
  • DateCompleted
  • TaskRecurrence
  • RecurrencePattern
  • AppointmentTimeZoneDefinitionEndDisplay
  • ReminderTime
  • CommonEnd
  • AppointmentStartWhole
  • AppointmentEndWhole
  • BusyStatus
  • Meeting Owner
  • Company Name of Task

  解決方案

  使用 [匯出至 PST] 選項還原遺漏的項目。

與還原相關

• 使用更新 4 或較低版本的代理程式時發生錯誤。

  症狀

  使用更新 4 或較低版本的代理程式時，發生下列錯誤：

  • 無法將 Exchange DB 還原至原始位置。隨即會顯示下列錯誤訊息：

    Exchange 儲存群組/資料庫已還原至其原始位置，是但無法加以掛載。」
    

  • 以重新執行日誌傾印 Microsoft Exchange 資料庫時，工作完成之後，日誌不會重新執行。

  解決方案

  將代理程式升級到 Arcserve UDP 代理程式 6.0 版。

• 以下列計劃設定保護節點時，Arcserve Backup UI 無法執行檔案層級還原。
  • 備份目標是非加密的資料儲存區。未提供 Arcserve UDP 工作階段密碼。
  • 複製到加密的資料儲存區。
  • 從複製伺服器上加密的資料儲存區封存至磁帶。
• 將檔案還原至替代位置 (遠端共用資料夾) 失敗，在活動日誌中有錯誤訊息：「存取遭拒」。

  症狀

  當還原目標是遠端共用資料夾，例如 \\FileServer\ShareFolder\RestDest，且備份目標是具有相同路徑的遠端共用資料夾，例如 \\FileServer\ShareFolder\RestDest，即會發生錯誤。

  如果用來連線到根共用資料夾的使用者帳戶不在權限清單中，無論針對還原目標資料夾使用哪個帳戶，還原工作都會失敗。

  解決方案

  新增已針對備份目標指派的使用者帳戶，將連線建置到根共用資料夾的權限清單，並且確定使用者帳戶具有還原檔案的適當權限。

  將使用者帳戶新增至 [備份操作員] 群組，並且確定其具有覆寫安全性限制的權限。

• 升級作業系統後，可能必須在從 Arcserve UDP Agent (Windows) 還原檔案時，重新輸入加密密碼或工作階段密碼。

  症狀

  如果復原點已啟用加密，則不必為從目前伺服器備份的復原點輸入密碼。但是，如果您升級 Windows 作業系統，例如從 Windows 2008 升級到 Windows 2008 R2，密碼將不會自動填入 Arcserve UDP Agent (Windows) 使用者介面中，您必須重新輸入密碼。

  解決方案

  記下復原點加密密碼或工作階段密碼，放在安全的地方待查閱。

• 無法在還原程序期間開啟 VMDK 檔案。

  症狀

  在還原 VMware 虛擬機器時，我收到下列錯誤：

  您沒有此檔案的存取權限，如需詳細資訊，請參閱還原偵錯日誌。如有需要，請連絡 Arcserve 支援。
  

  您可以參閱還原偵錯日誌中的下列日誌項目：

  [VDDKLOG] CnxAuthdConnect：因為系統要求 SSL 驗證，但目標 authd 不支援 SSL，故傳回 false。
  

  [VDDKLOG] CnxConnectAuthd：因為 CnxAuthdConnect 失敗，故傳回 false。
  

  [VDDKLOG] Cnx_Connect：因為 CnxConnectAuthd 失敗，故傳回 false。
  

  [VDDKLOG] Cnx_Connect：錯誤訊息：需要 SSL
  

  解決方案

  會發生此錯誤是因為 VMware ESX 主機已停用 SSL 驗證。若要解決此錯誤，請執行下列其中一個方法：

  • 使用 vSphere 用戶端
    1. 登入 VMware vCenter/ESX 伺服器。
    2. 依序按一下 [配置]、[進階設定]、[配置]、[預設安全性]。
    3. 開啟 ESX 伺服器設定。
    4. 啟用下列選項：

       config.defaults.security.host.ruissl
       

  • 使用命令列
    1. 使用 SSH 連線到 VMware ESX 主機。
    2. 開啟 config 檔案：

       /etc/vmware/config; 
       

    3. 將 security.host.ruissl 項目設定為 TRUE。
    4. 儲存檔案，並重新啟動管理代理程式。

  已啟用 SSL 驗證。

與伺服器連線相關

• 瀏覽日誌時，顯示伺服器連線錯誤。

  症狀

  當您從代理程式或主控台瀏覽活動日誌，可能會顯示以下錯誤：

  無法連線至 'arcservedocs.com' 伺服器。

  解決方案

  您可以直接忽略這個訊息。

與虛擬待命相關

• 將來源節點上的 Arcserve UDP RPS 或 Arcserve UDP 代理程式升級至 Arcserve UDP 6.0 之後，Hyper-V 的虛擬待命工作失敗。但是，Hyper-V 伺服器上的 Arcserve UDP 代理程式未升級。

  症狀

  Arcserve UDP Agent (Windows) 已備份至 Arcserve UDPRPS 資料儲存區，而且 RPS 已升級為 Arcserve UDP 6.0。此外，<caudp_agt_windoes> 已備份至共用資料夾，而且代理程式升級為 Arcserve UDP 6.0。Hyper-V 的虛擬待命 VSB 工作失敗，而且顯示下列錯誤：

  找不到 {http://webservice.arcflash.com} IsVMFileExist 的分配方法。
  

  或

  找不到 {https://webservice.arcflash.com}IsVmFileExist 的分配方法。
  

  解決方案

  將 Arcserve UDP 代理程式升級到 Hyper-V 伺服器上的 Arcserve UDP 6.0。

• 磁碟開啟時處於離線狀態。這個問題是因為 SAN 原則已套用在 Windows 2008 與更新版的作業系統上。作業系統會保護由超過一個伺服器存取的共用磁碟。伺服器第一次偵測到磁碟時，Windows 將磁碟設為離線狀態。當磁碟成為上線狀態後，磁碟將維持上線狀態。

  造成此行為的另一個原因與將其中包含「唯讀」磁碟區的虛擬機器開啟電源相關。若要修正此情況，請將磁碟上磁碟區設為可寫入的狀態。

• 應用程式不支援使用 VMware 連結模式匯入 vCenter 伺服器。為了保護 [連結模式] 群組中的所有 vCenter 伺服器執行個體，請個別新增每個 vCenter 伺服器執行個體。
• 虛擬待命不支援在來源電腦上的系統磁碟區或開機磁碟區位於動態磁碟時，將復原點轉換成 Hyper-V 格式。
• 虛擬待命不支援可讓您定義動態 RAM 數量的虛擬待命建立作業，這些動態 RAM 是由 Windows 2008 R2 SP1 和 Windows 2012 Hyper-V 伺服器系統上保護之虛擬機器所使用。
• 當您使用目前的快照執行 V2P 復原時，可能會出現一則訊息，指出下列內容：

  無法取得「復原點」資訊。

  當您使用最新快照執行 V2P 復原，而且節點的轉換工作並未在將虛擬待命工作重新部署到節點之後完成時，即會發生此行為。

  解決方案

  1. 提交 Arcserve UDP 代理程式備份工作，以擷取節點的目前狀態。然後執行節點的裸機復原。
  2. 關閉虛擬待命虛擬機器電源，然後提交虛擬待命轉換工作，以建立節點的目前復原點快照。
• V2P 使用者介面可能不會顯示最新快照。當您從最新快照完成 V2P 復原之後執行 V2P 復原時，即會發生此行為。

  解決方案

  使用 Arcserve UDP 代理程式裸機復原執行 V2P 復原。

• 當備份來源機器 (Arcserve UDP 代理程式的安裝處) 有原生的 4KB 磁區磁碟，且 Arcserve UDP 代理程式備份工作已在 4KB 磁區磁碟上備份磁碟區，則轉換 Arcserve UDP 代理程式備份工作階段的待命虛擬機器無法偵測對應 4KB 磁區磁碟的磁碟分割和磁碟區。當來源磁碟包含 4 KB 磁區，且待命虛擬機器支援 512 B 磁區時，便可以預期會有此情形發生。在轉換後，因為磁區大小變更，待命虛擬機器中的客體作業系統找不到磁碟中繼資料。

  附註：這項限制僅適用於在 Hyper-V 伺服器上執行的虛擬待命工作。

• 在以主機為基礎的虛擬機器工作階段中，如果有附加至 VM 而後卸除的網路介面卡，則虛擬待命中列出的網路介面卡數量會多於 VM 中目前清單涵蓋的數量。
• 轉換 2 TB 磁碟檔案失敗，因為 VM 無法建立快照。

  症狀

  Arcserve UDP Agent (Windows) 有一個 2 TB 的磁碟，且 ESX/ESX(i) 伺服器的版本低於 5.5 版，只能支援最高為 2 TB 大小的虛擬磁碟。然而，轉換期間可能發生下列錯誤：

  • 在 vSphere 用戶端中：
    • "Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'"
    • "File is larger than the maximum size supported by datastore"
  • 在 ESX/ESXi 4.x 的 hostd 記錄檔中：
    • 「快照客體失敗：檔案太大，無法為檔案系統使用。」
  • 在 ESXi 5.0/5.1 的 hostd 記錄檔中：
    • 「無法執行快照操作：錯誤：(21) 檔案太大，無法為檔案系統使用。」

  解決方案

  這是一個 VMware 的限制。低於 5.5 版本的 VMware ESX/ESX(i) 伺服器支援的最大大小為 2 T-16 GB，亦即 2032 GB。

  建議使用 VMware ESX(i) 伺服器 5.5 版做為執行大型磁碟轉換的目的地。

  如需相關資訊，請參閱 VMware 知識庫文件 1012384。

• 變更虛擬待命監控器的密碼，並在 Arcserve UDP 主控台 UI 中更新虛擬待命監控器的節點後，部署使用該監控伺服器的計劃可能會部署失敗。

  症狀

  部署計劃失敗，並顯示以下錯誤訊息：「無法將「虛擬待命設定」套用到節點 'xxx' 上。(無法從 xxx 連線至監控器：xxx。使用者憑證無效)」。

  解決方案

  編輯計劃中的虛擬待命工作，輸入監控器的正確密碼，然後儲存計劃。

與 VSS 快照相關

• 由於 VM 客體作業系統中 VMware 或 Microsoft 引起的 VSS 快照問題，可能無法為 VMware VM 的無代理程式備份作業產生目錄，並出現下列訊息：「無法將索引區塊對應到其正確的磁碟區區塊。發生 IndexAlloc 錯誤」。

  解決辦法

  1. 執行 'chkdsk' 以確保客體作業系統內的資料保持一致。
  2. 關閉虛擬機器電源，讓客體內的 VSS 快照不再發生。
  3. 備份電源關閉狀態下的虛擬機器。

  附註：這個問題極少發生。如需詳細資訊，請參閱 VMware 知識庫文件 2006849 或 Microsoft 知識庫文件 2853247。

Backward Compatibility Related

Data Corruption During UDP Upgrade due to Backward Compatibility

You may notice data corruption for backward compatibility of protecting UDP v5 nodes to UDP v6 RPS, it might cause data corruption on deduplication data store.

This issue does not impact if you are using one of the following options:

• Performing fresh installation with Arcserve UDP v6.
• Upgrading the full environment from Arcserve UDP v5 to Arcserve UDP v6 without running any backup/replication job during the upgrade,

This issue impacts if you have:

• Plans to ugrade from Arcserve UDP v5 to Arcserve UDP v6
• Already upgraded from Arcserve UDP v5 to Arcserve UDP v6

When do you face this data corruption:

If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6, you may face this issue in the following scenarios:

• If you run some failed backup/replication jobs while upgrading the full environment from Arcserve UDP v5 to Arcserve UDP v6.
• If you upgrade from Arcserve UDP v5 to Arcserve UDP v6 but stay in mixed versions, data corruption may occur when a failed backup/replication job takes place.

症狀

The data corruption issue might happen in the following two scenarios.

Scenario 1: The Agent node is with Arcserve UDP v5 and the RPS node is with Arcserve UDP v6. Agent job fails to back up and generates the incomplete recovery point on the deduplication data store. Deleting the incomplete recovery point from the deduplication data store may lead to data corruption.

Scenario 2: The source RPS node is with Arcserve UDP v5 and the destination RPS node is with Arcserve UDP v6. The Replication job fails and generates the incomplete recovery point destination deduplication data store. Deleting the incomplete recovery point from the destination deduplication data store may lead to data corruption.

Reason

Due to the mismatch of interface between different versions, when Arcserve UDP v6 RPS tries to delete the incomplete sessions generated by Arcserve UDP v5, it may wrongly delete additional index files which leads to data corruption.

解決方案

If you are upgrading from Arcserve UDP v5 to Arcserve UDP v6:

1. Upgrade full environment from Arcserve UDP v5 to Arcserve UDP v6 without running any backup/replication jobs during the upgrade.
2. Upgrade from Arcserve UDP v5 to Arcserve UDP v6, and immediately apply the patch T00000360 on RPS nodes with Arcserve UDP v6.

   Note: Before applying the patch, do not run any backup/replication jobs.

3. Wait for Upgrade to Arcserve UDP v6 update 1.

   Note: If you opt for this option, do not upgrade to Arcserve UDP v6. You can directly upgrade from Arcserve UDP v5 to Arcserve UDP v6 update 1.

If you have already upgraded from Arcserve UDP v5 to Arcserve UDP v6:

1. Either immediately apply the patch T00000360 on RPS nodes with Arcserve UDP v6 or upgrade the full environment from Arcserve UDP v5 to Arcserve UDP v6.

   Note: Contact Arcserve Support to get the patch.

2. Verify the data integrity at recovery point level. If data corruption has occurred, for details refer to the details provided in how to handle corrupted recovery points.

How to handle corrupted recovery points?

You cannot recover any recovery point that is corrupted due to the backward compatibility issue as the corresponding index file is incorrectly deleted.

To make sure that the subsequent recovery points do not depend on the corrupted recovery point, we recommend to take again full backup for the impacted node.

In addition, other jobs related to merge job that need to read from the corrupted recovery point might continue failing even though new full backup is done.

To solve the above, we recommend to rename the node folder in the backup destination folder of dedupe data store. Add Backup as prefix to the original node name.

For example:

NODE_NAME[1a98528f-db3c-45de-83d6-9d729815ab7d]

to

BackupNode_Name[1a98528f-db3c-45de-83d6-9d729815ab7d]

As a result, new folder name of the source node is created that automatically converts the recovery point as full when the specific node backs up to the data store again.

For the renamed folder, you can perform the following options:

1. Click the data store to browse recovery points at the very bottom in the section for “Plan: (not protected)
2. Restore from it, and
3. Access some recovery point that are not corrupted.

You can select to delete the renamed node through data store UI, if all the recovery points in the renamed folder are not useful anymore. The automatic retention management of the Plan only applies to the new recovery points done after the renaming of the folder.

瀏覽器相關事項

如果使用 Windows 10 Edge 網頁瀏覽器，當您按一下 [還原] 或 [登入代理程式時，可能無法從 [主控台] 登入 Windows 或 Linux 代理程式。使用其他瀏覽器以登入。

Arcserve UDP 主控台相關事項

• 在 [節點] 檢視中，若瀏覽器的畫面寬度不夠，[篩選器] 下拉式方塊會選取預先定義的篩選器，且瀏覽器上篩選器文字方塊不會顯示出來。變通辦法為隱藏右窗格，或放大瀏覽器以檢視 [篩選器] 下拉式方塊和文字方塊。
• 當您使用 Arcserve UDP 主控台來管理多個站台時，若要讓電子郵件警示運作，所有站台的閘道伺服器與主控台必須能與相同的電子郵件伺服器通訊。
• 如果工作正在進行中，且個別的代理程式重新開機，主控台就不會顯示進行中工作的任何工作歷程。
• 當您修改並儲存 UDP 計劃，其中包含在作用中複製到磁帶工作期間的複製到磁帶工作時，Arcserve UDP 上作用中複製到磁帶工作的工作監控器將會消失。您可以在 Arcserve Backup 管理員中驗證複製到磁帶的進度，或在工作完成時參閱 Arcserve UDP 主控台中的工作歷程。
• 執行自動搜索時，[虛擬層] 欄中的 VM 資訊會持續變更。

  症狀

  如果您有兩台虛擬機器 (VM1 及 VM2) 在 ESXi 主機中具有相同的 GUID，且這兩台 VM 分別由不同 vCenter 管理，即 VC1 和 VC2。您將 VM1 匯入主控台 (您不能匯入兩部 VM，因為主控台不允許具有相同 GUID 的節點)。但您也會從 vCenter VC2 匯入 VM。執行自動搜索時，首先會連線至 VC1，並依 GUID 偵測 VM1，且 [虛擬層] 欄會以 VC1 的資訊更新。稍後當它連線至 VC2 時，它會按 GUID 偵測 VM2，且 [虛擬層] 欄會以 VC2 的資訊更新。

  解決方案

  兩個 VM 具有相同的 GUID 很罕見。在最嚴重的情況下，如果發生這種情形，主機型無代理程式備份可備份錯誤的 VM，因為 Arcserve UDP 會使用 GUID 來識別 VM。若要解決此問題，您可以手動變更其中一個 VM 的 GUID。如需如何執行此動作的詳細資訊，請參閱《解決方案指南》中的相關主題。

• 主控台將顯示訊息，正在啟動識別服務

  症狀

  無法登入 Arcserve UDP 主控台。主控台在登入五分鐘後仍然顯示下列訊息：

  識別服務正在啟動
  

  解決方案

  若要解決此問題：

  • 請開啟 Windows 服務主控台，並重新啟動 Arcserve UDP 主控台服務、Arcserve UDP 管理服務。
  • 如果未解決問題，請確認 UDP_HOME\Management\Bin\ 目錄已加入路徑環境變數中。如果未新增，請手動新增，然後重新啟動 Arcserve UDP 識別服務。
• 多個節點的 Jumpstart 工作失敗。

  症狀

  如果其中一個節點有執行中的複製工作，則多個節點的 Jumpstart 工作會失敗。

  解決方案

  您可以等待該複製工作完成後再提交 Jumpstart 工作，或提交其他節點的 Jumpstart 工作。

• 複製到磁帶工作失敗。

  症狀

  複製到磁帶工作可能會在下列情況下失敗：

  1. Arcserve UDP 代理程式節點以當地語系化的使用者名稱 (例如，使用者名稱以繁體中文表示) 新增到 Arcserve UDP 主控台。Arcserve UDP 代理程式節點備份到本機磁碟或共用資料夾。然後，新增複製到磁帶，以將復原點從本機磁碟或共用資料夾移轉到磁帶。
  2. Arcserve UDP RPS 節點以當地語系化的使用者名稱 (例如，使用者名稱以繁體中文表示) 新增到 Arcserve UDP 主控台。其他 Arcserve UDP 代理程式節點進行備份或複製到 RPS 的資料儲存區。然後，新增複製到磁帶，以將復原點從 RPS 的資料儲存區移轉到磁帶。

  解決方案

  若為第一個問題，請以非當地語系化的使用者名稱將 Arcserve UDP 代理程式節點新增到 Arcserve UDP 主控台 UI。

  若為第二個問題，請以非當地語系化的使用者名稱將 RPS 節點新增到 Arcserve UDP 主控台。

• 在 NAT 環境中修改「從遠端管理的 RPS 複製」工作時，顯示未預期的 NAT 裝置設定。

  症狀

  當您需要在 NAT 環境中修改計劃時，如果計劃包含下列工作，您將在 [從遠端管理的 RPS 複製] 工作上看到多餘的 NAT 裝置設定。

  • 工作 1 [從遠端管理的 RPS 複寫]，啟用 NAT 路由器並設定 IP/連接埠。
  • 工作 2 [複製到遠端站台] 根據工作 1 配置，而且啟用 NAT 裝置並設定 IP/連接埠。

  當您需要修改計劃，並檢視工作 1 配置時，如果配置了 [伺服器位於 NAT 路由器後面]，您會發現 [伺服器位於 NAT 裝置後面] 選項是多餘的。如果正確提供 NAT 路由器資訊，則複製工作可以成功。

  解決方案

  當修改計劃時，您可以忽略 [從遠端管理的 RPS 複製] 工作上的 [伺服器位於 NAT 裝置後面] 欄位。使用 [伺服器位於 NAT 路由器後面] 欄位，確定複製工作成功。

Arcserve UDP 使用者管理主控台相關事項

• 由於協力廠商元件的某些錯誤，因此 Arcserve UDP 使用者管理主控台上某些對話方塊中的部份文字不會翻成當地使用語。
• Arcserve UDP 使用者管理主控台可讓您建立含有特殊字元的角色名稱，例如 ~!@#$%^&*\ 等等。不過，您無法重新命名、指派或刪除此類角色。

Arcserve UDP Agent (Linux) 相關事項

• 如果您在 Google Chrome 中開啟 Arcserve UDP Agent (Linux)，則 [工作狀態] 索引標籤中的列不會與對應的欄標題對齊。
• 不支援加密的磁碟區。您無法備份加密的磁碟區。
• BMR 不支援 FakeRAID。如果您的備份節點是 RHEL 6.4 或更新版本、CentOS 6.4 或更新版本、Oracle Linux Server 6.4 或更新版本，且備份節點包含 Linux 軟體 RAID，則要從這類復原點執行 BMR 時，必須使用 CentOS 型 Live CD。
• 當您使用 RHEL 6.x 或 CentOS 6.x D2D 伺服器從 RHEL 5.x 或 CentOS 5.x 復原點還原檔案，可能無法還原部份 SELinux (加強安全的 Linux) 屬性。
• 當您將這兩個安裝套件檔案下載到本機資料夾時，這個本機資料夾的完整路徑不得包含任何特殊字元 (空格除外)，且路徑只能包含下列字元：a-z、A-Z、0-9 及 _。
• 如果您提交一個檔案層級還原工作，或使用 [本機] 作為備份目標的 BMR 工作，而您想要將備份目標修改為 NFS 共用區或 CIFS 共用區，您必須先將 NFS 共用區或 CIFS 共用區新增到備份儲存區中。新增 NFS 共用區或 CIFS 共用區後，請開啟 [還原精靈] 並從 [工作階段位置] 下拉式清單中選取 NFS 共用區或 CIFS 共用區，然後再次提交工作。
• 只有 Red Hat 相容核心支援 Oracle Linux。您必須選取 Red Hat 相容核心做為預設的開機核心。不支援 Oracle Unbreakable 核心，且它不應該做為預設的開機核心。
• 如果使用 Live CD 在 Citrix XenServer 6.x 中啟動 PVM，在 Live CD 中不會有 Arcserve UDP Agent (Linux) 伺服器。

與備份相關

• 升級到 Windows 10 之後，系統會移除磁碟區的追蹤驅動程式上層篩選器。BLI 驅動程式無法追蹤磁碟區中的任何變更。因此，[遞增備份] 工作會轉換為 [驗證備份] 工作。

  症狀

  會移除磁碟區類別的登錄 BLI 上層篩選器。因此，BLI 驅動程式無法監控磁碟區。

  解決方案

  您可以在重新安裝變更追蹤驅動程式後繼續執行遞增備份。

  請按照下列步驟操作：

  1. 執行下列路徑的 UninstallDriver.bat 檔來解除安裝變更追蹤驅動程式。

     <安裝路徑>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
     

  2. 執行下列路徑的 InstallDriver.bat 檔來重新安裝變更追蹤驅動程式：

     <安裝路徑>\Arcserve\Unified Data Protection\Engine\BIN\DRIVER
     

• 操作 COM 型元件 (如 VSS、VDS) 時，備份、還原或 BMR 資訊收集可能會失敗。事件 ID 10006、1503 或 6287 可能會顯示在 Windows 事件日誌中。

  症狀

  您可以在事件日誌中找到下列訊息：「在登錄機碼上嘗試的非法作業已標示刪除」或「Windows 已偵測到您的登錄檔案仍然由其他應用程式或服務使用中。將立即卸載檔案。稍後包含您的登錄檔案的應用程式或服務可能無法正常運作」。

  解決方案

  如需原因和解決方案的詳細資訊，請參閱 Microsoft KB 文章 2287297。

• 裝載磁碟區失敗，並出現訊息「Failed to mount recovery point to path:"Z:".Incorrect function." (無法將復原點裝載至路徑 "Z:"。功能不正確)。

  症狀

  將工作階段裝載至磁碟機代號失敗。

  當目標是本機資料夾且是在 FAT32 磁碟區時，就會發生此情況。裝載磁碟機僅支援在 NTFS 磁碟區上建立快取檔案。

  解決方案

  新增登錄機碼，自訂快取檔案路徑為其他磁碟區。

  請按照下列步驟操作：

  1. 在 HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine 上建立機碼 "AFStorHBAMgmt"。
  2. 建立字串值 "CacheFilePath"。

  更多資訊：

  在已裝載可寫入磁碟區的情形下，裝載磁碟機就會建立快取檔案。若是細微還原目錄/還原工作，則會建立可寫入磁碟區。如果工作階段是要備份 Windows 8、Windows 2012 或更新作業系統上的磁碟區，當您將工作階段裝載至磁碟機代號時，請一定要裝載可寫入磁碟區。

• 當您從 Arcserve UDP Agent (Windows) UI 提交備份工作，若備份目標是使用 [復原點伺服器] 上的資料儲存區，備份工作可能不會啟動。

  症狀

  提交的備份會成功顯示，但從 Arcserve UDP Agent (Windows) UI 上看不到任何工作監控器。這是因為備份工作達到資料儲存區的並行節點計數上限設定。備份工作會被放入等候佇列中。

  解決方案

  開啟 Arcserve UDP 主控台，節點檢視中將顯示擱置的工作監控器。

• 如果 Arcserve UDP Agent (Windows) 機器重開機時有備份工作正在執行，在 Arcserve UDP Agent (Windows) 首頁上會將此工作標示為「毀損」，但在 Arcserve UDP 主控台上則沒有此工作的工作歷程。這是因為工作歷程項目是在工作結束時傳送至 Arcserve UDP 主控台，但在重開機的情況下，沒有機會將工作歷程從代理程式傳送到伺服器。
• 工作監控器上以主機為基礎的無代理程式驗證備份工作的壓縮百分比不正確。

  症狀

  以主機為基礎的無代理程式驗證備份工作執行時，如果已經在計劃中啟用壓縮，工作監控器上顯示的壓縮百分比將高於實際百分比。

  其他所有備份工作不會有這個問題，包括代理程式備份工作和以主機為基礎的無代理程式完整/遞增備份工作。

  解決方案

  活動日誌中顯示的壓縮百分比正確無誤。請在以主機為基礎的無代理程式驗證備份工作後加以查閱。

• VMware VM 備份工作成功完成，但產生傾印檔案。

  症狀

  VMware VM 的備份工作在 Arcserve UDP 主控台上成功完成。工作以綠色圖示標記，而且活動日誌顯示「備份工作成功完成」訊息。不過，會在代理程式安裝路徑下的 BIN 資料夾中產生後端程序傾印檔案，例如 AFBackend.exe.7912.00.dmp。例如：C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN。

  解決方案

  這種情況由於 VMware VDDK 的問題而發生，因為 Arcserve UDP 關閉對 VDDK 的 VDDK API 呼叫時，VDDK 有時候會損毀。您可以忽略這個問題，因為這種情況發生在備份工作的最後一個階段。此時備份工作幾乎完成，而且復原點已成功結束。

與 BMR 相關

• 建立開機套件失敗，發生下列錯誤：

  「無法將語言套件整合到 BMR ISO 映像中」。

  症狀

  此問題是協力廠商防毒軟體 (McAfee) 篩選驅動程式所造成的，但也有可能會發生在其他協力廠商篩選器。

  解決方案

  停用您的防毒軟體，並再次嘗試開機套件的建立。

• 執行 BMR 之後無法啟動伺服器。

  症狀

  若來源機器是執行 BMR 到含有不同硬體的實體機器，或是到 Hyper-V 伺服器上虛擬機器的 Active Directory 伺服器，該伺服器就不會啟動，並會出現一個藍色畫面來顯示下列訊息：

  停止：c00002e2 目錄服務因發生下列錯誤而無法啟動：附加到系統的裝置並未運作。錯誤狀態：0xc0000001。

  解決方案

  將系統重新啟動為 BMR PE 環境、將 C:\Windows\NTDS 資料夾中的所有 *.log 檔案重新命名，然後重新啟動系統。例如，將 edb.log 檔案重新命名為 edb.log.old，然後重新啟動系統。

• 無法在 BMR 期間將來源磁碟對應到目標磁碟，即使這兩個磁碟的大小完全相同也不例外。

  症狀

  當目標機器是虛擬機器，且其 IDE 磁碟位於 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上時，您可能無法在 BMR 期間對應磁碟/磁碟區。

  如果使用 BMR 將資料還原到其 IDE 磁碟位於 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上的虛擬機器，則系統無法將來源磁碟/磁碟區對應到目標磁碟/磁碟區，即使這兩個磁碟的大小看似完全相同也不例外。這是因為當您在 2008 Hyper-V 伺服器或 2008R2 Hyper-V 伺服器上建立 IDE 磁碟時，實際的磁碟大小會小於您所指定的大小。

  解決方案

  在 VM 上建立較大的磁碟。例如，如果您要還原 25 GB 磁碟的資料，建議您在目標 VM 上建立 26 GB 的磁碟。

• 如果您使用 Windows ADK 8.1 來建立 BMR ISO，在使用此 ISO 重新開機之後，可能會發現 PE 系統中偵測不到磁碟。

  症狀

  這是在 VMware ESX Server 上觀察到的現象。對於 Windows 2003 VM，預設磁碟控制器是 LSI Logic SCSI 介面卡，此 SCSI 介面卡類型的驅動程式未包含在 Windows ADK 8.1 中。您也可能會在部份具有舊 SCSI 介面卡的舊伺服器上觀察到這個情形。

  解決方案

  若要解決此問題，從硬體廠商網站取得驅動程式，並且從 BMR 使用者介面載入驅動程式。

與硬體快照相關

• 如果 VMware VM 備份工作使用的是硬體快照，您將會在偵錯日誌中看到以下訊息中的多個項目。訊息重複出現多次會使得安裝 Arcserve UDP 之磁碟區的磁碟空間用量增加。我們正與 NetApp 共同解決這個問題。

  [VDDKLOG] SSLCheckLockingCallback: locking callback overwritten!Expected 7FEE3A836E0, saw 113C2420

  若要解決此問題，請將以下路徑中的 VDDKLogLevel 登錄機碼設成 0：

  \HKEY_LOCAL_MACHINE\Software\Arcserve\Unified Data Protection\Engine\
  

• CSV 可傳輸快照有時候可能會失敗，並且回復為軟體快照。硬體提供者多次重新試著建立可傳輸快照後，就會發生此情況。您可以在 Windows 事件檢視器中找到下列錯誤。我們正與 NetApp 共同解決這個問題。

  以「10」秒為間隔重試「100」次後，仍無法在儲存系統「xxx」的多個磁碟區建立快照複本「{xxx}_backup」。

• 為 cDOT 使用最新的 Data ONTAP 版本時，硬體快照會使用 FlexClone，即使未取得授權亦然。這是 NetApp 的已知問題。若要繼續執行備份而不使用 FlexClone 授權，請在 Arcserve UDP Proxy 伺服器上建立登錄機碼。

  遵循下列步驟以建立登錄機碼：

  1. 登入 Proxy 伺服器。
  2. 請在下列位置建立 DoNotUseFlexCloneLicenseToCloneLun 機碼：

     HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
     

  3. 建立下列字串值，並將值設為 1。

     DoNotUseFlexCloneLicenseToCloneLun
     

與 Arcserve UDP 復原點檢視相關

在切換成 [Arcserve UDP 復原點檢視] 後，將無法裝載備份工作階段中裝載於檔案路徑下的磁碟區。

症狀

如果仍然裝載磁碟區，則 [Arcserve UDP 復原點檢視] 會直接開啟由作業系統 (而非備份工作階段) 所裝載的磁碟區。

如果已卸載磁碟區，則在該檔案路徑下的 [Arcserve UDP 復原點檢視] 會顯示空白。

解決方案

使用 [裝載復原點] 來裝載此類型的磁碟區。

Host-Based VM Backup Related

• Potential problem detected when backing up a VMware VM with Changed Block Tracking enabled and running on ESXi 6.0 or ESXi 6.0.

  症狀

  VMware recently published a KB article, which indicates that, in ESXi 6.0 or ESXi 6.0.x, a bug has been introduced in Changed Block Tracking (CBT) and it causes the CBT to return incorrect changed sector list. Arcserve UDP is potentially affected by this issue, which results inconsistent virtual machine backups (both full and incremental). For more details, refer to the VMware KB.

  If the problem occurs, the catalog job may fail and Check Recovery Point may report errors.

  解決方案

  VMware has released a patch for this issue. Apply this patch on your ESXi hosts. For more details, see the VMware KB article, or Arcserve KB article.

• An agentless backup of SUSE Linux Enterprise Server 12 VM in Hyper-V fails and VM guest OS hangs after the backup.

  症狀

  This problem is observed if the Hyper-V host is Windows 2012 R2 and VM’s guest OS is SUSE Linux Enterprise Server (SLES) 12 with runlevel 5 (with graphical interface). In this case, the agentless backup job hangs at the “taking snapshot” phase and finally fails. After that, the VM guest OS becomes unresponsive.

  解決方案

  This is not an issue of Arcserve UDP but a compatibility problem of Windows and SUSE. The same problem occurs when creating a VSS snapshot by using diskshadow command in the Hyper-V host. Follow these steps to verify the problem:

  1. Log in to the Hyper-V server.
  2. Open the Windows Command Line as an administrator.
  3. From the command line, type the following commands.
     1. Type "diskshadow" and press Enter.
     2. Type “add volume X:” and press Enter. (X: is the volume in which VM’s virtual disk files and configuration file reside. If VM’s disk files or configuration file are on different volumes, repeat this command to add all the volumes.)
     3. Type "create" and press Enter.
     4. After the snapshot creation finishes (this may take some time), type "end backup" and press Enter.
     5. Type "exit" and press Enter.
  4. Check if VM guest OS hangs.
  5. Check the Windows Event Log, Applications and Services Logs, Microsoft, Hyper-V VMMS, Admin. There should be one error log which indicates the failure of the VM during the snapshot creation.

  There is no workaround so far. We suggest you to work with Microsoft to solve the root cause. Alternatively, you may try changing the runlevel of SLES 12 from 5 to 3 (without graphical interface) but this does not guarantee any resolution.

• Pre-flight check (PFC) reports “failed to access the virtual machine” for VMware VM

  症狀

  For VMware VM, pre-flight check (PFC) reports the following warning message for the Data Consistency check even when you have already provided proper credentials.

  Not verified because the application failed to access the virtual machine. Verify that the user credentials are correct and have administrative privileges.

  解決方案

  Only PFC for VMware VM has this issue. Other features such as backup are not affected. The workaround is to install Arcserve UDP Agent on the machine in which Arcserve UDP Console is installed (Agent service does not have to be started).

• Backup and restore using SAN transport failover to non-SAN transport mode for VMs residing on ESXi 5.5 or earlier

  症狀

  Even when a SAN transport mode is possible, backup and restore jobs still use the HotAdd, NBD, or NBDSSL transport mode.

  解決方案

  This is a known issue of VMware VDDK 6.0.1. There is no solution from VMware for now. For details you can refer to Know Issues in VDDK 6.0.1 release notes.

• Backup and restore using SAN transport failover to non-SAN transport mode when the provisioned size of VM’s virtual disk is 4 TB or a multiple of 4 TB

  症狀

  Even when a SAN transport mode is possible, backup and restore jobs still use the HotAdd, NBD, or NBDSSL transport mode when the provisioned size of VM’s virtual disk is 4 TB or a multiple of 4 TB.

  解決方案

  This is VMware known issue which, according to VMware, has been in following patches:

  • For ESXi 5.5 - Patch Release ESXi550-201504001 (2112672)

  • For ESXi 6.0 - Patch Release ESXi600-201505001 (2116125)

  The workaround is to avoid using provisioned size which is the multiple of 4 TB. For example, do not use 4 TB or 8 TB; instead, use 3.9 TB or 8.1 TB.

• When VMware Tools snapshot quiescing method is used, an agentless backup of VMware systems back up a corrupted snapshot.

  症狀

  When you quiesce a VMware VM using VMware Tools, the snapshot contains corrupted data. The backup reads data from the snapshot and the data that is backed up also becomes corrupted. For more information about this issue, see the VMware KB article.

  Note: This problem occurs with all VMware ESXi versions and on a VM with guest OS Windows 2008 R2 SP1 and Windows 2012. Arcserve UDP cannot detect the data corruption problem because VMware does not return an error in this case. You may not be aware of the problem until you try to restore data.

  解決方案

  Perform the following tasks to detect and resolve the problem:

  • Recovery Point Check - Mount the volumes from the recovery point and verify data consistency by running the Microsoft tool CHKDSK at the end of the backup job. For more information on the chkdsk tool, see the Arcserve UDP Solutions Guide. The chkdsk tool may take a longer time to run. As a best practice, enable this option for weekly or monthly backup jobs.
  • Disable problematic writers in the guest OS of the VM - If the Recovery Point Check detects a problem, perform the steps described in "How to check if you may be affected by this bug" in the Arcserve KB article. The workaround suggested by VMware is to disable the VSS writers MSSearch Service Writer (ignore it, if not installed) and Shadow Copy Optimization Writer (typically present in every Windows VM) in the guest OS of the VM. You can manually do this per the VMware KB article. Arcserve UDP also provides a simple way to disable the problematic writers during a backup. For details on this known issue, see File System Catalog job fails or Recovery Point Check fails for Host-Based Agentless backup topic in the Troubleshooting chapter of Solution Guide.
• The Microsoft VSS Inside VM snapshot quiescing method in a VMware VM may results an inconsistent backup

  症狀

  When using the Microsoft VSS inside VM snapshot quiescing method to back up a VMware VM, the backup may not be consistent. Especially when backing up VM with applications (such as Exchange) installed.

  解決方案

  The workaround is to use VMware Tools snapshot quiescing method, along with disabling the VSS writers MSSearch Service Writer and Shadow Copy Optimization Writer in guest OS of VM before this problem gets fixed.

• After recovering a clustered VM to the original Hyper-V cluster, the network adapter could not connect to the virtual switch and displayed a warning message in the activity log:

  Unable to connect the network adapter <<adapter name>> to the virtual switch.
  

  症狀

  When backing up a VM, failover happens for the clustered VM before taking a snapshot . This failover causes the Hyper-V host that is recorded in the backup session to be inconsistent with the VM configuration.

  解決方案

  You can manually connect the network adapter to a virtual switch on the Hyper-V host or use the Restore to an alternative location option to recover the VM that lets you set the restore configuration for the VM.

• In Hyper-V 2012 or later, the virtual machine stays in the “Backing up” status although the agent-less host-based backup job of this virtual machine has already finished.

  症狀

  Although the backup job of one virtual machine has already finished, the virtual machine's status is still "Backup up" in the Hyper-V Manager. Therefore, if another backup job for this VM starts at this time, it will fail with error "The Hyper-V VSS writer has encountered an error when processing this virtual machine". In addition, you cannot perform some operations, such as power on/off, for the VM at that time in the Hyper-V Manager. If the VM is a Hyper-V cluster, you cannot perform live migration for that VM.

  This problem happens during the following situations:

  • There are several backup jobs starting at the same time or at times close to each other (within 1 minute).
  • One or more backup jobs finished, but there is still at least one backup job which is still in progress.

  解決方案

  While the VM is "locked", you can still use the guest OS as normal. Therefore, this has no impact on the usage/availability of the guest OS. However, if you have concerns and want to avoid this situation, you can do either of the following:

  • Use the Hyper-V Snapshot Separation option on the resources tab of agent-less host-based backup. For more information, see the Arcserve UDP Solutions Guide.
  • Use different plans to protect VMs which have a different size. In other words, include the VM with a similar size in one plan so that those backup jobs take a similar amount of time and, at the same time, set different schedules for those plans.
• When you perform Incremental backup jobs for VMware virtual machines, the backed up data size of the Incremental backup jobs may be larger than expected.

  症狀

  This is a known VMware issue where it involves Changed Block Tracking (CBT). With application level quiescing, Changed Block Tracking overstates changes.

  解決方案

  The issue is fixed in VMware ESXi 5.5 or later, and in VMware ESX 5.1 Patch 02. If VMware vCenter Server 5.5 manages any VMware ESXi 5.1 hosts, then the patch should be applied to them. For more information on this fix, see the VMware KB.

  If you still see the issue, then set the following registry on the proxy server:

  [HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM instance UUID>]

  "ResetCBT"=dword:00000001

  Example:

  [HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]

  "ResetCBT"=dword:00000001

  Note: After the registry value is set, the next Incremental backup job converts to a Verify backup job and then the subsequent Incremental backup jobs continue to run with the appropriate size.

• Due to a VMware known issue, when the storage DRS is enabled and the storage vMotion occurs while the backup job is in progress; the backup job can fail. The activity log specifies the following message: "Unable to open the VMDK file." VMware reported the following error: "A file was not found."

  For more information, see the VMware KB Article 2055943.

• The recovery of a VM with VMDK larger than 2-TB of disk fails because the VM failed to create a snapshot.

  症狀

  The backup source VM has VMDKs larger than 2-TB and the ESX/ESX(i) server with a version lower than 5.5 can only support a virtual disk of up to 2-TB disk in size. However, during the VM recovery, the following errors can occur:

  • In the vSphere Client:
    • "Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'".
    • "File is larger than the maximum size supported by datastore".
  • In the hostd log file for ESX/ESXi 4.x:
    • "Snapshot guest failed: The file is too big for the file system."
  • In the hostd log file for ESXi 5.0/5.1:
    • "Failed to do snapshot op: Error: (21) The file is too big for the datastore."

  解決方案

  This is a VMware limitation. The maximum size that VMware ESX/ESX(i) server version lower than 5.5 supports is 2 T-16 GB, which is equal to 2032 GB.

  It is recommended to use VMware ESX(i) server 5.5 as the destination to perform conversion with a large disk.

  For more information, see the VMware KB Article 1012384.

• Creating a snapshot fails when more than seven disks are attached to a single SCSI controller for a Windows VM running on an ESXi server.

  症狀

  When you run a backup job on a virtual machine containing a SCSI controller with more than 7 VMDKs, the backup job fails. The backup job fails because VMware requires a maximum number of free slots for VMDKs on a particular SCSI controller to create a snapshot. A SCSI controller can have a maximum number of 15 slots. For example, if a SCSI controller has 7 VMDKs, a snapshot can be created for each VMDK. (A total of 14 slots are used with one slot free.) If a SCSI controller has 8 VMDKs, the backup job fails because the snapshot cannot be created due to only 15 available slots.

  Note: Manually creating a snapshot also fails.

  解決方案

  For virtual machines with more than seven disks on a single SCSI controller, perform the following steps:

  1. Shut down the virtual machine.
  2. Create more thin virtual disks which allow you to add more SCSI controllers.
  3. Distribute the existing disks between multiple SCSI controllers.
  4. Power on the virtual machine.

  Snapshots can now be created for each VMDK.

  This issue is a VMware limitation where Arcserve Backup can only support the number of VMDK disks for backups.

  For more details, see the following VMware Knowledge Base article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181

• When you import VMware virtual machines from vCenter Server/ESXi 5.0 Update 3 and above while using HTTP protocol and port 80, the connection fails.
  This is a known issue with VMware. The following link opens the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069149
• When a VM is imported from a Hyper-V server, the VM becomes disabled after the Host-Based Agentless Hyper-V VM restore job overwrites the VM. The VM is disabled because the instance GUID of the restored VM is different from the original instance GUID, which was imported from the Hyper-V server. The VM instance GUID cannot revert to the original instance GUID.

  To resolve this issue, remove the old VM from Central Protection Manager and import the new VM.

• An ESX/ESXi/vSphere 5.5 purple screen of death appears when an Arcserve UDP job runs.

  症狀

  This is a known VMware issue affecting ESXi 5.0, 5.1, and 5.5 hosts and virtual machines using the E1000 and E1000e virtual network adapters.

  Note: This issue is resolved in the following VMware updates.

  • ESXi 5.0 Patch Release ESXi500-201401001. For more information, see the VMware KB.
  • ESXi 5.1 Update 2, available at VMware Downloads. For more information, see the VMware KB.
  • ESXi 5.5 Update 1, available at VMware Downloads. For more information, see the VMware ESXi 5.5 Update 1 Release notes.
  • ESXi 6.0 GA, available at VMware Downloads. For more information, see the VMware ESXi 6.0 Release notes.

  解決方案

  Switch to a VMXNET3 adapter. For more information, see the VMware KB Article 2059053.

• During backup, the Arcserve UDP agent merges the child disks data to the corresponding parent disk and creates a single disk image. Therefore, the parent-child relationship no longer exists after VM backup. As a result, only the parent disk is recovered and the "differencing disks" configuration is lost, however no data is lost. You can retrieve the data in a single merged disk after VM recovery.
  This behavior is expected for agentless backup. You can configure the "Differencing disks" manually after a successful VM recovery.
• Import VM fails when duplicate VM instance UUID exists.

  症狀

  When a VM is imported to the node view, it fails if another VM with same VM instance UUID is already added to the node view.

• A host-based VM backup plan is saved, it fails when the selected proxy machine is installed with Arcserve D2D r16.5.

  症狀

  When a host-based VM backup plan includes a proxy machine that has the previous release of Arcserve D2D installed (for example, r16.5), the error message “Cannot find dispatch method” appears when the plan is saved.

  解決方案

  This problem occurs because the API of the current version is not compatible with the API of the previous version of Arcserve D2D. As a work around, you can manually upgrade Arcserve D2D to the current version of the Arcserve UDP Agent (Windows).

• The host-based VM backup job may hang at the phase "Starting Backup" for a VM.

  症狀

  The host-based VM backup job hangs for hours and cannot proceed.

  解決方案

  End afbackend.exe according to the process ID in the activity log, remove the VM snapshot if any, and resubmit the backup job.

• After performing a restore job for a host-based VM backup Hyper-V virtual machine (VM), the status of the disks, except the boot disks on the recovered virtual machine is Offline.

  症狀

  The behavior of the operating system creates the offline state by default.

  The SAN policy was introduced in Windows Server 2008 to protect shared disks that are accessed by multiple servers. The default SAN policy from the source VM is “Offline Shared” for all SAN disks except the boot disk. Setting the policy to Offline enables the SAN disks to be offline during startup. After recovery, a new disk for the VM is created. The disk file from the VM appears to be a SAN disk where the operating system identifies it as being offline. When the offline disk is set to be back online, the disk remains online even after rebooting the system.

  解決方案

  As a workaround, specify the DISKPART.exe command: SAN POLICY=OnlineAll setting for the source VM before backup. Because the disks can be shared among other servers, data corruption can occur. You must use the correct SAN policy to protect the data.

  DISKPART.EXE command line

  Query SAN policy:

  DISKPART > san

  SAN Policy: Offline Shared

  Change SAN policy:

  DISKPART > san policy=OnlineAll

  DISKPART successfully changes the SAN policy for the current operating system.

• The iSCSI hard disk that is attached to a Hyper-V virtual machine will not be backed up.

  症狀

  After backing up a Hyper-V VM, the volumes on iSCSI devices are not listed in the restore UI.

  解決方案

  Create an agent-based backup plan in Arcserve UDP or use Arcserve UDP Agent (Windows) to back up the virtual machine.

• Pre/Post commands cannot be executed by host-based agentless backup jobs on a Hyper-V VM when the guest operating system is Windows Server 2003.

  症狀

  For host-based agentless backup jobs for a Hyper-V VM, if the guest operating system is Windows Server 2003, the Pre/Post commands cannot be executed. The activity log prints the warning "The virtual machine name is not expected. Pre/Post commands cannot be executed".

  解決方案

  Windows Server 2008, Windows Vista, or a later version of operating system do not have this problem and should be used.

• At times backup job for VMware VM crashes when the backup proxy is Windows 2003 R2 64-bit machine.

  症狀

  When Windows 2003 R2 64-bit machine is used as the backup proxy server to protect VMware VM, at times the backup job may crash. You can see error messages as following in the backup job debug log file:

  [2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLib: VixDiskLib_OpenEx: Open a disk. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}

  [2016/01/21 10:18:11:316 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: VixDiskLibVim_GetNfcTicket: Get NFC ticket for [datastore1 (3)] VMname/VMware_1.vmdk. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}

  [2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Error 18000 (listener error GVmomiFaultInvalidResponse). {AFBackend.exe::AFBackupVirtual.dll(1746.0)}

  [2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Login failure. Callback error 18000 at 2439. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}

  [2016/01/21 10:19:11:691 00 03820 03336 ] [VDDKLOG] VixDiskLibVim: Failed to find the VM. Error 18000 at 2511. {AFBackend.exe::AFBackupVirtual.dll(1746.0)}

  解決方案

  In Arcserve UDP Version 6.0, VMWare VDDK 6.0.1 is built in. But VDDK 6.0.1 does not officially support Windows 2003 R2. As a workaround, you can use one of the following options:

  • Switch to use a proxy that is officially supported by VDDK 6.0.1. For example, proxy with Windows 2008 R2, Windows 2012 or Windows 2012 R2.
  • Replace built-in VDDK 6.0.1 by VDDK 5.5.5, which is also supported by UDP 6.0. For details on how to replace VDDK, refer to the following topic in Arcserve UDP Solution Guide v6.0:

    How to apply different version of VDDK other than the built-in Version (6.0.1) in Arcserve UDP

即時虛擬機器相關事項

• 即時 VM 的名稱與位置與預期的結果不同。

  症狀

  當您使用 ESX 資訊登入，並選取資源集區作為即時 VM 的位置時，即時 VM 將位於 ESX 主機下方，且不在資源庫中。如果您從主控台刪除即時 VM，並重新建立同名的即時 VM，它會將尾碼 (1) 新增到即時 VM 名稱，而不是新增至預期的時間戳記。

  解決方案

  這是因為 ESX 伺服器是由 vCenter 管理。使用 vCenter 登入資訊來建立即時 VM。

• 如果您建立無代理程式備份計劃，並指定本機路徑作為備份目標，則無法從此復原點建立即時 VM。若要解決此問題，請使用共用資料夾作為備份目標。
• 如果使用 IP 位址新增節點，然後建立備份計劃，並指定共用資料夾作為備份目標，則可能無法從節點清單檢視中建立即時 VM。不過，您可以從目標檢視建立即時 VM。或者，您也可以使用主機名稱更新節點，然後再試一次建立即時 VM。
• 若復原點有鏡映的系統磁碟區，且您使用該復原點建立即時虛擬機器 (即時 VM)，您可能會收到一些錯誤，例如黑色死當畫面。
• 重新啟動復原伺服器後，無法在 Hyper-V 中啟動即時 VM。

  症狀

  啟動即時 VM，接著重新啟動 Hyper-V 復原伺服器時，即時 VM 可能會無法開機。

  解決方案

  若要解決這個開機失敗，請重新啟動即時 VM。

• 使用 Windows Server 2012 時，在動態磁碟上建立 NFS 可能會失敗。若要避免此問題，請使用基本磁碟。您也可以套用修補程式，並解決此問題。如需修補程式的詳細資訊，請參閱來自 Microsoft 的知識庫文章
• 當復原伺服器上作為 VMware NFS 的 Windows 磁碟區進行格式化時，建立即時 VM 會失敗。

  症狀

  我已指派 Windows 磁碟區作為 NFS 共用資料夾，並提供此共用磁碟區路徑作為即時 VM 的檔案路徑。當我將 Windows 磁碟區格式化，然後試著建立即時 VM 時，並無法建立即時 VM。無法建立即時 VM，因為 ESXi 主機無法新增 NFS 資料儲存區。VMware 顯示下列錯誤訊息：

  VMware 建立 VM 失敗。
  

  在 vmkernal.log 檔案中會顯示以下錯誤日誌：

  No underlying device for major, minor
  

  解決方案

  若要解決此問題，請對復原伺服器執行下列步驟。

  1. 依序開啟 [控制台]、[系統和安全性]、[系統管理工具]。

     [管理工具] 對話方塊隨即開啟。

  2. 按兩下 [服務]。

     [服務] 對話方塊隨即開啟。

  3. 以滑鼠右鍵按一下 [NFS 的伺服器]，然後按一下 [停止服務]。
  4. 以滑鼠右鍵按一下 [NFS 的伺服器]，然後按一下 [啟動服務]。
  5. 使用磁碟區重新建立即時 VM。

  已建立即時 VM。

與日誌檢視相關

當 NodeName 是 VM (主機名稱)，而且日誌檢視是透過按一下檢視日誌連結載入時，日誌篩選器不會有作用。

症狀

在日誌檢視中，如果受保護的 VM 沒有主機名稱，則其 NodeName 值將顯示為「VM(節點名稱)」。在此情況下，其他篩選器不會有作用。

解決方案

您可以手動將 NodeName 從 「VM (主機名稱)」 修改為主機名稱，如此所有篩選器即可正常運作。例如，將 NodeName "VM(xxxxx01-AB)" 修改為 "xxxxx01-AB"。

與安裝/遠端部署相關 (代理程式)

安裝裝載驅動程式失敗，偵錯日誌中出現錯誤代碼 1460。

症狀

Windows 設定 API 報告錯誤 1460，意指逾時期限已經到期。更新裝置驅動程式的預設逾時值為 300 秒。

解決方案

若要調整逾時值，請遵循下列步驟：

1. 在 [開始搜尋] 方塊中輸入 gpedit.msc，然後按 Enter。
2. 出現 UAC 提示時，按一下 [繼續]。
3. 導覽到下列原則位置：
4. Computer Configuration\Administrative Templates\System\Device Installation
5. 啟用下列原則設定：
6. 配置裝置安裝逾時。
7. 指定新的逾時值 (以秒為單位)。

與 Microsoft Exchange 相關

Exchange 資料庫還原失敗，發生錯誤：「無法加以掛載」。

症狀

當 Exchange 伺服器是安裝在虛擬機器之中，且執行 Arcserve UDP Agent (Windows) 來保護此虛擬機器時，就會發生這個情況。在備份執行一段時間後，如果虛擬機器回復為先前儲存的虛擬機器快照，且您嘗試將 Exchange 資料庫復原至原始位置，還原會失敗，並伴隨「Exchange 儲存群組/資料庫 [DB_Name] 已還原至其原始位置，但無法裝載它」錯誤。

根本原因仍在研究中，但目前看來似乎與 Exchange 資料庫中記錄的時間戳記以及最新的交易日誌檔有關。

解決方案

可嘗試將 Exchange 資料庫復原至替代目錄，或是先卸載資料庫、移除目標資料夾中的所有檔案、再執行還原。

與 Microsoft SQL Server 相關

如果 Microsoft SQL Server 無法分配更多記憶體，Arcserve UDP 主控台的回應可能變慢。

症狀

Microsoft SQL Server 有可能需要分配更多記憶體去處理查詢，特別是當 Arcserve UDP 資料庫中有許多資料時。但是，如果因為記憶體無法使用或配置的記憶體上限，導致 Microsoft SQL Server 無法取得更多記憶體，查詢過程將變得很慢，進而影響 Arcserve UDP 主控台的回應。

解決方案

使用 [日誌/刪除] 刪除資料庫中的部份日誌，然後重新啟動 SQL 服務。

與復原點伺服器 (RPS)/資料儲存區相關

• 手動合併工作不會執行並顯示錯誤

  症狀

  當您以手動方式提交合併工作時，不會執行工作，並在活動日誌中顯示下列訊息：

  無法執行 <節點名稱> 的合併工作，另一個工作正在執行
  

  解決方案

  此錯誤的原因可能是在相同的復原點伺服器的不同資料儲存區中，正在執行節點的其他工作。暫時的解決方案是等候工作完成，然後再試一次。

• 防毒軟體意外刪除資料儲存區檔案。

  症狀

  備份或複製工作失敗，具有錯誤：「系統找不到指定檔案」。

  檢查 Windows 事件日誌。McAfee 將資料儲存區檔案 (例如，P0000000042.data) 偵測為 Exploit-ScriptNull Trojan 病毒，並且加以刪除。

  解決方案

  配置防毒設定以在排除清單中設定復原點伺服器 (RPS) 資料儲存區位置。

  附註：部份防毒軟體需要您在伺服器端設定排除清單。

• 當目標是已刪除重複資料的資料儲存區時，取消複製工作可能得花上幾分鐘。

  症狀

  當您將網路節流設為極低頻寬，或是送至目標 RPS 伺服器的網路輸送量不高時，會發生這個情況。因此，需要數分鐘等待佇列中的資料傳送出去。

  解決方案

  等待複製工作結束。

• 如果下列兩個條件存在，則修改資料儲存區時，將不正確地顯示資料儲存區的雜湊記憶體：
  • RPS 伺服器的記憶體小於或等於 4 GB。
  • 您未在建立資料儲存區時選取雜湊記憶體的最大值。

復原點伺服器 (RPS)/從 Hyper-V 匯入/相關的節點

• 當嘗試根據 IP 位址或節點名稱新增節點時，會發生「需有管理員權限」錯誤，讓您無法新增節點。嘗試從 Hyper-V 匯入時可能發生「檢查該帳戶是否有這個 Hyper-V 伺服器的管理員權限」錯誤，造成您無法匯入虛擬機器。

  症狀

  當您嘗試根據 IP 位址或節點名稱在支援使用者帳戶控制 (UAC) 的 Windows 作業系統上新增節點 (Windows Vista 或更新版本)，或嘗試從支援 UAC 的 Hyper-V 伺服器匯入虛擬機器，且您使用的新 Windows 使用者帳戶是管理員群組的本機帳戶但不是內建管理員時，會顯示下列訊息：

  「需有管理員權限。」

  解決方案

  使用內建管理員或網域管理員。或者，可以停用遠端 UAC。

  這是預設 Windows 行為，稱為 UAC 遠端限制。如果您仍然要使用此帳戶來新增節點，請執行下列步驟以停用遠端 UAC：

  1. 按一下 [開始]，在 [搜尋程式及檔案] 欄位中輸入 regedit，然後按 Enter。

     [Windows 登錄編輯程式] 隨即開啟。

     附註：您可能需要提供管理憑證以開啟 [Windows 登錄編輯程式]。

  2. 尋找並按一下以下登錄機碼：

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
     

  3. 從 [編輯] 功能表，按一下 [新增]，然後按一下 [DWORD (32 位元) 值]。
  4. 指定 LocalAccountTokenFilterPolicy 作為新項目的名稱，然後按 Enter。
  5. 在 [LocalAccountTokenFilterPolicy] 上按一下滑鼠右鍵，然後按一下 [修改]。
  6. 在 [值] 資料欄位中指定 1，然後按一下 [確定]。
  7. 結束 [登錄編輯程式]。

  如需 Windows 行為的詳細資訊，請參閱文章 http://support.microsoft.com/kb/951016。

• 無法為節點移除指定的虛擬層。

  症狀

  這個版本沒有提供移除節點之虛擬層的功能。

  解決方案

  移除節點，然後再度新增節點。

• 當您嘗試將已由某個主控台管理的節點新增至另一個主控台時，不會顯示警告或快顯訊息。

  症狀

  Arcserve UDP 的 UI 可執行所有功能，使用者應該不需要使用多個 Arcserve UDP 主控台，因此，只有在舊伺服器淘汰時，才會發生要將代理程式從某個伺服器移至另一個伺服器的情形。

  解決方案

  將節點從某個主控台移至另一個主控台是很少見的情形。

與登錄相關

如果備份目標是 Windows Server 2012 上已啟用刪除重複資料的 NTFS 磁碟區，而且 Windows 2003 上已安裝 Arcserve UDP Agent (Windows)，則還原、合併或目錄工作可能失敗。此工作會失敗，並產生 Windows 錯誤代碼 50 和「不支援此要求」的訊息。

症狀

McAfee 或其他協力廠商軟體在安裝於 Windows Server 2012 上時，會在登錄中設定 EnableECP=1。

解決方案

在登錄中，將下列機碼下方的 EnableECP 值從 1 變更為 0：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters

如需相關資訊，請參閱 http://support.microsoft.com/kb/2817216。

與複製相關

• 中止複製來源端的 RPSReplication.exe 程序可能造成第二個複製工作失敗。

  症狀

  第二個複製工作將停滯在「準備」狀態，並且在 10 分鐘後失敗。

  解決方案

  您不需要執行任何特定作業。第二個複製工作失敗後，將觸發補救工作。

• 複製工作無法執行，直到檔案複製工作完成。

  症狀

  複製 (中) 工作失敗且活動日誌會顯示訊息「無法鎖定 <path> 上的工作階段。工作階段已被檔案複製工作鎖定，電腦名稱：<name>，程序 ID <ID>」。當啟用備份與檔案系統目錄工作搭配，而且您將檔案複製工作配置為從複製目標資料儲存區執行時，便會發生這種情況。

  解決方案

  檔案複製工作會鎖定工作階段，因此複製工作無法執行。若要解決，您可以使用下列任一個選項：

  • 配置檔案複製工作的適當排程，以便它可以及時執行，以允許複製 (中) 工作執行。或
  • 在計劃中停用檔案系統目錄。

與 Arcserve UDPExchange 細微還原 (AEGR) 公用程式有關

• 在使用 Arcserve UDP Exchange 細微還原公用程式時，不會將所有項目還原至即時伺服器。

  症狀

  在完成還原工作後，可能無法正確還原下列項目內容：

  • InternetHeaders
  • RTFCompressed
  • Codepage
  • DateCompleted
  • TaskRecurrence
  • RecurrencePattern
  • AppointmentTimeZoneDefinitionEndDisplay
  • ReminderTime
  • CommonEnd
  • AppointmentStartWhole
  • AppointmentEndWhole
  • BusyStatus
  • Meeting Owner
  • Company Name of Task

  解決方案

  使用 [匯出至 PST] 選項還原遺漏的項目。

• 在部署了 UDP 代理程式之後，無法移除舊版的獨立 Exchange 細微還原公用程式。

  症狀

  這個問題會在下列情況中發生：

  • 如果舊版的獨立 Exchange 細微還原公用程式是在部署 UDP 代理程式前後安裝，則 Exchange 細微還原公用程式無法移除。
  • 系統中有兩個版本的 Exchange 細微還原公用程式。
  • 所有捷徑都指向舊版的 Exchange 細微還原公用程式安裝資料夾。

  解決方案

  若要解決這些狀況，請執行下列其中一個解決方式，協助您解決問題：

  • 在 UDP 代理程式進行部署之前或之後，請從 [控制台] 手動解除安裝 Exchange 細微還原公用程式。
  • 如果您執行目前版本的 Exchange 細微還原公用程式，請確保舊版的 Exchange 細微還原公用程式已關閉，否則在執行目前版本時，也會繼續執行舊版。
  • 先從安裝資料夾 (%ProgramFiles%\Arcserve\Unified Data Protection\Engine\Exchange GRT) 開啟新版的 Exchange 細微還原公用程式，再解除安裝舊版的獨立 Exchange 細微還原公用程式。

與還原相關

• 使用更新 4 或更低版本的代理程式時發生錯誤。

  症狀

  使用更新 4 或更低版本的代理程式時發生下列錯誤：

  • 將 Exchange DB 還原至原始位置失敗。隨即會顯示下列錯誤訊息：

    Exchange 儲存群組/資料庫已還原到其原始位置，但無法加以裝載。」

  • 當 Microsoft Exchange 資料庫是使用重新執行日誌傾印時，不會在完成工作後重新執行日誌。

  解決方案

  將代理程式升級到 Arcserve UDP 代理程式 6.0 版。

• 將檔案還原至替代位置 (遠端共用資料夾) 失敗，在活動日誌中有錯誤訊息：「存取遭拒」。

  症狀

  當還原目標是遠端共用資料夾，例如 \\FileServer\ShareFolder\RestDest，且備份目標是具有相同路徑的遠端共用資料夾，例如 \\FileServer\ShareFolder\RestDest，即會發生錯誤。

  如果用來連線到根共用資料夾的使用者帳戶不在權限清單中，無論針對還原目標資料夾使用哪個帳戶，還原工作都會失敗。

  解決方案

  新增已針對備份目標指派的使用者帳戶，將連線建置到根共用資料夾的權限清單，並且確定使用者帳戶具有還原檔案的適當權限。

  將使用者帳戶新增至 [備份操作員] 群組，並且確定其具有覆寫安全性限制的權限。

• 升級作業系統後，可能必須在從 Arcserve UDP Agent (Windows) 還原檔案時，重新輸入加密密碼或工作階段密碼。

  症狀

  如果復原點已啟用加密，則不必為從目前伺服器備份的復原點輸入密碼。但是，如果您升級 Windows 作業系統，例如從 Windows 2008 升級到 Windows 2008 R2，密碼將不會自動填入 Arcserve UDP Agent (Windows) 使用者介面中，您必須重新輸入密碼。

  解決方案

  記下復原點加密密碼或工作階段密碼，放在安全的地方待查閱。

• 無法在還原程序期間開啟 VMDK 檔案。

  症狀

  在還原 VMware 虛擬機器時，我收到下列錯誤：

  您沒有此檔案的存取權限，如需詳細資訊，請參閱還原偵錯日誌。如有需要，請連絡 Arcserve 支援。

  您可以參閱還原偵錯日誌中的下列日誌項目：

  [VDDKLOG] CnxAuthdConnect：因為系統要求 SSL 驗證，但目標 authd 不支援 SSL，故傳回 false。

  [VDDKLOG] CnxConnectAuthd：因為 CnxAuthdConnect 失敗，故傳回 false。

  [VDDKLOG] Cnx_Connect：因為 CnxConnectAuthd 失敗，故傳回 false。

  [VDDKLOG] Cnx_Connect：錯誤訊息：需要 SSL

  解決方案

  會發生此錯誤是因為 VMware ESX 主機已停用 SSL 驗證。若要解決此錯誤，請執行下列其中一個方法：

  • 使用 vSphere 用戶端
    1. 登入 VMware vCenter/ESX 伺服器。
    2. 依序按一下 [配置]、[進階設定]、[配置]、[預設安全性]。
    3. 開啟 ESX 伺服器設定。
    4. 啟用下列選項：

       config.defaults.security.host.ruissl
       

  • 使用命令列
    1. 使用 SSH 連線到 VMware ESX 主機。
    2. 開啟 config 檔案：

       /etc/vmware/config; 
       

    3. 將 security.host.ruissl 項目設定為 TRUE。
    4. 儲存檔案並重新啟動管理代理程式。

  已啟用 SSL 驗證。

與伺服器連線相關

瀏覽日誌時，顯示伺服器連線錯誤。

症狀

當您從代理程式或主控台瀏覽活動日誌，可能會顯示以下錯誤：

無法連線至 'arcservedocs.com' 伺服器。

解決方案

您可以直接忽略這個訊息。

與虛擬待命相關

• 如果資料儲存區上有備份工作階段，則當您按一下 [恢復虛擬待命] 時，虛擬待命工作不會啟動。

  症狀

  會將節點備份到 RPS 資料儲存區，複製到另一個 RPS 資料儲存區，然後使用複製來源建立虛擬待命機器。規劃部署後，如果有虛擬待命工作的舊版工作階段，您可以直接恢復虛擬待命。但在提交工作後，虛擬待命工作將不會開始。

  解決方案

  若要解決此問題，請先執行手動複製。以滑鼠右鍵按一下節點，再按一下 [立即複製]。複製完成後，恢復虛擬待命工作。

• 當轉換工具正在使用 Arcserve UDP 5.0 版，且監視器 (Proxy) 正在使用 Arcserve UDP 6.0 版時，將無法執行虛擬待命工作。

  症狀

  虛擬待命工作失敗並顯示下列錯誤：

  無法取得磁碟簽章 (簽章為空)
  

  解決方案

  在 Arcserve UDP 6.0 版，VMWare VDDK 程式庫是從 5.5 版升級為 6.0 版。在 VDDK v6 中初始化 VDDK 程式庫時， 需要名為「指紋」的新欄位。VSB 轉換工具的呼叫是根據缺少指紋的 Arcserve UDP 5.0 版。這會導致轉換工具至監控器的呼叫失敗

  若要解決此問題，請將轉換工具更新為 Arcserve UDP 6.0 版。

• 將來源節點上的 Arcserve UDP RPS 或 Arcserve UDP 代理程式升級為 Arcserve UDP 6.0 之後，Hyper-V 的虛擬待命工作失敗。但 Hyper-V 伺服器上的 Arcserve UDP 代理程式不會升級。

  症狀

  Arcserve UDP Agent (Windows) 會備份至 Arcserve UDP RPS 資料儲存區，且 RPS 會升級為 Arcserve UDP 6.0。此外，Arcserve UDP Agent (Windows) 已備份至共用資料夾，且代理程式升級為 Arcserve UDP 6.0。Hyper-V 的虛擬待命 VSB 工作失敗並顯示下列錯誤：

  找不到 {http://webservice.arcflash.com}IsVmFileExist 的分配方法。
  

  或

  找不到 {https://webservice.arcflash.com}IsVmFileExist 的分配方法。
  

  解決方案

  在 Hyper-V 伺服器上將 Arcserve UDP 代理程式升級為 Arcserve UDP 6.0。

• 磁碟開啟時處於離線狀態。這個問題是因為 SAN 原則已套用在 Windows 2008 與更新版的作業系統上。作業系統會保護由超過一個伺服器存取的共用磁碟。伺服器第一次偵測到磁碟時，Windows 將磁碟設為離線狀態。當磁碟成為上線狀態後，磁碟將維持上線狀態。

  造成此行為的另一個原因與將其中包含「唯讀」磁碟區的虛擬機器開啟電源相關。若要修正此情況，請將磁碟上磁碟區設為可寫入的狀態。

• 應用程式不支援使用 VMware 連結模式匯入 vCenter 伺服器。為了保護 [連結模式] 群組中的所有 vCenter 伺服器執行個體，請個別新增每個 vCenter 伺服器執行個體。
• 虛擬待命不支援在來源電腦上的系統磁碟區或開機磁碟區位於動態磁碟時，將復原點轉換成 Hyper-V 格式。
• 虛擬待命不支援可讓您定義動態 RAM 數量的虛擬待命建立作業，這些動態 RAM 是由 Windows 2008 R2 SP1 和 Windows 2012 Hyper-V 伺服器系統上保護之虛擬機器所使用。
• 當您使用目前的快照執行 V2P 復原時，可能會出現一則訊息，指出下列內容：

  無法取得「復原點」資訊。

  當您使用最新快照執行 V2P 復原，而且節點的轉換工作並未在將虛擬待命工作重新部署到節點之後完成時，即會發生此行為。

  解決方案

  1. 提交 Arcserve UDP 代理程式備份工作，以擷取節點的目前狀態。然後執行節點的裸機復原。
  2. 關閉虛擬待命虛擬機器電源，然後提交虛擬待命轉換工作，以建立節點的目前復原點快照。
• V2P 使用者介面可能不會顯示最新快照。當您從最新快照完成 V2P 復原之後執行 V2P 復原時，即會發生此行為。

  解決方案

  使用 Arcserve UDP 代理程式裸機復原執行 V2P 復原。

• 當備份來源機器 (Arcserve UDP 代理程式的安裝處) 有原生的 4KB 磁區磁碟，且 Arcserve UDP 代理程式備份工作已在 4KB 磁區磁碟上備份磁碟區，則轉換 Arcserve UDP 代理程式備份工作階段的待命虛擬機器無法偵測對應 4KB 磁區磁碟的磁碟分割和磁碟區。當來源磁碟包含 4 KB 磁區，且待命虛擬機器支援 512 B 磁區時，便可以預期會有此情形發生。在轉換後，因為磁區大小變更，待命虛擬機器中的客體作業系統找不到磁碟中繼資料。

  附註：這項限制僅適用於在 Hyper-V 伺服器上執行的虛擬待命工作。

• 在以主機為基礎的虛擬機器工作階段中，如果有附加至 VM 而後卸除的網路介面卡，則虛擬待命中列出的網路介面卡數量會多於 VM 中目前清單涵蓋的數量。
• 轉換 2 TB 磁碟檔案失敗，因為 VM 無法建立快照。

  症狀

  Arcserve UDP Agent (Windows) 有一個 2 TB 的磁碟，且 ESX/ESX(i) 伺服器的版本低於 5.5 版，只能支援最高為 2 TB 大小的虛擬磁碟。然而，轉換期間可能發生下列錯誤：

  • 在 vSphere 用戶端中：
    • "Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'"
    • "File is larger than the maximum size supported by datastore"
  • 在 ESX/ESXi 4.x 的 hostd 記錄檔中：
    • 「快照客體失敗：檔案太大，無法為檔案系統使用。」
  • 在 ESXi 5.0/5.1 的 hostd 記錄檔中：
    • 「無法執行快照操作：錯誤：(21) 檔案太大，無法為檔案系統使用。」

  解決方案

  這是一個 VMware 的限制。低於 5.5 版本的 VMware ESX/ESX(i) 伺服器支援的最大大小為 2 T-16 GB，亦即 2032 GB。

  建議使用 VMware ESX(i) 伺服器 5.5 版做為執行大型磁碟轉換的目的地。

  如需相關資訊，請參閱 VMware 知識庫文件 1012384。

• 變更虛擬待命監控器的密碼，並在 Arcserve UDP 主控台 UI 中更新虛擬待命監控器的節點後，部署使用該監控伺服器的計劃可能會部署失敗。

  症狀

  部署計劃失敗，並顯示以下錯誤訊息：「無法將「虛擬待命設定」套用到節點 'xxx' 上。(無法從 xxx 連線至監控器：xxx。使用者憑證無效)」。

  解決方案

  編輯計劃中的虛擬待命工作，輸入監控器的正確密碼，然後儲存計劃。

與 VSS 快照相關

無法對 VMware VM 的無代理程式備份產生目錄

症狀

由於 VM 客體作業系統中 VMware 或 Microsoft 引起的 VSS 快照問題，可能無法為 VMware VM 的無代理程式備份作業產生目錄，並出現下列訊息：

「無法將索引區塊對應到其正確的磁碟區區塊。發生 IndexAlloc 錯誤」。

解決方案

1. 執行 'chkdsk' 以確保客體作業系統內的資料保持一致。
2. 關閉虛擬機器電源，讓客體內的 VSS 快照不再發生。
3. 備份電源關閉狀態下的虛擬機器。

附註：這個問題極少發生。如需詳細資訊，請參閱 VMware 知識庫文件 2006849 或 Microsoft 知識庫文件 2853247。

與檔案複製相關

檔案複製/封存未啟動。

症狀

檔案複製/封存未啟動。

解決方案

在一些罕見的情況下，於檔案複製/封存工作完成之後，用來指出復原點的檔案需要保留，以供檔案複製/封存工作使用，因此無法移除。這類檔案命名為 *.alck，位於特定節點的備份目標資料夾下，而且檔案大小為零。暫時的解決方法是您可以找出這些檔案，並手動刪除它們。

單一安裝程式相關事項

症狀

當目標磁碟區為 FAT32 檔案系統時，無法從單一安裝程式 (使用 ASDownloader.exe) 下載 Arcserve Backup 或 Arcserve High Availability 元件，因為套件超過 FAT32 檔案系統所支援的 4 GB 檔案大小限制。

解決方案

暫時的解決方法是您可以下載到 NTFS 磁碟區。

設備升級相關

• 將設備升級到 Arcserve UDP v6 後設備的出廠重設無法運作

  Arcserve UDP 設備升級到 Arcserve UDP v6 後，在 [Arcserve UDP 主控台] 的 [設定] 索引標籤中會看到 [出廠重設]。如果您嘗試按一下 [執行出廠重設] 執行出廠重設，然後按一下 [確認出廠重設] 對話方塊中的 [重設]，將顯示下列錯誤訊息︰

  設備出廠重設失敗。使用下列指令，手動重設設備的出廠設定︰"powershell.exe .arcserve_factoryreset.ps1 –perserve_data –auto_reboot " in cmd under path C:\Program Files\Arcserve\Unified Data Protection\Management\Appliance.

  附註：錯誤訊息不正確。升級到 UDP v6 的設備使用者需知道，因為在裝置機器上沒有任何 Arcserve UDP 復原磁碟分割，故不支援出廠重設。

• 在設備上使用 Linux 備份伺服器時 Linux 即時 VM 工作失敗

  如果在設備上使用 Linux 備份伺服器，設備不支援使用 Linux 復原點的即時 VM。　

  症狀

  Linux 即時 VM 工作失敗，並顯示下列錯誤訊息：

  無法從 VM $vmname 取得 IP 位址。請確認 VM 和備份伺服器是在相同網路中。

  解決方案

  失敗是由即時 VM 工作中建立的待命 VM 引起。它會嘗試透過 Appliance_hostname:8014 連線到 Linux 備份伺服器，雖然您已將 Appliance_hostname:8018 的 Linux 備份伺服器新增至主控台。因為在設備機器上，連接埠 8014 是由 UDP Windows 代理程式服務監控，所以即時 VM 工作會失敗。

  若要解決 Linux 即時 VM 工作使用靜態 IP 的問題，可以使用暫時解決方法。

  請按照下列步驟操作：

  1. 在 UDP 設備機器上找到兩個可用的連接埠，例如 8018 和 8035。

     您可以使用 netstat -aon|findstr "port" 來確認連接埠是否被佔用。  

     附註：如果您正在升級 Arcserve UDP v6，在 UDP 設備機器上的連接埠 8018會被配置為重新導向至 Linux 備份伺服器的 8014。使用下列命令釋放 UDP 設備機器上的 8018︰

     netsh interface portproxy delete v4tov4 listenport=8018

  2. 在 Linux 備份伺服器上，將下列檔案中的 port="8014"  修改為 port="8018"：/opt/Arcserve/d2dserver/TOMCAT/conf/server.xml
  3. 在 Linux 備份伺服器上，下列檔案中加入一行 "dss_port=8035"：/opt/Arcserve/d2dserver/configfiles/server.cfg

     附註：如果檔案不存在，請建立該檔案。 執行下列命令以重新啟動 Linux 備份伺服器：

     /opt/Arcserve/d2dserver/bin/d2dserver restart

  4. 執行下列命令，以允許 Linux 機器的防火牆上連接埠 8018 以及 8035 之間的通訊︰

     #iptables -A INPUT -p tcp --dport 8018 -j ACCEPT

     #iptables -A INPUT -p tcp --dport 8035 -j ACCEPT

     #/etc/init.d/iptables save

  5. 在 UDP 設備上，使用命令列執行下列命令︰

     netsh interface portproxy add v4tov4 listenport=8018 connectaddress=192.168.10.2 connectport=8018 protocol=tcp

     netsh interface portproxy add v4tov4 listenport=8035 connectaddress=192.168.10.2 connectport=8035 protocol=tcp

  6. 在 UDP 設備機器上
     1. 開啟位於下列位置的 setdns.ps1 檔案：

        C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Appliance

     2. 在檔案結尾加入以下列兩行︰

        netsh interface portproxy add v4tov4 listenport=8018 connectaddress=$VMIp connectport=8018 protocol=tcp

        netsh interface portproxy add v4tov4 listenport=8035 connectaddress=$VMIp connectport=8035 protocol=tcp

  7. 在 [UDP 主控台] 中，將 Linux 備份伺服器更新為連接埠 8018。

  重要！暫時解決方法不適用於下列選項︰

  • Linux 移轉 BMR 工作
• 預設的 Linux 備份伺服器設定 Linux 即時 VM 工作的 DHCP

Copyright © 2015 Arcserve. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

已知問題