Exchange 2010 - Backup und High Availability - aber wie?
Exchange 2010 hat anfangs einige Probleme aufgegeben was dieses Thema betrifft. Die Streaming Backup API wurde fallen gelassen. Ab sofort ist es nur mehr durch die viel modernere VSS API möglich ein vollständiges Backup zu machen. Was durchaus zu einigen Startproblemen bei so manchem Backup Produkt Hersteller geführt hat.
VSS bietet den Vorteil das wie der Name schon sagt - es handelt sich um einen Snapshot und dieser ist in wenigen Sekunden zu machen. Der Backupprozess wird wesentlich verkürzt, das kopieren auf Tape dauert halt entsprechend. Noch weiter optimieren kann man hier mit einer entsprechenden hardwarebasierten Snapshot Lösung.
Als Beispiel sei hier eine Lösung von NetApp genannt - der SnapManager for Exchange als Backup-Produkt und ideales Werkzeug zur Steuerung ihres Backupprozesses auf Basis NetApp Storagessysteme.
In der aktuellen Version 6.0 wird Exchange 2010 vollständig supported, selbst in der aktuellsten Form der Hochverfügbarkeit - die Database Availability Groups. Der SnapManager bietet nicht nur die vollständige Automatisierung ihres Backupprozesses, er erlaubt zusätzlich ebenfalls die Erweiterung auf ein Desaster Recovery Konzept. Direkte Integration der SnapMirror Technologie erlaubt es auf Storagelevel hocheffizient ihre Exchange Datenbanken auf einen entfernten Standort synchron oder auch asynchron zu spiegeln.Nicht zu verwechseln mit der Microsoft eigenen Technologie der Database Availability Groups um Datenbanken auf einen entfernten Standort zu replizieren. DAG Systeme auf Basis NetApp sind zwei Technologien die sich ideal ergänzen.
Der DAG Cluster bietet einen aktiven Failover im Falle eines Problems am lokalen Standort aber auch eine Replikation der Daten über kurze Distanzen. Das Backup selbst wird blitzschnell durch den SnapManager durchgeführt und aus dem lokalen System per SnapMirror auf einen entfernten Standort repliziert. Der Standort kann dabei entsprechend weiter entfernt sein auf den eine Replikation per DAG nicht mehr möglich wäre. Die SnapMirror Replikation ist dabei asyncron und kann entsprechend über eine nahezu beliebige Entfernung kopiert werden.
Database Availability Groups ersetzen die bisherigen Clustermodelle in Exchange vollständig. Damit sind CCR, SCR sowie SC Cluster Geschichte. DAG nutzt ähnlich dem CCR Modell die Möglichkeit der Replikation um Datenbank und Logfiles auf ein oder mehrere Knoten zu kopieren. Dort kann diese in Echtzeit oder auch verzögert betrieben werden und jederzeit zwischen diesen hin und hergeschalten werden. Der User merkt davon nichts, die Client Access Server übernehmen die Verbindung zum Client und halten diese selbst wenn ein Failover im Hintergrund stattfindet.Beide Technologien zielen in eine ähnliche Richtung, einzeln gesehen erfüllen sie nur nicht zwingend die Anforderung. Gemeinsam eingesetzt können sich beide ergänzen und fehlende Features der einen können durch die andere ergänzt werden.