Schwierigkeiten bei Schnapshot-Wiederherstellung

[tt33tt]

Guten Morgen zusammen,

ich habe eine VM, auf der ein wichtiger Web-Server läuft. Die Daten brauchen am Montag wieder einige hundert Mitarbeiter
Vor einer größeren Update-Installation auf der VM, habe ich ein Snapshot gemacht.
Dann habe ich auch noch die vmware-tools installiert. Während der Installation wurde die Netzwerkkarte abgeschaltet.
Deswegen habe ich versucht auf die lokale Konsole vom vSphere Client zuzugreifen. Allerdings konnte ich bei meinem PC die (lokale) Konsole nicht sehen. Deswegen habe ich dann auf ein Snapshot zurückgesetzt. Es hat weiterhin nicht geklappt und deswegen habe ich die Festplatte dann mit einer neu erzeugten VM eingebunden und ich konnte die Konsole weiterhin nicht sehen. Dann habe ich herausgefunden, dass ich von einem anderen PC auf die Konsole zugreifen kann. Somit hätte ich mir die ganze Mühe sparen können.
Nun hat sich allerdings herausgestellt, dass jetzt auf der VM ein Stand von Juli 2010 läuft und alle Daten zwischen Juli 2010 und heute weg sind
Immerhin wird die Datenbank regelmäßig gesichert. Doch die Dateien scheinen uns zu fehlen...

Ich vermute, dass ungewollt das Snapshot vom August 2010 aktiv ist.
Es gibt ein weiteres Snapshot von August 2013 und von gestern.
Wenn ich eines dieser beiden neueren Snapshots einspiele, dann versucht er als Festplatte etwas sehr Seltsames einzubinden: [datastore]vmname/vmname-000022.vmdk
Hierbei kommt die Fehlermeldung:
"Cannot open the disk '/vmfs/volumes/xxxetcxxx/vmname/vmname-000021.vmdk' or one of the snaphot disks it depends on. Reason: The parten virtual disk has been modified sine the child was created."
Der Sever versucht immer eine Nummer höher einzubinden, als in der Fehlermeldung steht, z.B: 22 statt 21. Bei jedem Versuch erzeugt er die Festplatte, die in der Fehlernummer genannt ist und die Nummer zählt jedes Mal weiter hoch.
Jetzt habe ein Haufen vmdk-Dateien, ohne meine Snapshots benutzen zu können

Ist das so üblich, dass er diese vmname-0000xx.vmdk einbindet, wenn er ein Snapshot zurückspielt?
Was kann ich noch machen, damit es wieder geht?
Ist es möglich, mir die Snapshots anzuschauen und auf die Daten zurückzugreifen? Soweit ich weiß, sind sie inkrementell.
Wenn ich die Festplatte auf einer anderen VM einbinde, gehen dann alle Snapshots verloren?

Ich hoffe, ihr könnt mir weiterhelfen

Liebe Grüße

[Dayworker]

Das wichtigste zuerst: Snapshots sind keine Backups.
Weshalb hast du also überhaupt noch mehrere Snapshots rumliegen und diese nicht zeitnah eingepflegt?

[tt33tt]

Ja, das ist mir bewusst
Was meinst du mit einpflegen?

[Dayworker]

Wenn du vor einer tiefgreifenden Änderungen einen Snapshot machst, solltest du diesen in VMware-Sprache auch wieder löschen. Falls dein Host-Datenträger nämlich ein Problem hat und dadurch die Snapshotkette unterbrochen wird, wirst du unweigerlich auch Daten verlieren. Um so länger eine Snapshotkette ist, desto mehr steigt auch das Risiko auf einen Datenverlust.
Problematisch ist dabei, daß du absolut keine VMDKs in diesem VM-Ordner löschen darfst, solange ein Snapshot diesen noch brauchen könnte. Du kannst aber auch nicht einfach sagen, daß die tiefste Snapshot-Nummer, erkennbar am 000001 am Ende einer VMDK, auch der älteste Datenbestand ist. Die Snapshot-Nummer richtet sich immer nach der tiefsten freien Nummerierung. Wenn du also die Nummern 000001, 000003 bis 000010 im Einsatz hast, wird der nächste Snapshot die Nummer 002 tragen.

[tt33tt]

Wenn ich einen Snapshot über den Snapshot-Manager lösche, müsste es gehen oder?
Ich frage mich, warum er bei jedem Versuch, den Snapshot einzupspielen, eine neue VMDK anlegt. Jedes Mal schlägt das ja auch mit dem Fehler fehl, den ich schon beschrieben habe.
Nur der Snapshot vom August 2010 klappt seltsamerweise (das ist der erste Snapshot in der Kette).

[Dayworker]

Achtung mach jetzt keinen Mist. Wenn du einen Snapshot "einpflegst", sind vohergehende Snapshots in dieser Kette wirklich weg und lassen sich nur von einem auf Datenrettung spezialisierten Unternehmen oder bei geschicktem VMDK-Format auch von unserem Ulli wiederherstellen.

Deine ganzen Angaben machen mir nicht den Eindruck, als ob du die Tragweite und den Ablauf von Snapshots überblicken kannst. Ein Snapshot enthält alle zukünftigen, sich von der jeweiligen Basis zum Zeitpunkt X verändernden Daten. Wenn du einen bestimmten Snapshot anspringst, wird dieser als neue Basis genommen und alle sich davon zukünftig unterscheidenden Daten werden in eine neue Snapshot-Nummer geschrieben. Wenn du lange Snapshotketten hast, macht das das Verständnis nicht gerade leichter. Hier mal eine kleine Exkursion zum Thema Snapshot:





Bei deinen ganzen Aussagen verstehe ich einige andere Dinge nicht. Ihr habt noch einen ESXi3 in Verwendung, der inzwischen auch deutlich ausserhalb jedweden Supports ist und dieser ist für mehrere 100 Mitarbeiter sogar von existenzieller Bedeutung. Wer kam da auf die absolut schwachsinnige Idee, dauerhaft mit Snapshots zu Arbeiten
Bei Euch scheint wirklich niemand verstanden zu haben, daß Snapshots nur Mittel zum Zwecke eines Backup sind und auch wieder zeitnah eingepflegt werden sollten.
Ich vermute daher mal ganz stark, daß eure Snapshot-Kette ungefähr so aussieht:

[tt33tt]

Der Server soll eigentlich auch schon lange Zeit weg sein. Wir werden den Anlass dann zum Grund nehmen, den Umzug zu beschleunigen!
Wir haben noch eine "richtige" Datensicherung, allerdings nur für die Datenbanken des Servers. Ich greife auch nur als Notlösung auf die paar Test-Snapshots zurück, weil ich momentan nichts anderes habe.
Ich weiß, dass die Snapshots voneinander abhängig sind, allerdings fehlt mir durchaus noch das Verständnis, wie sich das in der Praxis auswirkt. Deswegen danke!
Werden die Snapshots ungültig, wenn ich die Festplatte zwischendurch in einer anderen VM einhänge? Das habe ich nämlich gemacht gehabt, wie beschrieben. Eine Antwort darauf hilft mir schon sehr viel weiter

Ich habe die derzeitige Snapshot-Struktur angehängt:

Auf dem Datastore existiert zu jeder vmdk-Datei noch eine delta.vdmk-Datei, außerdem existiert noch eine flat.vdmk-Datei. Das ist die Struktur auf dem Datastore:

[Dayworker]

Die Snapshots werden eigentlich nicht ungültig, aber wenn du die falsche VMDK eingebunden oder dort sogar Snapshots gelöscht hast, könnte entweder die Basis-VMDK verändert worden sein, was den Snapshot ungültig machen und eine Fehlermeldung beim VM-Start produzieren würde, oder die Kette wäre unterbrochen und die VMSD-Datei im Ursprungsordner enthielte somit ungültige Einträge. Die VMSD-Datei liegt immer mit im selben Ordner, wo die momentan ausgeführte VMX-Datei gespeichert ist.

Wenn du also eine vDISK mit Snapshots temporär in eine andere VM einfügst und dort neue Snapshots auslöst, passen diese Einträge nicht mehr zur VMSD am Ursprung und du verlierst daher auch die Möglichkeit zu früheren Punkten zurückzuspringen. Die Folge ist ein Datenchaos und genau aus dem Grund operiert man mit Snapshots immer nur kurzzeitig und pflegt diese umgehend wieder ein.

Ein weiterer Grund gegen Snapshots ist das dadurch genutzte vDISK-Format Sparse bzw Thin, das zwar den Platz spart, aber regelmäßige Pflege in Form des Shrinken braucht und durch den internen Aufbau im Ernstfall fast immer für Datenverlust sorgt. Falls also Sparse/Thin-vDISKs zum Einsatz kommen, muß man immer auch den freien Platz im Datastore im Auge behalten.

Bevor du all deine Aktionen gestartet hast, hättest du einfach mal den gesamten VM-Ordner über den ESXi clonen sollen. Einfach nur den DB-Inhalt zurückspielen, kann je nach DB auch schon mal zu kurz greifen, wenn es den Benutzer zum damaligen Zeitpunkt noch nicht gab oder völlig andere DB-Einstellungen genutzt wurden.


Der Datastore-Browser ist bekanntermaßen unzuverlässig und wenn dessen Ausgabe mit der per SSH übereinstimmt, hast du ein echtes Problem. Schalte dich daher mal per SSH auf den ESXi und poste als {code} dann die Ausgabe von:

Code: Alles auswählen

ls -al

Das das Datum bei der Basis-VMDK aktueller als das einiger Snapshots ist und somit höchstwahrscheinlich auch deren Datenbestand aktueller als der der Snapshots ist, könnte dir noch viel Ärger einbringen. Besonders da du jetzt mit dem Datenbestand von 2010 hantierst und alle jetzt auflaufenden Dateiänderungen in den neuen Snapshot geschrieben werden. Du hast dir dadurch jetzt zwei Datenbestände produziert, einmal die alten von 2010 mit den aktuell auflaufenden, sich verändernden Daten und dann noch den Datenbestand vom Test-Snapshot. Die jetzt auflaufenden Daten kannst du aber nicht in den Test-Snapshot rüberretten, wenn du auf diesen umschaltest. Das mußt du manuell nachholen und auch von Hand in die DB einpflegen.

[tt33tt]

Ich habe keine Snapshots gelöscht. Es sind alle Snapshots da!

Da eine Datei gesperrt gewesen war, bin ich Anfangs dieser Anleitung gefolgt:
http://kb.vmware.com/selfservice/micros ... alId=10051
Deswegen habe ich mit touch auf die Dateien zugegriffen und somit ist das Datum falsch. Das Problem mit der Sperrung habe ich danna einfach nur durch einen Neustart des Host-Servers gelöst.
Das hier ist die Ausgabe von ls -al
---
-rw------- 1 root root 3137362432 Aug 28 15:27 vmname-000001-delta.vmdk
-rw------- 1 root root 242 Sep 6 14:44 vmname-000001.vmdk
-rw------- 1 root root 302012928 Sep 6 12:43 vmname-000002-delta.vmdk
-rw------- 1 root root 226 Sep 6 14:44 vmname-000002.vmdk
-rw------- 1 root root 23040 Sep 6 16:25 vmname-000003-delta.vmdk
-rw------- 1 root root 226 Sep 6 16:25 vmname-000003.vmdk
-rw------- 1 root root 23040 Sep 6 13:50 vmname-000004-delta.vmdk
-rw------- 1 root root 226 Sep 6 14:44 vmname-000004.vmdk
-rw------- 1 root root 43520 Sep 6 23:14 vmname-000005-delta.vmdk
-rw------- 1 root root 219 Sep 6 23:14 vmname-000005.vmdk
-rw------- 1 root root 23040 Sep 7 00:02 vmname-000006-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:02 vmname-000006.vmdk
-rw------- 1 root root 23040 Sep 7 00:04 vmname-000007-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:04 vmname-000007.vmdk
-rw------- 1 root root 23040 Sep 7 00:13 vmname-000008-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:13 vmname-000008.vmdk
-rw------- 1 root root 23040 Sep 7 00:15 vmname-000009-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:15 vmname-000009.vmdk
-rw------- 1 root root 23040 Sep 7 00:20 vmname-000010-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:20 vmname-000010.vmdk
-rw------- 1 root root 23040 Sep 7 00:20 vmname-000011-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:20 vmname-000011.vmdk
-rw------- 1 root root 23040 Sep 7 00:40 vmname-000012-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:40 vmname-000012.vmdk
-rw------- 1 root root 23040 Sep 7 00:41 vmname-000013-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:41 vmname-000013.vmdk
-rw------- 1 root root 23040 Sep 7 00:41 vmname-000014-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:41 vmname-000014.vmdk
-rw------- 1 root root 23040 Sep 7 00:42 vmname-000015-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:42 vmname-000015.vmdk
-rw------- 1 root root 16820736 Sep 7 00:44 vmname-000016-delta.vmdk
-rw------- 1 root root 219 Sep 7 00:43 vmname-000016.vmdk
-rw------- 1 root root 16820736 Sep 7 00:45 vmname-000017-delta.vmdk
-rw------- 1 root root 219 Sep 7 00:44 vmname-000017.vmdk
-rw------- 1 root root 23040 Sep 7 00:45 vmname-000018-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:45 vmname-000018.vmdk
-rw------- 1 root root 23040 Sep 7 00:45 vmname-000019-delta.vmdk
-rw------- 1 root root 226 Sep 7 00:45 vmname-000019.vmdk
-rw------- 1 root root 23040 Sep 7 09:58 vmname-000020-delta.vmdk
-rw------- 1 root root 226 Sep 7 09:58 vmname-000020.vmdk
-rw------- 1 root root 23040 Sep 7 09:58 vmname-000021-delta.vmdk
-rw------- 1 root root 226 Sep 7 09:58 vmname-000021.vmdk
-rw------- 1 root root 16820736 Sep 7 10:08 vmname-000022-delta.vmdk
-rw------- 1 root root 219 Sep 7 10:00 vmname-000022.vmdk
-rw------- 1 root root 23040 Sep 7 10:08 vmname-000023-delta.vmdk
-rw------- 1 root root 226 Sep 7 10:08 vmname-000023.vmdk
-rw------- 1 root root 16820736 Sep 7 12:56 vmname-000024-delta.vmdk
-rw------- 1 root root 219 Sep 7 12:51 vmname-000024.vmdk
-rw------- 1 root root 2148619095 Aug 26 2010 vmname-Snapshot1.vmsn
-rw------- 1 root root 2152978906 Aug 28 15:27 vmname-Snapshot2.vmsn
-rw------- 1 root root 18734 Sep 6 12:43 vmname-Snapshot3.vmsn
-rw------- 1 root root 18727 Sep 6 23:14 vmname-Snapshot5.vmsn
-rw------- 1 root root 21496084480 Sep 7 13:32 vmname-flat.vmdk
-rw------- 1 root root 8684 Sep 7 12:56 vmname.nvram
-rw------- 1 root root 395 Sep 7 13:25 vmname.vmdk
-rw------- 1 root root 1470 Sep 7 12:50 vmname.vmsd
-rwxr-xr-x 1 root root 1796 Sep 7 12:51 vmname.vmx
-rw------- 1 root root 260 Sep 7 00:46 vmname.vmxf
-rw-r--r-- 1 root root 22739 Sep 7 09:57 vmware-50.log
-rw-r--r-- 1 root root 17582 Sep 7 09:58 vmware-51.log
-rw-r--r-- 1 root root 30337 Sep 7 10:08 vmware-52.log
-rw-r--r-- 1 root root 18125 Sep 7 10:08 vmware-53.log
-rw-r--r-- 1 root root 18125 Sep 7 11:28 vmware-54.log
-rw-r--r-- 1 root root 18125 Sep 7 11:32 vmware-55.log
-rw-r--r-- 1 root root 30341 Sep 7 12:56 vmware.log
---
Als ich die VM-Disk in die andere VM eingebunden hatte, habe ich auch ein Snapshot gemacht. Der wurde im Ordner der anderen VM gespeichert. Da das im anderen Ordner ist, müssten die Snapshots noch in Ordnung sein oder? Sie werden ja auch im Snapshot-Manager angezeigt.

Alle Änderungen die ich jetzt an der VM noch vornehme, dürfen verloren gehen. Wir haben nämlich schon eine neue VM aufgesetzt, die die Services wiederherstellen soll. Uns fehlen noch die Dateien, die auf der VM gespeichert waren.

Das hier ist der Inhalt der vmname.vdmk:
---
Disk DescriptorFile
version=1
CID=0c222f26
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 41984540 VMFS "vmname-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "2613"
ddb.uuid = "60 00 C2 94 ac 13 0e ea-a3 b3 83 f2 6e 80 30 4a"
ddb.virtualHWVersion = "4"
ddb.toolsVersion = "0"
---
Hilft die dort genannte vmname-flat.vdmk weiter?

Das mit den Backups und dem Clonen habe ich jetzt dazugelernt. Sicherheit geht eindeutig vor Risiko!

[Dayworker]

Die Snapshots mögen noch da und trotzdem könnten die fast wertlos sein, da du am Anfang die Meldung bekamst:

"Cannot open the disk '/vmfs/volumes/xxxetcxxx/vmname/vmname-000021.vmdk' or one of the snaphot disks it depends on. Reason: The partental virtual disk has been modified sine the child was created."

Du mußt jetzt ganz genau schreiben, wo du diese Meldung bekommen hast und wirst dich wahrscheinlich auf Datenverlust einstellen müssen. Durch das Einbinden der Basis-VMDK, vermutlich "vmname.vmdk", in eine andere und starten dieser VM, hast du die Basis auch schreibtechnisch verändert. Dadurch passen nachher in der Ursprungs-VM die im Snapshot gespeicherten, veränderten Daten nicht mehr zur Basis-VMDK. Anstelle der Basis-VMDK hättest du die in der VMX-Datei genannte VMDK einbinden müssen und hättest dann den Datenbestand von der VM mit den unwilligen Snapshots gehabt.


Hoffentlich liest continuum mit und kann dir da wieder raushelfen. Mach mal bitte einen Call bei continuum unter http://sanbarrow.com/sickbay.html auf.

[continuum]

Wenn das Problem noch akut ist - meld dich doch morgen mal per Telefon

[Supi]

Wenn das Problem noch akut ist - meld dich doch morgen mal per Telefon

Guten Morgen zusammen [Verfasst am: 07.09.2013],

ich habe eine VM, auf der ein wichtiger Web-Server läuft. Die Daten brauchen am Montag wieder einige hundert Mitarbeite

Morgen ist es für Ihn ggf zu Spät. Aber da ist wohl vorher schon vieles zu spät gewesen.

[tt33tt]

Als ich die vmdk bei der anderen VM eingebunden habe, konnte ich nur eine vmdk auswählen: vmname.vmdk
Ich ging davon aus, dass wenn mir nur eine Datei angezeigt wird, ich auf jeden Fall die richtige auswähle. Wenn ich nur eine auswählen kann, dann muss das die richtige gewesen sein oder?

Nun zur Fehlermeldung "Cannot open the disk '/vmfs/volumes/xxxetcxxx/vmname/vmname-000021.vmdk' or one of the snaphot disks it depends on. Reason: The partental virtual disk has been modified sine the child was created."
Ich habe versucht auf das neueste Snapshot zu gehen. Dabei bindet er seltsamerweise die Festplatte "[datastorex] vmname/vmname-000025.vmdk" ein. Wenn ich dann versuche, die VM zu starten, kommt "A general system error oncurred: Internal error".
Wenn ich nun die Festplatte "[datastorex] vmname/vmname-000025.vmdk" über "Edit Settings" aus der Config entferne, binde ich stattdessen die "[datastorex] vmname/vmname.vmdk" Das ist auch die einzige Platte, die mir über "Browse" angezeigt wird. Anschließend kommt die Fehlermeldung "[datastorex] vmname/vmname-000025.vmdk"

Hm, wie finde ich die Platte heraus, die bei dem Fehler beschrieben ist?

[irix]

Ueber die GUI kann man generell kein Snapshot einbinden als vDisk und es wird immer nur die Basis VMDK angezeigt zur Auswahl. Somit ist nun die Ausgangsdatei,welche bis Dato statisch und nicht veraendert wurde seit dem Jahr 2010 nicht mehr die Basis fuer die Snaps welche nun in der Luft haengen.

Die VM ist sofort hart auszusachlen damit sich nicht noch mehr Bloecke aendern. Bei der hohen Laufzeit des Snaps besteht evtl. noch chance Grosseteile zuretten.

Ich wuerde Ulli anrufen.

Gruss
Joerg

[continuum]

Die VM läuft schon wieder.

Das Problem war dass jemand die Basisplatte woanders eingehangen und dann auch noch expandiert hatte.

Die VM ist ansonsten ohne Datenverlust gerettet worden.

[tt33tt]

Vielen Dank dir noch einmal!
Es musste in der Beschreibungsdatei die Zeile mit der Größe richtig angepasst werden und die Snapshots in die richtige Reihenfolge gebracht werden.
Beim nächsten Mal werde ich
1. ein Vollbackup machen und
2. bei Fehlern nicht dauernd einen Start probieren.

Alle Daten sind da und ich/wir sind glücklich

[irix]

Wird man nun eine Aktualisierung und die Einfuehrung eines VM Backupprogramms ins Auge fassen oder vertraut man auf das Glueck beim naechsten Vorfall?

Gruss
Joerg

[Dayworker]

Ich vermute, daß man sich wieder auf den glücklichen Zufall verläßt und ohne aktiven Snapshot wäre die Geschichte vermutlich auch nicht so aus dem Ruder gelaufen.
Bei einem jetzt noch eingesetzten ESXi3 steht aber zu vermuten, daß die HW für vSphere entweder zu schwach (unwahrscheinlich, da sich ansonsten sicherlich nicht IOs von mehreren 100 Mitarbeitern befrieden lassen) oder davon einfach nicht mehr unterstützt wird.

Mal sehen, ob sich der "tt33tt" dazu noch äußert.

[tt33tt]

@Dayworker: Ich verstehe deine Frage nicht

Unsere Hardware ist in Ordnung und die Performance auch.
Allerdings lösen wir den Server bald ab. Wir haben schon fast alle VMs abgeschaltet oder umgezogen. Der kleine Rest kommt jetzt bald nach und dann können wir den Server komplett abschalten.
Über komplette VM-Backups denken wir schon längere Zeit nach. Ein VM-Backup ist ja auch einfacher als bei einem Fehler die VM neu zu erstellen und DB+Dateien zurückzuspielen.
Continuum hat mir Empfehlungen für folgende Backup-Programme gegeben:
http://www.virtuallyghetto.com/p/vghett ... itory.html (kostenlos)
http://www.trilead.com/de/ (Freeware bzw. günstige Pro-Version)

[Dayworker]

Ich hatte dir doch noch keine Frage gestellt, die kommt nämlich erst jetzt.
Wohin habt ihr die restlichen VMs umgezogen bzw verbleibt ihr bei VMware aber mit aktuellerer vSphere-Version?

[irix]

GhettoVCB2 is ungeeignet fuer eigentlich fast alle Faelle wenn es um "Produktion" geht. Veeam und oder vRanger ist das was man haben moechte sofern man noch ueberhaupt kein Backupprogramm hat.

Gruss
Joerg

[tt33tt]

Hm, wir steigen auf Citrix um. Die Grundlagen sind dort ja gleich.
Ich denke mal, dass wir die VMware-Server gut für TestVMs und so verwenden können. Wäre ja auch schade um die Lizenzen

[irix]

Du meinst XenServer oder? Citrix waren die welche wegen Erfolgslosigkeit nun ihr Produkt freigeben wolllen oder schon haben.

Gruss
Joerg

[tt33tt]

Danke, ich meine XenServer

[tt33tt]

VMware haben wir weiterhin im Einsatz und es gibt viele praktische Anwendungsmöglichkeiten.
Ich habe gehört, dass VMware im Bereich der Hardwarevirtualisierung sogar noch besser ist.