Wir haben unser Backup auf DPM von Microsoft umgestellt. Hier ist beschrieben, wie man DPM installiert und hier, wie man DPM konfiguriert.

Der DPM Server steht in einem anderen Schulhaus als die Server und ist über eine Glasfaserverbindung mit den Servern verbunden. Grundsätzlich sollten also bei einem Desasterfall die Backups sicher sein. Trotzdem wollte ich testen, was passieren würde, wenn wir in einem “Worst Case” die Server und den DPM Server verlieren würden. Aus diesem Grund setzen wir auch noch eine Langzeitarchivierung auf virtuelle Bänder ein. Aus Kosten- und Performancegründen wollte ich keine physikalische Tape-Library einsetzen. Mit Firestreamer kann man virtuelle Tape-Libraries simmulieren. So kann man Backups statt auf Band auch auf externe USB-Disks oder sogar Netzwerkfreigaben (in nochmals einem anderen Schulhaus) sichern.

Nun wollte ich also testen, ob ich ein Backup aus so einem virtuellen Tape wiederherstellen könnte, wenn tatsächlich die Server und der DPM Server gleichzeitig ausfallen würden. Dazu habe ich in einer virtuellen Maschine nochmals einen DPM Server und auch die virtuelle Library Firestreamer installiert. Auf dem “richtigen” DPM wurde dann die Library deaktiviert, damit nicht zwei Server gleichzeitig auf die Netzwerkfreigabe zugreifen können.

Auf dem neuen DPM Server habe ich nun das bestehende virtuelle Band eingelesen.

Nun muss man das Band in DPM einlesen. Dazu muss die Türe der virtuellen Tape-Library entriegelt, das Band eingelesen und die Tür wieder verriegelt werden.

Danach habe ich ein Inventar durchgeführt. Um den Inhalt anzuzeigen, muss man dann das Band noch neu katalogisieren.

Nun kann man überprüfen, ob man das richtige “Band” “eingelegt” hat.

Unter “Wiederherstellen” wird nun der wiederherzustellende virtuelle Server angezeigt. Man kann ihn auswählen und wieder herstellen. Man kann nur auf Maschinen mit installiertem DPM Agent wiederherstellen. Nur für diesen Test habe ich keine neuen Agents installiert und die virtuelle Maschine lokal wiederhergestellt.

Nach der erfolgreichen Wiederherstellung habe ich den wiederhergestellten virtuellen Server in Hyper-V importiert und getestet, ob er wieder zu laufen kommt. Dies hat problemlos funktioniert.

Damit sollten wir also genügend geschützt sein. Tägliches und wöchentliches Backup auf den DPM Server in einem anderen Gebäude. Quartalsweises Backup auf externe USB-Disks oder ein NAS an einem dritten Standort mit Firestreamer. Im Desasterfall lässt sich schnell und einfach vom DPM Server wieder herstellen und im “Worst-Case-Desasterfall”, wenn beide Standorte betroffen wären, kann zumindest aus dem Backup vom letzten Quartal wiederhergestellt werden. Somit sind die geplanten Tests mit DPM gelungen. Für Schulen, die so günstig zu DPM Lizenzen kommen, definitiv eine Empfehlung wert.  

Als erstes muss man über “Verwaltung” –> “Datenträger” –> “Hinzufügen” einen Datenträger für die Backups hinzufügen. Auf diesem Datenträger sollten noch keine Volumes angelegt sein.

Nun kann man einen Agent auf den gewünschten Servern installieren. Gemäss KB2621989 soll man für diesen Vorgang die Firewall (auf dem Server, auf den der Agent installiert werden soll) deaktivieren und danach wieder aktivieren, oder man erstellt eine Firewallregel.

Netsh advfirewall firewall add rule name = "dpmac" dir=in program="C:\Windows\Microsoft Data Protection Manager\DPM\ProtectionAgents\AC\4.2.1205.0\dpmac.exe" action=allow

Sicherung erstellen
Über Schutz –> Neu kann man eine neue Schutzgruppe auswählen.

Nun kann man die Ressourcen auswählen. Hier wurde eine virtuelle Hyper-V Maschine ausgewählt, die von “aussen” gesichert wird, also selber gar keinen Agent installiert hat.

Unter Beibehaltungsdauer kann man angeben, wie lange zurück man aus der Sicherung wiederherstellen möchte.

Wiederherstellung
Ein Backup ist aber nur so gut, wie die Wiederherstellung funktioniert. Daher wollte ich testen, ob DPM die virtuelle Maschine von einem früheren Zeitpunkt wieder auf den Failover-Cluster herstellen kann.

Nach der Wiederherstellung ist die virtuelle Maschine heruntergefahren. Man kann sie aber problemlos im Failovercluster-Manager starten.

Dies ist das Vorgehen, wenn die Maschine noch im Cluster vorhanden ist, und zum Beispiel durch eine Fehlmanipulation oder ein fehlerhaftes Update auf einen vorherigen Zustand zurückgesetzt werden müsste. Im Desasterfall wäre aber so eine Maschine nicht mehr auf dem Cluster vorhanden. Um das zu simulieren, habe ich die Maschine vom Failover-Cluster entfernt und danach vom Hyper-V-Manager gelöscht. Die Dateien bleiben aber im Cluster Shared Volume (CSV) bestehen und müssen auch noch manuell gelöscht werden. Manuelle Eingriffe auf dem CSV sollten immer auf dem Knoten mit dem Quorum (in meinem Fall mit zwei Nodes ist das derjenige mit der Witness Partition) durchgeführt werden.

Wenn man die Wiederherstellung nun gleich wie oben beschrieben durchführt, erhält man die folgende Fehlermeldung.

Auf die Clusterressourcengruppe … für \Online\… der Schutzgruppe … konnte nicht zugegriffen werden. Stellen Sie die Datenquelle mithilfe des Workflows für alternative Speicherorte wieder her. (ID 32579).

Also habe ich es mit dem zweiten Wiederherstellungstyp versucht. Unten wird darauf hingewiesen, dass man den Netzwerkadapter für die virtuelle Maschine nach der Wiederherstellung konfigurieren muss.

Nun kann man ein Wiederherstellungsziel angeben. Eine direkte Wiederherstellung auf das CSV hat bei mir zu einer Fehlermeldung beim Start der virtuellen Maschine geführt. Daher habe ich einen Unterordner ausserhalb des CSV auf dem Clusternode mit der Witness Partition erstellt. 

Nach der Wiederherstellung findet man die Maschine im Hyper-V-Manager, aber nicht im Failovercluster-Manager. Nun muss man sie wieder hochverfügbar machen. Dazu müssen die Dateien zuerst auf das CSV verschoben werden.

In der nächsten Auswahl muss man “Speicher des virtuellen Computers verschieben” auswählen, da das Ziel ja auf dem gleichen Computer liegt.

Am besten erstellt man auf dem CSV einen Unterordner für die entsprechende virtuelle Maschine (nicht wie im Bild direkt ins CSV)

Nun ist die Maschine zwar im CSV gespeichert, aber noch nicht hochverfügbar. Um das auch noch zu erreichen, muss man im Failovercluster-Manager unter Rollen “Rolle konfigurieren” auswählen und “Virtueller Computer” auswählen. 

Nach der Wiederherstellung kann die Maschine erfolgreich im Failovercluster-Manager gestartet werden und ist wieder hochverfügbar. Über diesen Weg könnte also auch im Desasterfall wiederhergestellt werden.

Wir sichern unsere Server mit BackupExec auf Band. Der eine Backupjob wurde nun mit einer Fehlermeldung abgeschlossen:

Auftrag beendet am Dienstag, 24. September 2013 um 01:55:57
Abschlussstatus: Fehlgeschlagen
Endgültiger Fehler: 0xe000fed1 – Beim Abfragen des Writer-Status trat ein Fehler auf.
Endgültige Fehlerkategorie: Ressourcenfehler

Im Eventlog wird die Ereignis-ID 34113 mit der Meldung “Der Auftrag schlug mit folgendem Fehler fehl: Beim Abfragen des Writer-Status trat ein Fehler auf.” protokolliert.

Auf dem betroffenen Server kann man mit “vssadmin list writers” überprüfen, ob ein Writer fehlerhaft arbeitet. Dies war bei mir der Fall für den “IIS Config Writer” und “IIS Metabase Writer”

Gemäss einer Internetrecherche genügt es oft, wenn man den Server neu startet, damit diese Writer wieder korrekt arbeiten. Da der Server aber produktiv war, konnte ich ihn nicht gut neu starten. Dank diesem Technet Forumsbeitrag bin ich dann auf die entsprechenden Dienste gekommen.

Nachdem die Dienste “Anwendungshost-Hilfsdienst” und “IIS-Verwaltungsdienst” neu gestartet wurden, liefert nun auch wieder ein “vssadmin list writers” alle Writerabfragen ohne Fehler zurück. Somit sollte also auch das nächste Backup wieder funktionieren.