שרשרת תמונת מצב של מכונה וירטואלית שבורה (.VMDK / .VHDX / .QCOW2) והצלת דיסק¶

כאשר מכונה וירטואלית (VM) בייצור ב-VMware ESXi / Workstation, Microsoft Hyper-V, Proxmox VE / QEMU-KVM, או Oracle VirtualBox מסרבת לפתע להידלק לאחר שעבודת גיבוי נכשלה, למאגר הנתונים נגמר שטח הדיסק (0 bytes free), או שמנהל מערכת נוגע בקובץ תמונת מצב, קליק אחד מבוהל יכול למחוק חודשים או שנים של נתונים עסקיים חיים. צילומי מצב של מכונות וירטואליות הן לא גיבויים עצמאיים מלאים; הם שבירים שרשראות הבדל דלתא להעתקה על כתיבה (CoW) (*-000001-delta.vmdk, *.avhdx, או קובץ גיבוי .qcow2 שכבות-על) כאשר כל בלוק בודד שנכתב מאז שצולמה תצלום חי אך ורק בתוך קבצי הדלתא של הילד, בעוד שדיסק הבסיס המקורי יושב קפוא בעבר.

אם אתה רואה שגיאות כמו "The parent virtual disk has been modified since the child was created (Parent CID does not match)" ב-VMware, "Cannot boot: The chain of virtual hard disks is broken" ב-Hyper-V, או "Could not open backing file: L1/L2 table corrupted" ב-QEMU/Proxmox, הצבעה מחדש של ה-VM ישירות על הדיסק הבסיסי (flat.vmdk או בסיס .vhdx) ואתחול זה קטלני. פעולה זו מאתחלת את השרת כפי שהיה קיים לפני 6 חודשים כאשר נוצרה תמונת המצב הראשונה, מבטל באופן מיידי את קישור ההורה-ילד ה-GUID/CID ההצפנה ומעבד כל תמונת מצב של דלתא מאז אותו תאריך מיותמת ובלתי ניתנת למיזוג.

מדריך זה מספק שלב אחר שלב שחזור שרשרת תמונת מצב לא הרסנית, תיקון כותרות קובץ מתאר ופרוטוקולי חילוץ קבצי אורח מחוץ לפס המבוססים על מאמרי VMware מאת Broadcom Knowledge Base (KB 1007969 / 316578 ו-KB 1002511), Microsoft Hyper-V Merge-VHD ו Set-VHD מפרטים הנדסיים, QEMU qemu-img ו libguestfs (guestmount) תקנים משפטיים, ו-NIST Special Publication 800-86.

תעשה את זה עכשיו¶

אם מכונה וירטואלית מסרבת להפעיל או זורקת שגיאת שרשרת תמונת מצב/שגיאת דיסק וירטואלי פגום:

1. לעולם אל תערוך את הגדרות ה-VM כדי לאתחל ישירות מהדיסק הבסיסי (Server.vmdk או Server.vhdx) כאשר צילומי דלתא (-000001.vmdk או .avhdx) קיימים בתיקייה. ברגע שמערכת הפעלה אורחת מאתחלת ישירות מהדיסק האב הבסיסי אפילו למשך 2 שניות, מערכת ההפעלה האורחת כותבת חותמות זמן אתחול ועדכוני יומן NTFS/ext4 לתוך הדיסק הבסיסי, משנה את מזהה התוכן של הדיסק האב (CID) ב-VMware או ב-Linkage GUID / Timetamp ב-Hyper-V. האתחול הבודד הזה שובר את כל שרשרת צילומי הילד התלויים בכך שדיסק הבסיס יישאר קפוא ביט אחר ביט. אם חדר השרת שלך חווה שריפה פעילה, כשל קירור או סכנה פיזית, פנה והתקשר למספר החירום המקומי שלך (911 בארצות הברית וקנדה, 112 ברחבי האיחוד האירופי, 999 בבריטניה) או בדוק מספרי חירום.
2. לעולם אל תמחק .avhdx, -delta.vmdk, או -sesparse.vmdk קבצים בסייר Windows או בדפדפן ESXi Datastore כדי "לפנות שטח דיסק." שלא כמו קבצים זמניים רגילים, .avhdx ו -delta.vmdk קבצים הם הכונן הקשיח החי הנוכחי שלך. אם תמונת מצב נוצרה לפני 8 חודשים על ידי עבודת גיבוי תקועה של Veeam/CommVault ונותרה לפעול, 100 אחוז מכל עסקת מסד נתונים, חשבונית וקובץ שנוצרו במהלך 8 החודשים האחרונים מאוחסנים בתוך אלה .avhdx או -delta.vmdk קבצים. מחיקתם מוחקת את כל הנתונים שנוצרו מאז החלה תמונת המצב.
3. ** העתק או שכפול הכל .vmdk, .vhdx/.avhdx, או .qcow2 קבצים לנפח אחסון חיצוני / משני לפני הפעלת כל פקודת מיזוג, ביצוע או תיקון.** מיזוג שרשרת של תמונת מצב כותב את כל בלוקי הדלתא לאחור אל הדיסק האב במקום. אם המיזוג נכשל באמצע בגלל שגיאה של סקטור דיסק פגום או שגיאה מלאה של מאגר הנתונים, גם הדיסק האב וגם הדיסק הבן פגום אלא אם כן הוצאת תחילה עותק של קובץ גולמי.
4. אם ה-Hypervisor נכשל בגלל שמאגר הנתונים המארח/נפח פגע ב-100% מלא (No space left on device), לעולם אל תנסה "למחוק / לאחד תמונות Snapshots" עד שתוסיף שטח פנוי או שיבוט למאגר נתונים גדול יותר. איחוד שרשרת מרובת תמונות מצריך שטח שריטה זמני השווה לגודל דיסק הדלתא הגדול ביותר. ניסיון לאחד על מאגר נתונים מלא ב-99% יקרוס את ה-hypervisor mid-commit.
5. מפה את ההורה המדויק -> שרשרת התלות בילד באמצעות פקודות בדיקה לקריאה בלבד (vmkfstools -e, Get-VHD, או qemu-img info --backing-chain) לפני נגיעה בבייט בודד. כל כותרת של קובץ תמונת מצב שמה במפורש את שם הקובץ האב המדויק ואת מזהה ההצפנה ההורה שהוא מצפה שיישבו ישירות מעליו.

flowchart TD
    A["VM מסרב לאתחל: שרשרת Snapshot שבורה, חוסר התאמה של CID של הורה או VMDK/VHDX/QCOW2 פגום"] --> B["עצור: אין לאתחל את הדיסק הבסיסי ישירות, ואל תמחק אף קבצי -delta.vmdk או .avhdx"]
    B --> C["שלב 1: בדוק מאחסן נתונים מארח / שטח פנוי בנפח (`df -h` / `רשימת מערכת קבצי אחסון esxcli`)"]
    C --> D["שלב 2: העתק את כל קבצי הבסיס ותמונת המצב לכונן NAS/SAN/USB גיבוי משני לפני השינוי"]
    D --> E{"איזה Hypervisor / פורמט דיסק וירטואלי מושפע?"}
    E -->|"1. VMware ESXi / Workstation (.vmdk / -flat.vmdk / -delta.vmdk / -sesparse.vmdk)"| F["בדוק מתארי טקסט (`cat *.vmdk`) ובדוק שרשרת (`vmkfstools -e Server-000002.vmdk`)"]
    F --> G{"מהי תקלת VMware VMDK?"}
    G -->|"אי התאמה של CID הורה (`parentCID .= CID of parent`)"| H["ערוך את מתאר הטקסט הצאצא `.vmdk` כך ש- `parentCID` יתאים את `CID` של האב, או שיכפל דיסק עלה פעיל ל-VMDK מאוחד חדש (`vmkfstools -i`)"]
    G -->|"חסר מתאר טקסט של 1KB `.vmdk` (קיים רק `-flat.vmdk` ענק)"| I["חשב גודל בתים מדויק / 512 סקטורים וצור מחדש את מתאר הטקסט הפשוט `.vmdk` עם `vmkfstools -c`"]
    E -->|"2. Microsoft Hyper-V (שרשרת.vhdx ו-.avhdx)"| J["בדוק את השרשרת מ-`.avhdx` החדש ביותר כלפי מעלה: `Get-VHD -Path *.avhdx | בחר Path, ParentPath`"]
    J --> K["קישור מחדש של מצביע אב שבור (`Set-VHD -Path child.avhdx -ParentPath parent.vhdx -IgnoreIdMismatch`) או מיזוג לא מקוון (`Merge-VHD`)"]
    E -->|"3. Proxmox / KVM / QEMU (.qcow2) או VirtualBox (.vdi)"| L["בדוק `qemu-img info --backing-chain`; תקן טבלאות refcount/L2 (`qemu-img check -r all`) או rebase (`qemu-img rebase -u`)"]
    H --> M["Back Rescue File Out-of-Band: התקן כל שרשרת ישירות במצב קריאה בלבד באמצעות `guestmount --ro` או `7-Zip` / `UFS Explorer`"]
    I --> M
    K --> M
    L --> M

הבנת איך שרשראות צילומי מצב של מכונות וירטואליות עובדות בפועל¶

בין אם אתה מפעיל את VMware ESXi, Microsoft Hyper-V, Proxmox/KVM או VirtualBox, כל hypervisor מיישם צילומי מצב תוך שימוש באותה ארכיטקטורה בסיסית בדיוק: רשימה מקושרת חד כיוונית של דיסקים אב לקריאה בלבד ודיסק קריאה-כתיבה של עלה צאצא.

[Base Disk: Server.vmdk / Server.vhdx]  <-- Frozen Read-Only at Snapshot 1 (e.g., Jan 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 1234abcd)
[Snapshot 1: Server-000001.vmdk / Server_A.avhdx]  <-- Frozen Read-Only at Snapshot 2 (e.g., June 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 5678ef01)
[Snapshot 2 (Active Leaf): Server-000002.vmdk / Server_B.avhdx]  <-- Active Read/Write Today (Oct 31)

• כאשר ה-VM רוצה לכתוב בלוק חדש היום, הוא כותב רק לקובץ העלה התחתון (Snapshot 2).
• כאשר ה-VM רוצה לקרוא בלוק היום, ה-Hypervisor בודק Snapshot 2 תחילה. אם הבלוק הזה השתנה מאז 1 ביוני, הוא קורא אותו Snapshot 2. אם לא, זה מחפש במעלה השרשרת Snapshot 1. אם גם שם זה לא שונה, זה קורא את הבלוק המקורי מה- Base Disk.
• מדוע שרשראות נשברות: כל תמונת מצב של ילד מאחסנת שני מצביעים קפדניים בכותרת שלו: (1) נתיב הקובץ של ההורה המיידי שלו, ו**(2) מזהה תוכן של 32 סיביות (CID ב-VMware) או 128-bit Linkage GUID (ParentUniqueId ב-Hyper-V) שמתחדש בכל פעם שדיסק אב נפתח לכתיבה**. אם מישהו מעביר קובץ, משנה שם לתיקייה או מעלה לזמן קצר את הדיסק האב במצב קריאה-כתיבה, CID / GUID שינויים, וה-hypervisor מסרב מיד להעלות את תמונת הילד כדי למנוע שחיתות בלוקים שקטים.

מסלול 1: הצלת VMware ESXi & Workstation .vmdk שרשראות תמונת מצב¶

ב-VMware ESXi, דיסק וירטואלי יחיד מורכב למעשה משני קבצים נפרדים עבור הדיסק הבסיסי ושני קבצים נפרדים עבור כל תמונת מצב: 1. קובץ מתאר זעיר (-500-בתים) בטקסט רגיל (Server.vmdk ו Server-000001.vmdk) שמחזיק את CID, parentCID, גיאומטריית דיסק, ושם הקובץ המדויק של המידה הבינארית. (הערה: ממשק המשתמש באינטרנט של ESXi Datastore Browser מסתיר את הצמד -flat.vmdk ו -sesparse.vmdk קבצים בינאריים ומציג רק סמל אחד ממוזג, עליך להשתמש ב-מסוף SSH במארח ESXi כדי לראות את הקבצים האמיתיים). 2. קובץ היקף נתונים בינארי רב גיגה-בייט (Server-flat.vmdk עבור הדיסק הבסיסי, ו Server-000001-sesparse.vmdk או Server-000001-delta.vmdk עבור כל תמונת מצב).

תרחיש 1A: תיקון "The parent virtual disk has been modified since the child was created (Parent CID mismatch)"¶

1. SSH לתוך המארח ESXi ונווט אל ספריית מאגר הנתונים של ה-VM:

   cd /vmfs/volumes/<Datastore_Name>/<VM_Folder_Name>/
   ls -la *.vmdk
   

2. הדפיס את CID, parentCID, ו parentFileNameHint על פני כל מתאר הטקסט .vmdk קבצים בבת אחת: (חשוב: רק לרוץ cat או grep על מתאר הטקסט הזעיר של 500 בתים .vmdk קבצים, לא ב-Multi-Gigabyte -flat.vmdk או -sesparse.vmdk קבצים).

   grep -E "CID|parentFileNameHint|Extent description" -A 2 Server.vmdk Server-00000*.vmdk
   

3. השווה את CID של כל הורה נגד parentCID של הילד המיידי שלו: תסתכל על הפלט:

   Server.vmdk:           CID=1a2b3c4d
                          parentCID=ffffffff   (ffffffff means this is the root Base Disk)
   
   Server-000001.vmdk:    CID=99887766
                          parentCID=55443322   <-- ERROR: Should equal Server.vmdk's CID (1a2b3c4d)
                          parentFileNameHint="Server.vmdk"
   
   Server-000002.vmdk:    CID=aabbccdd
                          parentCID=99887766   <-- OK: Matches Server-000001.vmdk's CID (99887766)
                          parentFileNameHint="Server-000001.vmdk"
   

4. תקן את השבור parentCID בתיאור הילד ואמת עם vmkfstools -e:
5. ראשית, גבה את קבצי מתאר הטקסט (cp Server-000001.vmdk Server-000001.vmdk.bak).
6. פתוח Server-000001.vmdk ב vi ולשנות parentCID=55443322 ל parentCID=1a2b3c4d (תואם Server.vmdkהנוכחית CID).
7. בדוק את שלמות השרשרת מתוך תמונת המצב החדשה ביותר (במספר הגבוה ביותר) באמצעות vmkfstools -e:

   vmkfstools -e Server-000002.vmdk
   

8. אם השרשרת שלמה, ESXi מוציא: Disk chain is consistent.
9. איחוד לא הרסני (vmkfstools -i שיבוט לא במקום):
10. אם Server.vmdk שונה מעט לפני שתיקנת את parentCID, אל תאחד במקום על פני העותק היחיד שלך. במקום זאת, הצבע vmkfstools -i בתמונת העלים החדשה ביותר (Server-000002.vmdk) ושכפל את כל השרשרת ל-VMDK חדיש ושטוח יחיד בחנות נתונים עם מקום פנוי:

    vmkfstools -i Server-000002.vmdk /vmfs/volumes/<Target_Datastore>/Server_Rescue/Server_Merged.vmdk -d thin
    

11. vmkfstools -i קורא כל בלוק מ Server-000002.vmdk למטה דרך Server-000001.vmdk ו Server-flat.vmdk במצב קריאה בלבד קפדני וכותבת תמונה נקייה ונטולת תמונות Server_Merged.vmdk מבלי לגעת בקבצים המקוריים שלך.

תרחיש 1B: יצירה מחדש של 500-בתים חסרים או נמחקים .vmdk מתאר טקסט מתי Server-flat.vmdk עדיין שלם¶

לפעמים מנהל מערכת או סקריפט שבור נמחק Server.vmdk (או שזה נפגם ל 0 bytes), מה שגורם לדפדפן ה-Datastore להפסיק להציג את הדיסק הווירטואלי, למרות שהנפח העצום של 500 גיגה-בייט Server-flat.vmdkקובץ המכיל 100 אחוז מהנתונים האמיתיים שלך עדיין נמצא שם ב-SSH (ls -la *-flat.vmdk).

אתה יכול ליצור מחדש את הטקסט הפשוט החסר Server.vmdk קובץ התיאור תוך 60 שניות מבלי לאבד ולו בייט אחד של נתונים בפנים Server-flat.vmdk:

# 1. Check the exact byte size of your existing Server-flat.vmdk:
ls -l Server-flat.vmdk
# Example output: -rw------- 1 root root 107374182400 Oct 31 12:00 Server-flat.vmdk  (Exactly 107,374,182,400 bytes)

# 2. Create a temporary dummy VMDK of that EXACT byte size in /tmp or the datastore:
vmkfstools -c 107374182400 -d thin temp_dummy.vmdk

# 3. Delete the dummy binary file (temp_dummy-flat.vmdk) and rename the 500-byte descriptor to Server.vmdk:
rm -f temp_dummy-flat.vmdk
mv temp_dummy.vmdk Server.vmdk

# 4. Edit Server.vmdk in 'vi' and change the filename inside quotes from "temp_dummy-flat.vmdk" to "Server-flat.vmdk":
sed -i 's/temp_dummy-flat.vmdk/Server-flat.vmdk/g' Server.vmdk
# (Also delete the line 'ddb.thinProvisioned = "1"' if the original disk was thick-provisioned)

תרחיש 1C: ביטול נעילה של א .vmdk ננעל על ידי מארח ESXi נתלה או פרוקסי גיבוי קרס (Cannot open the disk: Failed to lock the file)¶

אם VM מסרב להידלק עם Failed to lock the file או Cannot open disk: Resource busy, מארח ESXi אחר באשכול (או מכשיר Veeam/גיבוי HotAdd שקרס במהלך הגיבוי) עדיין מחזיק נעילת קובץ SCSI / VMFS -flat.vmdk או -sesparse.vmdk: 1. בדוק אם VM של פרוקסי גיבוי קרס עדיין מכיל את VM הייצור שלך .vmdk מחובר לבקר ה-SCSI הווירטואלי שלו: ערוך את ההגדרות של מכשירי ה-VM של ה-Proxy Veeam/CommVault והסר כל דיסקי ייצור מיושנים המחוברים (**בחר "הסר ממכונה וירטואלית", לעולם אל "מחק קבצים מ-datastore"). 2. מצא איזו כתובת MAC מארח ESXi ותהליך העולם מכיל את נעילת VMFS:

vmfsfilelockinfo -p /vmfs/volumes/<Datastore>/<VM_Folder>/Server-flat.vmdk

מסלול 2: הצלת Microsoft Hyper-V .vhdx ו .avhdx שרשראות תמונת מצב¶

ב-Microsoft Hyper-V, כל נקודת ביקורת (תמונת מצב) יוצרת דיסק קשיח וירטואלי שונה עם ההרחבה .avhdx (או .avhd בפורמט VHD ישן יותר) הוקצה שם קובץ GUID ארוך כמו ProdSQL_A1B2C3D4-E5F6-7890-ABCD-1234567890AB.avhdx.

שלב 1: מפה את הכרונולוגי המדויק .avhdx עץ הורה-ילד ב- PowerShell¶

לפני מיזוג או קישור מחדש של משהו ב-Hyper-V Manager, פתח חלון Elevated Administrator PowerShell במארח Hyper-V, נווט אל התיקיה המכילה את .vhdx ו .avhdx קבצים, והפעל את ה-one liner הזה כדי להציג את שרשרת ההורה-ילד המדויקת מהחדש ליותר:

# Inspect every .vhdx and .avhdx in the directory, sorted by LastWriteTime:
Get-ChildItem -Filter "*.*vhd*" | ForEach-Object {
    Get-VHD -Path $_.FullName -ErrorAction SilentlyContinue |
    Select-Object Path, ParentPath, VhdType, FileSize, Size
} | Format-List

תסתכל על Path ו ParentPath שדות. הם יחשפו את סדר השרשרת המדויק: - ProdSQL.vhdx -> ParentPath: (blank) (דיסק בסיס בסיס, הישן ביותר) - ProdSQL_1111.avhdx -> ParentPath: D:\VMs\ProdSQL.vhdx (ילד 1) - ProdSQL_2222.avhdx -> ParentPath: D:\VMs\ProdSQL_1111.avhdx (ילד 2) - ProdSQL_3333.avhdx -> ParentPath: D:\VMs\ProdSQL_2222.avhdx (הדיסק Active Leaf החדש ביותר)

שלב 2: תיקון "The chain of virtual hard disks is broken" או "Differencing disk parent ID mismatch" (Set-VHD -IgnoreIdMismatch)¶

מה אם מישהו העביר את תיקיית ה-VM מ C:\VMs\ ל E:\VMs\, או אוחל בטעות ProdSQL.vhdx למשך 5 שניות, מה שגורם ProdSQL_1111.avhdx להיכשל עם: The chain of virtual hard disks is broken. The system cannot locate the parent virtual hard disk for the differencing disk או There is a mismatch in the virtual disk identifiers?

השתמש ב-cmdlet הרשמי Hyper-V PowerShell Set-VHDעם ה-IgnoreIdMismatch דגל (לאחר גיבוי הקבצים תחילה):

# Relink a child .avhdx to its parent .vhdx/.avhdx (adding -IgnoreIdMismatch if the parent timestamp/GUID shifted):
Set-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -ParentPath "E:\VMs\ProdSQL.vhdx" -IgnoreIdMismatch

שלב 3: מיזוג יתום יתום .avhdx שרשרת מהחדש ביותר לישן ביותר (Merge-VHD)¶

כאשר סוכן גיבוי משאיר 15 יתומים .avhdx קבצים בתיקייה שלך שאינם מופיעים יותר בעץ Hyper-V Manager GUI "Checkpoints", עליך למזג אותם באופן ידני ב-PowerShell בזמן שה-VM כבוי.

הפעל את הפקודות המדויקות של PowerShell על עותק עבודה של התיקיה:

# Step 1: Merge Child 3 (Newest) into Child 2:
Merge-VHD -Path "E:\VMs\ProdSQL_3333.avhdx" -DestinationPath "E:\VMs\ProdSQL_2222.avhdx"

# Step 2: Merge Child 2 into Child 1:
Merge-VHD -Path "E:\VMs\ProdSQL_2222.avhdx" -DestinationPath "E:\VMs\ProdSQL_1111.avhdx"

# Step 3: Merge Child 1 into the Base .vhdx:
Merge-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -DestinationPath "E:\VMs\ProdSQL.vhdx"

מסלול 3: הצלת Proxmox VE / QEMU / KVM .qcow2 ו-VirtualBox .vdi שרשראות¶

1. בדיקה ותיקון פגומים QCOW2 L1/L2 Cluster & Refound Tables (qemu-img check)¶

כאשר מארח Linux KVM או Proxmox סובל מהפסקת חשמל פתאומית ללא מטמון מגובה סוללה, .qcow2 דיסק וירטואלי לעתים קרובות לא מצליח לאתחל איתו qcow2: Marking image as corrupt: L2 table offset unaligned או Refcount block corrupted. 1. העתק תחילה את .qcow2 קובץ (cp vm-100-disk-0.qcow2 vm-100-disk-0.qcow2.bak). 2. בדוק את שרשרת הגיבוי ואת רשימת התמונות הפנימית:

qemu-img info --backing-chain vm-100-disk-0.qcow2
qemu-img snapshot -l vm-100-disk-0.qcow2

qemu-img check -r all vm-100-disk-0.qcow2

2. תיקון נתיב קובץ גיבוי QCOW2 שבור (qemu-img rebase -u)¶

אם תמונת מצב חיצונית QCOW2 (overlay.qcow2) לא מצליח להיפתח כי קובץ הגיבוי האב שלו (base.qcow2) הועבר לספרייה חדשה או למאגר אחסון חדש, עדכן את מצביע קובץ הגיבוי במצב לא בטוח (-u, מצב כותרת בלבד) ללא שכתוב בלוקי נתונים:

qemu-img rebase -u -b /new/path/to/base.qcow2 -F qcow2 overlay.qcow2

3. שיטוח שרשרת QCOW2 או VMDK או VHDX שבירה לתמונה עצמאית חדשה לגמרי (qemu-img convert)¶

אחד הכלים המגוונים ביותר בהצלת מכונות וירטואליות הוא qemu-img convert (שנקרא באופן מקורי .qcow2, .vmdk, .vhdx, .vhd, ו .vdi). כשאתה מצביע qemu-img convert בתמונת העלה החדשה ביותר של שרשרת חוקית, הוא קורא את כל ההיררכיה של הורה-ילד במצב קריאה בלבד וכותב דיסק וירטואלי חדש לגמרי, עצמאי, נטול תצלומי מצב באחסון ההצלה שלך:

# Non-destructively flatten an entire QCOW2, VMDK, or VHDX chain into a single clean image:
qemu-img convert -p -O qcow2 top_snapshot_leaf.qcow2 /mnt/rescue_storage/flattened_clean.qcow2

רצועה 4: הצלת קבצים מחוץ לפס (חילוץ קבצים כאשר ה-VM עדיין לא מאתחל)¶

מה אם מערכת ההפעלה האורחת בתוך הדיסק הוירטואלי אינה ניתנת לאתחול, או שתמונת מצב אמצעית בשרשרת פגומה חלקית ואתה צריך לשלוף מסדי נתונים של SQL (.mdf/.ldf), קבצי QuickBooks, /var/lib/mysql, או מסמכי חברה ב-30 הדקות הקרובות?

אינך צריך לאתחל מחשב וירטואלי כדי לחלץ את הקבצים בתוך הכונן הקשיח הווירטואלי שלו. השתמש בכל אחד משלושת כלי הרכבה מחוץ לפס הבלתי הרסניים הבאים:

שיטה 1: הר כל .vmdk, .vhdx, .qcow2, או .vdi במצב קריאה בלבד בלינוקס באמצעות libguestfs (guestmount / qemu-nbd)¶

התקן libguestfs-tools (sudo apt install libguestfs-tools qemu-utils ב-Ubuntu/Debian/Proxmox) והעלו את תמונת העלה החדשה ביותר במצב קפדני קריאה בלבד (--ro):

# Option A: Using guestmount (Automatically detects internal guest LVM/partitions and mounts read-only):
sudo mkdir -p /mnt/vm_rescue
sudo guestmount -a /path/to/Newest_Leaf_Snapshot.vmdk -i --ro /mnt/vm_rescue
# (If guest OS partitions fail auto-inspection due to dirty NTFS journal, list partitions with 'virt-filesystems -a disk.vmdk -l'
# and mount the specific partition directly with '-m /dev/sda2 --ro -o norecover')

# Option B: Attaching the virtual disk chain as a Read-Only Network Block Device (/dev/nbd0):
sudo modprobe nbd max_part=16
sudo qemu-nbd --read-only --connect=/dev/nbd0 /path/to/Newest_Leaf_Snapshot.qcow2
sudo partprobe /dev/nbd0
lsblk /dev/nbd0
# Now mount /dev/nbd0p2 read-only (with -o ro,norecover for NTFS or -o ro,noload for ext4):
sudo mount -o ro,norecover /dev/nbd0p2 /mnt/vm_rescue

שיטה 2: חילוץ מיידי לקריאה בלבד ב-Windows באמצעות 7-Zip או Disk Management -> Attach VHD (Read-Only)¶

• באמצעות 7-Zip (עובד על .vmdk, .vhdx, .vhd, .qcow2, ו .vdi): לחץ לחיצה ימנית על פריט עצמאי או שטוח .vmdk, .vhdx, או .qcow2 קובץ ב-Windows ובחר 7-Zip -> פתח ארכיון. 7-Zip מנתח באופן טבעי טבלאות מחיצות GPT/MBR ומערכות קבצים NTFS/ext4 בתוך דיסקים וירטואליים במצב של 100% קריאה בלבד, ומאפשר לך לגרור ולשחרר תיקיות אורחות ישירות אל שולחן העבודה שלך תוך שניות.
• שימוש בניהול דיסקים של Windows (עבור .vhdx / .avhdx): פתוח diskmgmt.msc -> פעולה -> צרף VHD -> דפדף אל הדף החדש ביותר .avhdx (או .vhdx), בדוק את התיבה [X] Read-only (קריטי: לעולם אל תשכח לסמן לקריאה בלבד, אחרת Windows ישנה את כותרת הדיסק), ולחץ על אישור. כונני C: ו-D: של ה-VM שלך מופיעים מיד בסייר הקבצים של Windows.

שיטה 3: שחזור שרשראות שנפגעו קשות עם UFS Explorer Professional Recovery¶

אם דיסק אב בשרשרת VMDK או VHDX אוחל ושונה בטעות, או אם השחתה של מאגר הנתונים VMFS/NTFS גרסה חלק מ- -sesparse.vmdk או .avhdx קובץ כך שכלי ה-Hypervisor דוחים אותו, UFS Explorer Professional Recovery (או R-Studio Technician) מאפשר לך להרכיב באופן ידני את דיסק הבסיס הגולמי וכל תמונת דלתא צאצאית ל-Virtual Delta Stack ב-RAM של תוכנה, תוך עקיפת Hypervisor. CID/GUID בדיקות כותרות כדי לגלף ולחלץ קבצי אורח שלמים.

רצועה 5: שחזור קובץ תצורה של VM יתום (.vmx, .xml, או <vmid>.conf)¶

לפעמים שרשרת הדיסק הקשיח הווירטואלי עצמו (*.vmdk, *.vhdx, או *.qcow2) הוא 100 אחוז שלם במערך האחסון, אבל קובץ התצורה הקטן שמגדיר את פריסת החומרה של המכונה הווירטואלית (.vmx ב-VMware ESXi, <GUID>.vmcx / .xml ב-Hyper-V, או /etc/pve/qemu-server/<vmid>.conf ב-Proxmox VE) פגום, נמחק בטעות או מאופס במהלך קריסת מארח.

אם תיצור מחדש מעטפת VM חלופית עם בקר אחסון וירטואלי או מצב קושחה שגויים, מערכת ההפעלה האורחת תקרוס מיד עם האתחול עם INACCESSIBLE_BOOT_DEVICE (Windows) או היכנס לתוך a dracut / initramfs מעטפת חירום (לינוקס). התאם את ארבע הגדרות החומרה האלה לתצורת האורח המקורית שלך לפני חיבור הדיסק הוירטואלי שחולץ:

שאלות נפוצות¶

נבדקו מקורות¶

• VMware מאת Broadcom Technical Knowledge Base: KB 1007969 / 316578 (פתרון "הדיסק הווירטואלי האב השתנה מאז שהילד נוצר" שגיאות CID Mismatch), KB 1002511 (יצירת מחדש של מתאר דיסק חסר של מחשב וירטואלי .vmdk קובץ), ו-KB 10051 (הבנת צילומי Snapshot של מחשב וירטואלי ב-ESXi).
• Microsoft Learn / Windows Server Hyper-V תיעוד הנדסי: Hyper-V PowerShell Reference for Get-VHD, Set-VHD -IgnoreIdMismatch, ו Merge-VHD איחוד דיסקים לא מקוונים.
• פרויקט QEMU & Red Hat Enterprise Linux תיעוד וירטואליזציה: רשמי qemu-img ידני (info --backing-chain, check -r all, rebase -u, convert) ו libguestfs (guestmount --ro) בדיקת דיסק וירטואלי לקריאה בלבד.
• תיעוד טכני של Oracle VirtualBox: VBoxManage showmediuminfo ו clonemedium ארכיטקטורת תמונה שונה.
• המכון הלאומי לתקנים וטכנולוגיה (NIST, ארצות הברית): פרסום מיוחד של NIST 800-86: מדריך לשילוב טכניקות משפטיות בתגובה לאירועים (שימור תמונה וירטואלית של מכונה).

מדריכים קשורים¶

• מערך NAS ו-RAID פגום, כשל בכוננים מרובים ושחזור ZFS/Btrfs
• NVMe או SSD נכנסים פתאום למצב קריאה בלבד או נעלמים מה-BIOS
• כשל בכונן הקשיח ושחזור מידע חירום
• כשל באתחול מערכת לינוקס ותיקון GRUB
• מסך כחול של Windows (BSOD) ותיקון אתחול
• גיבויי מחשב: אסטרטגיה 3-2-1 והתאוששות מאסון
• מספרי חירום גלובליים