Jump to content
Marco7488

Transaktionsprotokolle Exchange 2010 - Backup

Empfohlene Beiträge

Hallo Zusammen,

 

ich habe mal eine Frage bezüglich der Transaktionsprotokolle bei Exchange 2010.

 

Zur Zeit haben wir ein Backup laufen, welches sowohl die Exchange-Datenbanken als auch eine Mailbox-Sicherung durchführt.

Die Datenbanksicherung läuft nicht täglich.

 

Mir ist bekannt, dass die Transaktionsprotokolle nach einem jeweiligen FULL Backup der Datenbank in die DB geschrieben werden und abgeschnitten werden.

Aber wie sieht es in der Zeit zwischen zwei Backups aus? Ich konnte leider nirgendwo im Netz eine Aussage finden, ob die TA-Logs zwischen zwei Sicherungen auch einzeln gesichert werden sollten?

 

Meinem Verständnis nach weiß ich, dass man die Logs benötigt um eine Zeitpunktwiederherstellung durchzuführen. Ist das so korrekt?

Ausfallzeiten, Datenwiederherstellungszeiten, etc. sind bei uns irgendwie nicht sauber definiert, deswegen mache ich mir gerade Gedanken um sowas.

 

Wie macht Ihr das? Sichert ihr die Transaktionsprotokolle einzeln über den Tag? Oder läuft tägl. eine FULL Sicherung und das reicht als Datensicherung?

Bringt es etwas, die TA-Logs zwischen den Backups separat zu sichern für einen Recovery-Fall?

 

(Boardsuche, die bekannten Suchmaschinen und die Technet beantworten meine Frage irgendwie nicht zufriedenstellend :-( )

 

Beste Grüße & vielen Dank.

Marco

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

die Frage nach der Wiederhestellung sollte man erst stellen, daraus ergibt sich ein Backup - und Wiederherstellungs-Konzept.

 

Je nach eingesetzter Software (davon hast du nichts geschrieben - mit was werden die Backups gemacht?) werden die Logs auch bei inkrementellen Backups weggeschrieben und gelöscht.

 

Für weitere Empfehlungen müsstest du mal mehr zu deiner Umgebung schreiben, Glaskugel ist bei sowas nicht zielführend.

 

;)

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin Nobby,

 

danke für deine Antwort :-)

 

Also als Backupsoftware setzen wir CommVault in Version 11 ein. Die Backups laufen auf Storage, sind also relativ zügig.
Datenvolumen insgesamt: ca. 4 TB.

Die unterstützt auch inkrementelle Backups, bei denen auch die Logs gelöscht werden.

 

Die Umgebung ist eine 2-Node-DAG auf Exchange 2010.

Die Umlaufprotokollierung wurde vor über 2 Jahren aus Platzgründen aktiviert und dann erstmal so belassen.

Nun kam das Thema wegen einer Migration (eine andere Umgebung, gleicher Softwarestand) wieder auf.

(ich möchte dazu sagen, dass ich erst seit 3 Monaten in der aktuellen Firma tätig bin ;-) )

 

Nun diskutieren wir, ob wir die TA-Logs wieder aktivieren, damit wir keinen massiven Datenverlust zwischen den Sicherungen erleiden.

Daraufhin dachte ich nur, dass man die TA-Logs eventuell auch außerhalb der Exchange-Datenbanksicherungen backupen sollte, damit im DesasterRecovery Fall ein "Zeitpunkt-Restore" überhaupt möglich ist?

 

Da ich mir damit aber nicht 100% sicher bin, dachte ich mir, ich frage mal die Profis, wie ihr das handhabt. :)

 

Falls Du weitere Fragen hast, versuche ich die natürlich auch schnellstmöglich zu beantworten :)

 

Vielen Dank nochmal für deine schnelle Antwort.

 

 

Viele Grüße

Marco

bearbeitet von Marco7488

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Na wenn ihr nur alle paar Tage eine vollsicherung fährt, habt ihr im worst case „ein paar Tage“ Datenverlust. Wenn ihr alle 2h inkrementell sichert, hat man maximal 2h Datenverlust (als Beispiel). Also ist die Überlegung, die ihr anstellen müsstet, die Abwägung zwischen datenverlustmenge, datenvolumen des Backups, datenvolumen der Wiederherstellung und des handlings. Und das alles in Anbetracht der gesamtumgebung also ad, Exchange und die Redundanz durch die dag. Also Ideenanstoss sollte das reichen, den Rest müsst ihr schon selber festlegen. ;)

 

Bye

Norbert

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo Norbert,

 

vielen Dank :-)

Deine Aussagen habe ich verstanden. Ich tendiere auch zu einer Sicherung max. alle 2h, muss allerdings beobachten wie sich das Backup-Volumen entwickelt.

Ich werde mir aber ein Konzept überlegen und auch die erwähnten Denkanstöße berücksichtigen.

 

Würde es denn überhaupt etwas bringen, wenn man alle 30 Minuten nur die TA-Logs sichern würde zwischen den DB Backups um den Datenverlust im Desasterfall möglichst gering zu halten?

Wäre das für einen Desasterfall hilfreich?

 

Vielen Dank schon mal an die beiden Norberts, ihr habt mir schon sehr geholfen.

 

VIele Grüße

Marco

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hast du schonmal einen Test Restore gemacht und weißt was du dazu brauchst?

Evtl. auch einen Point-in-Time Restore? Dafür brauchst du nämlich das Backup der TA-Logs.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

also ... mag ja sein, dass das bei euch anders ist, aber derart hoch aufgelöste Datensicherungen (zwei Stunden ... 30 Minuten ... was kommt denn da noch?!) kenne ich nur von ERP-Systemen und sowas, aber nicht von Mailsystemen. Seid ihr wirklich sicher, dass das passt? (Und wie soll das mit einer aktiven Umlaufprotokollierung zusammengehen? Irgendwie fühle ich mich gerade etwas verlassen ...)

 

Meistens, wenn Kunden sowas äußern, sind das "Bauchwerte", aber es gibt keine belastbaren Anforderungen dazu.

 

Gruß, Nils

bearbeitet von NilsK
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Zunächst vielen Dank an alle Antwortgeber :)

 

 

Hast du schonmal einen Test Restore gemacht und weißt was du dazu brauchst?

Evtl. auch einen Point-in-Time Restore? Dafür brauchst du nämlich das Backup der TA-Logs.

Hallo Dukel,

 

Tatsächlich ist meine Exchange-Zeit etwas her. Ein Restore-Szenario habe ich noch nicht gestestet. Das werde ich wohl aber mal als nächstes angehen.

Danke :)

 

 

 

Moin,

 

also ... mag ja sein, dass das bei euch anders ist, aber derart hoch aufgelöste Datensicherungen (zwei Stunden ... 30 Minuten ... was kommt denn da noch?!) kenne ich nur von ERP-Systemen und sowas, aber nicht von Mailsystemen. Seid ihr wirklich sicher, dass das passt? (Und wie soll das mit einer aktiven Umlaufprotokollierung zusammengehen? Irgendwie fühle ich mich gerade etwas verlassen ...)

 

Meistens, wenn Kunden sowas äußern, sind das "Bauchwerte", aber es gibt keine belastbaren Anforderungen dazu.

 

Gruß, Nils

 

Hallo Nils,

 

die Umlaufprotokollierung soll deaktiviert werden, damit wieder ganz gewöhnlich die Transaktionsprotokolle geschrieben werden.

 

Eine belastbare Anforderung in dem Sinne gibt es nicht, sondern lediglich die Aussage "geringster Datenverlust" da Mail als Businesskritisch angesehen wird.

Ich finde es schwer, abzuschätzen welcher Rhytmus für ein Datenbankbackup ausreicht im Exchange-Bereich. Natürlich weiß ich, dass ein Backup regelmäßig durchgeführt werden soll und für die Wiederherstellungszenarien Anforderungen definiert werden sollten, nur scheinbar gibt es die zur Zeit nicht. :confused:

 

Die Frage die sich mir stellt ist, wie sichere ich die Änderungen zwischen zwei Backups?

 

 

Vielen Dank bisher :)

 

Viele Grüße

Marco

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Du hast eine Redundanz der Exchange Daten. Also ist der Ausfall eines Servers erstmal „unkritisch“. Wenn du also verlustängste hast, sollte das das spezifiziert werden. Viele sichern hauptsächlich weil sie Angst haben der User löscht etwas und dann müssten sie es wiederherstellen. Das ist bei mir Jahre her, dass ich aus diesem Grund schonmal ein restore fahren musste. Wenn ihr vom Totalverlust ausgeht, bliebe ja die Frage, warum man den nicht verhindert.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

wie immer gilt auch hier: Man plant vom Restore her, jedes Szenario ist separat zu betrachten, und ebenso ist jede Applikation separat zu betrachten. Was für eine Applikation passt, muss für die nächste noch lange nicht gelten.

 

Exchange-Umgebungen baut man völlig anders als etwa einen Dateiserver. Und man baut Exchange heute auch völlig anders als vor ein paar Jahren. Die Redundanzen, die Exchange mitbringt, decken bereits viele Standardsituationen ab. Für das Recovery muss man also genau planen, welche Szenarien überhaupt relevant sind und welche Methoden sich dafür eignen.

 

Es gibt Leute, die beraten sowas. :D

 

Gruß, Nils

PS. und wie immer, stimme ich Norbert zu. ;)

bearbeitet von NilsK
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Du hast eine Redundanz der Exchange Daten. Also ist der Ausfall eines Servers erstmal „unkritisch“. Wenn du also verlustängste hast, sollte das das spezifiziert werden. Viele sichern hauptsächlich weil sie Angst haben der User löscht etwas und dann müssten sie es wiederherstellen. Das ist bei mir Jahre her, dass ich aus diesem Grund schonmal ein restore fahren musste. Wenn ihr vom Totalverlust ausgeht, bliebe ja die Frage, warum man den nicht verhindert.

 

 

Moin,

 

wie immer gilt auch hier: Man plant vom Restore her, jedes Szenario ist separat zu betrachten, und ebenso ist jede Applikation separat zu betrachten. Was für eine Applikation passt, muss für die nächste noch lange nicht gelten.

 

Exchange-Umgebungen baut man völlig anders als etwa einen Dateiserver. Und man baut Exchange heute auch völlig anders als vor ein paar Jahren. Die Redundanzen, die Exchange mitbringt, decken bereits viele Standardsituationen ab. Für das Recovery muss man also genau planen, welche Szenarien überhaupt relevant sind und welche Methoden sich dafür eignen.

 

Es gibt Leute, die beraten sowas. :D

 

Gruß, Nils

PS. und wie immer, stimme ich Norbert zu. ;)

 

Vielen Dank Euch :)

 

Ich werde mir die Aussagen zu Herzen nehmen und mir noch  mal richtig Gedanken dazu  machen und die verschiedenen Szenarien durchgehen.

Vielen Dank :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

×