Exchange 2010 Sichern

Seit Exchange 2010 hat Microsoft den kompletten Wechsel zu Schattenkopien vollzogen und die Sicherung per "Streaming" ist nicht mehr möglich, zumindest offiziell. Sie müssen also die Exchange Datenbanken nun zwingend über Schattenkopien sichern.

Eine Streaming-Funktion gibt es aber immer noch. Dies sehen Sie z.B. bei einem "Seeding" einer Kopie im Cluster, welcher über die Streaming-API sich eine Kopie der Datenbank von einem Quellserver holt.

Dies ist aber für ihre Datensicherung keine Lösung, so dass Sie ein kompatibles Backupprodukt einsetzen müssen.

Da Windows Server Backup als "Ziel" eine VHD-Datei anlegt und VHD-Dateien ein 2 TB Limit haben, darf ein Backup aktuell nicht größer als 2 TB sein. Wer also per VSS die komplette Quelldisks sichern möchte, muss sicherstellen, dass diese <2TB ist. Größere Disks können gesichert werden, wenn Sie dann nur Verzeichnisse auswählen.

Sicherung mit Bordmittel

Mit Exchange 2010 ist es nun aber auch erstmals wieder mit Bordmitteln möglich, eine Exchange Datenbank zu sichern. Bei Exchange 2007 mussten wir bis Exchange 2007 Servicepack 2 warten, bis das Windows Backup endlich auch per VSS eine Exchange Datenbank korrekt sichern kann. Sie müssen in dem Fall einfach nur die entsprechende Partition mit auswählen und bei der Sicherung können Sie ganz kurz erkennen, dass die Daten mit gesichert werden.

Im Eventlog ist dann zu sehen, dass der Schattenkopiedienst auch den Exchange VSS-Writer anstößt:

Ich rate ihnen natürlich dazu, ein für Exchange 2010 kompatibles Backupprogramm einzusetzen, was ihren Anforderungen besser entspricht als ein Windows Backup in eine VHD-Datei auf einer anderen Festplatte

Dennoch wird es auch mit Exchange 2010 vermutlich einige Tage dauern, bis alle Hersteller mit Exchange 2010 harmonieren. Sogar der Microsoft eigene Data Protection Manager 2007 kann zum Release-Datum noch nicht Exchange 2010 sichern. Zudem hat das Windows Backup auch immer den großen Vorteil, dass es eben sehr schnell nachinstalliert ist (Windows 2008 Feature) und ein Restore damit auch sehr schnell starten kann. Per Default "sichert" Windows Server Backup eine "Kopie", d.h. die Transaktionsprotokolle werden nicht abgeschnitten und ein anderes aktiven Backup wird in seinem Rhythmus nicht gestört

Durch die "Zeitplanungsfunktion" kann das Windows Backup sogar sehr schnell den Exchange Server z.B. auf eine andere lokale oder Netzwerkfestplatte sichern. Wenn immer mehr Firmen sowieso nur zwei oder drei Generationen einer Sicherung aufheben, dann kann es durchaus hinreichend sein, Exchange mit Bordmitteln auf einen Netzwerkspeicher zu schreiben und langfristige Ablagen über eine separate Archivlösung bereit zu stellen.

Sicherung beim DAGs

Wer einen Exchange 2010 Cluster (Genauer eine Database Availability Group) betreibt, kann mit Bordmitteln sehr einfach die Kopie als Quelle für eine Sicherung heran ziehen. Sie können nämlich die Replikation sehr einfach mal "pausieren".

Suspend-MailboxDatabaseCopy DB1\SRV14 -SuspendComment "Datenbankreplikation wg Backup pausieren" -Confirm:$false

Mit dem Hilfsprogramm "VSSADMIN" von Windows 2008 können Sie per Kommandozeile eine Schattenkopie anfertigen lassen.

vssadmin create shadow /For=C:\mountpoints\db01
vssadmin create shadow /For=C:\mountpoints\db01_logs

Die so angerfertigte Kopie kann nun für weitere Schritte herangezogen werden. Wenn Sie mit ESEUTIL prüfen., welche LOG-Dateien sie für die Herstellung der Konsistenz erfordern, dann können Sie einfach mit sichern und später die Datenbank mit einem Roll Forward sogar "konsistent" bringen

eseutil.exe /r /e00 /a

Vergessen Sie danach aber nicht die angehaltene Replikation der Datenbanken wieder "online" zu nehmen

Resume-MailboxDatabaseCopy DB1\EX3

Wie beim Exchange 2007 CCR, bei dem die passive Datenbank gesichert werden konnte, ist es mit einem "richtigen" Backupprodukt Exchange egal, welche Instanz der DAG letztlich gesichert wird, da jede ja eine gültige Datenbank darstellt.

For backup operations, if the Exchange 2010 databases being backed up are configured in a DAG, the backup application can better prevent interference between the snapshot and the active server’s performance by taking the snapshot on one of the inactive database copies. Because the database copies are für the most part synchronized, the backup application can take snapshots from different copies of the database, and later reconstruct it from the pieces.
Exchange Database Mobility  http://msdn.microsoft.com/en-us/library/dd877016.aspx

"virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences für a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported."
Quelle: http://technet.microsoft.com/en-us/library/aa996719.aspx

Sicherung über Replikation

Mit der Exchange 2010 DAG ist es sogar möglich, bis zu 16 Server in einem Verbund zu betreiben und eine Datenbank auf bis zu 15 weitere Server zu verteilen. Da man jede Datenbank auch noch zeitlich verzögert nachlaufen lassen kann, könnten Sie sogar komplett ohne klassisches Backup auskommen. Was unterscheidet denn schon ein Backup, welches eine Kopie einer Datenquelle auf einen anderen Speicher und Server überträgt von einer Replikation der Datenbank auf einen anderen Exchange Server. Und tatsächlich unterstützt Microsoft solche Konfigurationen, bei denen gar kein klassisches Backup mehr eingesetzt wird.

Übrigens hat Microsoft diese Replikationsschnittstelle auch für Drittanbieter geöffnet.

Can I use a 3rd party replication tool to replicate the databases in the DAG?
By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases between servers in the DAG. If you are using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the DAG in third party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter, but note that Once this mode is enabled, it cannot be disabled.
Quelle: Demystifying Exchange 2010 database availability group (DAG)
http://blogs.technet.com/mbaher/archive/2009/07/27/demystifying-exchange-2010-database-availability-group-dag.aspx

Ich bin mal gespannt, ab wann Dritthersteller nicht mehr per VSS sichern, sondern Exchange kontinuierlich auf ihren eigenen Datenpool übertragen und dort die Protokolldateien weiter schreiben.

Restore einer Exchange 2010 Datenbank

Wer sichert, will natürlich auch wieder herstellen. Auch das ist per Windows Server Backup möglich. Nur hat natürlich Exchange 2010 erst mal keine Unterstützung durch die GUI. Sie müssen beim Restore also erst mal unterscheiden:

  • Restore an die produktive Datenbank
    In dem Fall muss die produktive Datenbank natürlich "down" sein und Sie restaurieren die Daten direkt an die Quelle zurück. Durch ein Einsatz einer DAG wird dieser Fall aber immer weniger angefragt.
  • Restore in die Recovery Database
    Interessanter ist die Wiederherstellung einer Mailbox, was recht einfach über die Recovery Datenbank geht. Nur gibt es dazu keine GUI

Ich beschreibe hier also kurz die Schritte für die Wiederherstellung einer Datenbank an eine "andere Stelle":

  • Einrichten einer Recovery Database
    Dies ist nicht über die Exchange 2010 SP1 GUI möglich sondern nur per PowerShell. Ist aber sehr einfach. Der Dateiname der EDB-Datei kann frei gewählt werden.

New-MailboxDatabase -Recovery -Name RDB2 -Server MBX1 -EdbFilePath "C:\Recovery\RDB2\RDB2.EDB" -LogFolderPath "C:\Recovery\RDB2

  • Wiederherstellung der Daten.
    Nun können Sie die Daten über Windows Server Backup zurück holen. Sie müssen aus dem Backup die EDB-Datei und die dazu gehörigen Protokolldateien restaurieren.
  • Kontrolle der Datenbank
    Dieser Schritt ist nicht zwingend aber ich mache ihn dennoch. Mit ESEUTIL /MH schaue ich mir den Header der gerade restaurierten Datenbank an. Die Datenbank wird zwar "Dirty Shutdown" sein aber mir zugleich auch anzeigen, welche Logdateien benötigt werden.

ESEUTIL /mh lw:\pfad\datenbank.edb

  • Datenbank Konsistent machen
    Wenn ihr Backup nicht "Exchange Aware" ist und bei der Wiederherstellung nicht selbst schon die Datenbank konsistent gemacht hat, dann wird dies nun nachgeholt. Achtung: bei einem Restore an einen anderen Ort müssen Sie ESEUTIL unterstützen und ihm den Pfad zur Datenbank angeben, da es ansonsten den Pfad nutzt, der in den Protokolldateien hinterlegt ist, z.B.

ESEUTIL /R e00 /d

  • Erneute Kontrolle der Datenbank
    Nun schaue ich nach, ob die Datenbank wirklich "clean" ist.

ESEUTIL /mh lw:\pfad\datenbank.edb

  • Datenbank umbenennen und Reste löschen
    Wenn die Datenbank "Clean" ist, dann können nun alle restaurierten Protokolldateien, CHK-Dateien etc. gelöscht werden. Zudem können Sie nun den Namen der Datenbankdatei auch ändern, wenn er nicht mit der Angabe oben beim "New-Mailboxdatabase" übereinstimmt.
  • Mounten der Datenbank
    Und dann können Sie die Datenbank per GUI oder PowerShell wieder mounten. Das sollte problemlos möglich sein.
  • Restore der Mailbox oder Teile davon
    Die Wiederherstellung der Inhalte dieser Recovery Database ist dann wieder Aufgabe der PowerShell.

Restore-Mailbox -Identity Scott -RecoveryDatabase RDB1
Restore-Mailbox -Identity Scott -RecoveryDatabase RDB1 -RecoveryMailbox John -TargetFolder Recovery
Get-Mailbox -Database DB1 | Restore-Mailbox -RecoveryDatabase RDB1

Weitere Informationen finden Sie in der Technet:

Weitere Links