Zur Zeit verwende ich System Center Data Protection Manager 2016 (DPM), der auf einem Windows Server 2016 läuft. Diese Version ist nicht mit Windows Server 2019 kompatibel. Da eine Datensicherung ein wichtiger Bestandteil meiner Infrastruktur ist, muss mein DPM auf die aktuelle Version 2019 aktualisiert werden. Dabei soll eine möglichst verlustfreie Migration des alten DPM-Servers durchgeführt werden: die bestehende Datensicherung soll also übernommen werden.

Für die Umstellung sind 2 Schritte laut Microsoft erforderlich:

1. eine Inplace-Aktualisierung des DPM von 2016 auf 2019 auf dem Windows Server 2016
2. eine Inplace-Aktualisierung des Betriebssystems von Windows 2016 auf 2019

Nur so können die bestehenden Sicherungen übernommen werden.

Mein DPM nimmt auch die SystemState-Backups meiner Windows Server entgegen. Alle Server speichern diese in eine SMB-Freigabe. Der DPM wiederum lenkt die Daten auf eine via iSCSI angebundene NAS um. BMR steht hier für BareMetalRecovery und ermöglicht die Wiederherstellung eines Windows Servers in einen leeren Computer. Das bietet sich besonders bei Problemen mit dem Betriebssystem (nach einem Update, einer verpatzten Konfiguration, …) an. Auch diese Funktion soll das System weiter ausführen.

Zuerst prüfe ich den aktuellen Systemzustand. Die Datensicherung funktioniert tadellos. Das Betriebssystem ist UpToDate. Es ist ausreichend freier Speicher vorhanden.

Auch in den Eventlogs finde ich keine Probleme:

Der Zuverlässigkeitsverlauf ist eine schnelle Möglichkeit für einen Systemcheck. Auch hier gibt es außer einem ungeplanten Shutdown keine Probleme:

Der DPM verwendet für die Verwaltung seiner Backups eine lokale SQL-Datenbank. Von dieser erstelle ich noch schnell eine Datenbanksicherung, denn die Aktualisierung des DPM wird auch das Schema dieser DB verändern. Mein Serveradmin hat aber nicht (mehr) die erforderlichen Berechtigungen. Der Zugriff auf die DB wird verweigert. Aber dank meiner (fast) lückenlosen Dokumentation fand ich im Installationslog des DPM 2016 den richtigen Hinweis. Folgender Account ist berechtigt:

Nun korrigiere ich die Berechtigungen mit dem Account admin-setup und berechtige eine neue AD-Gruppe, in der mein Serveradmin nun Mitglied ist. So kann die Sicherung erstellt werden:

Nun folgt noch ein Blick auf das Ergebnis der letzten Serversicherung. Hier gab es 2 Aussetzer. Aber eine Sicherung steht zur Verfügung. Es sollte also bei Problemen ein Rollback möglich sein.

Schritt 1 der Anweisungen von Microsoft ist die Aktualisierung des DPM von Version 2016 auf 2019. Das wird durch Ausführung des Setups erledigt:

Die Vorprüfung ergibt, dass hier noch weitere Vorarbeiten erforderlich sind: der SQL-Server hat eine zu alte Version. Stimmt, hier werkelt noch ein SQL Server 2012 drunter. Also beende ich das Setup des DPM und aktualisiere den SQL-Server Inplace auf Version 2017.

Drei Inplace-Updates … ob das gut geht??

Für das Update der SQL-Instanz beende ich den DPM-Service. So ist die Datenbank frei von Zugriffen:

Auch der SQL-Server wird über das Setup aktualisiert:

Aber einen Moment mal. Hier stimmt was nicht: die SQL-Engine wird nicht in der Zusammenfassung gelistet. Das wird nicht ausreichen!

Naja, im Bereich SQL-Server bin ich etwas eingerostet. Vielleicht kann ich die Version auf 2016 statt 2017 aktualisieren? Leider nein, dieses Setup zeigt sogar einen Fehler an:

Stop! Das artet in ein Gefummel aus: erst wehrt sich der SQL-Server beim Upgrade, danach vielleicht auch der DPM. Und selbst wenn das alles irgendwie funktioniert – wer weiß, ob das Betriebssystem-Upgrade sauber durchläuft??

Ganz ehrlich: ich denke, eine Neuinstallation ohne Mitnahme der bestehenden Backups ist auf lange Sicht betrachtet die bessere Alternative! Ich habe den Vorteil, dass meine Backups nicht so viel Speicherplatz belegen und relativ schnell wieder aufgebaut sind. Große Unternehmen haben hier eher einen Nachteil. Natürlich kann man auch SideBySide (alt neben neu) migrieren und die neuen Backups erstellen, während die alten noch verfügbar sind. Nur kostet diese Variante für die Übergangszeit auch entsprechend viel Speicherplatz.

Ob das bei anderen Sicherungsprogrammen auch so kompliziert ist?

OK, für den Neuaufbau möchte ich zuerst einmal die aktuelle Konfiguration des DPM auslesen und dokumentieren. Also aktiviere ich die zuvor beendeten Dienste des DPM. Nur leider lassen sich diese nicht wieder einschalten! Der Fehler scheint am SQL-Server zu liegen. Offensichtlich haben meinen Aktualisierungsversuche am SQL die Instanz beschädigt. Super!

Aber ich habe ja ein Backup des Betriebssystems. Genau für diese Szenarien prüft man VORHER den Zustand des Systems inklusive der Datensicherung.

Ich sichere meine Betriebssysteme mit Windows Boardmitteln (Windows Backup) über eine zentral gesteuerte Scriptlösung auf mehrere Netzlaufwerke. Dazu kommt ein Rotationsverfahren. Ich muss also zuerst herausfinden, in welches Verzeichnis zuletzt erfolgreich gesichert wurde:

Damit nicht noch mehr verlorengeht, erstelle ich im Hyper-V für die VM des DPM eine neue VHDX-Datei. So kann ich bei Bedarf auf den aktuellen Zustand zurückgehen.

Nun starte ich die VM mit einem Installationsdatenträger und hangele mich zu der SystemImageRecovery:

Die Datensicherung liegt nicht lokal. Daher zeigt das Setup eine Fehlermeldung an:

Über „erweitert“ kann aber eine Verbindung zum Netzwerk hergestellt werden. Dazu ist aber ein DHCP-Server erforderlich:

Mmh, das ist mir neu! Dem Benutzer admin-setup habe ich die erforderlichen Berechtigungen gewährt. Er sollte das Backup erreichen können. Was ist wohl die Ursache? Ich führe regelmäßig Wiederherstellungsversuche durch. Und diese habe mit diesem Account immer funktioniert. Was ist hier los?

Na klar! Die Anmeldung am Zielsystem wird über NTLM durchgeführt, da das Recovery-OS kein DomainMember ist und somit kein Kerberos verwenden kann. Und vor einiger Zeit hatte ich in meiner Umgebung NTLM deaktiviert. Auf den DomainControllern kann man das dank des NTLM-Audits sehr schön sehen:

Dafür gibt es in der GPO aber die Option von Ausnahmen. Und hier sieht man das Problem: Bisher wurde die Datensicherung von meinem DPM-Server auf WS-HV2 gespeichert. Diesen Server habe ich aber vor einigen Tagen durch WS-HV3 ersetzt. Und dieser Server steht NICHT in den Ausnahmen. Das hole ich nun nach:

Ich starte einen neuen Versuch. Aber auch dieser scheitert:

Die GPO wurde mit der Änderung erfolgreich verarbeitet. Die Ursache ist aber immer noch die Gleiche: NTLM wird nicht erlaubt. Auch hier kommt eine kleine Änderung am Account admin-setup zum Tragen: der Benutzer ist seit Neustem Mitglied der Gruppe „Protected Users“. Und diese dürfen kein NTLM verwenden…

Also nehme ich den Benutzer aus der Gruppe heraus und versuche es erneut. Dieses Mal mit Erfolg:

Die Wiederherstellung läuft. Im Hyper-V beobachte ich das Anwachsen der neuen VHDX:

Nach einigen Minuten ist das System wieder online:

Hier sieht man, wie wichtig regelmäßige Wiederherstellungen in der Produktion sind! Stellt euch dieses Szenario mal mit einem wichtigen Produktionssystem vor! Wenn dann der Stresspegel nach oben schnellt, wird der Erfolg der Recovery gefährdet sein! Bei meiner nächsten Test-Recovery hätte ich diese Fehlkonfiguration bemerkt und völlig stressfrei korrigiert.

Zwei Bemerkungen noch am Rande:

1. Ich spreche Kunden und Kursteilnehmer regelmäßig auf Recovery-Versuche an. Oft höre ich, dass diese in Testumgebungen ausgeführt werden. Ich bin kein Fan dieser Vorgehensweise. Eine Testumgebung wird niemals das Original wiederspiegeln können. Diese Infrastrukturen sind meist idealisierte und minimierte Umgebungen ohne reale Anforderungen. Führt die Tests besser in der Produktion aus.
2. Wie das geht? Genauso, wie ich eben wiederhergestellt habe: ich suche mir ein System heraus. In den allermeisten Fällen ist das eine VM. Diese wird (in der Wartungszeit) heruntergefahren und bekommt eine neue virtuelle Festplatte. Dann starte ich die Recovery. Wenn diese abgeschlossen ist, dann kann die VM entweder weiterbetrieben werden oder sie wird heruntergefahren und die alte Festplatte wird wieder eingebaut. Hierfür sind gute Kenntnisse des Services in der VM erforderlich. Aber die sind im Recovery-Fall immer wichtig! Und auch reale Hosts können getestet werden: entweder auf Reserve-Hardware oder in einer leeren VM (P2V).

Nun kann ich die bestehenden Sicherungsaufgaben erfassen und dokumentieren. Diese habe ich nach dem Typ der zu sichernden Daten definiert.

Die erste Schutzgruppe sichert meine Exchange-Server-Datenbanken:

Die 2. schützt meine Fileservices:

In der 3. sichere ich alle VMs, die ich nicht mit der Windows -Serversicherung intern erfassen kann – also meine Linux-Systeme:

Die 4. Gruppe ist etwas spezieller. Hier sichere ich standortübergreifend eine Anwendung meines anderen Geschäfts:

Die Sicherungen werden auf den Quellservern über dort installierte Agents erstellt. Diese Agents sind mit DPM 2019 nicht kompatibel. Da ich nicht abschätzen kann, ob es bei deren Neuinstallation zu Problemen kommt, werde ich sie jetzt deinstallieren. Das lässt der DPM 2016 aber nur zu, wenn die Agents keine zugewiesenen Sicherungsaufgaben mehr haben. Also muss ich die Schutzgruppen zuerst löschen:

Nun deinstalliere ich die Agents:

Oder auch nicht. Na gut. Dann eben lokal auf den Quellservern:

Auf dem Server sind noch einige Aufgaben und Scripte vorhanden, die den Zustand der Datensicherung überwachen sollen. Diese exportiere ich auf mein AdminShare.

Und nun kann ich den alten DPM-Server abschalten. Die VM hebe ich noch etwas auf, falls ich noch was vergessen habe. Zudem könnte ich über den alten DPM immer noch auf die bisherige Datensicherung zugreifen. Aber das System soll nicht mehr automatisch mitstarten. Daher benenne ich die VM im Hyper-V-Manager um und verhindere den automatischen Start:

Im Monitoring pausiere ich die Sensoren, damit mein Handy Ruhe gibt.

Nun habe ich eine grüne (Backup-)Wiese. Es wird Zeit für den neuen DPM 2019. In der realen Welt würde ich diese Schritte natürlich vorziehen, damit die alte Sicherung parallel noch weiterläuft.

Für den neuen DPM 2019 erstelle ich eine VM mit Windows Server 2019 als Basis. Das Image war bereits vorbereitet und es startet im OOBE-Modus. Nach wenigen Eingaben war das Betriebssystem bereit.

Ich möchte gerne den Namen des Servers wiederverwenden. Daher setze ich das Konto im AD zurück und benenne den neuen Server in WS-DPM um. Danach darf er der Domain beitreten:

Auch die IPv4 möchte ich weiterverwenden und trage die 192.168.100.5/24 ein. Damit erspare ich mir die Anpassung der Firewall-Regeln.

Noch ein kurzer Blick auf die Windows Updates: hier ist alles UpToDate, da ich das Image erst erstellt hatte.

Nun bekommt der Server Zugriff auf die Datenträger für die Sicherung. Diese werden über iSCSI von einer NAS bereitgestellt. Ich starte die iSCSI-Konfiguration:

Beide Datenträger wurden korrekt eingebunden:

Das Betriebssystem ist nun eingerichtet.

Es fehlt noch ein SQL-Server, den der DPM 2019 für seine Konfigurationen verwenden kann. Diesen installiere ich aus Restore-Gründen lokal: sollte es zu einem Totalausfall meiner Infrastruktur kommen, dann muss ich „nur“ den DPM-Server mit seiner BMR (wie oben gezeigt) recovern und dann habe ich Zugriff auf meine Nutzdatensicherung.

Der SQL-Server soll die Version 2017 verwenden. Ich starte das Setup:

Die Warnung ignoriere ich. Eine Firewall-Ausnahme kann ich später noch erstellen:

Ich installiere nur die notwendigen Features:

Dazu bekommt die Instanz einen hübschen Namen. Dem DPM kanns egal sein:

Die Principals der Services lasse ich unverändert. Das kann ich bei Bedarf auch nach dem Setup anpassen:

Ganz wichtig ist aber der Zugriff auf die Instanz. Lokale Administratorenrechte genügen seit Langem nicht mehr. Und weiter oben hat man gesehen was passiert. Wie gut, wenn man eine Dokumentation hat. Und passende AD-Gruppen zur Rechtedelegation:

Die Datenbank-Pfade lege ich etwas klarer an:

So kann das Setup starten. Und nach wenigen Minuten ist die Instanz bereitgestellt:

Nun installiere ich noch das SQL-Server Management Studio (SSMS). Dieses soll im Problemfall einen schnellen und komfortablen Datenbankzugriff ermöglichen:

Nach dem Neustart konfiguriere ich nun die Services des SQL-Servers. Im Active Directory habe ich einen Group Managed Service Account (gMSA) eingerichtet, welcher die Instanz betreiben soll. Für die Konfiguration kann nicht die GUI des SQL verwendet werden. Hier hat Microsoft leider nur die PowerShell vorgesehen. Aber vor einiger Zeit habe ich mir eine GUI mit der PowerShell programmiert (die gibt’s im Blog von ws-its.de). Mit dieser kann der Account leicht konfiguriert werden:

Nun aktiviere ich noch die Named Pipes, da der DPM die für den Zugriff benötigt:

Der DPM 2019 braucht aber auch die Reporting-Services in der Version 2017. Diese werden über ein separates Setup installiert:

Nach dem Setup benötigt der Reporting Service noch eine Einrichtung. Dafür steht ein eigenes Tool bereit:

Die weiteren Fragen bestätige ich einfach durch:

Nun ist der SQL-Server einsatzbereit.

Jetzt kann der DPM 2019 installiert werden. Das Setup bietet auch hier eine geführte Installation:

Hier gebe ich den SQL-Server mit seiner Instanz an. Wenn man keine Named Instance installiert hat, genügt der Servername:

OK, ich hatte meinen gMSA nur für den SQL-Service konfiguriert. Aber der Agent soll diesen auch verwenden. Also starte ich noch einmal meine GUI für die gMSA-Administration (auf meinem DomainController):

Und natürlich setze ich den SQL-Agentservice auf AutoStart.

Aber auch das Dienstkonto der Reporting-Services benötigt eine Anpassung. Da es schon konfiguriert ist muss ich die Verschlüsselungsschlüssel der RS-Datenbank sichern. Das geht wieder in der RS-Konfigurationsoberfläche:

Nach einem Neustart sind alle SQL-Services passend konfiguriert. Nun starte ich das DPM-Setup bis zur Vorprüfung erneut. Leider wird aber noch ein Fehler gemeldet. Details dazu finde ich in einer Textdatei:

Aha. Das passt etwas mit den Reporting-Services nicht. Ich starte dessen Konfiguration erneut und prüfe noch einmal alle Optionen. Schade: Ich hatte die Webdienst-URL vergessen:

Das sieht besser aus. Und was sagt das DPM-Setup dazu? Eine erneute Prüfung gibt mir grünes Licht:

Aktualisierungen erhält der DPM über meinen WSUS-Server:

Nach wenigen Minuten ist der DPM 2019 einsatzbereit.

In der Verwaltungsoberfläche füge ich zuerst den Datenspeicher dazu. Auf diesen sichert der DPM meine Nutzdaten. Der Datenträger ist aktuell eine LUN auf meiner Backup-NAS – angebunden durch iSCSI:

Nun installiere ich die Sicherungs-Agents auf den Quell-Servern. In den vorherigen Versionen des DPM gab es immer Probleme bei der Push-Installation vom DPM aus, wenn die Zielserver eine aktive Windows Firewall haben. Daher installiere ich die Agents lieber lokal auf meinen Servern. Für einen bequemen Zugriff auf die Installer erstelle ich daher auf dem DPM eine Freigabe:

Mit einem passenden Account melde ich mich nun auf meinem Fileserver, meinen Exchange-Servern und den Hyper-V-Hosts an und installiere das Setup:

Leider hat das Setup keine Konfigurationsdatei (das wäre ja intuitiv). Daher muss ich auf den Agent-Systemen noch einen Befehl in der cmd absetzen. Dafür habe ich ein Script erstellt:

Nun wissen die Quellserver, welchen DPM sie verwenden sollen. Der DPM selber muss aber auch noch unterrichtet werden. Dafür gibt es die Option „Agents verbinden“:

Der Dialog zeigt die hinzugefügten Server leider nicht an. Ein harmloser Bug…

Nun kann der DPM mit den Quellservern kommunizieren. Es fehlen noch die Sicherungsaufgaben (Schutzgruppen). Ich beginne mit dem „Schutz-Exchange“: Das System erkennt zuverlässig meine Exchange-DAG:

Wie in der Vorgängerversion wird auch beim DPM 2019 die zum Exchange-Server passende eseutil-Anwendung benötigt, wenn der DPM die gesicherten Datenbanken in seinem Repository in einen Clean-Shutdown-State überführen soll. Diese Dateien hat der Exchange-Server gespeichert. Ein paar Klicks später liegen sie auch im DPM bereit:

Nun kann ich die Datenbanken dem richtigen Sicherungsverfahren zuweisen. Meine aktiven DBs bekommen eine Vollsicherung. Die Kopiesicherungen sind für die passiven DBs:

Die Sicherung bekommt auch einen Zeitplan:

Als Sicherungsziel wähle ich die eine Partition auf der iSCSI-Disk:

Der DPM darf die initiale Sicherung sofort beginnen. Die Sicherung wird online erstellt. Es sollte also keine Serviceunterbrechung für meine Exchange-Benutzer geben:

Die Sicherung läuft an. Analog verfahre ich mit den Schutzgruppen „Schutz-Fileserver“, „Schutz-HyperV“ und „Schutz-JB“ (CRM). Somit ergibt sich folgender Sicherungsstand:

Da der DPM 2019 seinem Vorgänger extrem ähnlich sieht rechne ich nicht mit einer Verbesserung im Monitoring. Daher importiere ich meine eigene Scriptlösung, die mich jeden Morgen über den Sicherungserfolg informiert. Dazu erhält der Server weitere Aufgaben. Diese hatte ich im alten DPM einfach als XML exportiert:

Einige der Aufgaben laufen wieder im Kontext eines gMSA-Accounts. Diese weise ich wieder mit meiner PowerShell-GUI vom DomainController aus zu:

Nun erstelle ich noch die Freigabe für meine BMR-Sicherungen, konfiguriere die Deduplizierung und entferne im Hyper-V-Server die alte VM.

Im Monitoring gab es keine Anpassung, da ich die IPv4 und den Namen des Servers wiederverwende.

Die initiale Sicherung lief eigentlich ganz gut durch. Dennoch hat der DPM-Monitor (mein PowerShell-Script) immer wieder Fehler gemeldet:

Man erkennt deutlich, dass einige Sicherungen fehlschlagen. Das kann ich so nicht gebrauchen. Und auch meine BMR-Sicherungen, die von Windows-Server-Backup erstellt werden schlagen immer wieder fehl.

In den Eventlogs finde ich zahlreiche iSCSI-Fehler. Kann der Windows Server 2019 etwa nicht vernünftig mit meiner NAS kommunizieren?? Als Test binde ich einen anderen Windows Server 2019 via iSCSI an das NAS-Target an und kopiere testweise ein paar Daten. Und auch dieser kommt ins Stocken!!! Zur Validierung versuche ich das Gleiche von einem Windows Server 2016 – und auch dieser hat Probeme! Puh, es ist nicht das Betriebssystem. In der NAS, die nun auch schon einige Jahre im 24/7-Betrieb operiert, kommen die Platten an ihre Grenzen. Offenbar ist das vorher nicht aufgefallen, da der DPM keine Vollsicherungen erstellt, sondern nur Incrementals vom Quellserver zieht. Die komplette Vollsicherung meiner Nutzdaten war wohl zuviel.

In meinem neuen Hyper-V-Host hatte ich aber noch ne andere 4TB-Platte verbaut. Auf dieser erstellte ich eine neue VHDX und wies sie dem DPM zu. Natürlich musste er die gesamte Sicherung erneut erstellen, denn beim Versuch die Daten vom iSCSI-NAS auf VHDX zu verschieben kam das System wieder an seine Schmerzgrenze. Aber nun laufen alle Backups ohne Probleme durch!

Und auch die BMR-Sicherungen meiner Windows Server landen nun in einer weiteren VHDX, die im DPM freigegeben ist. Für die räumliche Trennung meiner Datensicherung habe ich schon eine andere Idee. Daher können die Sicherungen primär auf einer anderen Disk im gleichen Server landen.

Die DPM-Sicherungen laufen hervorragend. Nur meine BMR-Sicherungen kommen nicht nach. Diese werden über eine zentral gesteuerte Scriptlösung von den Servern nacheinander (!) ab 01:00 täglich ausgeführt. Bisher reichte das Zeitfenster bis kurz vor 04:45. Danach erfasst ein anderes Script das Ergebnis und berichtet mir per Mail. Nach der Umstellung sehen die Mails leider so aus:

Die rot markierten Server mit den ?? haben erfolgreich gesichert. Nur leider nicht mehr innerhalb des Sicherungszeitfensters. Die Sicherung ist nun oft erst nach 08:00 abgeschlossen!

Doch was ist die Ursache? Es muss etwas mit der Auslastung der physischen Festplatte zu tun haben. Das könnte ein anderer Task sein, der zur gleichen Zeit die Platte intensiv belastet. Und da hab ich auch schon einen Treffer: um Plattenplatz zu sparen habe ich auf dem DPM-Server die Deduplizierung des Volumes der BMR-Sicherungen aktiviert (da spart man richtig viel Speicher!). Blöderweise läuft diese 02:45 an – genau während der Sicherung:

Die Zeitplanung lässt sich aber im Servermanager anpassen.

Insgesamt habe ich mein Ziel erreicht: Der DPM läuft mit der aktuellen Version 2019 auf einem Windows Server 2019. Nur der Weg sah leider nicht so aus, wie ich es geplant hatte. Durch ein Inplace-Upgrade des SQL-Servers, des DPM-Servers und des Windows-Servers hätte ich meine alten Datensicherungen einfach weiterführen können. Aber Inplace … wie es aussehen kann habe ich seitenweise beschrieben. Und selbst wenn ich einen Weg durch die Probleme des Upgrades finde: Wer garantiert mir, dass der DPM danach auf lange Sicht betrachtet auch wirklich stabil läuft – und im Worstcase auf zuverlässig die Backups erfolgreich wiederherstellt?? Eben.

In meiner kleinen Umgebung konnte ich auf meinen Backupbestand verzichten. In großen Infrastrukturen muss die Sicherung Side-By-Side neu aufgebaut werden. Noch einmal ein Inplace? Nein danke!

Stay tuned!

Ach ja: Wie üblich gibt es 2019-08-15 WS-DPM hier diesen Beitrag auch als PDF.