Konsolidierung schlägt immer fehl.

[Seratin]

Hallo,

ich habe ein sehr großes Problem. Unsere Mailserver VM kann keine Konsolidierung durchführen. Und Veeam kann keine Backups machen, da die Löschung des Snapshots immer bei 99% stehen bleibt. Irgendwas scheint in dem Dateisystem falsch zu sein. Ich finde aber auch nirgendwo eine Fehlermeldung warum keine Konsoliderung möglich war. Erstellen eines Snapshots und dann Alle Löschen habe ich bereits ausprobiert, wobei dies nur die Einträge aus dem Snapshot-Manager gelöscht hat dann bei 99% stehen geblieben ist und die Snapshots immer noch alle da sind. Ich bräuchte dringend Hilfe.

 

[Asghan]

DIe wichtigtesten Fragen sind nicht beantwortet.
Welches Hostsystem? Welche Virtualisierungslösung? Welche Versionen,....

-> Hersteller fragen. Wir hier sind kein Businesssupport.

 

[Seratin]

Vsphere 6.0
ESXi 5.5 Update 2

Noch was?

Mein Chef muss erst noch alles abklären, bis wir dann schlussendlich Herstellersupport bekommen, deswegen dachte ich vielleicht hat hier jemand eine Idee.

 

[Maxell]

Wie groß ist die VM und wie sichert ihr?

 

[Seratin]

Wir sichern mit Veeam und haben das Problem nur bei dieser VM.
Die Größe der VM beträgt um die 615 GB.

 

[Maxell]

Bricht er die Konsolidierung ab oder bleibt der auf 99% stehen? Ich meine mich zu erinnern, dass die Fortschrittsanzeige bei VMware nicht so genau ist, ergo es bis auf 99% steigt und dann ewig dauert bis es auf 100% ist. Quasi, wie die Windows Kopieranzeige

Edit.: Ich meinte die Snapshots, vertippt

 

[Seratin]

Es gibt 2 Möglichkeiten:

Entweder die Konsolidierung startet nie und bleibt 3 Stunden bei "Vorgang läuft" bis dann die Meldung kommt, dass es nicht geht oder die Konsolidierung wird nach 20 Stunden bei 8% abgebrochen mit der Nachricht "Konsolidierung fehlgeschlagen" und ohne weitere Fehlermeldungen die man analysieren/googlen könnte.

 

[lampenschirm69]

Hi,
mal prüfen ob der Datamover noch einen Snapshot / Virtuelle HD der zu sichernden Maschine gemountet hat.
Führt gerne mal zu dem genannten Problem.

 

[Seratin]

Kannst du mir kurz sagen wie/wo ich das prüfe?

 

[chriss_msi]

1) Was habt ihr nun für einen Hypervisor, du schreibst vSphere 6 und ESXi 5.5, welchen von beiden?

2) Du schreibst Mailserver, was genau läuft in der VM? MS Exchange? Wenn ja, VMTools installiert und aktuell? Zarafa? Wenn ja, welche Version der open-vm-tools ist installiert?

3) Wie sieht die Veeam-Planung aus, inkrementell oder nur active full?

4) Betroffene VMs ausschalten -> Im Ordner der entsprechenden VMs auf dem Datastore die Delta-Disks manuell rausschneiden (nicht löschen!) -> Das sind die Dateien mit "-0001" etc. -> VM hochfahren -> Manuellen Snapshot erstellen und über den Manager "Alle löschen" -> Fertig. Falls die VM nach dem Rausziehen der Delta-Disks nicht hochfährt, VMX-Datei runterladen, nach Verweisen auf die Delta-Disks suchen, löschen und wieder hochladen.

Btw. bringt bei dem Fehler der Hersteller-Support von VMWare und Veeam nichts, da die sich bei diesen Problemen den Ball gegenseitig hin und her schieben.

 

[Seratin]

1. Host ist ESXi 5.5 .
2. MS Exchange und VMware Tools sind aktuell.
3. Veeam macht inkrementelle und am Wochenrnde Samstag full-

Wenn du sagst die Delta files manuell rausschneiden, wohin soll ich sie denn verschieben?

 

[chriss_msi]

1. Host ist ESXi 5.5 .
2. MS Exchange und VMware Tools sind aktuell.
3. Veeam macht inkrementelle und am Wochenrnde Samstag full-

Wenn du sagst die Delta files manuell rausschneiden, wohin soll ich sie denn verschieben?

Auf deinen Management-PC? Nur zum Zwischenlagern.

 

[Seratin]

Okay ich kopiere jetzt gerade alle Delta files, kann allerdings dauern, da die Größe ca. 220GB beträgt.. Da die Frage nachher wahrscheinlich aufkommen wird, wie kann ich die Abhängigkeiten der .vmx anschauen und löschen?

 

[chriss_msi]

Ok, 220GB ist ein Wort, da würde sogar der normale Löschvorgang auf dem Host Tage dauern, bzw. ist fast kein Wunder, dass die bisherigen Versuche fehlgeschlagen sind.

Zur VMX-Datei: Eine Original-Kopie im Datastore erstellen, dann vom DS runterladen, mit einem Editor (z.B. Notepad++) die Datei durchsuchen, ob die Deltas irgendwo aufgeführt sind, ggf. verwaiste Einträge löschen und die angepasste Datei wieder hochladen.

 

[Seratin]

Okay also jetzt habe ich folgendes Problem:

Der Kopiervorgang würde 26 Stunden dauern, d.h. der Mailserver müsste für dieses Zeit ausgeschaltet sein. Das ist leider keine Option.. . Allerdings gäbe es nicht die Möglichkeit die VM irgendwie zu sichern dann eine zweite VM zu erstellen und diese dann laufen zu lassen während an der "richtigen" gearbeitet wird? Die Mails könnte ich ja eventuell dann danach als .pst Import wieder auf den aktuellen Stand bringen, oder? Ich verzweifle hier..

 

[chriss_msi]

Hm keine 10GBit/s-Anbindung?

Leider keine Alternative, in den sauren Apfel muss man beißen, da die Deltas unbedingt raus müssen.
Es wird ja nur noch schlimmer, bei aktuell 220GB hat eure VM geschätzt schon 50-60% Leistungseinbuße, irgendwann wird die VM so träge, dass gar nichts mehr geht und dann habt ihr gar keinen Mailserver mehr...

Aber 26 Stunden bekommt man übers WE locker hin.

 

[Seratin]

Ich werde jetzt versuchen wenigstens ein Backup mit Acronis zu machen und dann werde ich das wohl am Wochenende machen .

Ergänzung (28. Juli 2016)

Ich habe mir mal gerade nochmal die Dateien angesehen. Ist es normal, dass ich 2 vmdk files habe mit den Namen Mailserver_5.vmdk und Mailserver_6.vmdk. Erstere hat 314Gb und die andere 104Gb. Außerdem steht bei beiden ein Änderungsdatum von gestern, obwohl der Server läuft?