雖然虛擬機災難恢復與物理DR實踐相比，是一個游戲規則的改變者，但它往往是緩慢而不靈活的，而且存在潛在的缺點。良好的DR不是憑空發生的，它必須得到有效的計劃、管理和適當的測試。雖然手動捕獲設置、配置和管理虛擬DR所需的數據和細節，對于小環境來說可能很簡單，但這種方法的伸縮性并不好。

服務器在沒有正確的授權或成本分配的情況下進行配置，這將導致虛擬機（VM）的蔓延。讓VM蔓延變得尤其令人討厭的是，這些蔓延的生產機器經常遇到配置問題。正如他們所說，這些規則是有原因的，例如，為了捕獲需要特殊處理的部署，例如虛擬機災難恢復和VM的依賴關系。

[[205056]]

在正常配置期間，捕獲需求和所有權數據不是問題。在配置過程之外執行時，在虛擬機災難恢復情況甚至日常支持中所需的大量關鍵信息尚未被正確收集和存儲，這使得這兩個任務更加困難。

妥善保護生產虛擬機

更糟糕的是，VM或服務可能沒有DR測試計劃或管理員。管理員經常會發現，生產機器并不是支持DR的。文檔和DR設置可能沒有發生。

如果DR管理器不知道這些機器，那么在真正的DR場景發生之前，問題才會顯現。企業集團或所有者可能認為虛擬機災難恢復已經啟用，但事實并未啟用，這不僅可能導致對提供商的信心喪失，而且會造成嚴重的財務損失。

大公司在通信方面是出了名的差，這就是為什么每個生產虛擬機都應該進行全面的生產部署。出于這個原因，用戶驗收測試和開發VM不應該被重新用于生產虛擬機。

在正確的部署過程中，應該在這些問題變得至關重要之前抓住它們。正確地做到這一點也意味著所有者已經正確地注意到，成本是分攤的，并且虛擬機有一連串的指揮和決策。

這些都是虛擬機災難恢復實際上不需要做的事情。按照預定的間隔，根據DR計劃檢查和交叉引用VM是符合業務的利益的。并不是每個機器都有DR計劃，但是這樣做會使得這些流氓機器能夠根據需要進行識別和修復。