Jump to content

Frage zu eurem Vorgehen bei einer WIederherstellung


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

gleich vorne Weg, es gibt Momentan kein Problem mit einem Exchange Server. Es geht mir lediglich um euer Vorgehen, bzw. die Möglichkeiten eines Recoverys, bzw. Reparatur der Datenbank.

Angenommen wir haben einen Exchange Server mit einer Datenbank.

Die Datenbank wird täglich um 22 Uhr mit Veeam gesichert und die Transaktions-Logs werden somit vom Exchange gelöscht.

 

Aus einem nicht bekannten Grund crasht die Datenbank. Eventuell Stromausfall und keine USV Vorhanden, oder die Datenbank lässt sich einfach nicht mehr einbinden.

 

Wie ist jetzt euer Vorgehen, bzw. welche Methoden geht ihr nacheinander durch und was versucht ihr alles, bevor Ihr die Datenbank komplett aus einem Backup wiederherstellt?

 

1.) Aktuelle Logs + Datenbank wegsichern / kopieren.

2.) Softrecovery mit Eseutil 

3.) Hardrecovery mit Eseutil

4.) Wiederherstellung der Datenbank "Dial Tone"

5.) Recovery Group um zu versuchen die alte Datenbank wieder Online zu bekommen oder Dritt Tools

 

#######

 

Zusätzliche Frage:

 

Angenommen man sichert wie oben beschrieben jeden Tag um 22 Uhr.

Die Datenbank fliegt am nächsten Tag um 18 Uhr auf die Nase. Somit hat man einen alte Datensicherung von circa 22:00 uhr und hat eine Defekte Datenbank.

Zusätzlich zur defekten Datenbank hat man allerdings die noch nicht entfernen Transaktionsprotokolle.


Somit kann man den wenn alles gut läuft mit der Sicherung vom Vortag und den aktuellen Logs den aktuellen Stand wiederherstellen.
Wie ist hier genau das Vorgehen, um so einen Stand wiederherzustellen?

 

1.) Verzeichnis sichern / kopieren

2.) Verzeichnis aus Backup in das ursprüngliche Verzeichnis kopieren

3.) die Logs, welche im Backup fehlen, allerdings bis zum crash geschrieben wurden hinzu kopieren

4.) und dann versuchen per Softrecovery die Protokolle einzuspielen?

 

Ist diese Vorgehen so richtig, oder habe ich einen Fehler.

 

#####

 

Angenommen es sind einige Transaktionslogs defekt, weswegen diese nicht korrekt in die Datenbank eingespielt werden können.

 

Kann man diese Logs mit einem Befehl ausfindig machen und löschen?

Wenn mann danach wieder versucht die Logs in die Datenbank einzuspielen, wird dies erledigt oder meckert der Exchange da Zwischenschritte bei den Logs fehlen? 


Danke euch im Voraus.

 

Grüße Phil  

bearbeitet von Gerber
Link zu diesem Kommentar

Danke dir für die Antwort.

 

Bedeutet in diesem Fall (Falls sowas auftreten sollte) hat man keine Chance und müsste somit mit Dritt Tools versuchen an die Mails zu kommen?

 

Kannst du mir auch zu den ersten zwei Punkten behilflich sein?

 

- Vorgehensweise beim Restore/Repair

- Defekte Datenbank mit altem Backup und aktuellen Trans Logs?

 

Grüße Phil 

Link zu diesem Kommentar

Gibts doch genügend Vorlagen im Netz. ;) alternativ einfach mal im Testsystem durchspielen. Wenn die DB defekt ist und alle logs bspw. Auf einer anderen Partition vorliegen, kann die DB einfach wieder hergestellt werden mit dem entsprechenden Schalter, dass da noch Logfiles nachkommen. Die Logs werden dann per rollforward nachgefühlt. Kann man im eventlog mitverfolgen. (Anekdote aus der Praxis) ein Neukunde hatte mal angerufen, dass bei seinem exchange die db Platte ausgestiegen ist. Es wurde nie ein Backup angefertigt und die Logs liefen auf ein anderes raid. Da reichte dann tatsächlich die Neuanlage der db und alle Logs wurden nachgefühlt. Dauerte zwar ziemlich lange, aber Verlust nahe null.

Link zu diesem Kommentar

Ohjeee, was ist denn jetzt los.  :)

Das war ne einfache Frage um etwas Erfahrungsaustausch zu betreiben. 

 

Entschuldigung hierfür ... 

 

Vllt ist mir dies auch zwecks der momentanen Corona Situation in den Sinn gekommen, um mal etwas Abwechslung zu finden. 

 

Von sowas lebt meiner Meinung ebenfalls ein Forum (Erfahrungsaustausch, oder nicht?) ?

 

 

Grüße Phil 

Link zu diesem Kommentar
vor 2 Stunden schrieb Gerber:

@magheinz

 

:D:D...

 

Ich habe ehrlich gesagt nur auf den Kommentar mit der USV und dem zweiten Server gewartet :D...

Ich hätte auch schreiben können.


Nehmen wir an: 2 Server 2x USV und alles ist abgeschmiert :D:D .

 

Grüße Phil

War ja auch ein Elfmeter ohne Torwart:grins2:

 

In meinen Augen ist das eine Situation, die man schon vorher versucht zu vermeiden.

Das ist dann Desasterrecovery: wir würden jetzt eine VM aus dem Backup zurückholen wenns schnell gehen soll, oder den Exchange neu aufbauen und dann die Datenbank aus dem Backup zurückholen. Wir hätten aber auch stündliche, konsistente snapshots auf dem filer.

Link zu diesem Kommentar
vor 1 Minute schrieb MrCocktail:

3 Node DAG in GEO Redundanz mit einer Lagged Copy... Aber ganz ehrlich, die letzte wirklich defekte Datenbank habe ich glaube ich mit Exchange 2007 gesehen, seit dem nicht mehr untergekommen, ausser ich mache das mal für einen Azubi mit voller Absicht.

richtig. So schaut's bei uns auch aus. Wobei GEO sich auf zwei Gebäude bezieht.

Der dritte Standort ist in Planung, dann kann ein DAG-Knoten noch umziehen.

 

Bei uns ist alles was wichtig ist dreifach vorhanden.

Ein Knoten ist dann jeweils in der DR-Umgebung am laufen, wenn sich die Replikation auf ein logisches Protokoll(nicht binär) und auf Applikationsebene abbilden lässt.

Link zu diesem Kommentar

Hello zusammen,

 

ich wollte mich jetzt nochmals kurz zu Wort melden mit einer Kleinigkeit
Ich habe nun diverse Szenarien der Wiederherstellung nochmals getestet und durchgespielt.

 

Eine Frage hätte ich zur Offline Wiederherstellung:

 

1.) ich habe die Offline Wiederherstellung wie folgt getestet:

 

- Exchange Datenbank Verbindung aufgehoben -> Datenbank Offline wegkopiert

- Exchange DB eingebunden und diverse Änderungen gemacht.

- Exchange DB Verbindung aufgehoben 

- ECK Datei im PFad C:\DB der Original DB gelöscht

- EDB Datei aus dem Backup in das Original Verzeichnis "c:\DB "der DB kopiert und ersetzt. Somit hat die DB ja den Stand des Offline Backups

- Datenbank eingebunden

- Alles super und passt

 

2.) Offline Wiederherstellung mit ständigem Fehler bei der Einbindung der DB

 

- Die Schritte wie oben gleich bis zur Wiederherstellung

- Exchange DB Verbindung aufgehoben

- Komplettes Verzeichnis (original) C:\DB nach D:\Backup wegkopiert und aus dem Original Pfad  C:\DB gelöscht

- Offline Backup komplett mit den Logs zum Stand des Offline Backups und mit allen Dateien in den Original DB Pfad C:\DB kopiert

- Zuvor wegkopiertes (original DB) per Copy und Paste aus D:\Backup in den Pfad C:\DB kopiert und nur die fehlenden Dateien kopiert

- DB eingebunden

- Fehler

 

Diesen Schritt habe ich schon mehrfach gesehen und habe ich bei mir schon mehrfach versucht. Es kommt immer zu einem Fehler und die DB kann nicht eingebunden werden.

 

Die Backup DB hatte Clean Shutdown.

 

Testserver ist ein Exchange 2019.

Kann sich daraus irgend jemand ein Reim machen?

 

Danke euch im Voraus.

 

Grüße Phil

 

 

bearbeitet von Gerber
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...