2026 Windows Server 2025 sichern: Was vor der vollständigen Wiederherstellung zu prüfen ist

Ein Sicherungslauf für Windows Server 2025 endet erfolgreich, aber niemand hat geprüft, ob sich der Server damit tatsächlich wiederherstellen lässt.

Sichern Sie Systemstatus, Geschäftsdaten und erforderliche Konfigurationen auf ein unabhängiges Ziel. Testen Sie anschließend die Wiederherstellung einzelner Dateien und den vollständigen Wiederherstellungsweg. Solange die passende Wiederherstellung nicht praktisch geprüft wurde, gilt die Sicherung nicht als verifiziert.

Dieser Leitfaden richtet sich an IT-Verantwortliche, die Windows Server 2025 neu einrichten und den Sicherungsumfang festlegen müssen.
Er hilft auch Verantwortlichen, deren geplante Sicherungen noch nie testweise zurückgespielt wurden.
Teams, die Windows-Geschäftsanwendungen auf einem dedizierten Server betreiben, finden hier Prüfpunkte für ein eigenständig organisiertes, externes Sicherungsziel.

Zuletzt aktualisiert am 25.10.2026; geprüft anhand der Microsoft-Dokumentation zu Windows Server Backup, wbadmin und zur vollständigen Serverwiederherstellung.

Zuerst den Wiederherstellungsfall festlegen

Eine Sicherung ist kein einzelner Schalter. Zuerst muss feststehen, was nach einem Fehler wieder verfügbar sein soll. Eine versehentlich gelöschte Datei erfordert einen anderen Wiederherstellungsweg als ein beschädigter Systemstatus oder ein Server, der nicht mehr startet.

Legen Sie für jede Anwendung fest, welcher Zustand wiederhergestellt werden muss. Berücksichtigen Sie dabei mindestens:

• Dateien und Datenbanken der Anwendung: Welche Volumes, Verzeichnisse und Datenbestände enthalten die aktuellen Geschäftsdaten?
• Systemstatus: Welche systembezogenen Einstellungen und Komponenten müssen zurückkehren, damit der Server wieder korrekt arbeitet?
• Vollständiger Server: Welche Volumes und Startkomponenten sind erforderlich, wenn Windows nicht mehr startet?
• Anwendungskonfiguration: Welche IIS-Einstellungen, Zertifikate, Skripte, Aufgaben und Abhängigkeiten müssen zusätzlich verfügbar sein?

Ermitteln Sie gemeinsam mit den fachlich Verantwortlichen die tolerierbare Datenlücke und die gewünschte Wiederanlaufzeit. Diese Werte hängen von der Anwendung und ihren Arbeitsabläufen ab; ein allgemeingültiger Richtwert lässt sich daraus nicht ableiten. Dokumentieren Sie, welche Datenquelle für den jeweiligen Fall maßgeblich ist und wer die Wiederherstellung freigibt.

Müssen Systemstatus und Geschäftsdaten getrennt gesichert werden?
Nicht zwingend in getrennten Aufträgen. Sie müssen aber als unterschiedliche Wiederherstellungsbedarfe geprüft werden. Eine Sicherung ausgewählter Dateien ersetzt keine Systemstatussicherung; eine Systemstatussicherung ersetzt umgekehrt nicht automatisch die Sicherung aller Anwendungsdaten. Microsoft beschreibt die vollständige Serversicherung und die verfügbaren Sicherungswege in der Dokumentation zu Windows Server Backup für einen vollständigen Server.

Das Sicherungsziel vom Ausfallbereich trennen

Eine weitere Partition im selben Server kann bei einem einzelnen Plattenfehler helfen, löst aber nicht den Ausfall des gesamten Systems. Auch ein erfolgreicher Sicherungslauf schützt nicht, wenn Produktionsserver und Sicherungskopie gleichzeitig durch denselben Vorfall betroffen sind. Das Ziel sollte daher außerhalb des Ausfallbereichs der Produktion liegen.

Windows Server Backup kann mit lokalen Datenträgern und unterstützten Netzwerkfreigaben arbeiten. Entscheidend sind das passende Ziel, ausreichende Berechtigungen und die Prüfung, ob dort tatsächlich die benötigten Sicherungsversionen vorhanden sind. Eine Freigabe auf einem anderen Server ist nicht automatisch unabhängig: Verzeichnisrechte, Anmeldeinformationen, Netzwerkzugriff und Aufbewahrung müssen ebenfalls funktionieren.

Kann wbadmin auf eine Netzwerkfreigabe sichern?
Ja, sofern Zielpfad und Berechtigungen korrekt eingerichtet sind. Microsoft führt ein Netzwerkziel als Sicherungsziel für wbadmin start backup auf. Die Freigabe muss zum Sicherungszeitpunkt erreichbar sein; die Berechtigung muss für den ausführenden Auftrag gelten. Verwenden Sie in einem Skript keine offen gespeicherten Zugangsdaten. Prüfen Sie außerdem, wie vorhandene Sicherungen auf dem Ziel erhalten bleiben, bevor ein neuer Lauf ältere Versionen überschreiben könnte. Die Befehlsreferenz für wbadmin start backup erläutert Parameter und Zielangaben.

Bewerten Sie das Ziel vor der Konfiguration anhand dieser Punkte:

• Liegt es außerhalb des Ausfallbereichs der Produktionsmaschine?
• Kann das Sicherungskonto schreiben und die benötigten Sicherungen später wieder lesen?
• Reicht der verfügbare Speicherplatz für Umfang und Aufbewahrung der vorgesehenen Sicherungen?
• Sind Zugriffsrechte und Umgang mit Geschäftsdaten dokumentiert?
• Gibt es eine Regel, wie historische Sicherungen erhalten bleiben?

Eine zweite Platte im Produktionsserver kann ein zusätzlicher Speicherort sein. Sie ist aber kein Ersatz für ein getrenntes Sicherungsziel. Wer nur auf diese Platte schreibt, bleibt von einem Ausfall des Servers oder einem Zugriff auf die ganze Maschine abhängig.

Windows Server Backup einrichten und den Auftrag starten

Installieren Sie zuerst die Sicherungsfunktion und legen Sie dann Umfang, Ziel und Zeitplan fest. Die Installation der Windows-Funktion lässt sich grafisch oder über PowerShell prüfen und ausführen.

1. Funktion kontrollieren. Öffnen Sie den Server-Manager und wählen Sie „Verwalten“ und anschließend „Rollen und Features hinzufügen“. Prüfen Sie unter „Features“, ob Windows Server Backup verfügbar und installiert ist. Die PowerShell-Referenz dokumentiert Install-WindowsFeature für Windows Server 2025: Install-WindowsFeature in Microsoft Learn.

Wenn die Funktion fehlt, kann sie in einer administrativen PowerShell-Sitzung mit folgendem Befehl installiert werden:

Install-WindowsFeature -Name Windows-Server-Backup

Prüfen Sie anschließend, ob die Installation erfolgreich abgeschlossen wurde. Eine abgeschlossene Installation sagt noch nichts darüber aus, ob der Sicherungsauftrag korrekt arbeitet.

2. Sicherungsumfang wählen. Öffnen Sie im Server-Manager die Windows-Server-Sicherung und starten Sie den Sicherungszeitplan. Wählen Sie entweder die vollständige Serversicherung oder die passenden Volumes und Daten nach dem zuvor dokumentierten Wiederherstellungsbedarf aus. Prüfen Sie vor dem Speichern, ob Geschäftsdaten, Anwendungskonfiguration und die für einen Start benötigten Volumes enthalten sind.

3. Ziel und Zeitplan festlegen. Wählen Sie das vorbereitete Ziel aus. Bei einer Netzwerkfreigabe muss der Pfad vom Server aus erreichbar sein; Schreib- und Leserechte sind mit dem tatsächlich verwendeten Konto zu prüfen. Legen Sie den Zeitplan passend zur tolerierbaren Datenlücke fest, statt ungeprüft einen allgemeinen Intervallwert zu übernehmen.

4. Auftrag ausführen und Ergebnis prüfen. Kontrollieren Sie den Status im grafischen Verwaltungswerkzeug sowie die zugehörigen Ereignisprotokolle. Ein Lauf ohne sichtbare Fehlermeldung ist ein erster Nachweis für die Auftragserstellung, nicht für die spätere Wiederherstellbarkeit.

Für einen manuellen Start kann wbadmin verwendet werden. Ersetzen Sie die Platzhalter durch die Volumes und das tatsächlich eingerichtete Ziel:

wbadmin start backup -backupTarget:\\<Sicherungsserver>\<Freigabe> -include:<Volumeangaben> -allCritical -quiet

-include benennt die zusätzlich einzuschließenden Volumes; -allCritical bezieht kritische Volumes ein. Prüfen Sie die für die Installation und das Sicherungsziel geltenden Parameter in Microsofts Dokumentation zu wbadmin start backup, bevor der Befehl produktiv eingeplant wird. Für einen Auftrag, der ausdrücklich den Systemstatus sichert, stellt die Windows-Server-Backup-Befehlsreferenz den passenden wbadmin-Befehl und seine Optionen bereit.

Was leistet Windows Server Backup für den ganzen Server?
Eine vollständige Serversicherung erfasst die für die geplante Wiederherstellung benötigten System- und Datenvolumes. Welche Auswahl für eine bestimmte Anwendung genügt, muss anhand ihrer Daten, Abhängigkeiten und Startvoraussetzungen geprüft werden. Verwechseln Sie eine vollständige Dateikopie nicht mit einer nachgewiesenen Bare-Metal-Wiederherstellung.

Sicherungsversionen und Auftragsergebnisse kontrollieren

Kontrollieren Sie nach jedem Lauf, ob eine Sicherungsversion vorhanden ist und ob sie zum geplanten Ziel gehört. Mit wbadmin get versions lassen sich verfügbare Sicherungsversionen für ein Ziel abfragen. Microsoft beschreibt die dafür vorgesehenen Parameter in der Referenz zu wbadmin get versions.

Ein einfacher Kontrollaufruf für eine Netzwerkfreigabe lautet:

wbadmin get versions -backupTarget:\\<Sicherungsserver>\<Freigabe>

Bewahren Sie das Ergebnis zusammen mit dem Zeitpunkt, dem Ziel und dem Status des Auftrags auf. Kontrollieren Sie anschließend, ob die erwarteten Sicherungen und Versionen auf dem Ziel tatsächlich abrufbar sind. Wenn der Auftrag fehlschlägt, notieren Sie Fehlertext, betroffene Volumes und die Behebung. Starten Sie nicht einfach erneut, ohne zu prüfen, ob dadurch vorhandene Sicherungen beeinträchtigt werden.

Bei Netzwerkzielen sind diese Punkte besonders wichtig:

• Berechtigungen: Das Konto für den Auftrag muss auf das Ziel zugreifen können. Ein interaktiver Zugriff durch einen Administrator beweist nicht automatisch, dass der geplante Auftrag dieselben Rechte hat.
• Erreichbarkeit: Ein vorübergehender Netzwerkausfall kann verhindern, dass eine Sicherung abgeschlossen oder eine vorhandene Version gelesen wird.
• Aufbewahrung: Prüfen Sie, ob ein neuer Auftrag frühere Wiederherstellungspunkte erhält. Eine einzige aktuelle Version kann für einen später erkannten Schaden unzureichend sein.
• Nachvollziehbarkeit: Protokollieren Sie das Ergebnis und die ergriffenen Maßnahmen. Ein Status „erfolgreich“ ersetzt keine Wiederherstellungsprobe.

Die Microsoft-Sicherheitsempfehlungen zu Sicherung und Wiederherstellung betonen den Schutz von Sicherungen und die Prüfung der Wiederherstellbarkeit. Für den Betrieb bedeutet das: Sichern Sie Zugangsdaten und Zielzugriff ab, begrenzen Sie Berechtigungen und behandeln Sie die Sicherungskopie als schützenswerte Geschäftsdaten.

Wiederherstellung getrennt nach Fehlerfall erproben

Führen Sie Wiederherstellungsproben ohne Eingriff in produktive Daten durch. Beginnen Sie mit einer einzelnen Datei oder einem Verzeichnis. Danach testen Sie – abhängig vom Geschäftszweck – den Systemstatus und den vollständigen Wiederherstellungspfad.

Für eine Datei prüfen Sie, ob die erwartete Sicherungsversion auf dem Ziel sichtbar ist, ob sich die Datei an einen getrennten Ort zurückspielen lässt und ob sie dort geöffnet werden kann. Bei Geschäftsdaten reicht ein Dateiname als Nachweis nicht aus: Prüfen Sie auch, ob die Anwendung die wiederhergestellten Daten verwenden kann.

Für den Systemstatus und den vollständigen Server dokumentieren Sie vorab die benötigten Berechtigungen, Zugangsdaten, Wiederherstellungsmedien und Startschritte. Eine Bare-Metal-Wiederherstellung setzt einen geeigneten Wiederherstellungsweg voraus. Die Microsoft-Dokumentation zur vollständigen Serverwiederherstellung beschreibt die dafür relevanten Schritte und Voraussetzungen im Kontext ihrer Anleitung. Übertragen Sie deren Vorgehen nicht ungeprüft auf andere Anwendungen oder abweichende Hardware.

Prüfen Sie vor einer geplanten vollständigen Wiederherstellung insbesondere:

• Sind Ziel, Version und Sicherungsumfang eindeutig zugeordnet?
• Ist der benötigte Zugriff auf das Sicherungsziel verfügbar?
• Sind Wiederherstellungsumgebung und erforderliche Medien vorhanden?
• Sind Speichergeräte, Startkonfiguration und benötigte Treiber für das Zielsystem berücksichtigt?
• Ist klar, welche Daten nach der Wiederherstellung noch mit der Anwendung abgeglichen werden müssen?
• Gibt es eine dokumentierte Entscheidung, wer den produktiven Betrieb wieder freigibt?

Eine erfolgreiche Probe an einer Datei beweist nicht, dass ein kompletter Server wieder startet. Umgekehrt beweist eine dokumentierte Anleitung ohne praktische Ausführung nicht, dass Zugangsdaten, Ziel und Medien im Ernstfall funktionieren. Halten Sie fest, was getestet wurde, was fehlgeschlagen ist und welche Änderungen bis zum nächsten Test erforderlich sind.

Wiederherstellungsprüfung als Abnahme-Checkliste

Verwenden Sie die folgende Checkliste vor der Produktionsfreigabe. Markieren Sie einen Punkt erst dann als erledigt, wenn ein Nachweis vorliegt. Ein nicht erfüllter Punkt bedeutet, dass die betreffende Wiederherstellung noch nicht belegt ist.

• [ ] Sicherungsumfang festgelegt: Geschäftsdaten, Systemstatus, IIS-Konfiguration, Zertifikate und erforderliche Abhängigkeiten sind erfasst.
• [ ] Unabhängiges Ziel eingerichtet: Die Kopie liegt nicht ausschließlich auf dem Produktionsserver; Netzwerkpfad und Zielkonto sind dokumentiert.
• [ ] Berechtigungen getestet: Das tatsächlich verwendete Sicherungskonto kann auf das Ziel schreiben und vorhandene Sicherungen lesen.
• [ ] Auftrag und Version kontrolliert: Der Lauf wurde im Verwaltungswerkzeug oder Protokoll geprüft; wbadmin get versions zeigt die erwartete Sicherung am vorgesehenen Ziel.
• [ ] Datei praktisch zurückgespielt: Eine repräsentative Datei wurde an einen separaten Ort wiederhergestellt und auf Lesbarkeit geprüft.
• [ ] Anwendungsdaten geprüft: Für kritische Daten wurde nachvollzogen, ob die Anwendung die wiederhergestellten Inhalte verwenden kann.
• [ ] Systemstatus berücksichtigt: Es ist dokumentiert, welcher Sicherungsumfang für die benötigte Systemstatuswiederherstellung vorgesehen ist.
• [ ] Vollständiger Wiederherstellungsweg vorbereitet: Zuständigkeiten, Zugangsdaten, Wiederherstellungsumgebung und notwendige Medien sind bekannt.
• [ ] Wiederherstellungsprobe dokumentiert: Datum, getesteter Fall, Ergebnis, Abweichungen und offene Maßnahmen sind festgehalten.
• [ ] Aufbewahrung geklärt: Die Sicherungshistorie wird kontrolliert; ein neuer Lauf löscht nicht unbemerkt die einzige benötigte Version.

Entscheidung: Sind alle für den Geschäftsfall erforderlichen Punkte belegt, kann die Sicherung als für diesen Wiederherstellungsfall geprüft dokumentiert werden. Fehlt der Nachweis für eine einzelne Datei, ist nur die Datei-Wiederherstellung ungeprüft. Fehlt der vollständige Wiederherstellungsweg, darf die Lösung nicht als getestete Server-Notfallwiederherstellung gelten.

Vor der Serverbereitstellung die Grenzen klären

Ein dedizierter Server stellt nicht automatisch Snapshots, externe Sicherung, Wiederherstellungsmedien oder einen Wiederherstellungsdienst bereit. Diese Leistungen dürfen nicht aus der Servermiete abgeleitet werden. Der Sicherungsplan muss deshalb auch dann eigenständig umgesetzt und getestet werden, wenn die Geschäftsanwendung auf einer exklusiv genutzten Maschine läuft.

Vor der Bestellung kann ein Team die tatsächlich verfügbaren Betriebssystem-, Sprach- und Speicheroptionen im NodeKVM-Angebot prüfen. Fragen zur Bereitstellung und zu den aufgeführten Optionen lassen sich über die NodeKVM-Hilfe klären. Daraus folgt jedoch keine Zusage, dass NodeKVM Sicherung, Snapshots oder Wiederherstellung für das Team übernimmt. Dafür braucht es ein separat geplantes Ziel und einen eigenen, dokumentierten Wiederherstellungstest.

Bei gemeinsam genutzten Cloud-Instanzen können geteilte Ressourcen und anbieterspezifische Sicherungsoptionen die eigene Planung begrenzen. Bei selbst betriebener Hardware liegen Beschaffung, Wartung und Ausfallvorsorge vollständig beim Betreiber. Eine gemietete physische Maschine kann passen, wenn Windows-Dienste dauerhaft laufen sollen und dedizierte Ressourcen gefragt sind. Für einen kurzen, leichtgewichtigen Test oder eine kurzfristige Aufgabe ist sie nicht automatisch die wirtschaftlichere Wahl.

Die entscheidende Abnahmefrage lautet daher nicht, ob der Sicherungsauftrag im Zeitplan steht, sondern ob das Team die benötigten Geschäftsdaten und den Serverzustand aus einem unabhängigen Ziel nachvollziehbar zurückholen kann. Solange dieser Nachweis fehlt, sollte die Sicherung nicht als verifizierter Notfallplan gelten.