Dies ist der erste Teil einer Exchange Backup und Restore Serie.
Der zweite Teil folgt in kürze.
Datensicherung ist in Exchange 2010 ein umfangreiches Thema. Für die Widerherstellung von einzelnen Elementen (Mails, Kontakte…) bietet sich z.B. der Dumpster an, dazu aber ein anderes Mal mehr. In diesem Beitrag möchte ich Datensicherung im klassischen Sinn behandeln, also Backup von Servern und Datenbanken.
Backup Software
Exchange 2010 verwendet den Windows eigenen VSS Dienst, kann also nur mit einer Backup Applikation gesichert werden die diesen Service unterstützt. Für Tests eignet sich natürlich Windows Backup von Server 2008R2, will man das Ganze in einer größeren Umgebung betreiben empfiehlt sich der Data Protection Manager.
System State Backup
Jeder Server sollte regelmäßig gesichert werden, dazu gehört ein Backup des System Volumes und des System State. System State Backups enthalten die Registry sowie die Boot Dateien und COM+ Class Registration Datenbank. Je nach installierter Serverrolle (ADDS, IIS…) werden weitere Informationen gesichert.
Mit einem System State Backup kann der Zustand des Servers (und der installierten Rollen/Applikationen) zum Zeitpunkt des Backups widerhergestellt werden.
Single Server Backup
Wenn alle Rollen auf einem Server installiert sind müssen der System State sowie die Volumes mit den Datenbanken und Logdateien gesichert werden.
Backup von Client Access Servern
Auf CA Servern befinden sich keine Daten die speziell gesichert werden müssen, diese Serverrolle sollte ohnehin ausfallsicher designed werden, da der Clientzugriff im Fehlerfall sonst nicht mehr möglich ist. Die Konfiguration kann aus dem System State Backup widerhergestellt werden.
Allerdings sollte man nicht vergessen das IIS Log Verzeichnis (C:\inetpub\logs\LogFiles\W3SVC1) zu überwachen bzw. alte Logs kontinuierlich zu löschen.
Backup von Hub Transport Servern
Es sind keine Daten auf Hub Transport Servern vorhanden ohne die eine Exchange Umgebung nicht widerhergestellt werden könnte, allerdings ist es für spätere Analyse Sinnvoll die Message Tracking Logs sowie die Protocol Logs zu sichern. Diese befinden sich im Exchange Installationsordner unter \Transportroles\Logs und können einfach auf File-Ebene gesichert werden.
Die Konfiguration des Transport Servers wird im Active Directory gespeichert, auch diese Serverrolle sollte ausfallsicher designed werden.
Backup von Edge Transport Servern
Edge Transport Server speicher die Konfiguration im Active Directory, im Fehlerfall kann man einfach den Server neu aufsetzen und die EdgeSync neu einrichten. Alternativ kann man mit Cloned Configuration arbeiten, also die Konfiguration exportieren und auf dem neuen Server wieder importieren, dazu mehr in einem anderen Beitrag. Die Logs die auf Hub Transport Servern gesichert werden sollten befinden sich bei Edge Transport Servern an der selben Stelle und sollten aus dem selben Grund gesichert werden.
Backup von Unified Messaging Servern
Die für die Konfiguration relevanten Informationen werden in der Active Directory gespeichert, einzig die Audio Prompts können auf File- Ebene gesichert werden, diese befinden sich im Exchange Installationsordner unter \UnifiedMessaging\Prompts.
Backup von Mailbox Servern
Auf den Servern auf denen die Mailbox Rolle installiert ist befinden sich die Datenbank und Transaction Log Files, diese müssen auf jeden Fall gesichert werden. Wird eine Sicherung mit Windows Backup durchgeführt muss jeweils das gesamte Volume auf dem die Datenbank bzw. Log Files liegen ausgewählt werden. Von diesen Volumes muss ein “Full VSS" Backup gemacht werden, nur so merkt Exchange dass die Daten gesichert wurden und löscht die entsprechenden Log Files.
Backup der Active Directory
Exchange Server speichert viele Daten und Einstellungen in der Active Directory und ist extrem Abhängig von einer funktionstüchtigen Umgebung. Daher sollten natürlich auch Domain Controller regelmäßig gesichert werden. Hierfür reicht ein System State Backup aus, dieses enthält alle Daten/Einstellungen der AD.
Backups und DAG
Sind die Exchange Server die gesichert werden sollen Mitglieder einer Database Availability Group (DAG) ändern sich die Gründe für eine Datensicherung. Da es bis zu 16 Kopien einer Mailbox innerhalb der DAG geben kann, ist das Backup nicht mehr der einzige Ausweg wenn die aktive Kopie der Datenbank offline geht. Fällt ein Mitglied einer DAG aus, werden die Datenbanken die auf diesem Server aktiv waren vom Server mit der nächst-höheren Priorität übernommen (natürlich muss es eine Kopie der Datenbank dort geben). So ist man bei einem Ausfall eines Mailboxservers gut gerüstet, allerdings kann es auch zu einem Datenbankfehler kommen, dafür gibt es aber folgende alternative zum Backup.
Datenbank Kopien werden standardmäßig aktuell gehalten, d.h. eine Änderung wird sofort an alle Mitglieder der DAG repliziert. Man kann allerdings eine Verzögerung (ReplayLagTime) konfigurieren und so z.B. auf einem Server ältere Versionen der Datenbanken halten. Tritt nun ein Datenbankfehler auf, kann die ältere Datenbank verwendet werden ohne umständliches Restore von Tape oder woher auch immer.
Ein weiterer Effekt des Backups ist das löschen der Log Files, sollte man also auf regelmäßige Backups verzichten muss man wohl oder übel Circular Logging für die Datenbanken aktivieren um ein überlaufen der Festplatten zu verhindern.
Diese neue Möglichkeit der Hochverfügbarkeit bringt sicher viele Vorteile, jedoch sollte man meiner Meinung nach nicht auf ein Backup verzichten. Ich empfehle regelmäßige System State Backups von allen Servern. Die Datenbanken würde ich auf jeden Fall auch sichern und das Backup und Restore Szenario ausreichend testen und dokumentieren!
Soweit mal zum Thema Backup, viele Grüße
tom