1
30. November 2016

System Center 2016 Blogpostreihe – Teil 2: Data Protection Manager

Haben Sie sich System Center 2016 schon angeschaut? Sind Sie schon in die Planung eines Upgrades eingestiegen? Lesen Sie in dieser Blogpostreihe, was bei einem Upgrade alles schief laufen kann und wie Sie die Probleme lösen können. Heute geht es um das Upgrade des Data Protection Manager.


Im zweiten Teil meiner Blogpostreihe zu System Center 2016 geht es um DPM 2016. Wie jedes Mal gehe ich kurz auf die Ausgangssituation ein und schildere dann meine Erkenntnisse, aufgetretene Probleme und deren Lösungen. Ich gehe auch auf den Modern Backup Storage ein, der die Speicherverwaltung in DPM revolutioniert.

Kurze Einführung in Modern Backup Storage (MBS)

Hier werden die Änderungen kurz beschrieben. Einer der Hauptgründe auf DPM 2016 upzugraden ist sicherlich MBS. Mit MBS sind die alten Konzepte und Probleme mit der Verwaltung der dynamischen Disks/Volumes, Logical Disk Manager, fehlgeschlagene Backups aufgrund zu wenig Speicherplatz im Replica-/Recoverypoint-Volume usw. Geschichte. Anders als früher stellt man dem DPM keine Disks sondern Volumes zur Verfügung, die DPM mit ReFS formatiert. Eine Sicherung von z.B. einer Exchange DB kann bei der Aufnahme im DPM einem festen Volume zugewiesen werden. Man kann nun steuern, wo welche Sicherung im DPM-Storage abgelegt wird bzw. kann DPM je nach Workload automatisch das entsprechende Volume zuweisen. Damit weiterhin eine Vergrößerung der DPM-Volumes möglich ist, sollten die DPM-Volumes mit Storage Spaces bereitgestellt werden.

Allgemeine Hinweise

Da mich die Situation gewundert hat, sei folgendes hier erwähnt. Leider unterstützen weder DPM 2012 R2 noch DPM 2016 die Sicherung von SQL Server 2016. Und Exchange Server 2016 wird aktuell nur von DPM 2012 R2 supported. Dies ist hier nachzulesen. Ebenso kann DPM 2016 keine VMware VMs auf Hostebene sichern, was DPM 2012 R2 UR11 kann. Dies wird mit UR2 für DPM 2016 kommen. Bei der Planung des Upgrades müssen diese Punkte beachtet werden.

Ausgangssituation

  • DPM 2016 Technical Preview 5 Umgebung mit sieben Agents
    1xExchange, 1xSharepoint, 2xHyper-V Host, 1xFileserver, 1xDomaincontroller, 1xClient
  • DPM-Server läuft unter Windows Server 2012 R2 als Hyper-V VM
  • Agents laufen auf Systemen mit Windows Server 2008 R2/2012/2012 R2 und Windows 10 als Hyper-V VMs
  • Als SQL-Instanz verwende ich SQL 2012 mit SP3
  • Langzeitbackup erfolgt nach Azure

Zielvorgabe

  • Inplaceupgrade des DPM-Servers
  • Update aller Agents
  • Alles soll nach dem Upgrade noch funktionieren, bzw. noch besser 😉
  • Einsatz von Modern Backup Storage inkl. Migration der alten Backupdaten, also ist das UR1 für SCDPM 2016 zwingend notwendig

Vorgehensweise

In der Technet wird der Upgradepfad auf DPM 2016 und MBS beschrieben.
Aus dem Artikel geht nicht ganz klar hervor, ob ein Inplace Upgrade des OS supported ist. Bis Windows Server 2012 R2 war das nicht supported. Mike Jacquet bestätigt aber hier, dass ein Inplace Upgrade auf Windows Server 2016 supported ist.

Es ist also ein Inplace Upgrade eines bestehenden DPM Servers von Windows Server 2012 R2 und DPM 2012 R2 UR10 auf Windows Server 2016 und DPM 2016 möglich! Alter Storage und MBS können nebeneinander koexistieren! Und das Beste: „Backups will continue without rebooting your production server.“ Ein Versionsupgrade ohne Reboot aller Server, das ging in der Vergangenheit noch nicht mal bei bestimmten URs. Gut gemacht, Microsoft!
Eine kleine Einschränkung gibt es, nachzulesen unten bei den möglichen Problemen.

Also kurz zusammengefasst die einzelnen Schritte:

  • Upgrade DPM 2012 R2 auf DPM 2012 R2 Update Rollup 10 – ich hatte schon DPM 2016 TP5 installiert
  • Upgrade DPM 2012 R2 Update Rollup 10 zu DPM 2016 UR1 – bei mir war es ein Upgrade von DPM 2016 TP5 auf DPM 2016
  • Upgrade der Agents auf den Protected Servern
  • Upgrade Windows Server 2012 R2 auf Windows Server 2016
  • Upgrade DPM Remote Administrator Konsole auf allen Systemen – gibt es bei mir keine
  • Sofern mindestens UR6 für DPM 2012 R2 installiert war, erfordert der gesamte Prozess KEINEN Neustart der Protected Server – ich hatte ja schon DPM 2016 TP 5 installiert

Upgrade des DPM-Servers und der Agents

Meinen DPM hatte ich schon vor ein paar Tagen von DPM 2012 R2 UR 11 auf DPM 2016 upgegraded. Das verlief ohne Probleme und es war wirklich kein Neustart der Agents notwendig. Es fehlten also nur das UR1 und Windos Server 2016, damit auch MBS genutzt werden kann. Also schnell einen Checkpoint der VM gemacht und das Upgrade auf Windows Server 2016 gestartet. Dies ist der dritte Server, den ich auf Windows Server 2016 anhebe. Auch dieses Mal verlief, wie bei den beiden anderen, alles problemlos. Nach dem Upgrade habe ich noch Windows Updates installiert (ja, es gibt schon Updates für 2016 😉 ).
Übrigens: Wer Longterm Backup nach Azure macht muss sicherstellen, dass der Azure Backup Agent für DPM mindestens auf der Version 2.0.9050.0 ist bevor auf UR1 upgedatet wird. Den Agent hatte ich schon vor ein paar Tagen upgedatet.
Zuletzt also noch das UR1 für DPM 2016. Die DPM-Agents mussten noch über die DPM-Konsole upgedatet werden. Auch hier verlief alles ohne Probleme und ohne Neustarts der Server. Zur Sicherheit habe ich nochmal die Funktionalität von DPM geprüft. Recoverypoints auf Disk und in der Cloud konnte ich noch erstellen.
Somit war das Upgrade an sich durch. Nun ging es an die Migration auf MBS.

Migration auf MBS

Hier eine Übersicht des derzeit verwendeten klassischen DPM-Storage:

klassischer DPM-Storage:
klassischer DPM-Storage

Ich habe dem DPM zunächst 5 neue Volumes hinzugefügt:

neue Volumes für MBS
neue Volumes für MBS

Wie ich diese bereitgestellt habe, beschreibe ich in einem zukünftigen Blogpost. Nur so viel: Da es sich bei meinem DPM um eine VM handelt, sind die zugrundeliegenden Disks dynamische VHDX. Diese sind im Windows Server 2016 über Storagespaces als Virtual Disks und Volumes als Mountpoint unter „C:\DPM-Storage“ bereitgestellt. So besteht weiterhin die Möglichkeit, die DPM-Disks im laufenden Betrieb ohne Migration zu erweitern und ich bin nicht an die 26 Buchstaben des Alphabets gebunden. Für meine vorhandenen Workloads habe ich jeweils ein Volume bereitgestellt.

Danach habe ich Protectiongroup für Protectiongroup umgestellt nach folgender Vorgehensweise:

  • Einstellungen der Protectiongroup notiert
  • Protectiongroup gelöscht und Daten beibehalten
  • Neue Protectiongroup mit den gleichen Einstellungen angelegt und als Storage den entsprechenden MBS ausgewählt

Am Beispiel meiner Exchange DB möchte ich den relevanten neuen Dialog zeigen. DPM zeigt sehr übersichtlich den verfügbaren Target Storage an mit den freien Kapazitäten. Da ich eine Exchange DB sichern möchte, bietet er mir direkt den als Exchange Workload klassifizierten Target Storage an.

Storage Allocation Dialog
Storage Allocation Dialog

DPM schlägt den Target Storage je nach Workload (im Beispiel hier „DPM-Exchange“) automatisch vor, ich kann diesen aber anpassen. Eine Größe für ein Replica- oder Recoverypoint-Volume muss ich nicht mehr definieren.
DPM migriert nun die Daten vom alten Storage auf den Target Storage. Dies kann in den Jobs überprüft werden.

Post Recovery Operation
Post Recovery Operation

Das Replica wird danach auf den Status inkonsistent gesetzt. Es muss also ein Konsistenzcheck durchgeführt werden.

Replica inkonsistent
Replica inkonsistent

So habe ich alle Protectiongroups umgestellt. Natürlich habe ich danach geprüft, ob die Backups korrekt laufen und auch Restoretests gemacht. Alles funktionierte einwandfrei.

Mögliche Probleme

Bei der Aktualisierung in Kundenumgebungen sind mittlerweile folgende Probleme aufgetreten:

Nach dem Upgrade auf DPM 2016 laufen keine Jobs mehr:
Wenn nach dem Upgrade auf DPM 2016 die Jobs in die Queue laufen, aber keine Daten übertragen werden, dann sollte geprüft werden, ob der DPMRA-Dienst auf dem DPM-Server selbst läuft. Lässt sich der nicht starten sollte geprüft werden, ob die VssRequestor.dll im BIN-Verzeichnis des DPM-Servers vorhanden ist. Wenn nicht, von einem funktionierenden System kopieren. Nachdem der DPMRA Dienst gestartet werden konnte, liefen auch alle Jobs wieder fehlerfrei.

DPM-Agent lässt sich nicht auf Windows Server 2008 R2 Systemen aktualisieren:
Auf Windows Server 2008 R2 Systemen muss das Windows Management Framework (WMF) 4.0 installiert sein, bevor der Protection Agent aktualisiert wird. Dieses erfordert einen Neustart. In der Microsoft Dokumentation wird dies so angegeben. Allerdings reichte auf meinen Windows Server 2008 R2 Systemen auch das WMF 3.0. Dieses hatte ich schon vor einiger Zeit installiert. Damit lies sich der Agent auch aktualisieren, ohne einen Neustart. Die Sicherungen liefen damit auch fehlerfrei.

Ein Gedanke zu „System Center 2016 Blogpostreihe – Teil 2: Data Protection Manager“

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.