Exchange 2013 ohne Backup betreiben

Es gibt bei Exchange 2010 und 2013 einige Design-Punkte, die bei Kunden und Kursteilnehmern immer wieder Skepsis hervorrufen. Zu einem davon möchte ich heute schreiben: Exchange Native Data Protection – der Betrieb ohne traditionelles Backup!

Welche Gründe gibt es  überhaupt, in dieser Hinsicht auf 3rd Party Software zu verzichten?

• Komplexität: Backup-Software ist oft kompliziert im Aufbau und Betrieb
• Kosten: Normalerweise müssen Agenten für Applikationen wie Exchange, SharePoint etc. extra bezahlt werden
• Abhängigkeiten: Upgrade auf neuere Versionen von Exchange ist von der Unterstützung durch die Backup-Software abhängig

Zugegeben, Native Data Protection ist nicht für jede Umgebung sinnvoll. In folgenden Fällen sollte diese Lösung nicht erwogen werden:

• Weniger als 3 HA-Kopien der Datenbanken vorhanden
• Es gibt keine klaren Vorgaben bezüglich RTO (Recovery Time Objective), RPO (Recovery Point Objective) und Retention Time

Komponenten der Lösung

Die Idee hinter Native Data Protection ist es, die Daten gar nicht auf ein Backup-Medium auszulagern, sondern für die erforderliche Zeit in der Datenbank zu belassen. Ein Restore bedeutet damit eine reine Verschiebung innerhalb dieser Datenbank, was sehr kurze Reaktionszeiten ergibt.

Natürlich wird dadurch das Datenvolumen grösser. Zusammen mit der oben erwähnten Anforderung, mindestens 2 weitere HA-Kopien zu haben und wie wir später sehen werden auch noch 1 oder 2 Lagged Copies, wird der Storage ein wichtiger Faktor. Hier ist es wichtig, mehrere unabhängige SANs zu verwenden oder besser noch lokale Disks in den Servern – ab 3 Kopien ist auch JBOD sinnvoll.

Um die Objekte in der Datenbank zu halten, auch wenn der Benutzer sie vermeintlich löscht, gibt es 2 Optionen:

• Single Item Recovery (SIR) kann pro Mailbox aktiviert werden. Gelöschte oder sogar hart gelöschte Objekte werden dabei in einen versteckten Unterordner von Deleted Items verschoben und für die definierte Retention Time von bis zu 30 Tagen aufbewahrt
• In-Place Hold macht prinzipiell dasselbe, aber ohne zwingende Retention Time

Eine weitere Komponente habe ich bereits erwähnt: die Lagged Copy. Dabei werden wie auch bei HA-Kopien die Transaction Logs vom Server mit der aktiven Datenbank zu den passiven kopiert. Im Gegensatz zu diesen werden die Logs aber nicht in die passive Datenbank eingespielt, bis die Lag Time abgelaufen ist, die maximal 14 Tage betragen kann. Gelöschte Objekte können wiederhergestellt werden, indem die Datenbank und alle Transaction Logs bis zum gewünschten Zeitpunkt wegkopiert und mittels Restore DB oder 3rd Party Software (zum Beispiel VEEAM Explorer for Exchange) zugänglich gemacht werden.

Konfiguration

SIR wird pro Mailbox in der Exchange Management Shell konfiguriert:

In-Place Hold wird ebenfalls pro Mailbox in der Shell oder EAC aktiviert:

Alternativ kann auch noch das aus Exchange 2010 bekannte Feature Litigation Hold verwendet werden. Empfohlen ist aber die neuere Variante:

Eine Lagged Copy kann seit Exchange 2013 SP1 ebenfalls in der EAC konfiguriert werden:

Funktionsweise

In den folgenden Screenshots sehen wir die Mailboxen von 2 Benutzern: TestUser1 ohne SIR und TestUser2 mit SIR. Beide haben vom Administrator heute 2 Mails bekommen, wovon eines soft- und das andere hard-deletet wird:

Soft-deletete Mails werden in den Ordner Deleted Items verschoben. Werden sie daraus gelöscht, können sie für die Dauer der Retention Time aus Recover Deleted Items durch den Benutzer selbst wiederhergestellt werden. Hard-deletete Objekte umgehen den Ordner Deleted Items, können aber ebenfalls aus Recover Deleted Items zurückgeholt werden.

Werden die Objekte aus Recover Deleted Items gelöscht, wie im nächsten Screenshot, werden sie ohne SIR definitiv aus der Datenbank entfernt:

Mit MFCMAPI sehen wir, wo das hard-deletete Mail beim Benutzer mit SIR gelandet ist: Im Ordner Purges unter Recoverable Items. Daraus kann ein Administrator alle vom Benutzer gelöschten Items zurückholen.

Kommen wir nun zum Handling von Lagged Copies. Der Benutzer ohne SIR hat seine Kopie des Mails komplett aus der Datenbank gelöscht. Unsere Lagged Copy hat aber den Stand von vor 3 Tagen – das Mail war damals noch vorhanden. Wir stoppen also die Replikation der Kopie:

Danach kopieren wir die Datenbank und alle benötigten Logs in ein Restore LUN. Achtung: Die Checkpoint-Datei NICHT mitkopieren.

Im Dump des Headers der Datenbank sehen wir, dass sie in einem Dirty-Shutdown-Status ist:

Wir spielen jetzt also alle Logs im Restore-Verzeichnis in die Datenbank. Damit stellen wir einen konsistenten Zustand der DB zu exakt dem gewünschten Zeitpunkt her.

Die Datenbank ist jetzt im Status Clean Shutdown und kann als Recover DB gemountet werden:

Schliesslich kann der Inhalt von einzelnen Mailboxen in die originale oder eine beliebig andere Mailbox wiederhergestellt werden.

In diesem Beispiel wurden die Objekte in den Ordner Restore der Mailbox des Administrators kopiert, der das benötigte Mail nun versenden oder kopieren kann.

Ich hoffe, ich konnte in diesem Artikel zeigen, wie einfach mit Bordmitteln Backups ersetzt werden können.