Data Protection Server 2007

Für die Sicherung von Exchange 2010 ist DPM 3.0 erforderlich, welches als BETA auf http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/2010beta-overview.aspx erhältlich ist. Erste Einrücke hat Hendrick Walther auf http://blogs.msexchange.org/walther/2009/10/02/protecting-exchange-2010-dags-with-dpm-2010/ beschrieben.

TechNet Webcast : DPM 2010 Release Candidate preview
http://blogs.technet.com/jbuff/archive/2010/01/11/technet-webcast-DPM-2010-Release-Candidate.aspx

Mit dem DPM 2007 hat Microsoft die zweite Version des Data Protection Manager released, die erst einen sinnvollen Einsatz ermöglichen Mit dem DPM2007 kann man nicht mehr nur "Dateiserver" sichern, sondern nun auch folgende Dienste mit absichern:

  • Exchange
    Hier sogar als erste Lösung zur Sicherung des passiven CCR-Knotens zertifiziert, kann DPM max. alle 15 Minuten auch die Protokolldateien abholen und das Verlustrisiko stark minimieren.
  • SQL und Sharepoint
    PM sichert zusätzlich zum Dateisystem auch die SQL-Datenbank mit den Protokollen und erlaubt auch hier sehr häufige Sicherungen, um das Verlustrisiko zu minimieren
  • Virtual Server
    Hier werden die VHD-Dateien werden ebenfalls über Schattenkopien konsistent gesichert, wenn der virtuelle Gast Windows 2003 oder Windows 2008 ist. Hier meldet der DPM Agent an den Gast die VSS Anforderung, so dass die VHD-Datei ohne Shutdown des Gastsysteme einen konsistenten Stand enthält. Andere Betriebssysteme werden kurz "angehalten" (Suspend)

Eine Absicherung von anderen Anwendungen (z.B. Oracle, Notes etc.) ist nur in Form eines Datei-Backups der Festplatten möglich. Letztlich muss man dazu also die Anwendung entweder "Schattenkopietauglich" machen oder die Dienste kurzfristig anhalten, damit DPM die Daten auch konsistent erwischt. Insofern ist der DPM primär eine Sicherungslösung für Windows Umgebungen und weniger für den heterogenen Einsatz.

Problemstellung und DPM-Arbeitsweise

Das soll Sie aber nicht davon abhalten, zumindest die Funktionsweise von DPM verstanden zu haben. Sie ist nämlich fundamental unterschiedlich zu klassischen Datensicherungen. Diese basieren nämlich auf Dateien, Verzeichnissen und Datenbanken. Je nach Sicherungsstruktur bedeutet dies bei einer Sicherung von drei Servern (a 100GB) über ein LAN von Montag -Freitag auf einen vierten Server:

Sicherungsart Netzwerklast Zielspeicher Gesamt

Täglich Voll

5x (100GB +100GB + 100GB)

5x (100GB +100GB + 100GB)

1,5 TB

FreitagVoll
Wochentag DIFF

1x (VolumenS1 + S2 + S3)
+ 4x (DeltaS1 + S2 + S3)

1x (VolumenS1 + S2 + S3)
+ 4x (DetlaS1 + S2 + S3)

 

Und das ist nur das Volumen für eine Woche bei einem täglichen Backup. Das Volumen wächst, wenn man Bänder länger aufheben will oder unter Tage auch noch "Zwischenbackups" machen möchte. An eine Sicherung von entfernten Standorten über WAN ist schon gar nicht zu denken.

Denken Sie mal über folgendes nach:

Tag für Tag sichern klassische Backups die gleichen Bits von den Festplatten des Quellservers (DiskIO/CPU) über das LAN (Bandbreite) zum Backupserver (DiskIO, TapeIO), obwohl die Informationen am Vortrag schon mal übertragen wurden. Selbst beim "Differenzbackup" werden speziell große Dateien (z.B. PST und PPT-Dateien) immer komplett übertragen, obwohl sich nur ein paar Bits geändert haben

Und nun kommt DPM mit seinem ganz anderen Denkansatz: Der DPM Server hält quasi eine "Kopie" der zu sichernden Festplatten bei sich als lokale Kopie. Der DPM-Agent (NTFS-Filter Treiber) merkt sich alle geänderten Blöcke auf den Festplatten, so dass der DPM-Server sich nur noch die geänderten Blöcke übertragen muss. Entsprechend gibt es drei Jobs der Sicherung:

  • Erstes Voll-Backup (Initial Sync)
    Hierbei wird wie beim klassischen Vollbackup eine komplette Sicherung des Servers durchgeführt. Im Gegensatz zu üblichen Sicherungen über SystemState und Dateisystem sichert DPM aber die belegten Blöcke der Festplatte als Kopie auf den DPM-Server.
  • Express Full (Sync)
    Während beim klassischen Backup aber nun bei folgenden Sicherungen weiterhin Dateien und der komplette SystemState gesichert werden, bedeutet ein "Express Sync" beim DPM nur noch das Kopieren der geänderten Blöcke auf das Ziel. Es werden also sehr viel weniger Daten übertragen. Je nach Quelle kann man den Prozess bis zu einmal pro Stunde ausführen lassen. Mit Exchange und SQL muss man dies aber nicht so oft machen, da hier die Protokolldateisicherung greift. Auf Dateiservern kann solch ein Express Sync jedoch sehr effektiv sein um verschiedene Versionen vorzuhalten (analog zu Schattenkopien). DPM kann maximal 512 solcher Stände pro Disk speichern.
  • Logfiles
    Bei Datenbanken wie Exchange und SQL kann DPM zusätzlich die Protokolldateien kopieren. Das kann bis zu alle 15 Minuten ausgeführt werden. Wer ein "gutes" Design hat, legt Protokolldateien natürlich immer auf anderen Festplatten ab, so dass bei einem Ausfall diese Sicherungen nicht erforderlich sind. Mit diesem Log verliert man aber maximal 15 Minuten an Mails oder Transaktionen.

Nach dem ersten kompletten Kopieren werden also prinzipiell nur noch Differenzen auf Blocklevel kopiert und auf dem DPM-Server zusammen gebaut. Dass die Daten "konsistent" sind, nutzt der DPM natürlich intensiv die Funktion der Schattenkopien. So kann man dann bis zu 512 sofort nutzbare "Schnappschüsse" vorhalten und anhand der Differenzen weitere Zwischenstände bei bedarf erstellen lassen.

Man erkennt, dass man für die Sicherung schon gut überlegen muss, wie man die Partitionen aufteilt. Die Trennung von Exchange Datenbank von Transaktionsprotokoll ist schon einmal sehr wichtig, damit mal die LUN mit den Protokolldateien nicht per ExpressFull mit sichern muss. Hier ändern sich ja relativ viele Blöcke. Zudem reduziert man damit noch einmal die 15 Minuten Verzögerung, wenn beim Ausfall die Protokolldateien erhalten bleiben.

Für einen großen Datei- Exchange- oder SQL-Server bedeutet dies aber dass nur beim ersten Mail die komplette Datenmenge analog zu einem klassischen Fullbackup übertragen werden muss und in der Folge selbst Sicherungen, die auf dem Ziel wieder ein komplettes Abbild erzeugen, nur die Änderungen übertragen. Das bedeutet:

  • weniger LAN-Belastung
    Die Sicherung kann über das LAN erfolgen und sogar langsamer angebundene Außenstandorte können eventuell gesichert werden.
  • weniger CPU der Quelle
    Weniger zu übertragende Daten entlasten natürlich auch die CPU des zu sichernden Systems aber auch des Backupserver
  • weniger DiskIO
    Wenn nur die Änderungen gelesen werden, dann spart sich das System sehr viele Disk-IOs und auch die Cacheraten des RAID-Controllers werden weniger verschlechtert.

Trotz deutlich reduzierter Sicherungsdatenmenge erhält man ein komplettes "Diskabbild" der Quelle, die man für ein restore heranziehen kann.

Funktionsprinzip DPM

Technisch löst DPM die Sicherung über einen "Filter-Treiber" auf dem Server, welcher Buch über alle Änderungen auf den Festplatten führt. In einem Chance-Journal werden dazu alle seit dem letzten Abgleich veränderten Datenblöcke der Festplatte protokolliert. Im Gegensatz zu Schattenkopien werden aber keine Schreibzugriffe verzögert oder Blöcke verschoben. Der Filtertreiber erkennt aber natürlich die Aktionen, die anhand des VSS-Treibers erfolgen und protokolliert auch diese mit.

Wenn dann eine Datensicherung ansteht, muss natürlich auch DPM sicherstellen, dass die kopierten Blöcke derart konsistent sind, dass die daraus erstellte Kopie auf dem DPM-Server auch brauchbar ist. Hier bedient sich DPM dann doch wieder den Schattenkopien. Vor dem Kopieren der Blöcke wird eine Schattenkopie angefertigt, die anhand der passenden VSS-Provider auch Exchange, SQL und Virtual Server unterstützt und damit die Festplatte zu einem gewissen Zeitpunkt einfriert. Das ist aber nur eine kurzer Moment, denn nach der Schattenkopie kann der Server selbst wieder weiter arbeiten.

DPM allerdings nutzt nun die Daten aus dem Change.-Journal des Filtertreibers, um eben alle geänderten Blöcke bis zur Schattenkopie auf den DPM-Server zu übertragen, der diese dort wieder in die lokale Partition einbaut. Damit enthält der DPM-Server eine 1:1 Kopie der Festplatte im Moment der Schattenkopie. Das entspricht genau dem Stand, den auch ein klassisches Backup mit VSS-Support anfertigen würde.

Natürlich ist das etwas vereinfacht ausgedrückt. DPM muss die Konsistenz der Datenbanken prüfen und dann per VSS-Provider dem Quellserver mitteilen, das die Sicherung erfolgreich war und dieser dann z.B.: die Exchange Transaktionsprotokolle löschen kann.

DPM Technik

Wenn Sie den DPM schon einmal installiert haben, dann muss man natürlich auch die Festplatten für den DPM entsprechende vorbereiten. Der wichtige "Trick" dabei ist, die Festplatten eben nicht zu partitionieren und dieses Aufgabe dem DPM zu überlassen. DPM benötigt nämlich direkt Platz auf den Disks, auf dem er dann selbst Partitionen anlegen kann und keine vorbereiteten Partitionen, in denen Dateien landen könnten.

Auf dem Bild ist gut zu sehen, dass DPM für jede Quellfestplatte auch auf dem DPM-Server eigene Partitionen anlegt und diese einfach in die DPM-Partition als Mountpoint einbindet. Das macht auch Sinn, da das Backup ja eine "Diskkopie" ist und aufgrund der begrenzen Laufwerksbuchstaben nur ein Mountpoint ausreichend Partitionen erreichbar macht.

Die Ablage als Partition erscheint erst einmal ungewöhnlich, aber erlaubt später auch einfach das "Kopieren" von Partitionen mit externen Hilfsmitteln, um ein noch schnelleres Restore zu ermöglichen.

Zur Dimensionierung gibt Microsoft erst einmal den Ratschlag, ca. 150% oder mehr der Quellkapazität vorzusehen. Sicher ist, dass die Anzahl der verfügbaren Versionen von der Kapazität des DPM aber auch von der Anzahl der Änderungen der Quelle abhängig ist. Hier können Sie einen einfachen Test machen: Aktivieren Sie die Schattenkopien und lassen Sie .z.B. jede Stunde eine Schattenkopie erstellen. Sie können sehr bald sehen, wie viel Platz diese Kopien benötigen. So erhalten Sie in etwa den Bedarf für Änderungen . Dies gilt so leider nicht per SQL und Exchange, da hier der VSS-Writer nicht angesprochen wird.

DPM und Sicherung

Die Sicherung in DPM ist relativ einfach einzustellen. Man passt Quellen in Gruppen zusammen und plant mit den Gruppen entsprechende Aufträge. Die Statusüberwachung zeigt dabei sehr schön, welche Aufträge wie gelaufen sind. Hier ist DPM denkbar einfach gestrickt und kann sicher nicht die kommerziellen Produkten wie BackupExec und ArcServe im Hinblick auf die "Features" übertrumpfen. Ein solides Backup kann man aber auch ohne "Featureitis" erreichen.

Interessant in dieser Ansicht ist natürlich die übertragene Datenmenge. Hier handelt es sich um Bilder meiner DemoUmgebung. In produktiven Umgebungen sind sicher größere Datenmengen zu bewältigen.

DPM normales Restore

Doch schauen wir uns erst mal ein "normales" Restore an. DPM hat auf seinen Partitionen eine Kopie der Festplatte des Quellsystems samt den Schattenkopien und optionalen Protokolldateien von Exchange und SQL. Sie sollten nun nicht über die Mountpoints direkt versuchen, die Festplatten anzusprechen. DPM erlaubt schon per grafischer Benutzeroberfläche die Wiederherstellung einzelner Dateien oder Datenbanken, selbst wenn das Backup eher einem "Image-Backup" entspricht. Bei diesem klassischen Weg werden die Daten aber wieder über das LAN auf das Zielsystem übertragen.

Ist das Zielsystem nicht mehr "online"; dann müssen Sie natürlich wie bei anderen Produkten erst einmal das eigentliche Betriebssystem samt DPM-Agent installieren, um dann ein Restore vornehmen zu können. Ganz richtig ist das aber nicht, da auch DPM ein "Desaster Recovery Modul" kennt, mit welchem Server schneller wieder hergestellt werden können. Allerdings benötigen Sie dazu die teurerer Client-CAL.

Eine pfiffige Option ist die Wiederherstellung durch den Anwender. Dieser kann ganz einfach durch seinen normalen Client, mit der bisher auch ältere Dateien von einer Schattenkopie wieder herstellt, nutzen um vom DPM Dateien zurück zu holen.-

DPM und SAN

Nun ist es ja so, dass jeder DPM Server quasi ein Abbild der Festplatten des Quellservers bei sich als Kopie vorhält. Wenn ich nun einen Server mit 1 TB Daten sichere und dieser komplett verloren geht, dann ist mir natürlich nichts damit geholfen, diese Datenmenge auf dem DPM vorliegen zu haben und nach der Wiederherstellung des Servers erst alles über das LAN zurück kopieren zu müssen. Selbst mit Gigabit als Team dauert dies doch zu lange.

Da auf dem DPM die Disks ja vorliegt, liegt der Gedanke gerade zu auf der Hand, die Festplatte des DPM dem Originalserver zu geben (was ich nie nie nie machen würde, weil man dann kein Backup mehr hat, wenn das auch noch schief geht) oder (besser) die Festplatte einfach "kopiert". Man könnte also in der Zeit, in der der ausgefallene Server wieder repariert wird, die Daten der Backupplatte direkt auf dem DPM-Server auf eine temporär angeschlossene Festplatte (SAN, iSCSI etc.) quasi per RAID1 kopieren oder die ganze Kopieraktion direkt durch das SAN durchführen lassen.

Genau diese Option bietet DPM schon über die Menüführung. Die Daten werden beim Restore einfach per "Hardware Snapshot" von der DPM-Platte kopiert auf eine andere Festplatte kopiert, die man dann dem ausgefallenen Server einfach wieder zur Verfügung stellt.

Andere Programme

Natürlich ist Microsoft nicht als erstes auf die Idee gekommen, Festplatten und Server per "Image" zu kopieren und mit einem Filtertreiber die Änderungen zu verfolgen. So sichert auch Acronis True Image Server und die aktuelle Version nutzt dazu sogar ebenfalls VSS, um einen konsistenten Stand zu erhalten. Allerdings ist das Ziel dabei dann keine Festplattenpartition sondern eine große TIB-Imagedatei. Auch Differenzsicherungen sind möglich, die dann allerdings weitere Imagedateien anlegen. Aber auch hier ist ein Desaster Restore eines Server über eine BootCD ebenso möglich wie eine Wiederherstellung einzelner Dateien.

Ganz konnte ich aber nicht die Unterstützung von Exchange und SQL klären. Insbesondere kann Acronis wohl (noch) nicht die Transaktionsprotokolle abschneiden oder als Differenzsicherung kopieren und die Konsistenz der Datenbank prüfen. Ebenso konnte ich auf die Schnelle noch nicht die Wiederherstellungen von Versionen und die zentrale Steuerung vieler Imageserver anschauen. Hier stehen auf jeden Fall noch Teste aus.

Aber Sicherungen des Betriebssystems und der Anwendungen sind damit sicher heut schon möglich, sofern man natürlich auf die Domaincontroller verzichtet, welche auf Wiederherstellungen von alten Images empfindlich reagieren.

Weitere Links