Exchange Backup extrem

Diese Seite beschreibt alternativen Überlegungen zur Sicherung und Wiederherstellung von Exchange. Dies ist eine Kurzfassung ohne Anspruch auf Vollständigkeit und erst recht keine Anleitung. Diese Optionen sind für "Enterprise Kunden" zu evaluieren. Allen "normalen" Exchange Administratoren empfehle ich ein ordentliches Online Backup (Siehe Exchange Backup und Restore und NTBACKUP)

Unterstützung durch Net at Work:
Sie können mich gerne mit einer Konzeption für ihre individuelle Backupanforderungen beauftragen. Speziell wenn es um SAN, Library, Hochverfügbarkeit und kurze SLAs geht, können aus verschiedenen Bausteinen und natürlich einer entsprechenden Schulung der Mitarbeiter leistungsfähige Lösungen entstehen.

"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

Grundlagen

Ehe ich ihnen ein paar Optionen für Sicherungen vorstelle, sollten wir uns ein paar Dinge klar machen:

  • Ein Backup ist immer erforderlich
    Wer nur eine Instanz seiner Daten hat, handelt nicht nur fahrlässig. Und es sollte auch nicht nur eine "Kopie" eines Datenbestandes vorhanden sind.
  • Intervall des Backups
    Klar ist eine regelmäßige Erstellung einer Sicherung. Exchange DAG-Replikationen sind ein Extrembeispiel, weil die Datenbanken quasi kontinuierlich auf andere Server repliziert werden. Relevant ist hier der RPO (Recovery Point Objective), d.h. wie viele Daten im Falle maximal verloren gehen dürften. Dies gibt die maximale Zeit zwischen zwei Sicherungen vor.
  • Backup mit minimalem Einfluss auf den Betrieb
    Auch Sicherungen belasten das System aber diese Auswirkungen sollten gering sein. Daher muss überlegt werden, ob z. B. jedes Mal die komplette Datenmenge kopiert und damit Disk-IO, PCI-Bus-Belegung, SAN-Belastung und Netzwerkverkehr "kosten" oder ob differenzielle oder inkrementelle Sicherungen eignen. Es gibt verschiedene Optionen um die Wege zu optimieren, verkürzen oder zu umgehen oder die Datenmengen zu reduzieren.
  • Restore mit maximalem Speed
    Sollte dann einmal der Fall eintreten, dass eine Wiederherstellung erforderlich ist, dann muss das Restore natürlich mit maximaler Geschwindigkeit erfolgen können.

Die Datenmengen in Exchange und anderen Systeme wachsen von Tag zu Tag. Zeitgleich werden die Ansprüche an die Wiederherstellung und Verfügbarkeit immer höher, so dass das klassische "Vollbackup auf Tape" selbst mit einem dedizierten BackupServer nicht immer zu erreichen ist.

Das Wunder der Replikation

Für die meisten Lösungen wie ist die Replikation ein Hilfsmittel zur Erhöhung der Verfügbarkeit, da die erste Kopie zugleich auch als produktive Instanz im Fehlerfall genutzt werden kann. Zugleich ist es natürlich eine erste "Kopie" und damit eine Sicherung der Daten. Möchte man weitere Kopien (sprich Backups) anfertigen, dann kann dies von dieser Kopie erfolgen und belastet den Hauptserver nicht. Zudem der Abstand zwischen zwei Sicherungen bei einer synchronen Replikation 0 Sekunden so dass im Fehlerfall kein Datenverlust (RPO) zu befürchten ist. Weiterhin ist die Kopie ebenfalls in sehr kurzer Zeit (z.B. Sekunden) wieder verfügbar, so dass auch die Wiederherstellungszeit (RTO) minimal ist. Abgesehen von einer ersten kompletten Kopie werden danach nur noch Differenzen übertragen, so dass auch dies die Systembelastung reduziert.

Es gibt verschiedene Optionen der Replikation.

Datenbestand Replikation RPO RTO Beschreibung

Exchange Mailbox

CCR, LCR, DAG

<5 MB

<1Min

Exchange 2007 hat damit angefangen, dass eine EDB-Datei auf einem zweiten Server (CCR) oder einer zweiten Disk (LCR) als Kopie vorgehalten werden konnte. Exchange 2010 hat diese Verfahren verbessert, indem mehr als nur eine Kopie bereitgestellt werden kann und die Replikation auch direkt (statt LogShipping) erfolgen, was die RPO weiter reduziert.

Exchange Public Folder (Bis 2010)

PF Replikation

<15 Min

Min

Seit es öffentliche Ordner gibt, können Administratoren die Inhalte auf mehrere Server replizieren. Die Latenzzeit ist eher hoch und es ist keine Datenbank sondern eine Inhaltsreplikation. Aber wenn diese gut überwacht und konfiguriert wird, erhält man so eine "Kopie" auf weiteren Servern.

Bei Exchange 2013 sind die Public Folder in Mailboxdatenbanken gewändert, so dass Aussagen zur EDB-Replikation anzuwenden sind.

SQL (ab 2008R2)

Mirroring

<Min

<Min

Auch SQL 2008 kann analog zu Exchange 2007 eine Datenbank auf einen anderen SQL-Server replizieren und damit eine erste "Kopie" erzeugen, die beim Ausfall sogar live gehen kann. Allerdings muss die Clientanwendung den "Switch" auch unterstützen.

HyperV

Mirroring

<Min

<Min

Auch hier können mittlerweile VHD Dateien auf zwei Servern (Cluster) repliziert werden.

Dateisystem

DFS Replication

wenige Min

<Min

Windows selbst nutzt DFS um z.B. Dateifreigaben SYSVOL und NETLOGON auf allen Domänencontrollern "hochverfügbar" und Synchron bereit zu stellen. FRS kann aber auch Nutzdaten replizieren und damit Daten eines Dateiserver auf einem anderen System synchron halten

Dateisystem

XCOPY/Robocopy/Rsync

Dauer des Scan/Copy-Durchlauf.

?

Ich habe auch schon Lösungen gesehen, bei denen ein "XCOPY /MIR" oder "ROBOCOPY" ausgewählte wichtige Daten von einem Quellserver regelmäßig uaf einen Zielserver übertragen haben und damit eine Kopie anlegen, Verbindet man dies mit der Funktion "Vorherige Version" (Schattenkopien) im Ziel, kann dies auch eine Komponente einer Backupstruktur sein. Knifflig wird es nur z.B. bei Access Datenbank etc., da keinerlei Konsistenzsicherung auf der Quelle stattfindet

Storage + VSS

RAID1
VSS

0

0

Auch RAID-Level stellen streng genommen Replikate der Daten bereit, aber würde ich nicht als Backup ansehen, da eine logische Korruption der Dateistruktur immer beide Disks betrifft. Da hilft dann auch keine "Vorherige Version", die per Schattenkopien erstellt werden könnte

Storage

EMC BCV, Snapshot

0-x Min

0-x Min

Anders sieht es aus, wenn die "Snapshots" durch das Storage-System selbst erstellt werden und damit auch eine logische Korruption in der Disk zurückgedreht werden kann.. Verschiedene SAN-und Softwarehersteller bieten auch die Replikation von LUNs auf verschiedene Storage-Systeme an, so dass damit die Daten auch örtlich getrennt sind. Einige dieser Replikationen können sogar zeitlich gesteuert werden. Weitere Kopien der Kopie belasten den Server dann nicht.

Selbst eine zeitliche Steuerung ist möglich, wobei bei einem Resync dann idealerweise nur die geänderten Blöcke übertragen werden

Disk

DPM

z.B. 15 Min

 

Eine Besonderheit beim Backup ist der Microsoft Data Protection Manager. Er sichert die Quelle über Schattenkopien und baut auf dem DPM-Server quasi eine Kopie der Partition auf, die bei weiteren Backups einfach fortgeschrieben wird. per Schattenkopien-Versionierung auf dem DPM-Server werden so mehrere Generationen bereit gestellt.

Workstation

SBS2011, Win2012 Essentials

1-2 Tage

Stunden

Der Vollständigkeit wegen sei auch mal das Backup erwähnt, mit dem früher mein Windows Home Server und nun der Windows 2012 Essentials meinen Notebook sichert. Auch hier wird eine konsistente VSS-Instanz erzeugt und dann nur das vergangene Delta gesichert.

Ich denke es ist nun gut zu verstehen, warum immer mehr Produkte auf Replikation setzen.

Wegewahl

Auf der Seite Backupkonzepte finden Sie eine Beschreibung der unterschiedlichen Wege. Mittlerweile wurde das Bild der Server durch Virtualisierung deutlich erweitert.

 

Weg    

Lokales Backup

 

 

Gast via LAN

 

 

Host via LAN

 

 

Host via SAN Snapshot

 

 

Host via SAN auf Tape

 

 

 

Option: Sicherung per Schattenkopie (VSS Online)

Exchange 2003 unterstützt Schattenkopien (Siehe auch Windows 2003 Schattenkopien) und da liegt es doch nahe, diese Funktion auch zu nutzen. Leider unterstützt Microsoft NTBACKUP zwar Schattenkopien, aber nicht den Exchange Teil. Sie können also mit Schattenkopien Exchange aktuell nur dann sichern, wenn Sie eine Drittsoftware einsetzen.

Wenn eine Sicherungssoftware nun eine Schattenkopie anfordert, dann wird Exchange über den VSS-Writer so gesteuert, dass es alle offenen Transaktionen abschließt und für bis zu 20 Sekunden keinen Schreibzugriff mehr auf Datenbank und Transaktionsprotokolle durchführt. In dieser Zeit kann ihre Lösung dann die Festplatte irgendwie "sichern". Nun wird es so schnell keine Lösung schaffen, mehrere Gigabyte in weniger als 20 Sekunden physikalisch kopieren kann, aber das ist ja auch erst einmal gar nicht nötigt. Es gibt einfach ein 20 Sekunden Zeitfenster, in der ein Schnappschuss der Partition mit einem Mittel ihrer Wahl durchgeführt werden kann.

  • VSS Shadow durchführen
    danach benötigen Sie Zugriff auf diese Schattenkopie. Einige Produkte "kopieren" dazu die Schattenkopie mittels "VSS Copy" auf ein eigene Festplatte oder Sie können auch ein Laufwerk mit der Schattenkopie (ReadOnly) verbinden
  • Prüfen der Datenbank mit ESEUTIL
    Eine "Kopie" einer Datei bedeutet nicht, dass diese konsistent und fehlerfrei ist. ESEUTIL erlaubt einen Test und kann auch per Kommandozeile gesteuert werden.
  • Sicherung der Datenbank
    Wenn die Datenbank korrekt durch die Schattenkopie kopiert wurde, dann können Sie diese nun auf das Bandlaufwerk verschieben.
  • Logfile abschneiden
    Über die gleiche VSS-API kann die Sicherung das erfolgreiche "Backup" an Exchange mitteilen, so dass Exchange die Transaktionsprotokolle bis zur Schattenkopie abschneidet

Diese Art der Sicherung ist mittlerweile bei fast allen Backupprodukten verfügbar. Hinderlich ist dabei sicherlich, dass diese API weder per VBScript nicht mit NTBACKUP nutzbar ist, sondern Dritthersteller in ihrem Backupanwendungen diese Funktionen nutzen müssen

Aber auch wenn Backupprodukte eine Sicherung per Schattenkopie anbieten, gilt es die ein oder andere Falle zu umgehen oder Einschränkung zu können.

  • VSS und Recovery Storage Group
    Exchange 2003 VSS Backups können NICHT in eine Recovery Storage Group (MSXFAQ.DE - Recovery Storage Group) restauriert werden. Das geht erst mit Exchange 2007
  • Umleitung
    Auch die Umleitung von Backups bei der Wiederherstellung in ein anderes Verzeichnis ist mit Exchange 2003 anscheinend nicht möglich, sondern erst ab Exchange 2007 verfügbar. Der VSS-Requester bietet die Funktion nicht an. Allerdings wird es dann auch wieder einige Zeit dauern, bis die Hersteller diese Funktion anbieten
  • Ausschluss der EDB
    Sichern Sie auch das Dateisystem über Schattenkopien, dann müssen Sie die Exchange Datenbankendateien (EDB/STM) aus der Sicherung ausschließen. BackupExec weist z.B. darauf hin, dass beim Einsatz der AOFO (Advanced Open FileOption) sogar eine Beschädigung der Datenbanken auftreten könnte

Insofern ist die Sicherung per Schattenkopie zwar eine saubere und stabile Lösung, die aber mit Exchange 2003 noch ein paar Einschränkungen hat. Es ist aber speziell für Firmen mit hohen Ansprüchen an eine schnelle Sicherung und besonders eine schnelle Wiederherstellung der beste Weg, dies mit entsprechender Hardware zu erreichen. Schattenkopien können nämlich auch genutzt werden, um in Verbindung mit entsprechender SAN-Hardware auch ein "Serverless Backup und Restore" zu ermöglichen. Hier mal ein paar Screencaptures von BackupExec 11d:

BackupExec AFO Einstellungen

BackupExec 11d Exchange Optionen

Wenn Sie auf der Karte für "Advanced File Option" die Unterstützung von Schattenkopien oder kompatiblen Funktionen aktiviert haben, dann nutzt BackupExec auf für Exchange diese Funktion. Zusätzlich können Sie auf der Exchange Karteikarte hinterlegen, dass er noch schnelle eine Konsistenzprüfung der Schattenkopie vornimmt. Auch die Unterstützung von Exchange 2007 LCR bzw. CCR Cluster ist vorhanden.

Option VSS + Offline

Aber auch wenn ihre Backuplösung keine Unterstützung ´für Exchange und Schattenkopien bietet, können Schattenkopien vielleicht eine sinnvolle Option sein. Voraussetzung ist aber dass ihre Sicherungssoftware zumindest Schattenkopien anfordern und Sichern kann. Dann könnten Sie folgendes durchführen:

  • Exchange Datenbank beenden
    Die Exchange Datenbanken können per Skript sehr schnell beendet werden. Wenn Sie dies nachts durchführen, wenn kaum Leute arbeiten und diese z.B.: per Outlook Cached Mode arbeiten, dann ist hier nur eine kurze "Downtime" zu bemerken
  • Schattenkopie
    Da die Datenbank ja nun "offline" ist, ist diese auch nicht mehr im Zugriff und kann über die normale Schattenkopie des Dateisystems quasi gesichert werden. Der Prozess dauert ja auch nur wenige Sekunden.
  • Exchange Dienste wieder starten
    Nun sollten Sie die Datenbanken wieder starten.
  • Zugriff auf die Schattenkopie
    Nun kann ihre Sicherungssoftware einfach die Datei aus der Schattenkopie wegkopieren. Die Datenbank war ja "Clean Shutdown". Das können Sie auch problemlos noch mal mit ESEUTIL prüfen.

Durch dieses Verfahren haben Sie dann eine sehr schnelle "offline-Sicherung" von Exchange, die auch im Desasterfall sehr schnell wieder bereit gestellt werden kann. Allerdings gibt es da noch ein paar kleine aber wichtige Details zu klären:

  • Kein automatisches Logfile löschen
    Die Transaktionsprotokolle müssen Sie natürlich auch noch löschen. Vielleicht ist ein Differenz-Backup über die API hier der beste Weg.
  • DB Stop/Start muss geskriptet und überwacht werden
    Das Stoppen und Starten der Datenbanken müssen Sie noch realisieren.
  • kurze Downtime beim user
    Auch wenn der Downzeit vielleicht nur ein paar Minuten ist, so ist es eine kurze Ausfallzeit.

Insofern ist dieser Ansatz nur bedingt brauchbar.

Option Remote VSS, Hardware VSS

Ich habe mich hiermit noch nicht weiter beschäftigt, aber es ist nicht vorgeschrieben, dass der VSS-Writer auf die gleiche Festplatte schreibt. Theoretisch könnten über den VSS-Mechanismus die Daten sofort auf einer zweiten Festplatte geschrieben werden und bei der Ausführung eines Snapshot eben dort aktualisiert wird. Technisch sicherlich interessant.

Ebenso soll es mittlerweile SAN-Systeme geben, die einen "VSSCopy" selbständig in Hardware ausführen und das Hostsystem damit nicht mehr belasten

Option SAN Split online oder offline

Schon lange gibt es SAN-Systeme, die herrlich mit Festplatten und Kopien hantieren können. So gibt es von EMC schon viele Jahre die Funktion der "Business continuous Volumes", die, vereinfacht ausgedrückt, nichts anderes besagen, als dass man eine Festplatte auf eine andere Festplatte im laufenden Betrieb kopieren kann, die synchrone Kopie dann wieder abspaltet und die Daten darauf nutzt. Wird die Festplatte dann wieder an den Master angehängt, werden nur die in der Zwischenzeit geänderten Blöcke kopiert.

Windows und Exchange "merken" davon gar nichts. Da aber das SAN-System nicht weiß, ob gerade eine Transaktion stattfindet und in der Regel das SAN dem Server auch nicht sagen kann "halt mal kurz an", entspricht die Kopie in etwa einer Festplatte des Servers, der einfach ausgeschaltet worden wäre. Transaktionsorientierte Dateisysteme wie NTFS und Programme wie SQL und Exchange haben damit eher wenig Probleme. Aber was macht das SAN, wenn ein Block durch zwei Schreibbefehle erst komplett geschrieben wird (z.B. weil ihr Dateisystem eine andere Blocksize verwendet als der Massenspeicher ?), dann ist der Split eventuell unbrauchbar. Auch hier ist also eine "Prüfung" des Dateisystems und der Daten erforderlich.

Das Risiko können Sie natürlich vermeiden, wenn Sie die Datenbanken von Exchange einfach kurz Offline nehmen. Das geht mit Exchange 2000/2003 ja um einiges schneller als unter Exchange 5.5.

Man könnte die SAN-Split  Funktion natürlich auch mit VSS kombinieren,  so dass eine Schattenkopie vor dem Split zumindest für eine konsistente Schattenkopie sorgt. Statt des "Livesystem" nutzt man dann einfach die ein paar Sekunden alte Schattenkopie.

  • Prüfung der Datenbank muss entwickelt werden
  • Kein automatisches löschen der Transaktionsprotokolle
  • optionales Stop/Start der Datenbank muss programmiert und überwacht werden
  • optionale kurze Downtime beim user
  • Restore bedeutet alte Platte "zurückspiegeln" oder live durch Backup ersetzen
    Wenn dann was schief geht, dann ist auch die Kopie weg, eventuell VSS als Hilfe
  • Kein Rollforward bei "aktivem Check
    Wird die Kopie per ESEUTIL z.B.: "konsistent" gebracht, dann kann bei einem Fehler zwar die Datenbank von dem Zeitpunkt bereit gestellt werden, aber nachfolgende Transaktionsprotokolle werden natürlich nicht weiter eingespielt

Option Data-Replication

Die Angst vor dem Ausfall des Servers hat natürlich Dritthersteller schon lange vor der Funktion Local Continuous Replication auf den Gedanken gebracht, mittels Filtersoftware jeden Schreibbefehl auf eine lokale Festplatte auf einen zweiten Server zu kopieren. Da ist es natürlich auch eine Idee, den zweiten Server einfach als Backupquelle zu nutzen. Im Falle eines Ausfalls muss dieser Server ja auch alle Daten haben.

Auch hier muss natürlich hinterfragt werden, wie die Daten auf dem zweiten Server "gültig" sind. Wird dazu die Replikation einfach angehalten oder welche Optionen werden hier angeboten? Auch hier gilt:

  • Prüfung muss entwickelt werden
  • Kein automatisches löschen der Transaktionsprotokolle
  • Zusatzsoftware
  • Restore bedeutet Daten zurückkopieren

Aber der Gedanke einen Standby-Cluster weiter zu verwenden hat durchaus seinen Charme. Mit Exchange 2010 hat Microsoft mit der DAG die Funktion dann auch noch besser ausgeführt.

Option "Data Protection Manager"

Dass direkte Sicherungen vom Server zum  Bandlaufwerk nicht mehr ausreichend sind, hat sich sicher schon herum gesprochen. Zum einen sind die Bandlaufwerke damit oft nicht ausgelastet während ein Restore oft lange dauert (Bandpositionnierung etc.). Daher sichern viele Firmen mittlerweile ihr Daten auf eine andere Festplatte um diese dann auf ein Bandlaufwerk zu verlagern.

Passend hierzu gibt es natürlich auch von Microsoft den "Data Protection Manager", welcher auf einem eigenen Server mittels Replikation und Schattenkopien die Daten produktiver Dateiserver bei sich aufnimmt und auch wieder schnell restaurieren kann. Die Daten der produktiven Server müssen daher nicht  mehr gesichert werden (der SystemState sollte aber weiter gesichert werden), da diese über die Sicherung des DPM automatisch gesichert sind.

Leider kann der DPM 2006 nicht Exchange sichern. Es gibt hier nur den Umweg, dass die Exchange Datenbanken z.B. mit NTBACKUP auf eine Datei gesichert werden, welche ihrerseits dann per DPM gesichert wird. Auch wenn des dazu sogar eine Beschreibung in einem TechNet Artikel gibt (909644 How to use Microsoft System Center Data Protection Manager 2006 to help protect an Exchange Server), so halte ich diesen Ansatz in der heutigen Form für unbrauchbar. Bei einem Restore müsste ein Restore von der Banddatei über LAN erfolgen, was zu langsam ist.

Option Software-RAID und z.B.: iSCSI

Mit den dynamischen Datenträgern kann Windows 2003 auch selbst Daten zwischen Festplatten spiegeln. Da könnte es durchaus eine Option sein, ein "kleines VSS" in der Art zu bauen, dass eine Festplatte per RAID1 an das produktive System angehängt und gespiegelt wird und zum "Backupzeitpunkt" einfach das intakte RAID aufgebrochen wird. Diese losgelöste Platte (Vergleiche "SAN Split") kann dann eigenständig gesichert werden. Dank der Unterstützung von iSCSI kann so eine LUN sogar direkt auf einem anderen Server liegen, z.B.: nahe beim Bandlaufwerk.

Aber auch hier ist wieder das Problem, ob die Daten auf der abgetrennten Festplatte konsistent sind. Insofern ist diese Funktion als Backup weniger geeignet.

Option MS-Cluster mit Disks im SAN

Eine ganz andere Lösung hat Microsoft selbst angeblich implementiert. Ihr Exchange Server mit Postfächern sind alle als Microsoft Cluster ausgelegt. Ein Vorteil von Cluster ist aber nicht nur eine höhere Verfügbarkeit, sondern Sie können mit Clusterressourcen problemlos auch Festplatten zwischen Clusterknoten verlagern. Und da liegt nun der Trick. Neben den "Exchange virtuellen Servern" mit ihren eigenen Disk Ressourcen können Sie weitere virtuelle Server anlegen, die einfach nur eine IP-Adresse, einen Netzwerknamen und eine weitere Disk enthalten. Wenn Sie dann diese Ressource auf den gleichen Knoten verschieben, auf dem auch Exchange läuft, dann kann der Exchange Server auch mittels NTBACKUP von einer "lokalen" Disk auf die ebenfalls "lokale" Disk der Backupgruppe gesichert werden.

Nach dem Backup kann die Gruppe wieder auf einen anderen passive Knoten verschoben werden und von von dort auf das Band übertragen werden.

Weitere Links