2003 Server Vm lässt sich nicht konsolidieren/Sichern

[skrix182]

Hallo Zusammen,
ich habe ein Problem mit einer Win2003 Server VM, übernommen von einem ESXi 4.1.
Das Problem ist auch schon hier beschrieben, im Forenbeitrag
http://vmware-forum.de/viewtopic.php?t= ... descriptor
Leider aber ohne Lösung...
Das System, um das es geht ist ein Produktivsystem, und da wir auf grund des nicht ausführbaren backups keine Sicherung mehr haben, wird´s langsam ziemlich heiß...
Kurzer Überblick zum Problem: Die VM hat seid letztem monat 37 (!) Snapshot dateien angelegt, und lässt sich seid dem auch nicht mehr Sichern, jeder Versuch, sei es mit Veeam, über Vsphere etc. schlägt mit dem Redo-Log Fehler fehl. Ebenso ein vmkfstools-Clone versuch.
Wäre echt super wenn jemand da eine Idee hätte!
Danke Schonmal,
Gruß

[Thorsten]

Guten Morgen,

als vielleicht letzte Möglichkeit würde ich die VM herunterfahren und diese dann klonen.
Die Snapshots sind im Klon dann nicht mehr vorhanden.

Gruß
Thorsten

Edit:
Du hattest das klonen ja bereits versucht, war das während die VM eingeschaltet oder ausgeschaltet war?

[skrix182]

Danke für die schnelle Antwort!
Ja, klonen habe ich sowohl mit vmkfstools als auch mit Veam, Trilead, und Copy im Vsphere versucht. Jeweils mit ein- und ausgeschalteter maschine. Und Datenverlust ist in diesem Fall keine Option, zumal die Vm ja noch läuft! man kann sie halt nur nicht sichern...

Noch eine Zusatzinformation: Auch wenn ich den Server hochfahre und eine Sicherung der Datenbank ausführe, Schießt sich der Server nach ~40 % ab und es erscheint die Redo-Log Fehlermeldung.

[JustMe]

Einmal heisst's "Bad File Descriptor", einmal Redo-Log-Meldung...

Wie waer's mal mit einem Screenshot (eines ENGLISCHEN vSphere Clients)?

Ansonsten waere die letzte vmware.log und ein VM-Verzeichnislisting (ls -lah auf der Kommandozeile, KEIN Screenshot aus dem Datastore Browser!) hilfreich.

Laeuft ein chkdsk innerhalb der VM sauber durch?

Zu guter letzt:
Wieso "ohne Loesung"?
Genausogut koennte es sein, dass die angesprochene PN an continuum und eine nachfolgende direkte Kontaktaufnahme die Loesung darstellte.

[skrix182]

hey,
wie im verlinkten Forenbeitrag oben, die redolog meldung kommt beim Backupversuch mit Veeam, und anderer Backup-Software. Sie erscheint, nachdem sich der Server aufgehängt hat. Die bad file descriptor Meldung kommt beim Clone-Versuch via vmfstools, vom aktuellen Snapshot in eine neue VMDK. bei ca. 50 %.
Checkdisk im System bricht auch ab, ebenso vie eine Acronis-Sicherung.
Ich bin grade irgendwie zu blöd um die .txt Dateien hier anzuhängen, es kommt immer eine fehlermeldung ( Maximale Anzahl von 0 Atachements wurde erreicht (?))
Ansonsten wäre es halt super wenn die Lösung im anderen beitrag dann auch publik gemacht wird..
Vielen Dank für die Hilfe![/list]

Edit: Hier das Ergebnis des ls-Befehls
/vmfs/volumes/54898300-5abc0496-dba3-0025900ca9b9/itk-server # ls -lah
drwxr-xr-x 1 root root 19.6k Jan 18 09:00 .
drwxr-xr-t 1 root root 1.2k Dec 11 19:06 ..
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000001-ctk.vm dk
-rw------- 1 root root 3.0G Dec 11 19:15 itk-server-000001-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:15 itk-server-000001.vmdk
-rw------- 1 root root 7.8M Dec 11 21:22 itk-server-000002-ctk.vm dk
-rw------- 1 root root 14.6G Dec 11 19:14 itk-server-000002-delta. vmdk
-rw------- 1 root root 394 Dec 11 21:17 itk-server-000002.vmdk
-rw------- 1 root root 7.8M Dec 11 19:15 itk-server-000003-ctk.vm dk
-rw------- 1 root root 225.0M Dec 11 19:15 itk-server-000003-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:09 itk-server-000003.vmdk
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000004-ctk.vm dk
-rw------- 1 root root 2.3G Dec 11 21:23 itk-server-000004-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:15 itk-server-000004.vmdk
-rw------- 1 root root 7.8M Dec 11 19:15 itk-server-000005-ctk.vm dk
-rw------- 1 root root 1.5G Dec 11 19:06 itk-server-000005-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:14 itk-server-000005.vmdk
-rw------- 1 root root 7.8M Dec 11 19:14 itk-server-000006-ctk.vm dk
-rw------- 1 root root 97.0M Dec 11 21:22 itk-server-000006-delta. vmdk
-rw------- 1 root root 401 Dec 11 21:23 itk-server-000006.vmdk
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000007-ctk.vm dk
-rw------- 1 root root 3.4G Dec 11 21:22 itk-server-000007-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:09 itk-server-000007.vmdk
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000008-ctk.vm dk
-rw------- 1 root root 753.0M Dec 11 19:10 itk-server-000008-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:15 itk-server-000008.vmdk
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000009-ctk.vm dk
-rw------- 1 root root 481.0M Dec 11 19:15 itk-server-000009-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:06 itk-server-000009.vmdk
-rw------- 1 root root 7.8M Dec 11 19:06 itk-server-000010-ctk.vm dk
-rw------- 1 root root 545.0M Dec 11 19:06 itk-server-000010-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:09 itk-server-000010.vmdk
-rw------- 1 root root 7.8M Dec 11 19:14 itk-server-000011-ctk.vm dk
-rw------- 1 root root 337.0M Dec 11 19:09 itk-server-000011-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:10 itk-server-000011.vmdk
-rw------- 1 root root 7.8M Dec 11 19:15 itk-server-000012-ctk.vm dk
-rw------- 1 root root 2.5G Dec 11 19:10 itk-server-000012-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:15 itk-server-000012.vmdk
-rw------- 1 root root 7.8M Dec 11 21:23 itk-server-000013-ctk.vm dk
-rw------- 1 root root 15.0G Dec 15 22:30 itk-server-000013-delta. vmdk
-rw------- 1 root root 401 Dec 11 19:14 itk-server-000013.vmdk
-rw------- 1 root root 7.8M Dec 15 22:36 itk-server-000014-ctk.vm dk
-rw------- 1 root root 721.0M Dec 16 02:26 itk-server-000014-delta. vmdk
-rw------- 1 root root 401 Dec 15 22:36 itk-server-000014.vmdk
-rw------- 1 root root 7.8M Dec 16 02:26 itk-server-000015-ctk.vm dk
-rw------- 1 root root 3.3G Dec 16 13:53 itk-server-000015-delta. vmdk
-rw------- 1 root root 401 Dec 16 02:26 itk-server-000015.vmdk
-rw------- 1 root root 7.8M Dec 16 13:54 itk-server-000016-ctk.vm dk
-rw------- 1 root root 2.2G Dec 17 00:52 itk-server-000016-delta. vmdk
-rw------- 1 root root 401 Dec 16 13:54 itk-server-000016.vmdk
-rw------- 1 root root 7.8M Dec 17 01:00 itk-server-000017-ctk.vm dk
-rw------- 1 root root 14.9G Dec 19 11:04 itk-server-000017-delta. vmdk
-rw------- 1 root root 401 Dec 17 01:00 itk-server-000017.vmdk
-rw------- 1 root root 7.8M Dec 19 11:04 itk-server-000018-ctk.vm dk
-rw------- 1 root root 81.0M Dec 19 11:05 itk-server-000018-delta. vmdk
-rw------- 1 root root 401 Dec 19 11:04 itk-server-000018.vmdk
-rw------- 1 root root 7.8M Dec 19 11:06 itk-server-000019-ctk.vm dk
-rw------- 1 root root 2.8G Dec 19 19:00 itk-server-000019-delta. vmdk
-rw------- 1 root root 401 Dec 19 11:06 itk-server-000019.vmdk
-rw------- 1 root root 7.8M Dec 19 19:00 itk-server-000020-ctk.vm dk
-rw------- 1 root root 97.0M Dec 19 19:02 itk-server-000020-delta. vmdk
-rw------- 1 root root 401 Dec 19 19:00 itk-server-000020.vmdk
-rw------- 1 root root 7.8M Dec 19 19:02 itk-server-000021-ctk.vm dk
-rw------- 1 root root 21.2G Dec 29 12:18 itk-server-000021-delta. vmdk
-rw------- 1 root root 401 Dec 19 19:02 itk-server-000021.vmdk
-rw------- 1 root root 7.8M Dec 29 12:24 itk-server-000022-ctk.vm dk
-rw------- 1 root root 4.9G Dec 30 10:11 itk-server-000022-delta. vmdk
-rw------- 1 root root 401 Dec 29 12:24 itk-server-000022.vmdk
-rw------- 1 root root 7.8M Dec 30 10:12 itk-server-000023-ctk.vm dk
-rw------- 1 root root 97.0M Dec 30 10:16 itk-server-000023-delta. vmdk
-rw------- 1 root root 401 Dec 30 10:12 itk-server-000023.vmdk
-rw------- 1 root root 7.8M Dec 30 10:17 itk-server-000024-ctk.vm dk
-rw------- 1 root root 15.6G Jan 8 15:14 itk-server-000024-delta. vmdk
-rw------- 1 root root 427 Dec 30 10:17 itk-server-000024.vmdk
-rw------- 1 root root 7.8M Jan 8 18:17 itk-server-000025-ctk.vm dk
-rw------- 1 root root 1.5G Jan 8 18:17 itk-server-000025-delta. vmdk
-rw------- 1 root root 401 Jan 8 15:14 itk-server-000025.vmdk
-rw------- 1 root root 7.8M Jan 8 18:17 itk-server-000026-ctk.vm dk
-rw------- 1 root root 337.0M Jan 8 21:26 itk-server-000026-delta. vmdk
-rw------- 1 root root 401 Jan 8 18:17 itk-server-000026.vmdk
-rw------- 1 root root 7.8M Jan 8 21:26 itk-server-000027-ctk.vm dk
-rw------- 1 root root 17.0M Jan 8 21:29 itk-server-000027-delta. vmdk
-rw------- 1 root root 401 Jan 8 21:26 itk-server-000027.vmdk
-rw------- 1 root root 7.8M Jan 8 21:29 itk-server-000028-ctk.vm dk
-rw------- 1 root root 33.0M Jan 8 21:55 itk-server-000028-delta. vmdk
-rw------- 1 root root 401 Jan 8 21:29 itk-server-000028.vmdk
-rw------- 1 root root 7.8M Jan 8 21:55 itk-server-000029-ctk.vm dk
-rw------- 1 root root 17.0M Jan 8 21:55 itk-server-000029-delta. vmdk
-rw------- 1 root root 401 Jan 8 21:55 itk-server-000029.vmdk
-rw------- 1 root root 7.8M Jan 8 22:16 itk-server-000030-ctk.vm dk
-rw------- 1 root root 129.0M Jan 8 22:17 itk-server-000030-delta. vmdk
-rw------- 1 root root 401 Jan 8 21:55 itk-server-000030.vmdk
-rw------- 1 root root 7.8M Jan 8 22:17 itk-server-000031-ctk.vm dk
-rw------- 1 root root 17.0M Jan 8 22:17 itk-server-000031-delta. vmdk
-rw------- 1 root root 401 Jan 8 22:17 itk-server-000031.vmdk
-rw------- 1 root root 7.8M Jan 8 22:18 itk-server-000032-ctk.vm dk
-rw------- 1 root root 897.0M Jan 9 02:39 itk-server-000032-delta. vmdk
-rw------- 1 root root 401 Jan 8 22:18 itk-server-000032.vmdk
-rw------- 1 root root 7.8M Jan 9 02:39 itk-server-000033-ctk.vm dk
-rw------- 1 root root 17.0M Jan 9 02:39 itk-server-000033-delta. vmdk
-rw------- 1 root root 401 Jan 9 02:39 itk-server-000033.vmdk
-rw------- 1 root root 7.8M Jan 9 02:39 itk-server-000034-ctk.vm dk
-rw------- 1 root root 273.0M Jan 9 05:58 itk-server-000034-delta. vmdk
-rw------- 1 root root 401 Jan 9 02:39 itk-server-000034.vmdk
-rw------- 1 root root 7.8M Jan 9 10:42 itk-server-000035-ctk.vm dk
-rw------- 1 root root 1.8G Jan 9 10:41 itk-server-000035-delta. vmdk
-rw------- 1 root root 401 Jan 9 05:58 itk-server-000035.vmdk
-rw------- 1 root root 7.8M Jan 13 13:59 itk-server-000036-ctk.vm dk
-rw------- 1 root root 11.8G Jan 13 07:31 itk-server-000036-delta. vmdk
-rw------- 1 root root 401 Jan 12 21:40 itk-server-000036.vmdk
-rw------- 1 root root 7.8M Jan 18 08:59 itk-server-000037-ctk.vm dk
-rw------- 1 root root 12.1G Jan 19 09:35 itk-server-000037-delta. vmdk
-rw------- 1 root root 427 Jan 18 09:00 itk-server-000037.vmdk
-rw-r--r-- 1 root root 1 Jan 9 07:37 itk-server-917afa20.hlog
-rw------- 1 root root 4.0G Jan 18 08:59 itk-server-917afa20.vswp
-rw------- 1 root root 29.2k Jan 9 02:39 itk-server-Snapshot8926. vmsn
-rw------- 1 root root 133 Jan 9 12:57 itk-server-aux.xml
-rw------- 1 root root 7.8M Dec 11 19:15 itk-server-ctk.vmdk
-rw------- 1 root root 500.0G Jan 9 03:00 itk-server-flat.vmdk
-rwx------ 1 root root 28.0k Jan 8 22:18 itk-server-vss_manifests 8923.zip
-rw------- 1 root root 8.5k Jan 18 11:05 itk-server.nvram
-rw------- 1 root root 662 Dec 11 21:23 itk-server.vmdk
-rw------- 1 root root 535 Jan 13 09:57 itk-server.vmsd
-rw------- 1 root root 3.7k Jan 19 07:12 itk-server.vmx
-rw------- 1 root root 0 Jan 17 12:10 itk-server.vmx.lck
-rw------- 1 root root 1.6k Jan 18 03:12 itk-server.vmxf
-rw------- 1 root root 3.7k Jan 19 07:12 itk-server.vmx~
-rw------- 1 root root 9.4M Jan 18 02:51 vmmcores-1.gz
-rw------- 1 root root 30.7M Jan 18 08:59 vmmcores-2.gz
-rw------- 1 root root 159.4k Jan 14 16:43 vmware-23.log
-rw------- 1 root root 40.6k Jan 15 00:09 vmware-24.log
-rw------- 1 root root 158.5k Jan 15 16:58 vmware-25.log
-rw------- 1 root root 158.7k Jan 17 12:00 vmware-26.log
-rw------- 1 root root 119.6k Jan 18 02:51 vmware-27.log
-rw------- 1 root root 167.6k Jan 18 08:59 vmware-28.log
-rw------- 1 root root 132.9k Jan 19 09:04 vmware.log
-rw------- 1 root root 2.5M Jan 2 07:56 vmware64-core0.gz
-rw------- 1 root root 2.1M Jan 2 07:56 vmware64-core1.gz
-rw------- 1 root root 110.0M Jan 18 08:59 vmx-itk-server-244075574 4-1.vswp
-r-------- 1 root root 5.0M Jan 2 07:56 vmx-zdump.000
-r-------- 1 root root 6.5M Jan 18 02:51 vmx-zdump.001
-r-------- 1 root root 6.8M Jan 18 08:59 vmx-zdump.002
-rw------- 1 root root 7.4k Dec 11 21:23 vmxbackup.xml

[JustMe]

Attachments gehen in diesem Forum nicht. Steht in jedem Beitrag von Dayworker, continuum, etc.pp., zusammen mit Links, wo man solche Anhaenge ablegen kann.

Text laesst sich aber gut verwendbar auch in einem "Code" Kontext direkt im Posting ablegen (wenn's nicht allzu gross wird, natuerlich...)

Wegen des anderen Threads: Vielleicht war die Loesung ja auch nur einfach nicht so allgemein verwendbar. Vermutungen ueber Vermutungen.

[skrix182]

Okay, dann hier der Link zum VMwareLog-File:
http://www.load.to/SbBEiFZbI9/vmware.log
Der Screenshot soll von der Fehlermeldung sein?
Oder Was meintest du damit?

Wie waer's mal mit einem Screenshot (eines ENGLISCHEN vSphere Clients)?

[JustMe]

Jou, wenn die Screenshots die (oder eine) Fehlermeldung zeigen, waere das hilfreich

Im Log findet sich aber bereits der Hinweis

Code: Alles auswählen

2015-01-18T08:59:26.480Z| Worker#0| I120: DISKLIB-CTK   : Could not open change tracking file "/vmfs/volumes/54898300-5abc0496-dba3-0025900ca9b9/itk-server/itk-server-000037-ctk.vmdk": Change tracking invalid or disk in use.
[...]
2015-01-18T08:59:26.481Z| Worker#0| I120: OBJLIB-FILEBE : Error creating file '/vmfs/volumes/54898300-5abc0496-dba3-0025900ca9b9/itk-server/itk-server-000037-ctk.vmdk': 3 (The file already exists).

Probier' doch mal, ob Du mit dem Deaktivieren/Loeschen des Changed-Block-Trackings wie beschrieben in den KB-Artikeln 2001004 und 2009244 das Problem bereits beseitigen kannst. Backup geht ja anscheinend eh' momentan nicht mehr.

Dabei gehe ich davon aus, dass auf dem VM-Datastore noch Platz ist.

Da aber auch chkdsk innerhalb der VM abbricht (apropos: Mit was fuer einer Meldung?), scheint es auch logische Defekte zu geben. Wieviel dann ueberhaupt noch wiederherstelltbar ist, muss ggfs. Schritt fuer Schritt ausprobiert werden...
Leider sind die -delta-Dateien ja durchaus nennenswert gross (soll heissen: da sind tatsaechlich Daten drin).

[skrix182]

Hey, super, das ist mir bis jetzt übehraupt nicht in den Sinn gekommen. Danke!
Ich werds heute abend mal ausprobieren, momentan kann ich den Server leider nicht ausschalten. Screenshot habe ich grade keinen da, aber vermutlich bekomme ich heute abend die möglichkeit, einen zu machen...
Auf dem gleichen Datastore ist nicht mehr viel Speicherplatz (~70 gb) Es gab aber schon die Überlegung, die VM zu kopieren auf ein größeres Datastore, aber das schlägt auch, wie alle anderen Kopiervorgänge fehl (Fehlermeldung: The redo log is corrupted. If the problem persists, discard the redo log)
Gelöscht hab ich´s schon...

[JustMe]

70GB sollten eigentlich durchaus noch hinreichen...
Trotzdem gilt zu beachten, wie "schnell" die neueste Snapshot-Datei -00037 waechst, damit der Datastore nicht doch volllaeuft.

Die -ctk-Dateien wurden also bereits geloescht? Oder was wurde ggfs. als Redo-Log geloescht?
Waren die dann alle wirklich weg? Unbedingt auf der Kommandozeile pruefen; dem DS Browser traue ich persoenlich nicht weiter als ich spucken kann.

Wenn man die .vmx-Datei bearbeitet wie im KB-Artikel beschrieben, sollten bei einem Neustart der VM keine neuen ctk-Dateien mehr angelegt werden.

[skrix182]

kann ich diese .ctk Files und die Änderungen in der vm-Config, die in dem VM-Artikel stehen, ohne Risiko auch am Produktiv-System machen? oder kann´s sein, das diese vermurkste vm das nicht mehr verkraftet?
Und deinem beitrag kann ich jetzt entnehmen, das redo-logs und .ctk files genau das selbe sind? oder hab ich da was falsch verstanden...
Was da genau gelöscht wurde, weiß ich nicht mehr, allerdings war da auf jeden fall ein "redo" im Dateinamen, wärend bei den anderen .ctk files nichts mehr davon steht...
Danke nochmal für dein engagement, ist ja nicht selbstverständlich...

[JustMe]

Hmm, an dieser VM wuerde ich persoenlich ohne erstelltes Backup (nicht per Veeam et. al., sondern per FileCopy) nichts mehr machen, auch wenn 500G+ einen ziemlichen Brocken darstellen...

Anonsten sollte man diese ctk-Dateien tatsaechlich einfach so loeschen koennen, aber bei heruntergefahrener VM. Sie sind Vermerke, welche Bloecke in den "grossen" vmdk (flat + delta) gegenueber einem vorherigen Stand geaendert wurden. Backup-Programme koennen damit den zu sichernden Umfang an Daten verkleinern. Sind die ctk-Dateien weg, sichert das Backup-Programm halt alles.

Ich glaube nicht, dass Redo-Logs und ctk-Dateien dasselbe sind. Als Redo-Logs werden oft die Snapshots selbst bezeichnet. Und dann gab's solche *REDO* Dateien eigentlich eher in "alten" ESXi-Versionen. Aber Du schriebst ja, dass die VM aus einem ESXi4.1 uebernommen wurde, wofuer auch die v.HW Version 7 spricht.

Insofern waere es schon gut, wenn man genau wuesste, was tatsaechlich geloescht wurde. Wenn es auf der ESXi-Shell geloescht wurde, kann ein Blick in /var/log/shell.log nicht schaden.

Aber wie bereits erwaehnt: Da chkdsk in der VM schon Probleme bereitet, sieht's tatsaechlich alles andere als gut aus.

Zu guter Letzt: Gern geschehen; ich hoffe dass wir zu einem guten Ende kommen. Auch Dein Dank ist ganz und gar nicht selbstverstaendlich.

[skrix182]

ich habe grade nach stöbern und googeln noch diesen Artikel aus der VMWare-Support Datenbank gefunden, und überlege , ob ich mich da ran wagen sollte... was Meinst du dazu? Scheint ein ähnliches Problem zu sein...
http://kb.vmware.com/kb/1004545

[JustMe]

Versuchen kann man's ja. Aber wie schon geschrieben: Vorher unbedingt sicherstellen, dass alle Dateien noch in Kopie vorliegen, damit man bei einem Fehler wenigstens wieder auf dem aktuellen Stand aufsetzen kann.

Ansonsten glaube ich leider nicht, dass dies abschliessend hilft. Die Fehlermeldungen ("Symptoms") sind doch andere als bei Dir.

Ich fuerchte, dass auch damit der letzte/neueste Snapshot -00037 (der, zu dem die ctk-Datei angemeckert wird) nicht konsolidiert wird. Immerhin waeren alle anderen aelteren Snapshots dann wieder bereinigt; das koennte man auch als Teilerfolg ansehen.

Trotzdem moechte ich warnenderweise auf einen Umstand hinweisen, den der KB-Artikel meiner Ansicht nach nicht ausreichend wuerdigt: Es ist durchaus moeglich, dass die Snapshot-Numerierung nicht in aufsteigender Reihenfolge (..., 21 setzt auf 20 auf, 22 setzt auf 21 auf, ...) vorliegt. Dann koennte die beschriebene Vorgehensweise Probleme bereiten, wenn man nicht genau aufpasst...

[skrix182]

Guten Morgen,
also, ich habe gestern noch diese Schritte aus dem artikel durchgeführt mit einer älteren Sicherung, letztendlich haben sie dazu geführt, dass ebendiese auch nicht mehr bootfähig war....

Trotzdem moechte ich warnenderweise auf einen Umstand hinweisen, den der KB-Artikel meiner Ansicht nach nicht ausreichend wuerdigt: Es ist durchaus moeglich, dass die Snapshot-Numerierung nicht in aufsteigender Reihenfolge (..., 21 setzt auf 20 auf, 22 setzt auf 21 auf, ...) vorliegt

Das hatte ich im Voraus überprüft, indem ich alle vmdk´s per vi angeschaut und die parentfilenames überprüft habe. Aber hat ja leider nichts gebracht..
Ich fange jetzt dann doch an, die Dateien, die Domänenstruktur und die Datenbank auf ein neu aufgesetzten 2008er Server zu übernehmen, um von dieser korrupten Vm weg zu kommen.
Eine Frage hätte ich aber noch: Wenn ich eine Sicherung per Filecopy machen will, reicht es dann, die Base-Vmdk und evtl. auch die Snapshots bis 000036.vmdk nur einmal zu kopieren, und dann jeweils immer nur den aktuell benutzen Snapshot zu sichern (000037.vmdk)? Das würde mir extrem viel Zeit einsparen..

[Supi]

Hallo,

manchmal macht es sinn, über den Vmware Tellerand zu schauen.
Wäre es denn machbar, die VM z.b. mittels drivesnapshot zu sichern und die Daten dann in eine neu angelegte VM zu bringen?
Braucht halt ein größeres Wartungsfenster.

[skrix182]

Wäre es denn machbar, die VM z.b. mittels drivesnapshot zu sichern und die Daten dann in eine neu angelegte VM zu bringen?

Da ein Backup mithilfem von Acronis und Windows Backup jeweils bei ~50 % zum einem Abschuss der VM geführt haben (mit ausgabe der Redo-Log Fehlermeldung), glaube ich nicht, das eine Sicherung aus dem System möglich ist. Egal mit welcher Software..
Das Problem ist auch, dass ich immer nur über Nacht sichern kann, und die Zeit läuft langsam davon...

[JustMe]

@skrix182:
Ich bin mir nicht ganz sicher, ob ich Deine Kopier-Sicherungs-Beschreibung richtig verstanden habe...
Auf jeden Fall ist es so, dass alles, was innerhalb der VM momentan an Daten auf den VM-Datentraegern veraendert wird, nur noch in der -00037 landet. Die aelteren Snapshots werden nicht mehr angetastet.

Falls Du gut 500G und potentes Storage zur Verfuegung hast, koenntest Du mal schauen, bis zu welchem Snapshot die VM noch sauber bootet, indem Du aeltere Staende in eine neue vmdk klonst, fuer diese neue vmdk eine neue VM ohne Netzwerkanschluss erstellst, und schaust, ob die noch sauber bootet. Z.B.

Code: Alles auswählen

vmkfstools -i itk-server-000030.vmdk /vmfs/volumes/<Testverzeichnis>/itk-server.vmdk

Das geht sogar waehrend die VM laeuft. Wie erwaehnt: Potentes Storage ist wuenschenswert, damit der Klonvorgang nicht die laufenden VMs abwuergt.

Wo ich so drueber ueberlege, koennte man sich das (wiederholte) Klonen vmtl. auch sparen, indem man einer (ausgeschalteten!) neuen VM mit GLEICHER vmdk sofort einen Snapshot verpasst, und diesen Snapshot dann z.B. auf die itk-server-000030.vmdk verweisen laesst...
Das erfordert zwar einige Frickelei, aber die CID-Verzeigerung hast Du Dir ja auch schon erarbeitet.

[skrix182]

@skrix182:
Ich bin mir nicht ganz sicher, ob ich Deine Kopier-Sicherungs-Beschreibung richtig verstanden habe...
Auf jeden Fall ist es so, dass alles, was innerhalb der VM momentan an Daten auf den VM-Datentraegern veraendert wird, nur noch in der -00037 landet. Die aelteren Snapshots werden nicht mehr angetastet.

Es geht im Grunde darum, bei einer Sicherung nicht immer eine Datenmenge von 600 gb zu kopieren, sondern nur die Größe des aktuellen Snapshots (~20 gb)
In der Praxis war es bislang so, dass ich immer mit dem Trilead Vm explorer über nacht ALLE Dateien der VM per FileCopy kopieren musste (andere automatische Backupprogramme haben ja nicht funktioniert)
D.h. nach deinem Satz oben müsste ich ja theoretisch immer nur abends den aktuellen Snapshot durch den zuletzt gesicherten erstzen, oder?
Wie gesagt, für 600 gb braucht der explorer ~5 Std., für 20 nur ein paar minuten..

vmkfstools -i itk-server-000030.vmdk /vmfs/volumes/<Testverzeichnis>/itk-server.vmdk

Genau diesen Befehl habe ich im Zuge meiner Aktion gestern abend ausgeführt

http://kb.vmware.com/kb/1004545

Ist soweit auch durchgelaufen, allerdings habe ich nicht getestet ob die VM Bootfähig war, und nachdem ich den Rest wie im Artikel konsolidiert habe, war sie es definitiv nicht mehr..
Was meinst du mit "potentes" Storage? Der Begriff ist mir noch nie untergekommen..

Wo ich so drueber ueberlege, koennte man sich das (wiederholte) Klonen vmtl. auch sparen, indem man einer (ausgeschalteten!) neuen VM mit GLEICHER vmdk sofort einen Snapshot verpasst, und diesen Snapshot dann z.B. auf die itk-server-000030.vmdk verweisen laesst..

Das hab ich nicht so ganz vestanden, um auf einen Snapshot zu verweisen müssen die .vmdk Dateien doch im selben Ordner sein, oder?
Danke nochmal, man kann´s nicht oft genug sagen

Edit: Zur Storage-Struktur: Ich habe Ein Storage mit 3 Lun´s, das über Sas verbunden ist
Dann ein Qnap-Nas, verbunden über ein seperates Speichernetz, und noch ein Backup-Storage, ebenfalls über das Speichernetz verbunden

[JustMe]

Z.B.:
potent beim Duden
Von mir gemeint war: Leistungsstark, d.h. schnell & ausreichend Platz.

...müsste ich ja theoretisch immer nur abends den aktuellen Snapshot durch den zuletzt gesicherten erstzen...

Jepp, so ist es. Aber ggfs. die CID kontrollieren; sonst passt u.U. die Verzeigerung nicht mehr.

...müssen die .vmdk Dateien doch im selben Ordner sein...

Das muessen sie mitnichten. Der ParentFilenameHint darf durchaus auch einen Pfad enthalten; wenn's keinen gibt, erst DANN muss die Datei im gleichen, d.h. aktuellen Ordner liegen. Absolute Pfade (/vmfs/volumes/...) sind gebraeuchlich; ob relative Pfade wie ../.. gehen, weiss ich leider nicht.

[skrix182]

indem man einer (ausgeschalteten!) neuen VM mit GLEICHER vmdk sofort einen Snapshot verpasst, und diesen Snapshot dann z.B. auf die itk-server-000030.vmdk verweisen laesst...

Also, genau das hab ich jetzt gemacht, mit der vmdk-000030 bis 000037. Jeweils die ParentCID und den ParenFilename angepasst. Hat auch jedes Mal super funktioniert, d.h. die Vm hat jedes Mal normal gebootet (ohne netzwerkkarte)
Aber das eigentliche Problem ist ja nicht, dass die VM nicht ordnungsgemäß bootet, sondern dass sie sich nicht normal kopieren/konsolidieren/sichern lässt..
Ich würde einfach mal gerne diese 37 Snapshots wegbekommen, aber das hat ja bis jetzt nie funktioniert. Weder über die GUI von Vsphere, noch über den Snapshotmanager (der zeigt mir übrigens überhaupt keine an). Und auch das vmfks -i Command über SSH hat bis jetzt und mit Auswählen des aktuellen Snapshts nicht funktioniert..
Oh je, ich wiederhol mich schon, das hatten wir ja schon alles..
Langsam macht´s einen echt fertig, das ganze.

[JustMe]

Stimmt, man muss zwei Teilaspekte getrennt beachten.

Die Geschichte mit dem Einbinden aelterer Snapshots kam in's Spiel, als es hiess, dass die VM nach dem Konsolidieren ihr Gastsystem nicht mehr bootet, und sollte ergeben, ab welchem Snapshot dieses Problem hinzukam.

Konnte die Test-VM, die auf irgendwas VOR 37 verwies, sauber ge-chkdsk-ed oder gesichert werden?

Wenn jetzt sichergestellt ist, dass die ganzen Snapshots VOR 37 ok sind, koennte man zumindest diese ja in die Basis-Datei konsolidieren. Dazu nimmt man eine neue VM, schaltet NICHT ein, haengt die -000036 da dran, und waehlt fuer diese VM "Delete all Snaps" (ggfs. einen neuen Snapshot manuell erstellen). Ergebnis ist dann eine itk-server.vmdk, die man dem -000037er Snapshot als Parent praesentiert, und ist alle alten Snapshots los.

Das Problem mit dem neuesten Snapshot 000037 behebt das alles noch nicht. Dafuer waren die Hinweise auf die beiden KB-Artikel bei VMware gedacht, aber dann konnte ja nicht gesagt werden, was tatsaechlich schon einmal geloescht worden war. Und ein Ergebnis fuer die explizite Befolgung der KB-Hinweise zum Ausschalten von ctk habe ich hier im Thread-Verlauf nicht gefunden.

Der Snapshot-Manager im vSphere-Client zeigt uebrigens nix an, weil die .vmsd-Datei im VM-Verzeichnis keine sinnvollen Daten enthaelt. Die ist mit ca. 500B viel zu klein, um Infos fuer alle 37 Snapshots zu enthalten. Wie mit dieser vmsd zu verfahren ist, steht auch in einem der beiden KB-Artikel: Einfach weg damit.

[skrix182]

okay, dann weiß ich ja was ich als nächstes noch machen kann..

Dazu nimmt man eine neue VM, schaltet NICHT ein, haengt die -000036 da dran, und waehlt fuer diese VM "Delete all Snaps" (ggfs. einen neuen Snapshot manuell erstellen).

Das hab ich allerdings noch nicht ganz verstanden... Ich leg eine neue Vm an, vmdk Größe gleich wie bei der Ursprungsvmdk (500gb).Bis hierhin alles klar. Aber was meinst du mit "dranhängen"? alle 36 Snapshots rüberkopieren? oder nur die CID/ParentFileName bearbeiten?

[JustMe]

Nein, so nicht. Das mit der VM mit 500er Platte war angedacht als Test fuer die Verwendbarkeit der alten Snapshots, wo Du schriebst, dass Du die schon verifiziert haettest.

Zum Loeschen aller verifizierten Snapshots:
VM erstellen, und dieser VM als Platte keine neue geben, sondern die itk-server.vmdk.
Dann die .vmx-Datei der VM bearbeiten, dass die nicht auf /vmfs/volumes/...itk-server.vmdk verweist, sondern eben z.B. auf .../itk-server-000036.vmdk.
Dann die VM wieder registrieren, NICHT EINSCHALTEN, Snapshot erstellen, "Remove all Snaps".
(Leider kann man einer VM im Client nicht einfach einen Snapshot als "Disk" zuweisen; der Wizard zeigt nur Basis-Dateien an. Das hat in der Vergangenheit schon etlichen Leuten den Hals gebrochen in ihren Wiederherstellungsversuchen...)

Zu guter Letzt dann die -000037.vmdk anpassen, dass sie nicht mehr auf die -000036 verweist, sondern auf die itk-server.vmdk, die jetzt nach der Konsolidierung ja alle "aelteren" Snapshots enthaelt, und mithin den Stand der vorherigen -000036 darstellt.

Bitte ggfs. immer darauf achten, dass VMs nur aus dem Repository (Bestandsliste) entfernt werden, und NICHT von der Platte geputzt werden!

[skrix182]

Dafuer waren die Hinweise auf die beiden KB-Artikel bei VMware gedacht, aber dann konnte ja nicht gesagt werden, was tatsaechlich schon einmal geloescht worden war. Und ein Ergebnis fuer die explizite Befolgung der KB-Hinweise zum Ausschalten von ctk habe ich hier im Thread-Verlauf nicht gefunden.

Ich hab die Hinweise alle befolgt, die -ctk- Dateien sind alle weg.
Anschließend habe ich nochmal einen Backup-Versuch mit Veeam gestartet. Der Bricht nach 46 % mit folgender Fehlermeldung ab:

Code: Alles auswählen

13.01.2015 08:33:36 :: Processing itk-server Error: VDDK error: 21036749815809.NBD_ERR_DISKLIB
Unable to read file block. File: [vddk://[DS01] itk-server/itk-server-000036.vmdk]. Offset: [250733395968]. Block granularity: [1048576].
Exception from server: VDDK error: 21036749815809.NBD_ERR_DISKLIB
Unable to read file block. File: [vddk://[DS01] itk-server/itk-server-000036.vmdk]. Offset: [250733395968]. Block granularity: [1048576].
Unable to retrieve next block transmission command. Number of already processed blocks: [23911


Das hört sich doch so an, als ob der Fehler im Snapshot Nummer 36 Liegt, oder?
Gibts da jetzt noch eine Möglichkeit? Klar, ich kann die Snapshots bis -35 konsolidieren, aber das wird wohl nix an dem oben genannten Fehler ändern...
Edit: Sorry, das ist die Fehlermeldung aus dem ersten Backup-Versuch.. Aber außer dem Datum hat sich nichts verändert. Bricht genau an der gleichen Stelle ab.