Nach der Installation von Update Rollup 3 für DPM 2012 R2 gibt es eine Meldung im Server Manager, dass der Dienst “VSSNullProvider” beendet sei, obwohl der Starttyp auf automatisch gesetzt ist.

Gemäss dem “System Center: Data Protection Manager” Blog wird der VSSNullProvider Dienst nur für das Backup gestartet und danach wieder beendet. Man kann also die Meldung ignorieren, oder besser den Starttyp auf manuell setzen, damit die Meldung nicht mehr angezeigt wird.

Microsoft System Center Data Protection Manager (DPM) ist eine von vielen Möglichkeit, Backups zu erstellen. Obwohl DPM eigentlich für sehr grosse Umgebungen gemacht und normalerweise entsprechend teuer ist, gibt es auch hier spezielle Schulkonditionen von Microsoft. Aus diesem Grund haben wir auf DPM gewechselt, was bisher eine gute Entscheidung war. Hier die bereits veröffentlichten Dokumentationen in dem Zusammenhang.

DPM 2012 R2 installieren
DPM 2012 R2 konfigurieren und testen
Backup wiederherstellen nach einem “Worst Case”

Wir speichern unsere Backups also kurzfristig auf den DPM und langfristig auf eine virtuelle Bandbibliothek auf einem NAS in einem anderen Schulhaus. Zusätzlich wird jedes Quartal ein Backup auf eine externe Festplatte geschrieben, um noch einen dritten Standort für die Backups zu haben, aber vor allem, um noch Backups zu haben, die vom laufenden System getrennt sind.

Für dieses Quartalsbackup habe ich also eine USB Festplatte zuerst gemäss Anleitung für DPM konfiguriert. In Firestreamer habe ich eine zweite Library für diese Quartalsbackups angelegt. Diese muss nun ausgewählt werden.

Durch einen Klick auf “Aktion” –> “Edit…” kommt man in den Media Layout Editor.

Gemäss Hilfe soll man auch für externe Festplatten File Media auswählen und nicht wie man zuerst vermuten könnte Drive Media:

We recommend that you use external HDDs with Microsoft DPM in the file media mode which allows multiple virtual tapes per HDD.
Due to Microsoft DPM’s limitations, using external HDDs in the drive media mode (i.e. one virtual tape per HDD) is only feasible if you plan to have at least five external HDDs available to Microsoft DPM at any given time. Do not attempt to use a single HDD as a drive medium with Microsoft DPM because you will have trouble adding several backups to the same tape.

Wenn man nun auf “Load Media” klickt, meldet Firestreamer, dass man in DPM die “Bibliothekstüre entriegeln” muss.

Also zuerst die Türe entriegeln und dann auf “Ja” klicken…

Nun muss man bei den einzelnen Schutzgruppen die Bibliothek auf die neue mit den USB Festplatten ändern und entweder warten, bis am nächsten Termin (bei uns jeweils Freitag Nacht) das Backup auf Band ausgelöst wird, oder ein Backup auf Band manuell anstossen.

Am Schluss sollte man daran denken, die Schutzgruppen wieder auf die immer verfügbare Library umzustellen.

Wenn das Backup beendet ist, sollte man die virtuellen Bänder aus der virtuellen Bandbibliothek entfernen, bevor man einfach die externe Festplatte abzieht.

Dazu muss man erneut in DPM die Sperre der Türe aufheben und danach in Firestreamer die Medien entfernen.

Danach werden in DPM alle Bänder wieder als Empty angezeigt.

Wenn man irgendwann eine Wiederherstellung davon machen muss, kann man die Festplatte wieder anhängen und die darauf gespeicherten Bänder über “Add Existing File Media…” wieder einlesen.

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.

Früher haben wir immer ein vollständiges Backup auf Band durchgeführt. Aber mit der zunehmenden Datenflut ist das nicht mehr möglich. Eine Vollsicherung dauert im Moment ungefähr 11 Stunden, würde also den laufenden Betrieb stören. Nun gibt es die Möglichkeit, unter der Woche differentielle oder inkrementelle Backups zu erstellen, wobei ich mich entschieden habe, differentielle Sicherungen einzusetzen.

Um herauszufinden, ob eine Datei gesichert werden muss, verwendet unsere Backuplösung das sogenannte Archivbit. Windows setzt bei allen neuen oder geänderten Dateien ein solches Archivbit. Bei einer Vollsicherung am Wochenende wird dieses Archivbit von der Backupsoftware zurückgesetzt. Diese Dateien werden dann unter der Woche vom differentiellen Backup nicht mehr gesichert. Bei allen Dateien, die aber seit dem Wochenende neu angelegt oder geändert wurden, setzt Windows wieder das Archivbit. Diese so gekennzeichneten Dateien werden nun beim differentiellen Backup gesichert, das Archivbit aber nicht zurückgesetzt. Damit werden sie (im Gegensatz zum inkrementellen Backup, bei dem das Archivbit zurückgesetzt wird) jeden Tag unter der Woche erneut gesichert, auch wenn sie bereits am Montag erstellt wurden (bis bei der nächsten Vollsicherung wieder alle Archivbits zurückgesetzt werden). 

Unter Linux ist das in Windows verwendete Archivbit nicht implementiert. Um Dateien von einem Linuxserver auch in die Bandsicherung aufzunehmen, erstellt der Linuxserver eine Sicherung auf eine Sambafreigabe. Von dort werden sie über ein Skript mit Robocopy auf einen Windowsserver kopiert, damit sie in der Nacht auf Band gesichert werden können. Da aber Linux das Archivbit nicht kennt, werden diese Dateien beim differentiellen Backup ausgelassen, obwohl sie jeden Abend neu kopiert werden…

Aber wie heisst es so schön? Das sind keine Probleme, sondern nur Herausforderungen 😉
Robocopy bietet die Möglichkeit, das Archivbit beim Kopieren zu setzen mit der Option /A+:A, was soviel bedeutet wie: setze Attribut (/A+) Archivbit (:A).

Bei einer neuen Backup Exec Installation hatte ich folgende Fehlermeldung bei einem Backup mit ausgewältem “Systemstatus”: “VSS-Snapshotwarnung. Datei %BeBootDrive%\bootmgr ist im Snapshot nicht vorhanden.”

Auf der Supportseite von Symantec fand ich dann eine Beschreibung meines Problems mit der passenden Lösung.

Gemäss dieser Anleitung kann man im Registrierungseditor unter “HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec for Windows\Backup Exec \Engine\Shadow Copy Components\” einen neuen Schlüssel “Additional Not Authorized Writers” erstellen.

         

Nun kann man bei diesem Schlüssel eine neue Zeichenfolge mit dem Namen “ASR” und dem Wert “{BE000CBE-11FE-4426-9C58-531AA6355FC4}” erstellen.

Damit der “Systemstatus” korrekt gesichert werden kann, muss man jetzt noch den Auftrag aktualisieren. Gemäss Supportseite kann man dazu den Auftrag löschen und erneut erstellen oder den Systemstatus ausschliessen und anschliessend wieder hinzufügen.