← Windows Server Administration
Härtung und Wiederherstellung
Eine Sicherung, die läuft, ist eine Datei — ob daraus ein funktionierender Dienst wird, ist eine andere Frage, und sie wird meistens erstmals im Ernstfall gestellt. Dieses Modul behandelt die Windows-Seite davon: welcher Wiederherstellungsweg ein laufendes System voraussetzt und welcher nicht, warum das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus nach sechs Jahren verlässlich niemand mehr kennt, und warum eine Härtungseinstellung mit UEFI-Sperre auch das Löschen ihres eigenen Schalters überlebt.
Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04
Sicherung ist ein Artefakt, Wiederherstellung eine Fähigkeit
Eine Sicherung, die läuft, ist eine Datei. Ob sich daraus ein funktionierender Dienst herstellen lässt, ist eine andere Frage — und sie wird in vielen Umgebungen erstmals im Ernstfall gestellt.
Der Unterschied ist nicht theoretisch. Eine Sicherung kann vollständig sein und trotzdem nicht zum Ziel führen: weil der Wiederherstellungsweg ein Medium braucht, das niemand hat; weil die Reihenfolge mehrerer Systeme nicht bekannt ist; oder weil der Server danach zwar startet, aber nicht in ein Netz darf, in dem noch dieselbe Lücke offen ist.
backup-disaster-recovery behandelt Wiederherstellbarkeit als Disziplin — Wiederherstellungsziele, unabhängige Kopien, unveränderbare Aufbewahrung, Übungsprogramme. Hier geht es um die Windows-Werkzeuge und die Entscheidungen, die auf dem Server selbst fallen: was gesichert wird, womit zurückgeholt wird, und was gehärtet sein muss, damit die Rückkehr nicht in denselben Vorfall führt.Was Windows Server Backup kann
Windows bringt eine eigene Sicherungsfunktion mit. Sie ist für einzelne Server gedacht, nicht für eine Flotte, und ihre Kommandozeile heißt wbadmin.
wbadmin start backup- Sichert Volumes, Dateien, Ordner oder Anwendungen — je nach Angabe.
wbadmin start systemstatebackup- Sichert den Systemstatus: Registry, Startdateien, Systemdateien, bei einem Domänencontroller auch das Verzeichnis.
wbadmin start recovery- Holt Volumes, Anwendungen, Dateien oder Ordner zurück.
wbadmin start systemstaterecovery- Holt den Systemstatus zurück.
wbadmin start sysrecovery- Vollständige Wiederherstellung des Systems — laut Dokumentation nur in der Wiederherstellungsumgebung verfügbar.
sysrecovery vorsieht und nicht klärt, wie man dorthin kommt, hat eine Lücke an der teuersten Stelle.Für den Alltag sind zwei weitere Befehle nützlich. wbadmin get versions listet die vorhandenen Sicherungen mit ihrem Zeitpunkt und ihrer Kennung — die braucht man für jede gezielte Wiederherstellung. wbadmin get items -version:<Kennung> zeigt, was in einer bestimmten Sicherung tatsächlich enthalten ist. Der zweite Befehl beantwortet eine Frage, die überraschend oft offen ist: ob die nächtliche Sicherung wirklich das enthält, was man später zurückholen will, oder ob jemand vor Monaten ein Volume ausgeschlossen hat.
Systemstatus ist nicht das System
Der Systemstatus umfasst die Bestandteile, die einen Windows-Server zu diesem Server machen — nicht die Daten, die darauf liegen. Das macht ihn klein und schnell und beantwortet nur einen Teil der Frage.
- Systemstatus
- Registry, Startdateien, Systemdateien, Leistungsindikatoren, bei einem Domänencontroller das Verzeichnis. Klein, häufig sicherbar.
- Volume-Sicherung
- Die Daten. Getrennt zu planen, oft mit anderer Frequenz und anderem Ziel.
- Vollständige Wiederherstellung
- Alles kritischen Volumes zusammen, aus der Wiederherstellungsumgebung heraus.
Für die Planung ergibt sich daraus eine einfache Trennung mit zwei Frequenzen. Der Systemstatus ist klein und ändert sich bei jedem Change — er darf und soll häufig gesichert werden, und aus ihm kommt ein Server zurück, der wieder er selbst ist. Die Datenvolumes sind groß und ändern sich nach der Arbeit der Nutzer — ihre Frequenz ergibt sich aus der Frage, wie viel Arbeit im Verlustfall verloren gehen darf. Wer beides in einen Auftrag legt, bekommt entweder eine zu seltene Systemstatussicherung oder eine zu teure Datensicherung.
Was ein Restore-Test wirklich prüft
Ein Wiederherstellungstest, der eine einzelne Datei zurückholt, prüft, dass die Sicherung lesbar ist. Das ist nicht nichts und beantwortet keine der Fragen, die im Ernstfall zählen.
- Ist das Sicherungsziel im Ernstfall erreichbar — oder hängt es an demselben System, das ausgefallen ist?
- Wie lange dauert die vollständige Wiederherstellung tatsächlich, gemessen und nicht geschätzt?
- Wer darf sie auslösen, und ist diese Person im Ernstfall verfügbar?
- Funktioniert der Dienst danach — geprüft über den Weg, den ein Client benutzt?
Der Test, der die Zeit misst
Szenario
Für einen Dateiserver mit 4 TB Daten ist eine Wiederanlaufzeit von acht Stunden zugesagt. Die Sicherung läuft auf ein Netzziel über eine 1-Gbit-Anbindung. Ein Wiederherstellungstest hat bisher nur einzelne Dateien geholt.
Anforderungen
- Die zugesagte Wiederanlaufzeit soll belegt oder widerlegt werden.
- Der produktive Betrieb soll nicht gestört werden.
Schritte
- Die reine Übertragungszeit rechnen: 4 TB über 1 Gbit ergibt bei realistischem Durchsatz deutlich über neun Stunden — allein für die Daten.
- Dazu die Zeit für Systemwiederherstellung, Neustarts und fachliche Prüfung addieren.
- Ergebnis der Rechnung dem zugesagten Wert gegenüberstellen: Die Zusage ist rechnerisch nicht haltbar.
- Einen Test auf einem Ersatzsystem durchführen, um die Rechnung zu bestätigen statt sie zu behaupten.
- Entweder die Zusage korrigieren oder das Verfahren ändern — schnelleres Ziel, lokale Kopie, andere Wiederherstellungsreihenfolge.
Merksatz: Die Rechnung dauert fünf Minuten und widerlegt die Zusage, bevor der Ernstfall es tut. Wiederanlaufzeiten, die nie gegen Datenmenge und Bandbreite gehalten wurden, sind Wunschwerte — und im Ernstfall wird daraus ein Vertrauensverlust zusätzlich zum Ausfall.
Härtung hat vier Achsen
Härtung wird oft als Liste von Einstellungen behandelt. Nützlicher ist die Sortierung nach dem, was sie jeweils schwerer machen — denn dieselbe Maßnahme kann auf einer Achse viel und auf einer anderen nichts bringen.
- Konten und Rechte
- Wer darf sich anmelden, wer darf was? Anmelderechte, Gruppenmitgliedschaften, verwaltete Dienstkonten.
- Angriffsfläche
- Was läuft überhaupt? Installationsoption, Rollen, Dienste, offene Ports.
- Anmeldeinformationen
- Was liegt im Speicher und auf der Platte? LSA-Schutz, keine geteilten Kennwörter, kein interaktives Anmelden mit hohen Rechten auf beliebigen Servern.
- Nachvollziehbarkeit
- Was bleibt übrig, wenn jemand es versucht hat? Protokollierung, Weiterleitung, Aufbewahrung.
Die vierte Achse wird bei Härtungsprojekten regelmäßig übersprungen, weil sie nichts verhindert. Sie ist trotzdem die, ohne die man hinterher nicht sagen kann, ob eine der anderen drei gehalten hat.
Nützlich ist die Sortierung vor allem beim Priorisieren. Eine Umgebung, in der dasselbe lokale Administratorkennwort überall gilt, gewinnt mit einer Maßnahme auf der dritten Achse mehr als mit zwanzig Einstellungen auf der zweiten. Umgekehrt bringt der Verzicht auf eine Rolle, die niemand braucht, auf der zweiten Achse sofort etwas und kostet fast nichts. Die Reihenfolge ergibt sich also nicht aus einer Checkliste, sondern aus der Frage, welche Achse in dieser Umgebung am schwächsten ist.
Der Schutz des Anmeldeinformationsspeichers
Der lokale Sicherheitsdienst prüft Anmeldungen und verwaltet dabei Anmeldeinformationen im Speicher. Genau dieser Speicher ist das Ziel, wenn jemand aus einem kompromittierten Server heraus weiterkommen will.
Zusätzlicher LSA-Schutz — Eine Einstellung, die den Dienst als geschützten Prozess ausführt. Nicht geschützte Prozesse können seinen Speicher dann weder lesen noch Code in ihn einschleusen.
Der Schutz wirkt gegen eine konkrete Angriffsform: das Auslesen des Speichers, um an dort liegende Anmeldeinformationen zu kommen. Er wirkt nicht gegen jemanden, der ohnehin schon als hoch berechtigtes Konto auf dem Server arbeitet — dieser Weg bleibt offen und wird durch die Einstellung nur teurer. Wie bei jeder Maßnahme lohnt es deshalb, sie mit der Angriffsform zu benennen, gegen die sie hilft. Eine Härtungsliste ohne diese Zuordnung lässt sich weder priorisieren noch verteidigen.
Erst prüfen, dann einschalten
Für genau diesen Fall gibt es einen dokumentierten Weg, der die Reihenfolge umdreht: Statt einzuschalten und zu hoffen, lässt sich zuerst protokollieren, welche Plug-ins unter dem Schutz nicht laufen würden.
Die Tür, die zufällt
Der LSA-Schutz lässt sich über einen Registry-Wert unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa steuern. Das klingt nach einer Einstellung, die man zurücknehmen kann — und unter bestimmten Bedingungen ist sie es nicht.
Rückkehr nach einem Vorfall
Nach einem Sicherheitsvorfall ist die Wiederherstellung des Dienstes nicht der letzte Schritt, sondern der vorletzte. Dazwischen liegt die Frage, die im Zeitdruck am liebsten übersprungen wird: Ist der Weg geschlossen, über den jemand hereinkam?
Kurzcheck
Ein kompromittierter Anwendungsserver soll wieder in Betrieb gehen. Die Sicherung von vor dem Vorfall ist vorhanden und geprüft. Was fehlt in dieser Reihenfolge: zurückspielen, starten, freigeben?
- Der Eintrittsweg muss geschlossen sein, sonst holt die Sicherung ihn zurück
- Nichts — eine geprüfte Sicherung von vor dem Vorfall ist per Definition sauber
- Ein zweiter Wiederherstellungstest, um die Integrität der Sicherung zu bestätigen
Treffer. Richtig. Eine Sicherung von vor dem Vorfall enthält den Zustand von vor dem Vorfall — einschließlich der Lücke, über die jemand hereinkam. Ohne Schließen wiederholt sich derselbe Vorgang.
Daraus ergibt sich eine Reihenfolge, die im Ernstfall Zeit kostet und deren Verletzung mehr kostet: eingrenzen, Beweise sichern, Eintrittsweg bestimmen und schließen, wiederherstellen, prüfen, freigeben. Der vorletzte Schritt ist eine fachliche Prüfung über den Clientweg — nicht ein grüner Dienststatus.
Praktisch heißt „Eintrittsweg bestimmen“ nicht, den vollständigen Hergang aufzuklären — das kann Wochen dauern und ist im Wiederanlauf nicht leistbar. Es heißt, die plausiblen Wege zu benennen und die zu schließen, die mit vertretbarem Aufwand zu schließen sind: ein ungepatchter Dienst, ein offener Verwaltungszugang aus einem falschen Netz, ein Dienstkonto mit zu weiten Rechten. Was danach bleibt, gehört als bewusst getragenes Restrisiko in die Freigabeentscheidung, nicht in eine Fußnote.
Was aus einer Sicherung zurückkommen darf
Nicht alles, was in einer Sicherung steht, soll zurück. Bei einer Wiederherstellung nach einem Vorfall gehören drei Dinge getrennt betrachtet.
- Daten
- Sollen zurück, möglichst aktuell. Der Grund für die ganze Übung.
- Konfiguration
- Soll zurück — aber ohne die Einstellung, die den Vorfall ermöglicht hat.
- Anmeldeinformationen
- Sollen nicht unverändert zurück. Was ein Angreifer gesehen haben könnte, ist verbrannt.
Was in die Übergabe gehört
Wie bei Start und Beobachtbarkeit gilt: Fast nichts davon lässt sich im Ernstfall noch herstellen. Die Liste ist kurz und wird trotzdem selten abgearbeitet.
- Welche Sicherung gibt es für diesen Server, mit welcher Frequenz und welchem Ziel?
- Ist das Ziel im Ernstfall erreichbar, wenn dieser Server ausgefallen ist?
- Wie lange dauert die vollständige Wiederherstellung — gemessen, nicht geschätzt?
- Gibt es einen Weg in die Wiederherstellungsumgebung, und wer hat die Zugangsdaten?
- Bei einem Domänencontroller: Wer kennt das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus?
Diese fünf Punkte gehören in dieselbe Übernahmeprüfung wie die aus den Modulen über Start und über Beobachtbarkeit. Zusammen beantworten sie drei Fragen über jeden Server: Wie komme ich an ihn heran, wenn er nicht mehr antwortet? Was kann er mir über sich sagen? Und wie bekomme ich ihn zurück, wenn er weg ist? Alle drei Antworten entstehen an dem Tag, an dem der Server übernommen wird — oder sie entstehen gar nicht.
Der Preis der Härtung
Jede Maßnahme in diesem Modul hat einen Preis, und ihn zu verschweigen macht Härtungsprojekte unglaubwürdig. Drei Muster wiederholen sich.
- Etwas läuft nicht mehr
- Signaturpflichten, engere Rechte, geschlossene Ports treffen immer auch etwas Legitimes. Der Auditmodus ist die Antwort, wo es ihn gibt.
- Etwas lässt sich nicht mehr zurücknehmen
- UEFI-gesperrte Einstellungen, Konvertierungen, entfernte Rückwege. Sie gehören vor die Aktivierung, nicht danach.
- Etwas wird langsamer oder umständlicher
- Zusätzliche Anmeldeschritte, getrennte Verwaltungswege, mehr Freigabeschritte. Wer den Aufwand nicht anerkennt, erzeugt Umgehungen.
Für den Betrieb ist daraus eine praktische Regel abzuleiten: Jede Maßnahme bekommt vor der Einführung einen benannten Verantwortlichen, ein Datum für die Wirksamkeitsprüfung und eine Aussage darüber, was passiert, wenn sie etwas blockiert, das gebraucht wird. Der dritte Punkt ist der entscheidende. Ohne ihn wird jede Störung, die zeitlich in die Nähe der Änderung fällt, ihr zugeschrieben — und die Maßnahme fällt, unabhängig davon, ob sie die Ursache war.
Jetzt anwenden
Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.
Zum Modul →Quellen & Aktualität10 Primärquellen · zuletzt geprüft:
- 01wbadmin
- 02Configuring additional LSA protection
- 03How to configure protected accounts
- 04Volume Shadow Copy Service (VSS)
- 05REAgentC Command-Line Options
- 06Windows LAPS overview
- 07Registry Hives
- 08learn.microsoft.com/en-us/powershell/module/windowsserverbackup
- 09learn.microsoft.com/en-us/windows-server/secur…curity-and-assurance
- 10learn.microsoft.com/en-us/windows-server/ident…ing-active-directory