UCAMC
← 回到 Blog
虛擬化約 3 分鐘閱讀

PVE 還原 VM 會不會覆蓋原機？先看 Restore 的 VM ID 與 storage

Updated 2026/07/22UCAMC
分類虛擬化網站經營維運筆記
標籤#Proxmox VE#PVE#Backup Restore#VM
電腦螢幕上的維運筆記與指令畫面，象徵 Proxmox VE VM 還原前的選項檢查

PVE 還原 VM 最容易讓人緊張的問題通常不是「備份檔在哪裡」，而是按下 Restore 之後到底會不會把原本那台 VM 蓋掉。尤其當備份來源、正式 VM、測試 VM 都在同一台 Proxmox VE 主機上時，畫面裡的 VM ID、storage、target node 看起來很像，判斷錯一次就可能把原本可以保留的回復路線弄亂。

這篇先不把它寫成完整教學，而是整理還原前我會看的判斷點：PVE 的還原風險主要看 VM ID 與目標 storage，而不是只看備份檔名稱。

第一個判斷：還原到原 VM ID，還是新 VM ID？

在 PVE 的備份還原流程裡，最重要的是 VM ID。一般情境可以分成兩種：

  1. 還原到原本 VM ID：目標就是把原 VM 回復到備份狀態，這通常帶有覆蓋或替換的意味。
  2. 還原成新的 VM ID：把備份複製成另一台測試 VM，原本 VM 不應被動到。

如果只是想確認備份能不能開機，我會優先選第二種：給它一個新的 VM ID，例如正式機是 101，測試還原就先用 901 或其他未使用 ID。這樣做的好處是風險比較小，後面也比較容易比較差異。

還原前可以先在 PVE shell 檢查目前已存在的 VM ID：

qm list

如果要看某台 VM 的設定，則用：

qm config 101

這兩個指令的目的不是炫技，而是避免只靠 GUI 記憶判斷。只要目標 VM ID 已經存在，就要停下來確認這次到底是要覆蓋、替換，還是應該改成新的 VM ID。

第二個判斷：storage 不是小事

很多人還原時只注意 VM ID，卻忽略目標 storage。PVE 可能有 local-lvm、ZFS、NFS、Ceph、PBS 來源或其他儲存層；備份還原時，磁碟最後放到哪裡會影響容量、效能與後續 snapshot 能力。

我會先確認兩件事：

pvesm status

以及：

qm config 101 | grep -E '^(scsi|virtio|sata|ide)[0-9]:'

第一個指令看 storage 是否在線、容量是否足夠；第二個指令看原本 VM 磁碟介面與位置。若正式機原本放在 local-lvm，測試還原卻放到一個容量很小或效能不同的 storage，開機測試結果就可能失真。

Restore 畫面裡我會特別慢慢看的欄位

PVE Restore 視窗會因版本與備份來源不同而略有差異，但判斷邏輯大致相同：

  • Source backup：確認時間點，不要只看最新檔名，還要看備份完成時間。
  • VM ID / Unique：確認是使用原 ID，還是產生新 ID。
  • Target storage：確認磁碟會還原到哪個 storage。
  • Target node：叢集環境要確認還原到哪一台節點。
  • Bandwidth / rate limit：大型 VM 還原時要避免把 production storage 打滿。
  • Start after restore：測試還原時通常不要急著自動開機，先檢查設定再啟動。

如果畫面上出現 overwrite、replace、existing VM 之類的提示，我會把它當成需要二次確認的紅燈。PVE 不會知道你心裡想的是「正式回復」還是「只想測試」，它只會依照你指定的 VM ID 與目標執行。

我比較安全的還原順序

若目標只是測試備份可用性，而不是立即救援 production，我會採用這個順序：

  1. 先用 qm list 找一個未使用的新 VM ID。
  2. 從備份還原到新 VM ID。
  3. 先不要勾選自動開機。
  4. 還原完成後檢查 VM 設定與磁碟位置。
  5. 暫時斷開或隔離網路，避免測試 VM 跟正式服務搶 IP 或 hostname。
  6. 開機後確認系統能進入、服務能啟動、資料時間點合理。
  7. 測試完成後再決定是否保留、刪除，或進入正式回復流程。

網路隔離很重要。很多 VM 不是壞在還原，而是測試還原後直接開機，結果和正式機使用同一組 IP、同一個資料庫連線、同一組排程工作，造成另一種事故。

什麼時候才考慮還原到原 VM？

還原到原 VM ID 比較像正式救援動作，不應該只是「試試看」。我會先確認：

  • 現有 VM 是否已經關機或進入維護狀態。
  • 是否已經備份目前狀態，避免把事故後仍有價值的資料覆蓋掉。
  • 是否知道要回到哪個備份時間點。
  • DNS、反向代理、資料庫、外部儲存與排程是否有相依性。
  • 是否有回復失敗時的第二條路，例如再還原到新 VM ID。

如果目前問題是資料被誤刪、系統被入侵、檔案系統損壞，還原到原 VM 前更要確認「事故發生時間」與「備份時間」的關係。最新備份不一定是最好的備份；它可能已經包含錯誤狀態。

PBS 備份成功，也還是要做還原測試

Proxmox Backup Server 顯示備份成功，只代表備份任務完成，不等於整台 VM 一定能在你期待的 storage、網路與啟動模式下正常回來。比較可靠的做法，是定期挑一台低風險 VM 做還原測試，並記錄：

備份來源：PBS / storage 名稱
原 VM ID：101
測試還原 VM ID：901
還原 storage：local-lvm
是否自動開機：否
第一次開機結果：可進入系統 / 卡在 boot / 網卡名稱改變
測試後處置：刪除測試 VM / 保留待比對

這份紀錄不用很華麗，但日後真正需要救援時，會比「我記得上次可以」可靠很多。

總結：不要把 Restore 當成單一按鈕

PVE Restore 不是單一動作，而是一組選擇：備份時間點、VM ID、storage、node、開機策略與網路風險。若只是測試，優先還原成新的 VM ID；若要正式回復，先保留現況、確認時間點，再處理原 VM。

最簡單的安全原則是：不確定會不會覆蓋時，就先不要使用原 VM ID。 先用新 VM ID 做可開機驗證，再決定是否進入正式回復，通常能避免把一次救援變成第二次事故。