none
TA Logs nachträglich einfügen RRS feed

  • Frage

  • Hallo,
    wir nutzen Exchange 2010.
    Besteht die Möglichkeit TA Logs nachträglich in die DB schreiben zu lassen?
    Z. B. wenn man vom Backup die DB rücksichert aber noch aktuelle Logs hat.

    Gruß
    Dennis

    Sonntag, 7. August 2016 17:50

Antworten

  • Moin,

    wenn Du mit den Logs, die Du vom Backup zurückholst und denen, die Du auf dem produktiven Storage hast, eine vollständige Kette hinbekommst, könntest Du mit ESEUTIL /R Erfolg haben.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert HaschkeD Montag, 8. August 2016 08:27
    Montag, 8. August 2016 04:35
  • Moin,

    "dirty shutdown" hat erst mal mit der vollständigen Kette nicht zwangsläufig was zu tun, das bedeutet nur, dass nicht alle Transaktionen abgeschlossen wurden. Du kannst Dirty Shutdown auch ohne Datenverlust reparieren, wenn Du alle benötigten Logs hast (die benötigten Logs kannst Du mit ESEUTIL /MH ermitteln).

    In jedem Fall aber kannst Du nur so viele Logs in die Datenbank flushen wie zusammenhängend vorliegen. Wenn Du z.B. aus dem Backup eine EDB ziehst, die einen Checkpoint bei 1000 hat, und dazu noch Logs 1001 bis 1100, kannst Du die Datenbank verlustfrei bis Checkpoint 1100 aktualisieren (das ist natürlich vereinfacht, denn "verlustfrei" aus Sicht von ESE muss nicht bedeuten, dass auch tatsächlich alle Exchange-Elemente konsistent sind).

    Hast Du nun in Produktion nur die Logs 1200 bis 1400, so kannst Du NICHT auf Checkpoint 1400 gelangen, denn die Logs 1101 bis 1199 fehlen Dir und die Kette somit bei 1100 endet. Diese anderen Logs kriegst Du auch nicht mehr rein in die Datenbank.

    Ist es eigentlich eine theoretische Frage oder hast Du da einen konkreten Fall? ;-)

    EDIT: Denn im Labor könntest Du natürlich auch Sauereien versuchen wie Checkpoint händisch anpassen, fehlende Logs ignorieren usw... In Produktion solltest Du dazu immer den PSS Supporter an der Strippe haben.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.


    • Bearbeitet Evgenij Smirnov Montag, 8. August 2016 08:25
    • Als Antwort markiert HaschkeD Montag, 8. August 2016 08:26
    Montag, 8. August 2016 08:23

Alle Antworten

  • Moin,

    wenn Du mit den Logs, die Du vom Backup zurückholst und denen, die Du auf dem produktiven Storage hast, eine vollständige Kette hinbekommst, könntest Du mit ESEUTIL /R Erfolg haben.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert HaschkeD Montag, 8. August 2016 08:27
    Montag, 8. August 2016 04:35
  • Und wenn ich keine vollständige Kette hätte hätte ich den Status "Dirty Shutdown" und müsste einen "Hard Repair" versuchen?
    Montag, 8. August 2016 07:50
  • Moin,

    "dirty shutdown" hat erst mal mit der vollständigen Kette nicht zwangsläufig was zu tun, das bedeutet nur, dass nicht alle Transaktionen abgeschlossen wurden. Du kannst Dirty Shutdown auch ohne Datenverlust reparieren, wenn Du alle benötigten Logs hast (die benötigten Logs kannst Du mit ESEUTIL /MH ermitteln).

    In jedem Fall aber kannst Du nur so viele Logs in die Datenbank flushen wie zusammenhängend vorliegen. Wenn Du z.B. aus dem Backup eine EDB ziehst, die einen Checkpoint bei 1000 hat, und dazu noch Logs 1001 bis 1100, kannst Du die Datenbank verlustfrei bis Checkpoint 1100 aktualisieren (das ist natürlich vereinfacht, denn "verlustfrei" aus Sicht von ESE muss nicht bedeuten, dass auch tatsächlich alle Exchange-Elemente konsistent sind).

    Hast Du nun in Produktion nur die Logs 1200 bis 1400, so kannst Du NICHT auf Checkpoint 1400 gelangen, denn die Logs 1101 bis 1199 fehlen Dir und die Kette somit bei 1100 endet. Diese anderen Logs kriegst Du auch nicht mehr rein in die Datenbank.

    Ist es eigentlich eine theoretische Frage oder hast Du da einen konkreten Fall? ;-)

    EDIT: Denn im Labor könntest Du natürlich auch Sauereien versuchen wie Checkpoint händisch anpassen, fehlende Logs ignorieren usw... In Produktion solltest Du dazu immer den PSS Supporter an der Strippe haben.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.


    • Bearbeitet Evgenij Smirnov Montag, 8. August 2016 08:25
    • Als Antwort markiert HaschkeD Montag, 8. August 2016 08:26
    Montag, 8. August 2016 08:23
  • Ist nur rein aus Interesse.
    Hoffe dieser Fall tritt nicht mal ein :-)

    Vielen Dank.
    Montag, 8. August 2016 08:27
  • Moin,

    nur der formhalber, weil wir hier ja über die Theorie reden:

    Der von Evgenji beschrieben Vorgang "/R", das sog. "Soft Recovery" kommt eigentlich nicht beim Restore eines Backups zu tragen.

    Nach dem Backup wird ein sog. "Hard Recovery" durchgeführt, für den eseutil mit der Option "/CC" aufgerufen wird (oder das Restore-Programm, wenn es da mitmacht). Dafür wird auch eine Datei "restore.env" erwartet.

    Technisch werden dann zuerst die restorten Logs eingespielt (bis wohin steht in der restore.env) und danach weitere Log-Dateien, wenn sich sich im korrekten Logfile-Ordner befinden.

    Wenn alles gut läuft, ist die Datenbank danach "Clean Shutdown", aber mit Recovered-Vermerk, d.h. die Einbindung in Exchange klappt nur, wenn man den Haken "Datenbank wurde wiederhergestellt" setzt.

    Der "Repair"-Vorgang mit /P ist nur der allerletzte Schritt, wenn gar nichts mehr geht. In der neu erstellten Datei sind alle Transaktionen verworfen und lassen sich auch nie wieder einspielen.

    Hier gibt es näheres (ist zwar alt, aber immer noch gültig bei 2010):

    https://technet.microsoft.com/de-de/library/aa997478(v=exchg.65).aspx

    In der Praxis bekommt man die Aktionen auch mit /R und anderen "Manipulationen" hin, die man, wie Evgenij schon schreibt, niemals ohne Support durchführen sollte.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Montag, 8. August 2016 08:52