build 7bbbddf7 | content blog-content@c8490fa · 338 posts | profiles 20 · corpus 267 | 0 skipped | | format
apiVersion: soultec.ch/v1kind: Postmetadata: name: problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files locale: de labels: author: dario-doerflinger series: lessons-learned capability/virtualization: 1.37 capability/backup-recovery: 2.18 vendor/vmware: 0.88 annotations: source: blog-content/posts/de/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md route: /de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files/ schema: /nerd/schema/posts.json markdown: /de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.mdspec: title: >- Probleme mit einer wiederhergestellten VM: falsche IDs in den Snapshot-Dateien date: 2014-11-21 author: dario-doerflinger locale: de summary: >- Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte. capabilities: [virtualization, backup-recovery] vendors: [vmware] series: lessons-learned migrated: 2026-08-24 translationReviewed: false draft: false sections: - body: | Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte. Wie auch immer: Der Restore lief durch, warf aber eine Fehlermeldung, dass der Snapshot nicht entfernt werden konnte. Kein Problem, dachte ich. Also in den "Snapshot Manager" und alle Snapshots gelöscht. Der Task lief sauber durch, dafür kam die nächste Meldung: "VM needs consolidation". Auch gut. Über die GUI wollte ich die Disks konsolidieren, was ebenfalls in einem Fehler endete. Zeit, sich direkt per ssh auf den ESXi Host zu verbinden und dort nachzuschauen. Ich ging auf den Datastore mit der VM (genauer gesagt lag die VM über sieben Datastores verteilt, aber der Punkt bleibt) und sah mir die Descriptor-Dateien an. Es stellte sich heraus, dass sämtliche Snapshot-Descriptor-Dateien (somevm\_1-000001.vmdk) eine falsche ParentCID hatten. Sie verwiesen auf sich selbst. Der nächste Schritt war, alle falschen CIDs durch die korrekte CID der Parent-Disk zu ersetzen. Bei einer VM mit 16 Disks über 7 Datastores ist das eine ordentliche Fleissarbeit. Danach (wichtig: Prüfe zweimal, dass die richtige CID in der Descriptor-Datei steht, sonst zerlegst du dir die ganze VM) musste ich die VM nur noch neu ins Inventory registrieren. Sie erkannte den Snapshot wieder, und der Consolidate-Task lief ohne Fehler durch. Das war es. Die falschen CIDs in den Descriptor-Dateien waren behoben und die VM liess sich wieder starten.status: corpus: 267 alsoLike: - {ref: posts/backing-up-fault-tolerance-protected-vms-the-operation-is-not-supported-on-the-object, score: 1.00} - {ref: solutions/vmware/vmware-cloud-foundation/addon/site-recovery-manager, score: 1.00} - {ref: experts/marco-betschart, score: 0.74}
{ "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": { "name": "problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files", "locale": "de", "labels": { "author": "dario-doerflinger", "series": "lessons-learned", "capability/virtualization": "1.37", "capability/backup-recovery": "2.18", "vendor/vmware": "0.88" }, "annotations": { "source": "blog-content/posts/de/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md", "route": "/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files/", "schema": "/nerd/schema/posts.json", "markdown": "/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md" } }, "spec": { "title": "Probleme mit einer wiederhergestellten VM: falsche IDs in den Snapshot-Dateien", "date": "2014-11-21", "author": "dario-doerflinger", "locale": "de", "summary": "Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.", "capabilities": [ "virtualization", "backup-recovery" ], "vendors": [ "vmware" ], "series": "lessons-learned", "migrated": "2026-08-24", "translationReviewed": false, "draft": false }, "sections": [ { "body": "Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.\n\nWie auch immer: Der Restore lief durch, warf aber eine Fehlermeldung, dass der Snapshot nicht entfernt werden konnte. Kein Problem, dachte ich. Also in den \"Snapshot Manager\" und alle Snapshots gelöscht. Der Task lief sauber durch, dafür kam die nächste Meldung: \"VM needs consolidation\".\n\nAuch gut. Über die GUI wollte ich die Disks konsolidieren, was ebenfalls in einem Fehler endete.\n\nZeit, sich direkt per ssh auf den ESXi Host zu verbinden und dort nachzuschauen. Ich ging auf den Datastore mit der VM (genauer gesagt lag die VM über sieben Datastores verteilt, aber der Punkt bleibt) und sah mir die Descriptor-Dateien an.\n\nEs stellte sich heraus, dass sämtliche Snapshot-Descriptor-Dateien (somevm\\_1-000001.vmdk) eine falsche ParentCID hatten. Sie verwiesen auf sich selbst.\n\nDer nächste Schritt war, alle falschen CIDs durch die korrekte CID der Parent-Disk zu ersetzen. Bei einer VM mit 16 Disks über 7 Datastores ist das eine ordentliche Fleissarbeit. Danach (wichtig: Prüfe zweimal, dass die richtige CID in der Descriptor-Datei steht, sonst zerlegst du dir die ganze VM) musste ich die VM nur noch neu ins Inventory registrieren. Sie erkannte den Snapshot wieder, und der Consolidate-Task lief ohne Fehler durch.\n\nDas war es. Die falschen CIDs in den Descriptor-Dateien waren behoben und die VM liess sich wieder starten." } ], "status": { "corpus": 267, "alsoLike": [ { "ref": "posts/backing-up-fault-tolerance-protected-vms-the-operation-is-not-supported-on-the-object", "score": "1.00" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/site-recovery-manager", "score": "1.00" }, { "ref": "experts/marco-betschart", "score": "0.74" } ] }}
apiVersion = "soultec.ch/v1"kind = "Post"[metadata]name = "problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files"locale = "de"[metadata.labels]author = "dario-doerflinger"series = "lessons-learned""capability/virtualization" = "1.37""capability/backup-recovery" = "2.18""vendor/vmware" = "0.88"[metadata.annotations]source = "blog-content/posts/de/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md"route = "/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files/"schema = "/nerd/schema/posts.json"markdown = "/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md"[spec]title = "Probleme mit einer wiederhergestellten VM: falsche IDs in den Snapshot-Dateien"date = 2014-11-21author = "dario-doerflinger"locale = "de"summary = "Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte."capabilities = ["virtualization", "backup-recovery"]vendors = ["vmware"]series = "lessons-learned"migrated = 2026-08-24translationReviewed = falsedraft = false[[sections]]body = '''Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.Wie auch immer: Der Restore lief durch, warf aber eine Fehlermeldung, dass der Snapshot nicht entfernt werden konnte. Kein Problem, dachte ich. Also in den "Snapshot Manager" und alle Snapshots gelöscht. Der Task lief sauber durch, dafür kam die nächste Meldung: "VM needs consolidation".Auch gut. Über die GUI wollte ich die Disks konsolidieren, was ebenfalls in einem Fehler endete.Zeit, sich direkt per ssh auf den ESXi Host zu verbinden und dort nachzuschauen. Ich ging auf den Datastore mit der VM (genauer gesagt lag die VM über sieben Datastores verteilt, aber der Punkt bleibt) und sah mir die Descriptor-Dateien an.Es stellte sich heraus, dass sämtliche Snapshot-Descriptor-Dateien (somevm\_1-000001.vmdk) eine falsche ParentCID hatten. Sie verwiesen auf sich selbst.Der nächste Schritt war, alle falschen CIDs durch die korrekte CID der Parent-Disk zu ersetzen. Bei einer VM mit 16 Disks über 7 Datastores ist das eine ordentliche Fleissarbeit. Danach (wichtig: Prüfe zweimal, dass die richtige CID in der Descriptor-Datei steht, sonst zerlegst du dir die ganze VM) musste ich die VM nur noch neu ins Inventory registrieren. Sie erkannte den Snapshot wieder, und der Consolidate-Task lief ohne Fehler durch.Das war es. Die falschen CIDs in den Descriptor-Dateien waren behoben und die VM liess sich wieder starten.'''[status]corpus = 267[[status.alsoLike]]ref = "posts/backing-up-fault-tolerance-protected-vms-the-operation-is-not-supported-on-the-object"score = "1.00"[[status.alsoLike]]ref = "solutions/vmware/vmware-cloud-foundation/addon/site-recovery-manager"score = "1.00"[[status.alsoLike]]ref = "experts/marco-betschart"score = "0.74"
<?xml version="1.0" encoding="UTF-8"?><manifest kind="Post"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files</name> <locale>de</locale> <labels> <author>dario-doerflinger</author> <series>lessons-learned</series> <entry key="capability/virtualization">1.37</entry> <entry key="capability/backup-recovery">2.18</entry> <entry key="vendor/vmware">0.88</entry> </labels> <annotations> <source>blog-content/posts/de/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md</source> <route>/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files/</route> <schema>/nerd/schema/posts.json</schema> <markdown>/de/insights/problems-with-a-restored-vm-invalid-ids-in-the-snapshot-files.md</markdown> </annotations> </metadata> <spec> <title>Probleme mit einer wiederhergestellten VM: falsche IDs in den Snapshot-Dateien</title> <date>2014-11-21</date> <author>dario-doerflinger</author> <locale>de</locale> <summary>Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.</summary> <capabilities> <item>virtualization</item> <item>backup-recovery</item> </capabilities> <vendors> <item>vmware</item> </vendors> <series>lessons-learned</series> <migrated>2026-08-24</migrated> <translationReviewed>false</translationReviewed> <draft>false</draft> </spec> <sections> <section> <body>Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.Wie auch immer: Der Restore lief durch, warf aber eine Fehlermeldung, dass der Snapshot nicht entfernt werden konnte. Kein Problem, dachte ich. Also in den "Snapshot Manager" und alle Snapshots gelöscht. Der Task lief sauber durch, dafür kam die nächste Meldung: "VM needs consolidation".Auch gut. Über die GUI wollte ich die Disks konsolidieren, was ebenfalls in einem Fehler endete.Zeit, sich direkt per ssh auf den ESXi Host zu verbinden und dort nachzuschauen. Ich ging auf den Datastore mit der VM (genauer gesagt lag die VM über sieben Datastores verteilt, aber der Punkt bleibt) und sah mir die Descriptor-Dateien an.Es stellte sich heraus, dass sämtliche Snapshot-Descriptor-Dateien (somevm\_1-000001.vmdk) eine falsche ParentCID hatten. Sie verwiesen auf sich selbst.Der nächste Schritt war, alle falschen CIDs durch die korrekte CID der Parent-Disk zu ersetzen. Bei einer VM mit 16 Disks über 7 Datastores ist das eine ordentliche Fleissarbeit. Danach (wichtig: Prüfe zweimal, dass die richtige CID in der Descriptor-Datei steht, sonst zerlegst du dir die ganze VM) musste ich die VM nur noch neu ins Inventory registrieren. Sie erkannte den Snapshot wieder, und der Consolidate-Task lief ohne Fehler durch.Das war es. Die falschen CIDs in den Descriptor-Dateien waren behoben und die VM liess sich wieder starten. </body> </section> </sections> <status> <corpus>267</corpus> <alsoLike> <item> <ref>posts/backing-up-fault-tolerance-protected-vms-the-operation-is-not-supported-on-the-object</ref> <score>1.00</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/site-recovery-manager</ref> <score>1.00</score> </item> <item> <ref>experts/marco-betschart</ref> <score>0.74</score> </item> </alsoLike> </status></manifest>
Lessons Learned · 2014-11-21

Probleme mit einer wiederhergestellten VM: falsche IDs in den Snapshot-Dateien

Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.

2014-11-21Datum
Dario DörflingerAutor
1Min. Lesezeit
Themen Virtualisierung 1.37 Backup und Recovery 2.18
Hersteller VMware 0.88

Dieser Beitrag ist von 2014. Er bleibt online, weil er nach wie vor nachgefragt wird, beschreibt aber einen Produktstand von damals.

Kürzlich durften wir eine Datenbank-VM aus dem letzten Backup zurückholen, weil ein Kollege versehentlich eine wichtige .vmdk auf dem Datastore gelöscht hatte.

Wie auch immer: Der Restore lief durch, warf aber eine Fehlermeldung, dass der Snapshot nicht entfernt werden konnte. Kein Problem, dachte ich. Also in den “Snapshot Manager” und alle Snapshots gelöscht. Der Task lief sauber durch, dafür kam die nächste Meldung: “VM needs consolidation”.

Auch gut. Über die GUI wollte ich die Disks konsolidieren, was ebenfalls in einem Fehler endete.

Zeit, sich direkt per ssh auf den ESXi Host zu verbinden und dort nachzuschauen. Ich ging auf den Datastore mit der VM (genauer gesagt lag die VM über sieben Datastores verteilt, aber der Punkt bleibt) und sah mir die Descriptor-Dateien an.

Es stellte sich heraus, dass sämtliche Snapshot-Descriptor-Dateien (somevm_1-000001.vmdk) eine falsche ParentCID hatten. Sie verwiesen auf sich selbst.

Der nächste Schritt war, alle falschen CIDs durch die korrekte CID der Parent-Disk zu ersetzen. Bei einer VM mit 16 Disks über 7 Datastores ist das eine ordentliche Fleissarbeit. Danach (wichtig: Prüfe zweimal, dass die richtige CID in der Descriptor-Datei steht, sonst zerlegst du dir die ganze VM) musste ich die VM nur noch neu ins Inventory registrieren. Sie erkannte den Snapshot wieder, und der Consolidate-Task lief ohne Fehler durch.

Das war es. Die falschen CIDs in den Descriptor-Dateien waren behoben und die VM liess sich wieder starten.

Passt ausserdem