Workloads wiederanlaufen lassen: Datenbanken, Dateidienste, zustandslose Dienste

Der Bestand ist zurück, und der Dienst läuft trotzdem nicht: Die Datenbank wurde einen Schritt zu früh freigegeben, dem Dateiserver fehlen die Zugriffssteuerungslisten, und der zustandslose Dienst findet sein Artefakt nicht mehr, weil die Registry Teil des Ausfalls war. Dieses Modul behandelt die Schritte zwischen „Daten sind da“ und „Dienst nimmt Arbeit an“ — die Restoresequenz mit ihrer unteilbaren Reihenfolge, die Sicherung des Protokollendes, die eine letzte Datenlücke rettet, und die Bestandteile eines Workloads, die außerhalb seines Datenverzeichnisses liegen.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Daten zurück ist nicht Dienst zurück

Bis hierher ging es darum, einen verwertbaren Bestand zu erzeugen und ihn an die richtige Stelle zu bringen. Was danach passiert, unterscheidet sich je nach Art des Dienstes so stark, dass ein gemeinsames Verfahren nicht existiert — eine Datenbank kommt anders zurück als ein Dateidienst, und ein zustandsloser Dienst kommt gar nicht zurück, sondern wird neu gebaut.

Dieses Modul behandelt drei Arten, weil sie zusammen den weit überwiegenden Teil abdecken und weil ihre Unterschiede die typischen Fehler erklären. In allen drei Fällen gilt derselbe Satz: Der Teil, der am häufigsten fehlt, ist nicht der Datenbestand, sondern das, was ihn benutzbar macht.

Warum die Beispiele konkret sindDie Verfahren unterscheiden sich in den Details je Produkt, und die Details sind hier der Lehrstoff — an ihnen scheitern Wiederherstellungen. Die benutzten Beispiele sind dokumentiert und nachlesbar; die dahinterstehende Frage ist übertragbar: Welche Schritte liegen zwischen „Daten sind da“ und „Dienst nimmt Arbeit an“, und welcher davon ist der, den niemand aufgeschrieben hat?

Datenbank: Der Bestand kommt in einer festen Sequenz zurück, und erst ihr letzter Schritt macht ihn benutzbar. Fehler in der Reihenfolge kosten den ganzen Vorgang.
Dateidienst: Der Bestand ist schnell da; benutzbar wird er erst mit Berechtigungen und einer stimmigen Zuordnung der Eigentümer.
Zustandsloser Dienst: Es gibt nichts zurückzuholen und einiges neu zu beschaffen: Konfiguration, Geheimnisse, Zertifikate — und das auszurollende Artefakt selbst.

Datenbank: die Restoresequenz

Restoresequenz — Eine Folge von Wiederherstellungsvorgängen, die zusammen einen Bestand auf einen bestimmten Zeitpunkt bringen. Sie wird als eine Sequenz ausgeführt: Zwischen ihren Schritten darf die Datenbank nicht online gehen, sonst ist die Kette beendet.

Für SQL Server unter dem vollständigen Wiederherstellungsmodell beschreibt die Dokumentation fünf Schritte, und die Reihenfolge ist keine Empfehlung, sondern eine Bedingung.

Das aktive Transaktionsprotokoll sichern — die Sicherung des Protokollendes→Die jüngste Vollsicherung zurückspielen, ohne die Datenbank freizugeben→Falls vorhanden, die jüngste differenzielle Sicherung zurückspielen, ebenfalls ohne Freigabe→Die Protokollsicherungen der Reihe nach zurückspielen, jeweils ohne Freigabe→Die Datenbank freigeben

Erst der letzte Schritt macht die Datenbank benutzbar

Die Fachbegriffe dazu lauten WITH NORECOVERY für die Schritte zwei bis vier und WITH RECOVERY für den letzten. Der Unterschied ist entscheidend und wird regelmäßig verwechselt: WITH NORECOVERY lässt die Datenbank im wiederherstellenden Zustand, sodass weitere Teile angewendet werden können. Wer versehentlich einen Zwischenschritt mit WITH RECOVERY ausführt, hat die Datenbank freigegeben — und muss die gesamte Sequenz von vorn beginnen.

Warum die differenzielle Sicherung nicht optional istDie Dokumentation nennt ihren Zweck genau: Sie verringert die Zahl der Protokollsicherungen, die zurückgespielt werden müssen. Damit ist sie kein zusätzlicher Bestand, sondern eine unmittelbare Verkürzung der Wiederanlaufzeit — und ihr Fehlen ein Aufschlag darauf, der sich vorher berechnen lässt: Zahl der Protokollsicherungen seit der letzten Vollsicherung mal Anwendungsdauer je Stück.

Das Ende des Protokolls

Der erste Schritt der Sequenz ist der, den man im Ernstfall am ehesten überspringt, weil er widersinnig wirkt: Bevor irgendetwas zurückgeholt wird, wird noch einmal gesichert. Genau darin steckt die Datenlücke zwischen der letzten planmäßigen Protokollsicherung und dem Ausfall.

Die letzte Stunde, die noch zu retten war

Szenario

Um 14:20 fällt eine Datenbank aus. Protokollsicherungen laufen alle 15 Minuten, die letzte um 14:15 planmäßig durchgelaufen. Die Datendateien sind beschädigt, das Transaktionsprotokoll liegt auf einem anderen, unbeschädigten Datenträger.

Anforderungen

Der Datenverlust soll so klein wie möglich sein.
Es soll keine Annahme über den Zustand der Datendateien gemacht werden.

Schritte

Vor jedem Zurückspielen das aktive Transaktionsprotokoll sichern — es enthält die Änderungen von 14:15 bis 14:20, die in keiner planmäßigen Sicherung stehen.
Die Dokumentation zur Kenntnis nehmen: Ist das aktive Protokoll nicht verfügbar, sind alle Transaktionen in diesem Teil verloren. Die Sicherung des Protokollendes ist die einzige Gelegenheit dafür.
Die jüngste Vollsicherung ohne Freigabe zurückspielen, danach die jüngste differenzielle ohne Freigabe.
Alle Protokollsicherungen nach diesem Stand der Reihe nach ohne Freigabe anwenden — einschließlich der eben erzeugten Sicherung des Protokollendes.
Die Datenbank mit dem letzten Schritt freigeben und die fachliche Abnahmeliste durchführen.

Merksatz: Der teuerste Fehler an dieser Stelle ist Eile: Wer sofort mit dem Zurückspielen beginnt, verliert die fünf Minuten Arbeit, die noch vorhanden waren, und merkt es nie — die Datenbank läuft ja. Die Sicherung des Protokollendes kostet Sekunden und ist unwiederbringlich, wenn sie unterbleibt.

Der Fall, in dem sie nicht funktioniertDie Dokumentation nennt eine Ausnahme, die man kennen muss: Unter dem massenprotokollierten Wiederherstellungsmodell erfordert die Sicherung eines Protokolls, das massenprotokollierte Vorgänge enthält, Zugriff auf alle Datendateien der Datenbank. Sind diese nicht erreichbar, lässt sich das Protokoll nicht sichern — dann müssen laut Dokumentation alle Änderungen seit der letzten Protokollsicherung von Hand nachvollzogen werden. Ein Wiederherstellungsmodell, das aus Leistungsgründen gewählt wurde, kostet hier die letzte Datenlücke.

Den Zielzeitpunkt wählen

Nicht immer soll bis zum Ausfall zurückgeholt werden. Nach einer fehlerhaften Massenänderung ist der gewünschte Zeitpunkt derjenige unmittelbar davor, und dafür gibt es einen eigenen Weg.

Zeitpunkt: Ein Datum mit Uhrzeit. In T-SQL die Klausel STOPAT beim Zurückspielen des Protokolls.
Markierte Transaktion: Ein vorher gesetzter Bezugspunkt im Protokoll — nützlich, wenn ein riskanter Vorgang absehbar war.
Protokollfolgenummer: Die genaueste Angabe, wenn die Untersuchung den Vorgang exakt bestimmt hat.
Empfehlung der Dokumentation: Den Zeitpunkt früh in der Sequenz angeben — nicht erst beim letzten Protokoll, weil sonst bereits über das Ziel hinaus angewendet wurde.

Die Einschränkung, die man vorher kennen mussAuch hier gilt eine dokumentierte Ausnahme für das massenprotokollierte Modell: Enthält eine Protokollsicherung massenprotokollierte Änderungen, ist eine Wiederherstellung auf einen Zeitpunkt innerhalb dieser Sicherung nicht möglich — die Datenbank muss bis zum Ende dieser Protokollsicherung wiederhergestellt werden. Wer das Modell aus Leistungsgründen wählt, gibt damit die punktgenaue Rückkehr innerhalb der betroffenen Zeiträume auf. Das ist eine Entwurfsentscheidung, keine Betriebsüberraschung — vorausgesetzt, jemand hat sie so getroffen.

Dateidienst: die Berechtigungen sind der Dienst

Bei Dateidiensten ist der Datenbestand meist der einfache Teil. Was einen wiederhergestellten Bestand benutzbar macht, sind die Rechte darauf — und die fallen bei den gängigen Werkzeugen still unter den Tisch, wenn man die Voreinstellungen benutzt.

Das Handbuch von rsync ist an dieser Stelle vorbildlich deutlich. Die verbreitete Sammeloption -a entspricht -rlptgoD und bewahrt „fast alles“ — und dann folgt der Satz, den man gelesen haben muss: Sie schließt nicht die Bewahrung von ACLs (-A), erweiterten Attributen (-X), Zugriffszeiten (-U), Erstellungszeiten (-N) und das Auffinden und Bewahren harter Verweise (-H) ein.

Was -a bewahrt: Rekursion, Symlinks, Rechte, Zeiten, Gruppe, Eigentümer, Geräte- und Spezialdateien.
Was -a nicht bewahrt: Zugriffssteuerungslisten, erweiterte Attribute, harte Verweise. Ein Dateiserver mit feingranularen Berechtigungen verliert damit genau das, was ihn ausmacht.
Was zusätzlich zu beachten ist: Bei erweiterten Attributen kopiert laut Handbuch ein privilegierter Benutzer alle Namensräume außer system.*; ein normaler Benutzer nur user.*. Eine unter normalem Konto laufende Sicherung verliert damit unter anderem Sicherheitskennzeichnungen.

Warum das so lange unbemerkt bleibtDer Restore-Test holt eine Datei zurück, sie ist da, der Inhalt stimmt. Berechtigungen prüft niemand, weil der Prüfende Administrator ist und ohnehin überall hineinkommt. Bemerkt wird es erst, wenn die ersten Anwender zugreifen — also nach der fachlichen Abnahme, wenn sie nicht von Anwendern durchgeführt wurde. Genau dafür existiert die Abnahmeliste aus dem Modul über den Restore-Nachweis.

Die Konsequenz für den Betrieb ist unspektakulär und wird trotzdem selten gezogen: Die verwendeten Optionen gehören in das Restore-Manifest, und zwar mit Begründung. Ein Sicherungsbefehl, den jemand vor Jahren aus einem Beispiel übernommen hat, trägt die Voreinstellungen dieses Beispiels — und die waren für einen Datenordner gedacht, nicht für einen Dateiserver mit gewachsenem Berechtigungsmodell. Die Prüfung dauert eine Minute: Enthält der Befehl die Optionen für Zugriffssteuerungslisten und erweiterte Attribute, und läuft er mit ausreichenden Rechten?

Eigentümer sind Nummern, keine Namen

Ein zweiter Fallstrick bei Dateidiensten betrifft die Identität der Eigentümer. Im Dateisystem stehen Zahlen; die Namen kommen aus einer Zuordnung, die anderswo liegt — im lokalen System, im Verzeichnisdienst, in einer Zuordnungstabelle.

Restore auf ein anderes System. Stimmen die Zuordnungen dort nicht überein, gehören die Dateien nach dem Zurückspielen den falschen Konten — technisch korrekt, fachlich falsch.
Restore nach einem Neuaufbau. Wird der Verzeichnisdienst neu aufgebaut, können neu vergebene Kennungen entstehen, obwohl die Namen gleich sind.
Die Prüfung. Nicht die Namen im wiederhergestellten Bestand vergleichen, sondern eine Stichprobe aus Sicht eines echten Benutzerkontos: Kommt es an seine Daten heran und nur an seine?
Die Vorsorge. Die Zuordnung von Kennungen zu Konten gehört zum Wiederherstellungsumfang — sie ist so wichtig wie die Daten selbst und wird fast nie mitgesichert.

Der Fall wirkt akademisch, bis er eintritt. Er entsteht immer dann, wenn nicht auf dasselbe System zurückgespielt wird — also in genau der Lage, für die die Sicherung gedacht war. Im Test auf demselben Server fällt er nie auf, weil die Zuordnung dort unverändert ist. Das macht ihn zu einem der wenigen Fehler, die ein gut gemachter Restore-Test regelmäßig verfehlt, wenn er nicht ausdrücklich auf Ersatzhardware läuft.

Zustandslose Dienste sind nicht zustandslos

Ein Dienst, der keine eigenen Daten hält, gilt als unproblematisch: einfach neu ausrollen. Das stimmt für die Nutzdaten und für nichts anderes. Was ihn benutzbar macht, liegt außerhalb seines Datenverzeichnisses — und wird deshalb regelmäßig von keiner Sicherung erfasst.

Konfiguration: Umgebungsvariablen, Verbindungszeichenfolgen, Merkmalsschalter. Oft nur in der Bereitstellungsumgebung vorhanden.
Geheimnisse: Zugangsdaten zu Datenbanken und Schnittstellen. Werden zur Laufzeit eingespielt und sind nach dem Neuaufbau nicht automatisch da.
Zertifikate und Vertrauensstellungen: Mit eigener Gültigkeitsdauer, die vom Sicherungsstand unberührt bleibt.
Das Artefakt selbst: Die Anwendungsversion, die zuletzt lief. Liegt sie in einer Registry, die Teil des Schadens ist, gibt es nichts auszurollen.

Die letzte Zeile ist die unangenehmste und die häufigste. Ein zustandsloser Dienst lässt sich in Minuten neu ausrollen — vorausgesetzt, das auszurollende Abbild existiert an einem Ort, der den Schaden überstanden hat. Ist die Registry Teil derselben Plattform, ist der Dienst nicht in Minuten zurück, sondern erst nach einem Neubau aus dem Quelltext.

Die Prüffrage für diese KlasseSie lautet nicht „ist der Dienst gesichert?“, sondern: Aus welchen Bestandteilen ließe sich dieser Dienst heute neu erzeugen, und liegt jeder davon außerhalb der Umgebung, die ausfallen kann? Wer die Frage einmal je Dienst durchgeht, findet regelmäßig zwei bis drei Bestandteile, die nur an einer Stelle existieren — meist die Geheimnisse und das Artefakt. Beide sind billig zu duplizieren, sobald man sie kennt.

Die Reihenfolge innerhalb eines Workloads

Auch innerhalb eines einzelnen Dienstes gibt es eine Reihenfolge, und sie ist enger, als sie aussieht: Ein Anwendungsteil, der beim Start keine Datenbank findet, beendet sich oft nicht mit einer verständlichen Meldung, sondern läuft mit halbem Zustand weiter.

Kurzcheck

Ein Dienst besteht aus Datenbank, Nachrichtenspeicher, Anwendungsservern und einem vorgelagerten Verteiler. Die Datenbank ist wiederhergestellt und freigegeben. Was kommt als Nächstes?

Der Nachrichtenspeicher — mit gesperrter Weiterverarbeitung, bis über die Warteschlange entschieden ist.
Der vorgelagerte Verteiler, damit die Erreichbarkeit sofort wiederhergestellt ist.
Die Anwendungsserver, weil sie die längste Startzeit haben und parallel hochkommen können.

Treffer. Richtig. Er ist die zweite Zustandskomponente und muss stehen, bevor Anwendungsserver starten. Gesperrt deshalb, weil sein Inhalt aus der Zeit vor dem Ausfall stammt und ohne Abgleich nicht verschickt werden darf.

Das Restore-Manifest

Alle bisherigen Punkte laufen auf ein Dokument zu, das im Ernstfall eine zufällige Zusammenstellung verhindert: eine Liste dessen, was für diesen Workload zusammengehört, und in welcher Reihenfolge es zurückkommt.

Der Anlass für dieses Dokument ist ein wiederkehrendes Bild aus echten Wiederanläufen: Nach vier Stunden ist unklar, welche Teile schon zurück sind, wer woran arbeitet und ob der Stand von 02:00 zu dem von 23:00 passt. Nicht weil niemand aufgepasst hätte, sondern weil die Übersicht bei sechs Beteiligten und zehn Beständen im Kopf nicht mehr trägt. Das Manifest ist die schriftliche Fassung dieser Übersicht — vor dem Ernstfall angelegt und im Ernstfall abgehakt.

Die Bestände, aus denen der Workload besteht — mit ihrem jeweiligen Zeitpunkt und der Frage, ob sie denselben Konsistenzpunkt brauchen.
Die Reihenfolge ihrer Wiederherstellung und die Stellen, an denen nicht freigegeben werden darf.
Die Zusatzbestandteile, die nicht im Datenverzeichnis liegen: Berechtigungszuordnung, Konfiguration, Geheimnisse, Zertifikate, Artefakte.
Die Abnahmeliste des Fachbereichs, die den Wiederanlauf beendet.

Warum das Manifest je Workload und nicht je Server entstehtEin Server taucht in mehreren Manifesten auf, und ein Workload erstreckt sich über mehrere Server — das ist genau die Dienstsicht aus dem Inventarmodul. Das Manifest ist ihre praktische Ausprägung: Es beantwortet im Ernstfall die Frage, die sonst niemand schnell beantworten kann — was gehört zu diesem Dienst, und was davon habe ich schon?

Prüfen, bevor produktiv gesetzt wird

Ein letzter Schritt vor der Freigabe betrifft die Vertrauenswürdigkeit des Bestands selbst. Die SQL-Server-Dokumentation formuliert dazu eine Empfehlung, die weit über ihren unmittelbaren Anlass hinausreicht.

Dort steht, Datenbanken aus unbekannten oder nicht vertrauenswürdigen Quellen nicht anzuhängen oder wiederherzustellen — sie könnten Schadcode enthalten oder durch Änderungen an Schema und physischer Struktur Fehler verursachen. Vor der Verwendung soll auf einem nicht produktiven Server eine Konsistenzprüfung mit DBCC CHECKDB laufen, und der in der Datenbank hinterlegte eigene Code — gespeicherte Prozeduren und Ähnliches — soll geprüft werden.

Warum das nach dem Angriffsmodul anders klingtNach einem Angriff ist die eigene Sicherung genau das: eine Quelle, deren Vertrauenswürdigkeit offen ist. Die Empfehlung gilt dann für den eigenen Bestand — Prüfung auf einem nicht produktiven System, Blick auf den hinterlegten Code, erst danach Freigabe. Im normalen Ausfallfall ist derselbe Schritt eine Formalie; im Angriffsfall ist er die Bedingung.

Verallgemeinert lautet der Schritt: Vor der Freigabe wird der wiederhergestellte Bestand in einer Umgebung geprüft, in der ein Fund folgenlos bleibt. Das kostet Zeit, die auf die Wiederanlaufzeit anfällt, und ist deshalb eine Abwägung — aber eine, die vorher getroffen und im Recovery-Vertrag festgehalten werden kann, statt unter Druck aus dem Bauch. Für Dienste der obersten Schutzklasse ist die übliche Antwort, die Prüfung parallel zum Wiederanlauf laufen zu lassen und die Freigabe an ihr Ergebnis zu binden.

Abgrenzung

Hier geht es um den Wiederanlauf eines Workloads. Die Reihenfolge über viele Dienste hinweg, die Priorisierung unter Ressourcenknappheit und die Führung der Lage sind Gegenstand des Moduls über Disaster Response.

NachbartracksDatenbankbetrieb im Detail steht in database-administration-basics, Dateidienste und Berechtigungsmodelle in storage-file-services und windows-server-administration, Bereitstellungsverfahren für zustandslose Dienste in cloud-infra. Hier interessiert nur, welcher Schritt zwischen einem vorhandenen Bestand und einem benutzbaren Dienst liegt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-04