Home/技術 / 【ESXi 實戰救援案例】快照損毀、VM 卡 77% / 81%、3.4TB 資料救回完整流程

VMware Snapshot Chain Repair + Delta Merge 完整教學(含真實案例)

在 VMware ESXi / vSphere 的環境中,
虛擬機快照(Snapshot)一旦使用不當、或合併中斷,就會造成:

  • VM 卡在 77% / 81% 無法開機
  • D 槽資料回到舊版本
  • snapshot chain 爛掉 → parentCID mismatch
  • vmkfstools 無法合併 → Error (18)
  • 無法移除 snapshot
  • 無法掛載 delta → 顯示 0MB

本篇文章記錄一次 真實救援案例
成功救回 超過 3.4TB 的 Windows Server 2019 資料磁碟
並完整修復被破壞的 snapshot chain。


🧨 一、災難描述:VM 無法開機、快照合併中斷

客戶一台 Windows 2019 Mail Server(ESXi 6.7)突然出現:

  • vSphere HA 嘗試重啟失敗
  • VM 卡住:“Powering On 77% / 81%”
  • 主機看到殘留 vmx process → Zombie VM
  • Snapshot “Delete All” 卡住只到 50%
  • 檔案大量存在(000001~000012)

vmware.log 中看到:

The parent virtual disk has been modified since the child was created. (18)
Change tracking invalid
Could not open sesparse…

→ 代表 快照鍊鏈(Snapshot Chain)損毀


🧭 二、初步處理:停止 Zombie VMX、清除 LCK

ESXi SSH:

esxcli vm process list
esxcli vm process kill --type=force --world-id <worldid>
rm -f *.lck

VM 從 “卡住” → “可以操作”,但仍無法啟動。


📦 三、發現關鍵:快照鏈仍完整,但資料未填回 base disk

檢查 snapshot descriptor:

grep -E "CID|parentCID|parentFileNameHint" *.vmdk

結果:

  • _1-000001_1-000012CID 與 parentCID 完全正確
  • 沒有 CID mismatch
  • 鏈子是通的!

但問題是:

❗ 最上層快照(000012)中包含 最新資料
❗ Snapshot Delete 中斷 → Delta 未回寫 base
❗ VM fallback 到 base → D 槽顯示 “舊資料”


🔥 四、決定救援方向:強制合併 delta

❗ vmkfstools 在 parent 被改過時會拒絕合併:

The parent virtual disk has been modified... (18)

原因:

  • Delete snapshot 中途混亂,parent longContentID 改變
  • child(000012)的 parentCID 與 metadata 被不同步

🔧 五、修復 snapshot chain(手動 CID 修復)

  1. 找出 000011 的 CID:
cat "win2019-mail1 Notes_1-000011.vmdk"
CID=11111111

將 base vmdk 修成與第一層 parent 一致:

sed -i 's/CID=f0eb2cd4/CID=5212b7ae/' "win2019-mail1 Notes_1.vmdk"

讓 chain 成功串接:

base → 000001 → 000002 → … → 000012

🛠 六、建立 Merge Descriptor(強制合併用)

建立:

# Disk DescriptorFile
CID=22222222
parentCID=11111111
parentFileNameHint="win2019-mail1 Notes_1-000011.vmdk"
RW 7340032000 SESPARSE "win2019-mail1 Notes_1-000012-sesparse.vmdk"

🚀 七、vmkfstools 成功開始合併(Clone)

vmkfstools -i "win2019-mail1 Notes_1-000012-MERGE.vmdk" "Fixed_D.vmdk"

出現:

Clone: 0% done

→ 代表修復成功,VMware 接受了這條 chain。


🕘 八、等待數小時,clone 產生完整 3.4TB 新磁碟

完成後目錄出現:

Fixed_D-flat.vmdk   (3.4 TB)
Fixed_D.vmdk

這就是 已完整合併所有 snapshot 的 D 槽


🧩 九、掛載新磁碟到原 VM

  1. 移除舊 D 槽(不刪檔案)
  2. Add Hard Disk → Existing Disk
  3. 指向:
Fixed_D.vmdk
  1. 開機 Windows

D 槽立即恢復所有最新資料。

🧹 十、清理大量殘留快照檔案(可回收 TB 空間)

可安全刪除:

win2019-mail1 Notes_1-000001*.vmdk
win2019-mail1 Notes_1-000002*.vmdk
...
win2019-mail1 Notes_1-000012*.vmdk
*.sesparse.vmdk
*.bak
*.MERGE.vmdk
*.FIXED.vmdk

不可刪除:

win2019-mail1 Notes-flat.vmdk     ← C 槽
win2019-mail1 Notes.vmdk
Fixed_D-flat.vmdk                 ← D 槽(最新)
Fixed_D.vmdk

🧠 十一、本次救援的重點技巧總結

✔ 善用 CID / parentCID 判斷 snapshot chain 是否健康
✔ 不要亂刪 delta,先 clone 出乾淨磁碟
✔ vmkfstools -i 是最安全的救援方式
✔ chain mismatch 可透過手動修正 descriptor 修復
✔ 修復後 clone → 生出乾淨 flat disk
✔ 任何 snapshot merge 卡住都能用此方式救回

🛡 十二、防止未來快照災難的建議

1. 不能把快照當備份
2. 不要留 snapshot 超過 24~72 小時
3. iSCSI / NFS NAS 請保持快照期間負載低
4. 避免 snapshot 多層(>5 就危險)
5. 快照 Merge 期間不要中斷 ESXi / vCenter
6. 定期備份 VMX / descriptor
7. 若 snapshot 合併超過 2 小時 → 儘早救援

🧠 本文章與所附圖片部分內容為 AI 生成或 AI 輔助產製。文中提及之商標、品牌名稱、產品圖片及相關標識, 其著作權與商標權均屬原權利人所有,本網站僅作為資訊呈現與示意使用

最新文章

推薦文章
M365 社交工程新變種:當 MFA 也擋不住「Token 竊取」攻擊

前言:密碼已死,現在駭客要的是你的「

社交工程+電子郵件攻擊深入分析

社交工程與電子郵件攻擊:企業面臨的多

DNS/BIND 伺服器安全隱患曝光:攻擊手法速查

DNS / BIND 伺服器安全議題與


留言

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

分析完成 ✔