Vom Serverbestand zur Schutzabdeckung: Inventar, Klassen, Lücken

Die Serverliste existiert, die Sicherung läuft — und trotzdem lässt sich für keine Zeile sagen, wen man anruft und was verloren gehen darf. Dieses Modul baut aus dem vorhandenen Bestand ein Inventar, mit dem sich Wiederherstellung überhaupt entscheiden lässt: Dienste statt Hostnamen, wenige Schutzklassen statt sechzig Einzelverhandlungen, beobachtete statt behaupteter Abhängigkeiten. Am Ende steht die eine Zahl, die fast nie gemessen wird — die Differenz zwischen dem, was geschützt sein soll, und dem, was das Sicherungssystem tatsächlich kennt.

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

Das Inventar, das es schon gibt, ist meist das falsche

In fast jedem Betrieb existiert eine Liste. Sie heißt Serverliste, Asset-Verzeichnis oder CMDB, und sie enthält Hostnamen, Betriebssysteme, IP-Adressen und vielleicht eine Kostenstelle. Für die Wiederherstellung ist sie fast wertlos — weil sie die falsche Einheit führt.

Wiederhergestellt wird nie ein Server, sondern ein Dienst: etwas, das ein Fachbereich benutzt und dessen Ausfall jemandem wehtut. Ein Dienst kann auf fünf Servern liegen, und ein Server kann drei Dienste tragen, die völlig verschiedene Zusagen haben. Wer die Serverliste als Recovery-Inventar benutzt, kann für keinen einzigen Eintrag die Frage beantworten, die im Ernstfall zählt: Wen ruft man an, und was darf verloren gehen?

Der Test, der die Liste bewertetNimm eine beliebige Zeile aus dem vorhandenen Inventar und versuche, daraus einen Recovery-Vertrag zu füllen: Dienst, Eigentümer, Verlustgrenze, Ausfallgrenze, Umfang, Abhängigkeiten. Gelingt das bei weniger als der Hälfte der Zeilen, ist die Liste ein Betriebsmittelverzeichnis und kein Recovery-Inventar. Beides ist nützlich — aber nur eines beantwortet die Frage dieses Tracks.

Welche Felder ein Recovery-Inventar tragen muss

Die Versuchung, ein umfassendes Verzeichnis zu bauen, ist groß und in einem kleinen Team tödlich: Ein Inventar mit vierzig Feldern wird nach drei Monaten nicht mehr gepflegt und ist dann schlechter als keines, weil ihm noch jemand glaubt. Sieben Felder tragen die Entscheidungen dieses Tracks.

Dienst: Der fachliche Name, unter dem der Fachbereich ihn kennt — nicht der Hostname.
Eigentümer: Die Person, deren Prozess stillsteht und die die Verlustgrenze bestätigt hat.
Schutzklasse: Die Zuordnung zu einer der wenigen vordefinierten Klassen, statt einer eigenen Verhandlung je Dienst.
Datenorte: Wo die Daten des Dienstes tatsächlich liegen — inklusive der Orte außerhalb des eigenen Rechenzentrums.
Abhängigkeiten: Die Dienste darunter, ohne die dieser nicht funktioniert.
Schutzzustand: Ob und wodurch der Dienst derzeit tatsächlich gesichert ist — der Ist-Wert, nicht der Plan.
Aufbewahrungspflicht: Ob eine gesetzliche oder vertragliche Pflicht die Aufbewahrungsdauer bestimmt.

Warum Schutzklasse und Schutzzustand getrennt stehenDie Schutzklasse ist die Zusage, der Schutzzustand die Wirklichkeit. Erst die Trennung macht die einzige Kennzahl möglich, die dieses Modul liefern muss: die Abdeckungslücke — die Menge der Dienste, deren Ist-Zustand hinter ihrer eigenen Klasse zurückbleibt. Wer beides in ein Feld schreibt, kann sie nicht mehr messen.

Schutzklassen statt Einzelverhandlung

Jeden Dienst einzeln zu verhandeln, skaliert nicht: Bei sechzig Diensten sind das sechzig Gespräche, sechzig Sonderfälle und am Ende sechzig Verfahren, die niemand mehr überblickt. Der übliche Ausweg sind drei bis vier Klassen, die je ein fertiges Paket beschreiben — der Fachbereich wählt eine Klasse, nicht eine Zahl.

Klasse A: Ausfall in Stunden, Datenlücke unter einer Stunde. Zweite Kopie an anderem Ort, geprobter Ablauf, benannte Zuständigkeit rund um die Uhr.
Klasse B: Ausfall in einem Arbeitstag, Datenlücke bis zu einem Tag. Tägliche Sicherung, jährlich geprobter Restore.
Klasse C: Ausfall in mehreren Tagen tolerierbar. Sicherung ohne Zusage über die Wiederanlaufzeit, Wiederherstellung im Rahmen des Möglichen.
Ohne Klasse: Keine Zusage. Muss eine bewusste, dokumentierte Entscheidung sein — nicht der Zustand der Dienste, an die niemand gedacht hat.

Der eigentliche Gewinn liegt nicht in der Einteilung, sondern in der letzten Zeile. Ein Dienst ohne Klasse ist ein sichtbarer, benannter Zustand, über den jemand entschieden hat. Ohne Klassenmodell gibt es diesen Zustand nicht — es gibt nur Dienste, die keiner erwähnt hat, und die sind im Ernstfall nicht von den geschützten zu unterscheiden.

Der Preis fester KlassenKlassen sind Kompromisse. Ein Dienst mit einer Vier-Stunden-Anforderung landet in Klasse A und bekommt einen Aufwand, den er nicht braucht, oder in Klasse B und bekommt eine Zusage, die er nicht einhält. Der ehrliche Umgang damit ist eine Ausnahmeliste mit Begründung und Datum — kurz gehalten, denn eine Ausnahmeliste, die länger wird als die Klassenliste, hat das Modell abgeschafft.

Vertraulichkeit ist keine Schutzklasse

In vielen Organisationen existiert bereits eine Klassifizierung: „öffentlich, intern, vertraulich, streng vertraulich“. Sie in das Recovery-Inventar zu übernehmen, ist naheliegend und falsch — die beiden Einteilungen beantworten verschiedene Fragen.

Sicherheitsklassifizierung — Beantwortet, wer die Daten sehen darf und wie stark sie gegen unbefugten Zugriff geschützt werden müssen. Sie steuert Verschlüsselung, Berechtigungen und Übertragungswege.

Schutzklasse für die Wiederherstellung — Beantwortet, wie schnell und wie vollständig die Daten nach einem Schaden zurück sein müssen. Sie steuert Rhythmus, Kopienzahl, Aufbewahrung und Übungsaufwand.

Die Fälle, in denen beide auseinanderfallen, sind die interessanten. Das Telefonverzeichnis der Firma ist als „intern“ eingestuft und trotzdem in Klasse C — sein Ausfall stört, aber nichts steht still. Die Produktionsplanung des laufenden Monats ist ebenfalls „intern“, aber in Klasse A, weil ohne sie die Fertigung stillsteht. Umgekehrt kann ein streng vertrauliches Archiv, auf das im Jahr dreimal zugegriffen wird, eine Wiederanlaufzeit von einer Woche haben.

Wo beide sich doch berührenAn genau einer Stelle greifen die Einteilungen ineinander: Hoch eingestufte Daten erzeugen zusätzliche Anforderungen an den Wiederherstellungsweg. Eine Testwiederherstellung darf dann nicht in eine beliebige Umgebung laufen, und die Kopie darf nicht bei jedem Anbieter liegen. Das ändert nichts an der Dringlichkeit — nur an den erlaubten Wegen.

Abhängigkeiten finden, die niemand aufgeschrieben hat

Das Feld „Abhängigkeiten“ ist das einzige, das sich nicht erfragen lässt. Was ein Dienst wirklich benutzt, weiß niemand vollständig — die ursprünglichen Erbauer sind weg, und die Dokumentation beschreibt den Stand der Inbetriebnahme. Was bleibt, ist Beobachtung.

Offene Verbindungen ansehen. Unter Linux zeigt ss -tanp laut ss(8) TCP-Sockets mit Prozess, numerisch und einschließlich der bestehenden Verbindungen; unter Windows leistet Get-NetTCPConnection dasselbe. Jede fremde Gegenstelle ist ein Kandidat.
Konfigurationen nach Namen durchsuchen. Verbindungszeichenfolgen, Endpunkt-Adressen und Servernamen in Konfigurationsdateien nennen Abhängigkeiten, die im Betrieb nur selten auffallen.
Namensauflösung mitlesen. Welche Namen ein Server nachfragt, ist oft aussagekräftiger als der Netzverkehr selbst — Anfragen entstehen auch für Dienste, die gerade nicht antworten.
Die Menschen fragen, die den Dienst benutzen. Fachliche Abhängigkeiten wie „ohne die Preisliste aus dem anderen System ist die Anwendung nutzlos“ tauchen in keinem Netzmitschnitt auf.

Die Abhängigkeit, die nur einmal im Monat auftaucht

Szenario

Für einen Abrechnungsdienst soll die Abhängigkeitskette ermittelt werden. Eine Beobachtung der Netzverbindungen über eine Woche liefert vier Gegenstellen: Datenbank, Verzeichnisdienst, Namensauflösung, Protokollserver.

Anforderungen

Die Kette soll den Monatsabschluss abdecken, nicht nur den Alltag.
Der Aufwand soll im Rahmen eines halben Arbeitstags bleiben.

Schritte

Die Beobachtungsdauer als das benennen, was sie ist: eine Stichprobe über sieben Tage, die alles verpasst, was seltener läuft.
In der Konfiguration und den geplanten Aufgaben des Dienstes nach Zielen suchen, die in der Beobachtung nicht vorkamen.
Dabei einen Aufruf an einen Zahlungsdienstleister finden, der nur am Monatsende ausgeführt wird — in der Woche der Messung also nie.
Die fachliche Gegenprobe machen: Die Sachbearbeitung bestätigt, dass ohne diesen Aufruf der Abschluss nicht fertig wird.
Beide Erkenntnisse in das Inventar eintragen und die Beobachtungslücke dokumentieren, statt die Kette für vollständig zu erklären.

Merksatz: Beobachtung findet, was im Beobachtungsfenster läuft. Monats-, Quartals- und Jahresläufe fallen systematisch heraus — und es sind genau die, deren Ausfall am teuersten ist. Die Ergänzung kostet ein Gespräch und einen Blick in die Aufgabenplanung.

Die Abdeckungslücke messen

Abdeckungslücke — Die Menge der Dienste, deren tatsächlicher Schutzzustand hinter der Schutzklasse zurückbleibt, die für sie zugesagt ist — gemessen, nicht geschätzt. Sie ist die einzige Kennzahl, die ein Recovery-Inventar liefern muss.

Sie entsteht aus einem Vergleich zweier Listen: der Dienste im Inventar und der Objekte, die das Sicherungssystem tatsächlich kennt. Die Differenz ist der Befund — und sie ist bei der ersten Messung fast immer größer als erwartet, weil beide Listen aus verschiedenen Anlässen entstanden sind und nie gegeneinander gehalten wurden.

Liste der Dienste mit Schutzklasse aus dem Inventar→Liste der tatsächlich gesicherten Objekte aus dem Sicherungssystem→Beide auf denselben Schlüssel bringen — Dienst, nicht Hostname→Differenz in beide Richtungen bilden→Jede Zeile der Differenz benennen und einer Entscheidung zuordnen

Der Vergleich muss in beide Richtungen laufen

Die zweite Richtung wird meist vergessen und ist ebenso aufschlussreich: gesicherte Objekte, die zu keinem Dienst im Inventar gehören. Dahinter stecken abgeschaltete Systeme, deren Sicherung weiterläuft, Testumgebungen im Rhythmus der Produktion — und gelegentlich ein Dienst, den tatsächlich jemand betreibt und den niemand in die Liste geschrieben hat. Die ersten beiden Fälle kosten Speicherplatz und Sicherungsfenster; der dritte ist ein Fund, der die ganze Übung rechtfertigt.

Eine Feinheit entscheidet über die Aussagekraft: Ein Dienst gilt erst dann als abgedeckt, wenn alle seine Datenorte abgedeckt sind. Eine Anwendung, deren Datenbank gesichert wird und deren hochgeladene Dokumente auf einer nicht gesicherten Freigabe liegen, ist im Vergleich der Listen unauffällig und im Ernstfall unvollständig. Deshalb steht im Inventar das Feld „Datenorte“ in der Mehrzahl.

Warum die Listen selten zusammenpassenSicherungssysteme führen ihre Objekte technisch: als virtuelle Maschine, Datenträger, Datenbankinstanz oder Repository. restic snapshots --json liefert Pfade und Hosts, eine Virtualisierungsplattform liefert Maschinennamen. Das Inventar führt Dienste. Diese Übersetzung ist Handarbeit, sie ist der eigentliche Aufwand dieses Moduls — und sie ist der Grund, warum die Lücke in vielen Betrieben nie gemessen wurde.

Drift: der Bestand ändert sich schneller als die Liste

Ein einmal gemessenes Inventar ist ab dem nächsten Tag falsch. Neue Systeme entstehen, alte werden abgeschaltet, Dienste ziehen um. Entscheidend ist deshalb nicht die Genauigkeit der Momentaufnahme, sondern die Richtung, in die ein neues System standardmäßig fällt.

Aufnahme per Einzelschritt: Ein neues System wird geschützt, wenn jemand daran denkt. Der Standardzustand ist ungeschützt, und der Fehler fällt erst im Schadensfall auf.
Aufnahme per Voreinstellung: Ein neues System fällt über eine Regel — Merkmal, Namensraum, Platzierung — automatisch in eine Klasse. Der Standardzustand ist geschützt, und die Ausnahme muss begründet werden.

Der Unterschied ist strukturell, nicht organisatorisch: Er hängt nicht daran, ob das Team sorgfältig arbeitet, sondern daran, wohin ein Versäumnis führt. Die zweite Variante lässt sich in jeder halbwegs modernen Umgebung bauen — über Merkmale an virtuellen Maschinen, über Namenskonventionen, über die Platzierung in einem Ordner oder Ressourcengruppen-Äquivalent. Sie ist die einzige Antwort auf Drift, die ohne dauerhafte Disziplin auskommt.

Kurzcheck

Eine Regel ordnet jede neue virtuelle Maschine automatisch der Klasse B zu. Ein Team legt für einen Lasttest zwanzig kurzlebige Maschinen an. Was ist die richtige Reaktion?

Ein Merkmal für kurzlebige Systeme definieren, das ausdrücklich in „ohne Klasse“ führt.
Die automatische Zuordnung abschalten, weil sie unnötige Sicherungslast erzeugt.
Die zwanzig Maschinen einzeln aus der Sicherung nehmen.

Treffer. Richtig. Die Ausnahme wird selbst zur Regel und damit sichtbar, nachvollziehbar und wiederverwendbar — der Standardzustand bleibt geschützt.

Der blinde Fleck: was der Anbieter nicht sichert

Ein Inventar, das nur eigene Server kennt, verfehlt inzwischen einen erheblichen Teil des Bestands. Postfächer, Dateiablagen, Projektwerkzeuge und Fachanwendungen liegen bei Anbietern — und die Annahme, dort werde „schon gesichert“, ist die häufigste unausgesprochene Annahme im ganzen Themengebiet.

Die Anbieter selbst sind dabei bemerkenswert deutlich. Die Verantwortungsmatrix von Microsoft weist die Zeile Kundendaten über alle Betriebsmodelle hinweg dem Kunden zu — im eigenen Rechenzentrum, bei IaaS, bei PaaS und ausdrücklich auch bei SaaS. Dasselbe gilt für Konfiguration und Identitäten. Was der Anbieter übernimmt, sind Verfügbarkeit und Haltbarkeit der Plattform, nicht die Wiederherstellbarkeit deiner Inhalte nach einer Fehlbedienung oder einem Angriff.

Papierkorb ist keine SicherungNahezu jeder Anbieter hält gelöschte Objekte eine begrenzte Zeit vor. Das deckt den versehentlichen Einzellöschvorgang ab und endet dort: Es hat eine feste Frist, es schützt nicht gegen eine über Wochen laufende Verfälschung, und es steht unter derselben Anmeldung, die ein Angreifer bereits hat. Der Prüfsatz dafür lautet: Was passiert, wenn ein Konto mit Verwaltungsrechten absichtlich Schaden anrichtet? Alles, was dieselbe Anmeldung erreicht, ist keine unabhängige Kopie.

Für das Inventar folgt daraus ein einfacher Zusatz: Das Feld „Datenorte“ muss Anbieterdienste ausdrücklich mitführen, und für jeden von ihnen ist derselbe Schutzzustand einzutragen wie für eigene Systeme. Das Ergebnis ist unbequem und deshalb wertvoll — es macht eine Lücke sichtbar, über die noch niemand entschieden hat.

Aufbewahrungspflicht und Löschpflicht im selben Bestand

Das siebte Feld ist das unangenehmste, weil in ihm zwei Pflichten aufeinandertreffen. Handels- und steuerrechtliche Vorgaben verlangen, bestimmte Unterlagen jahrelang aufzubewahren. Das Datenschutzrecht verlangt, personenbezogene Daten auf Verlangen zu löschen. Sicherungen enthalten regelmäßig beides — und sind so gebaut, dass sich einzelne Datensätze gerade nicht herausschneiden lassen.

Die britische Aufsichtsbehörde ICO beschreibt für die dortige Fassung der Datenschutz-Grundverordnung einen praktikablen Weg, der die technische Wirklichkeit anerkennt: Ein Löschbegehren kann im Live-System sofort erfüllt werden, während die Daten in der Sicherung verbleiben, bis diese planmäßig überschrieben wird. Verlangt wird dafür, die Daten außer Gebrauch zu setzen — sie ausschließlich in der Sicherung liegen zu lassen, sie für keinen anderen Zweck zu verwenden und die betroffene Person klar darüber zu informieren, was mit ihren Daten geschieht.

Was das für das Inventar bedeutet — und wo die Grenze dieses Textes liegtDie Argumentation trägt nur, wenn ein festgelegter Aufbewahrungsplan existiert und die Sicherung tatsächlich planmäßig überschrieben wird. Unbegrenzt aufbewahrte Sicherungen entziehen sich ihr: Was nie überschrieben wird, wird auch nie gelöscht. Damit wird die dokumentierte Aufbewahrungsdauer zum Bestandteil des Inventars. Die rechtliche Bewertung für den deutschen Rechtsraum gehört in fachkundige Hände — hier geht es um die betriebliche Folge, nicht um Rechtsberatung.

Was das Inventar nicht leistet

Ein gepflegtes Inventar schützt nichts. Es verschiebt nur den Zeitpunkt, an dem eine Lücke auffällt, von der Wiederherstellung auf den Schreibtisch. Das ist der ganze Gewinn — und er ist erheblich, weil eine Lücke am Schreibtisch Geld kostet und eine Lücke im Ernstfall den Dienst.

Es sagt nichts darüber, ob die vorhandene Sicherung lesbar ist — das prüft erst ein Restore.
Es sagt nichts darüber, ob die Kopien unabhängig genug voneinander sind — das entscheidet das Schutzdesign.
Es sagt nichts über die Wiederanlaufzeit — die hängt am Verfahren, nicht an der Liste.
Es veraltet ab dem Tag der Erstellung; nur die Voreinstellung für neue Systeme hält es brauchbar.

Der kleinste nützliche AnfangZehn Dienste, sieben Felder, eine Tabelle. Wer mit dem Anspruch auf Vollständigkeit beginnt, wird nie fertig; wer mit den zehn Diensten beginnt, deren Ausfall am meisten kostet, hat nach einem Tag eine Grundlage für die nächsten Module — und meist schon den ersten Befund, für den sich der Tag gelohnt hat.

Weiter im Track

Aus dem Inventar entstehen die Eingaben für die folgenden Module: Die Schutzklassen werden im Schutzdesign in Kopienzahl, Trennung und Aufbewahrung übersetzt. Die Abdeckungslücke wird in der Recovery-Architektur zu einer Auswahl von Verfahren. Die Abhängigkeitsketten bestimmen später die Reihenfolge im Wiederanlauf.

AbgrenzungWie ein Betriebsmittelverzeichnis als Ganzes gepflegt wird — Lebenszyklus, Lizenzen, Beschaffung — steht in itsm-operations. Hier interessiert nur der Ausschnitt, der eine Wiederherstellungsentscheidung trägt: Dienst, Eigentümer, Klasse, Orte, Abhängigkeiten, Ist-Zustand, Aufbewahrung.

Jetzt anwenden

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

Zum Modul →

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