Gerber 15 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 (bearbeitet) 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 5. April 2020 von Gerber Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 vor 48 Minuten schrieb Gerber: 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? Nein afaik entweder alle oder keins. 1 Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 5. April 2020 Autor Melden Teilen Geschrieben 5. April 2020 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 Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 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. 1 Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 5. April 2020 Autor Melden Teilen Geschrieben 5. April 2020 Klaro gibt es genügend Unterlagen im Netz, welche ich auch schon Gefühlt alle durchgeschaut habe. Ich wollte einfach mal die Erfahrung anderer erfragen, wie Ihr an die Sache geht . Danke dir. Grüße Phil Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 Die Erfahrung bringt einen dazu, einen zweiten Server und eine USV zu verwenden Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 5. April 2020 Autor Melden Teilen Geschrieben 5. April 2020 @magheinz ... Ich habe ehrlich gesagt nur auf den Kommentar mit der USV und dem zweiten Server gewartet ... Ich hätte auch schreiben können. Nehmen wir an: 2 Server 2x USV und alles ist abgeschmiert . Grüße Phil Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 (bearbeitet) vor 3 Stunden schrieb Gerber: Ich wollte einfach mal die Erfahrung anderer erfragen, wie Ihr an die Sache geht Ob jemand Seminar oder Training dafür anbietet? Zum Vorbereiten auf einen Ernstfall könnte man vorbeugend nach potentiellen Helfern suchen. bearbeitet 5. April 2020 von lefg Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 5. April 2020 Autor Melden Teilen Geschrieben 5. April 2020 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 Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 Ja, da hilft nur, testen und selber machen. :) die Grundlagen und das Verfahren sind dir ja bekannt. ;) 1 Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 vor 2 Stunden schrieb Gerber: @magheinz ... Ich habe ehrlich gesagt nur auf den Kommentar mit der USV und dem zweiten Server gewartet ... Ich hätte auch schreiben können. Nehmen wir an: 2 Server 2x USV und alles ist abgeschmiert . Grüße Phil War ja auch ein Elfmeter ohne Torwart 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. 1 Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 5. April 2020 Autor Melden Teilen Geschrieben 5. April 2020 @NorbertFe Hast du Recht . Dann werde ich mir mal das ganz in Hyper V kurz aufbauen. @magheinz Heheh, und den Elfmeter hast du mal sauber versenkt ... Yes. Die Situation gilt es tatsächlich im Voraus zu vermeiden. Die Stündliche Sicherung ist natürlich viel Wert und sehr schön. Grüße Zitieren Link zu diesem Kommentar
MrCocktail 192 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 *g* Also wenn schon, dann richtig ... 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. Gruß J 1 Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 5. April 2020 Melden Teilen Geschrieben 5. April 2020 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. Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 8. April 2020 Autor Melden Teilen Geschrieben 8. April 2020 (bearbeitet) 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 8. April 2020 von Gerber Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.