vSphereDataProtection killt ExchangeDB

[fazez 10]

Hi zusammen,

 

wir haben glaube ich ein riesen Problem :(

 

Wir haben eine  Exchange 2013 auf vSphere 6.0 laufen. Das Backup wird durch VDP 6.0 durchgeführt. Auf dem Exchange Server wir dazu ein kleiner Plugin installiert dass auch die Exchange DB sichert.

Seit heute morgen ist der Exchange nicht mehr erreichbar. Im Log steht, dass die Datenbank corrupt bzw. die TimeStamps nicht mehr ok wären.

 

Im Datenbankverzeichnis sehe ich jetzt 3 .edb mit dem gleichen Namen. Zwei davon haben auch die gleiche Größe. Die Timestamps der .edb unterscheiden sich.

Das vCenter sagt, dass die VM Konsolidiert werden muss, obwohl im Snapshotmanager keine Snapshots sichtbar sind.

 

Liege ich richtig in der Annahme, dass mir das VDP wahrscheinlich meine ExchangeDB geschossen hat?

Was sollte ich jetzt am besten tun?

 

Meine ersten Maßnahmen:

Exchange heruntergefahren.

Wenn der Exchange heruntergefahren ist, könnte ich Snapshot --> Konsolidieren auswählen.

 

Da ich aber nicht genau weiss was dann passiert habe ich mich entschlossen erst einmal den Exchange zu klonen.

Wenn der Klon erstellt ist würde ich Konsolidieren versuchen und den Exchange wieder hochfahren.

 

Würdet ihr das auch so machen? Soll ich die Original VM Konsolidieren oder erst den Klon?

 

Bitte um Tipps, ich möchte jetzt nichts falsch machen.

 

MfG Ben

 

[zahni 521]

Du hast doch sicher Support bei VMWare mit eingekauft. Öffne dort ein Ticket. Wobei ich mir nicht sicher bin, ob man Exchange  per VM Snapshot sichern sollte.

 

Ist der Datastore vielleicht  vollgelaufen?

bearbeitet 29. Oktober 2015 von zahni

[P@trick 10]

Jedoch ist eine "Sicherung" (Clone) vom aktuellen Zustand nicht das schlechteste.

 

Steht den im Data Protection Log was drin?

 

Gruß
Patrick

[fazez 10]

Ja, Ticket wird aufgemacht.

Das VDP bietet ein eigenes Plugin für Exchange um die Datenbank zu sichern.

Am 27.10 und 28.10 konnte kein Sanpshot erstellt werden. Der Fehler ist am 26.10 laut VDP aufgetreten.

VDP: Es ist ein unerwarteter Fehler mit folgendem Fehlercode aufgetreten: 10020. Weitere Informationen sind möglicherweise in den Clientprotokollen verfügbar, die von der Konfigurationsanwendung (https://<VDP-Hostname>:8543/vdp-configure) heruntergeladen werden können.

Snip aus dem Protokoll:

2015-10-26T21:02:18.438-02:00 avvcbimage Warning <19733>: vSphere Task failed (quiesce, snapshot error=44): 'An error occurred while saving the snapshot: Failed to quiesce the virtual machine.'.
2015-10-26T21:02:18.438-02:00 avvcbimage Error <17775>: Snapshot 'VDP-1445889663eb584fa5f8b9514aded246119dbd3260d278ab6a' creation for VM '[Esxi-Exchange-LUN01] Exchange01/Exchange01.vmx' task creation encountered a quiesce problem
2015-10-26T21:02:18.438-02:00 avvcbimage Warning <0000>: The VM could not be quiesced prior to snapshot creation and this backup will not be used as a base for subseqent CBT backups.
2015-10-26T21:02:18.438-02:00 avvcbimage Warning <0000>:     Consider using the pre-freeze and post-thaw scripts to facilitate VM quiescing
2015-10-26T21:02:18.439-02:00 avvcbimage Warning <0000>:     If this is a level 0 backup, rerun with the --quiesce_fs flag set to false to get a valid baseline and then remove it for subsequent backups.


2015-10-26T22:37:38.232-02:00 avvcbimage Warning <16004>: Soap fault detected, Get In-Use Block problem, Msg:'SOAP 1.1 fault: "":ServerFaultCode [no subcode]
"Error caused by file /vmfs/volumes/554c8d68-bbe7f810-94b1-001b214ad5e8/Exchange01/Exchange01_1-000001.vmdk"
Detail: <FileFaultFault xmlns="urn:vim25" xsi:type="FileFault"><file>/vmfs/volumes/554c8d68-bbe7f810-94b1-001b214ad5e8/Exchange01/Exchange01_1-000001.vmdk</file></FileFaultFault>
'
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <14654>: The in-use blocks (pass 1) could not be found for 'VDP-1445889663eb584fa5f8b9514aded246119dbd3260d278ab6a', using disk extents.
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <0000>:    In-use blocks are not available for certain storage types.  The disk must be located on VMFS Volume.
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <0000>:    additionally, the virtual machine must have zero snapshots when change block tracking was enabled.
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <0000>: vCenter returned one in-use block of size 858993459200,
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <0000>:         This could be the result of either a long formatted (or secure erased) disk,
2015-10-26T22:37:38.232-02:00 avvcbimage Warning <0000>:         the virtual disk is thick and eager zeroed, or a cloned thick disk.

[Squire 211]

Hi,

 

durch die Sicherung dürfte mit an Sicherheit grenzender Wahrscheinlichkeit keine Beschädigung der DB auftreten.

 

Die VDP macht einen Snapshot der Maschine und dieser wird weggezogen. Innerhalb der Maschine passiert normalerweise nichts über die VDP - außer, dass das OS einen VSS Snapshot vorbereitet. Da liegt irgendwo anders ein Fehler vor. 

 

Ich würde an Deiner Stelle zum einen die Agents draufziehen und den Exchange vielleicht auch mal mit dem Bordmittelbackup aus Windows wegziehen

 

Gruß

Robert

[fazez 10]

Es sieht mittlerweile so aus, dass ich ein corruptes Filesystem auf dem Datenbank-Laufwerk habe.

Ich sehe 3 .edb files; habe aber nur eine Datenbank.

 

Kann so natürlich auch mit ESEUTIL kein recover machen. Datenbank ist in dirty shutdown.

 

Versuche es jetzt mal mit einem checkdisk, hoffe da geht nicht noch mehr kaputt.....

[WSUSPraxis 48]

Hallo Ben,

 

nicht böse gemeint. Aber suche Dir jemand der dies mit Dir direkt und Remote anschaut und erarbeitet. Bevor noch mehr kaputt geht.

 

Viele Grüße Arnd
 

[DocData 85]

VDP killt keine Exchange DB. Anhand der Fehler und dem was du nun auch festgestellt hast, kannst du eher mal von einem defekten Dateisystem ausgehen. Warum es defekt ist? Gute Frage. Die Snaphotkonsolidierung wird nur vorgeschlagen, wenn es im Working Dir der VM noch Snapshotfiles gibt (die auch verwendet werden), aber die dazugehörigen Descriptor File sfehlen. Die Snapshots sind da, aber du siehst sie im Snapshotmanager nicht. Laufen die anderen VMs im gleichen Datastore problemlos? Wo liegt der Datastore (DAS, NFS, iSCSI, FC?)?

 

Auf jeden Fall ein Ticket bei VMware eröffnen.