none
Exchange 2010: Protokolle werden nicht gelöscht trotz Sicherung RRS feed

  • Frage

  • Hallo zusammen,

    ich habe hier ein etwas wirres Problem. Wir sitze hier vor zwei Exchange Server 2010 SP2 ohne Rollup-Packages in einer DAG. Als Sicherungssoftware wurde Backup-Exec eingesetzt. Bis vor zwei Wochen hat es mit der Sicherung keine Probleme gegeben, allerdings hat zu diesem Zeitpunkt die Sicherung gestreikt. Lange Rede kurzer Sinn, die Transactions-Logs sind seit diesem Tag logischerweise ständig gestiegen und die Festplatten entsprechend vollgelaufen (Shit happens). Nachdem die Festplatten entsprechend vergrößert wurden und die Exchange-Server ordnungsgem. ihren Dienst wieder aufgenommen haben, wurde der Server mit Windows bordeigenen Mitteln gesichert um die Situation zu entschärfen. Hierzu wurde entsprechend des Artikels hier (Artikel auf MSExchange.org) zu rate gezogen. Das Backup verlief reibungslos und ist ohne Fehler abgeschlossen worden - allerdings sind die Transaction-Logs immer noch da. Daraufhin wurde sogar ein Komplett-Backup des Servers durchgeführt worden - auch ohne Probleme und Meldungen -> aber die Logs sind immer noch da.

    Daraufhin habe mir die Eigenschaften der Datenbank angesehen und festgestellt, dass er das Update nicht "mitbekommt"

    Um das Problem in den Griff zu bekommen, gibt es denke ich zwei Möglichkeiten

    1. Das Backup wird erkannt und die Transaktions-Logs werden automatisch gelöscht
    2. Man löscht die Transaktions-Logs manuell

    [Fragen hierzu]

    Hat hier jemand vielleicht noch eine Idee, warum die Datenbank, den Backup-Job nicht wahrnimmt?

    Wie führe ich die zweite Variante am Sichersten durch?

    Idee hier wäre DB offline schalten, Dienst stoppen und logs manuell löschen, oder eine neue Datenbank anlegen -> migrieren -> und die alten Reste löschen.

    Vielen Dank für eure Mühen im Voraus.

    Alex

    Freitag, 11. Mai 2012 12:14

Antworten

  • Moin,

    das ist aus der Ferne ohne die notwendigen Werkzeug nur Spekulation, aber:

    Hat hier jemand vielleicht noch eine Idee, warum die Datenbank, den Backup-Job nicht wahrnimmt?

    Vermutlich sind die internen Zähle mit Voll- und inkrementiellen Sicherungen durcheinander gekommen. Erschwernd kommt hinzu, dass Du das Backup-Programm "gewechselt" hast.

    Wie führe ich die zweite Variante am Sichersten durch?

    Idee hier wäre DB offline schalten, Dienst stoppen und logs manuell löschen, oder eine neue Datenbank anlegen -> migrieren -> und die alten Reste löschen.

    Genau so. Du kannst von der Datenbank ALLES löschen, bis auf die EDB-Datei und den Ordner "CatalogData" (das ist der Suchindex). Also alle LOG, JRS, TMP und vorallem auch die CHK-Datei.

    WICHTIG:
    1. Nach dem Stoppen des Dienstes mit ESEUTIL /MH NAME_DER_EDB.EDB nachschauen, ob der Status auf "Clean Shutdown" steht -> dann sind keine Log-Dateien mehr erforderlich.
    2. Nach dieser Aktion SOFORT ein eines Voll-Backup machen, da die alten Backups eventuell nicht mehr konsistent und daher unbrauchbar sind
    3. Das geht nicht mit DAG-Datenbanken. In diesem Fall muss die DAG vorher aufgelöst und danach neu angelegt werden.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Freitag, 11. Mai 2012 12:58
  • Hi,

    der /die häufigste Fehler bei der Verwendung der Windows eigenen Back-Software.

    1) Nur auf dem aktiven Knoten werden die Logs richtig entfernt.

    2) Die falsche Option ist ausgewählt in den erweiterten Optionen der Sicherung:

    Achtung:
    Transaktionsprotokolle werden erst dann abgeschnitten, wenn sie in den "erweiterten Optionen" auch eine "Vollsicherung" auswählen. Per Default ist hier ein "COPY"-Backup aktiv.

    siehe http://www.msxfaq.de/admin/backupwinbackup.htm

    hth und schönes Wochenende.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/ Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer"; if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. If a answer or remark helps you to cope with your problem you can "mark it as helpful".

    Freitag, 11. Mai 2012 12:58
    Moderator

Alle Antworten

  • Moin,

    das ist aus der Ferne ohne die notwendigen Werkzeug nur Spekulation, aber:

    Hat hier jemand vielleicht noch eine Idee, warum die Datenbank, den Backup-Job nicht wahrnimmt?

    Vermutlich sind die internen Zähle mit Voll- und inkrementiellen Sicherungen durcheinander gekommen. Erschwernd kommt hinzu, dass Du das Backup-Programm "gewechselt" hast.

    Wie führe ich die zweite Variante am Sichersten durch?

    Idee hier wäre DB offline schalten, Dienst stoppen und logs manuell löschen, oder eine neue Datenbank anlegen -> migrieren -> und die alten Reste löschen.

    Genau so. Du kannst von der Datenbank ALLES löschen, bis auf die EDB-Datei und den Ordner "CatalogData" (das ist der Suchindex). Also alle LOG, JRS, TMP und vorallem auch die CHK-Datei.

    WICHTIG:
    1. Nach dem Stoppen des Dienstes mit ESEUTIL /MH NAME_DER_EDB.EDB nachschauen, ob der Status auf "Clean Shutdown" steht -> dann sind keine Log-Dateien mehr erforderlich.
    2. Nach dieser Aktion SOFORT ein eines Voll-Backup machen, da die alten Backups eventuell nicht mehr konsistent und daher unbrauchbar sind
    3. Das geht nicht mit DAG-Datenbanken. In diesem Fall muss die DAG vorher aufgelöst und danach neu angelegt werden.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Freitag, 11. Mai 2012 12:58
  • Hi,

    der /die häufigste Fehler bei der Verwendung der Windows eigenen Back-Software.

    1) Nur auf dem aktiven Knoten werden die Logs richtig entfernt.

    2) Die falsche Option ist ausgewählt in den erweiterten Optionen der Sicherung:

    Achtung:
    Transaktionsprotokolle werden erst dann abgeschnitten, wenn sie in den "erweiterten Optionen" auch eine "Vollsicherung" auswählen. Per Default ist hier ein "COPY"-Backup aktiv.

    siehe http://www.msxfaq.de/admin/backupwinbackup.htm

    hth und schönes Wochenende.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/ Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer"; if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. If a answer or remark helps you to cope with your problem you can "mark it as helpful".

    Freitag, 11. Mai 2012 12:58
    Moderator
  • Hallo Alexander,

    die Gründe für das nicht korrekte löschen von Logs kann verschiedene Ursachen haben.

    Schau zunächst mal in Dein Application LOG des Servers ob dort Fehler zur Sicherung erkennbar sind. (z.B. Event ID 2137 oder ähnliches)

    Der Ansatz das Ganze mit der Windows Server Sicherung durchzuführen ist erstmal ok, allerdings können auch nur aktive Kopien gesichert werden.

    Schau dazu mal hier : http://exchangeserverpro.com/event-id-2137-windows-server-backup-completed-warnings-exchange-2010-mailbox-server

    Im englischen Forum gab es diverse Threads in welchen die Admins Probleme mit dem Search Indexer hatten, auch ein Support Call eines Users führte zu diesem Punkt:

    http://social.technet.microsoft.com/Forums/en-US/exchangesvravailabilityandisasterrecovery/thread/dcf3a54b-ac64-46de-8667-d838091a8715

    Hier noch was generelles zum Thema Datenbanken, hier sind auch die Informationen wann Logfiles gelöscht werden dokumentiert:

    http://technet.microsoft.com/en-us/library/dd335158.aspx


    Grüße, Christoph

    Freitag, 11. Mai 2012 13:03
  • Hallo Christoph,

    das Applikation Log sieht erstmal nicht berauschend aus und keine Vorkomnisse die Auffällig wären. Das mit den aktiven Kopien ist klar. Die Links habe ich mir angesehen und sind hilfreich und bringen ein wenig Licht ins dunkle. Danke dafür

    Gruß Alex

    Freitag, 11. Mai 2012 18:45
  • Ich habe das Vorgehen probiert indem ich die Maschine in die Testumgebung geklont habe und sie funktioniert.

    Freitag, 11. Mai 2012 18:48
  • Hallo Walter,

    ich habe mir den Backup-Job angesehen und es war tatsächlich die Vollsicherung nicht ausgewählt. Ich versuche die Sicherung mit dieser Option nochmals und werde hier dann weitere Infos geben, ob dies zum Erfolg geführt hat.

    Gruß Alex

    Freitag, 11. Mai 2012 18:50
  • Hallo Walter,

    wollte nur noch abschließend berichten, dass der Tip richtig war. Es hat auch mit dieser Variante funktioniert.

    Danke für Eure Mühen

    Alex

    Samstag, 12. Mai 2012 05:56