KI Programmierung: Ein Sicherungssystem für zwei Plattformen: mit Selbstprüfung und nachweisbarer Wiederherstellung

Abschlussbericht aus der eigenen Infrastruktur: Was am Ende steht, was es kann, was es nicht kann und warum es für NIS-2 relevant ist.

---

Kurz gesagt

Wir sichern VMs von zwei verschiedenen Virtualisierungsplattformen (VergeOS und Proxmox) nach demselben Prinzip auf ein NAS außerhalb der Hypervisoren: nachts, inkrementell, mit Prüfsummen. Zwei identische Appliances teilen sich die Arbeit, überwachen sich gegenseitig und springen füreinander ein. Eine Weboberfläche bringt Wiederherstellung, Auswahl und Einstellungen an einen Ort.

Ein Verfahren, eine Oberfläche, ein Bericht für beide Plattformen. Ein Backuptoo für unsere virtuelle Landschaft. Das war das Ziel, und es ist erreicht.

Der Punkt, der uns am Ende am wichtigsten geworden ist: Das System beweist jede Nacht, dass es wiederherstellen kann, und schickt uns den Beweis. Jede Nacht wird eine VM aus ihrer Sicherung tatsächlich zusammengesetzt und geprüft, und einmal pro Woche wird eine wiederhergestellte Proxmox-VM zusätzlich wirklich gestartet. Das Ergebnis kommt als ausführlicher Nachweis per Mail, bei Erfolg und bei Fehlschlag. Das hilft im Alltag, und es ist genau die Art von Belegbarkeit, die die europäische NIS-2-Richtlinie von Betreibern wichtiger Dienste erwartet.

Was das System kann

Inkrementell auf beiden Plattformen. Bei VergeOS nutzt die Appliance die Änderungsverfolgung des Clusters. Bei Proxmox lesen wir die Änderungsinformationen aus dem LVM-Thin-Pool selbst und übertragen nur geänderte Blöcke. Jede Nacht wandert nur, was sich verändert hat.

Ketten statt Einzelkopien. Eine Vollsicherung und die Inkremente darauf bilden eine Kette. Neue Vollsicherungen laufen zeitlich versetzt, damit nicht alle VMs in einer Nacht voll gesichert werden. Alte Ketten werden nach einer einstellbaren Frist gelöscht (VergeOS 28 Tage, Proxmox 14 Tage), die jüngsten bleiben immer erhalten.

Gepackt. Die Proxmox-Sicherungen werden beim Schreiben mit zstd komprimiert. In unseren Messungen belegten die gepackten Dateien rund 35 bis 45 Prozent des Originals, und das Packen ist deutlich schneller als der Weg zum NAS. Es bremst die Sicherung also nicht. Ältere, ungepackte Sicherungen bleiben lesbar. Gepackte und ungepackte Schritte lassen sich in derselben Kette zusammensetzen und bit-genau wiederherstellen.

Wiederherstellung per Klick. Zeitpunkt wählen, Fortschritt ansehen, Ergebnis herunterladen oder direkt als neue VM anlegen lassen. Das geht auch über Plattformgrenzen: Eine Proxmox-VM lässt sich auf VergeOS bringen, eine VergeOS-VM auf Proxmox. Eine Proxmox-VM kann direkt aus der Sicherung wieder auf Proxmox entstehen, auf dem gewünschten Speicher und samt UEFI- und TPM-Daten. Fehlt in einer wiederhergestellten Windows-Kopie der Startpfad für UEFI, legt die Appliance ihn selbst an. Eine Tabelle sagt vorher, welche Platte wohin kommt und worauf zu achten ist. Laufende Aufträge lassen sich abbrechen.

Die Auswahl gehört den Administratoren. Welche VMs gesichert werden und von welchen Speichern, stellt man mit Häkchen ein. Neue VMs sind automatisch dabei. Abgewählte VMs behalten ihre vorhandenen Sicherungen und lösen keinen Alarm aus.

Alle Werte einstellbar. Aufbewahrung, Zeiten, Wiederholungen, Schwellenwerte und Kompression stehen als Einstellungen in der Weboberfläche. Jede Änderung zeigt vorher „alt → neu“, gilt für beide Appliances und wird mit Verlauf festgehalten. Wer Zugang zur Appliance hat, darf sie ändern, eine neue Rechtegruppe brauchten wir dafür nicht.

Aufräumen mit Bremse. Sicherungen von VMs, die es nicht mehr gibt, werden als „verwaist“ markiert und lassen sich löschen. Ein Fenster nennt vorher, was verschwindet, und verlangt bei „alles“ den VM-Namen. Die Weboberfläche selbst löscht nichts: Sie reicht den Auftrag an einen getrennten Dienst, der ihn noch einmal prüft, protokolliert und per Mail meldet.

Sicherheit im Betrieb

Zwei Appliances, kein Alleinstehender. Beide laufen auf verschiedenen Plattformen. Eine sichert, die andere beobachtet sie. Fällt die erste aus, übernimmt die zweite. Schlägt dagegen nur ein einzelner Lauf fehl, springt die Reserve bewusst nicht ein, denn ohne Kenntnis des Fehlers würde sie vermutlich denselben Fehler wiederholen. Stattdessen kommt eine Mail.

Gegenseitige Überwachung. Jede Appliance prüft die andere alle fünf Minuten und meldet Ausfälle per Mail. Weil die Reserve auf der anderen Plattform läuft, erreicht uns die Meldung auch dann, wenn eine ganze Plattform ausfällt.

Selbstprüfung. Jede Nacht um sechs liest das System ein Siebtel aller Proxmox-Sicherungen komplett von der Platte zurück und vergleicht die Prüfsummen. Die ganze Sicherung ist damit einmal pro Woche geprüft. Beschädigung wird so Wochen vor dem Ernstfall entdeckt, nicht erst im Ernstfall. Der erste Lauf prüfte 85 GB in knapp einer Stunde und fand keinen Fehler. Das Ergebnis steht im Tagesbericht, bei Fehlern kommt eine Mail.

Probe-Wiederherstellung mit Nachweis. Jede Nacht um 03:30 setzt die Appliance die neueste Kette einer VM zu einer Platte zusammen, genau wie bei einer echten Wiederherstellung, aber nur im Zwischenspeicher. Danach prüft sie das Ergebnis: Enthält die Platte Daten, ist die Partitionstabelle in Ordnung (bei GPT mit ihren Prüfsummen), werden in den Partitionen Dateisysteme erkannt, ist bei UEFI das EFI-Verzeichnis lesbar. Dann wird alles wieder gelöscht. Die Auswahl rotiert: Es kommt immer die VM an die Reihe, deren letzte Probe am längsten zurückliegt, Proxmox und VergeOS gemischt. Bei 23 gesicherten Systemen ist jedes in knapp vier Wochen einmal an der Reihe. Die Probe läuft nie gleichzeitig mit der Sicherung und hat eine einstellbare Zeitgrenze.

Echter Start der wiederhergestellten VM. Einmal pro Woche geht die Probe einen Schritt weiter: Bei einer Proxmox-VM werden die zusammengesetzten Platten samt EFI-Variablen und TPM-Zustand auf den Host gebracht und dort als Probe-VM gestartet. Die Probe-VM läuft in einem eigenen Pool, ohne Netzwerkverbindung, mit begrenztem Arbeitsspeicher (Standard höchstens 8 GiB) und höchstens zwei Prozessorkernen, damit sie weder die Produktion stört noch mit einer echten VM verwechselt oder im Netz sichtbar wird. Die Appliance beobachtet bis zu fünf Minuten, ob die VM durchgehend läuft, ob das Betriebssystem von der Platte liest und ob es in einen Neustart-Kreislauf gerät, und sie macht ein Bildschirmfoto, das auf Inhalt und auf einen Bluescreen geprüft wird. Danach wird die Probe-VM immer gestoppt und samt Platten gelöscht, auch nach einem Fehler. Reste eines früher abgebrochenen Laufs räumt die Appliance beim nächsten Mal selbst weg. Grenzen für Datenmenge, Arbeitsspeicher, Beobachtungszeit und Abstand sind einstellbar.

Zugriff auf den Hypervisor so eng wie möglich. Die Appliance darf auf dem Proxmox-Host nur einen einzigen, festgelegten Befehl ausführen, ohne Shell. Die Weboberfläche läuft hinter dem zentralen Single Sign-on, mit getrennter Notanmeldung für den Fall, dass das SSO selbst ausfällt.

Updates mit Netz. Neue Versionen gehen mit einem Befehl auf alle Maschinen. Das Verteilwerkzeug prüft vorher die Syntax, sichert die alten Dateien und rollt automatisch zurück, wenn die Seite danach nicht antwortet. Während einer Wiederherstellung startet es die Weboberfläche nicht neu.

Warum das für NIS-2 zählt

Die NIS-2-Richtlinie (Artikel 21) verlangt von betroffenen Einrichtungen Maßnahmen zur Aufrechterhaltung des Betriebs, ausdrücklich auch Backup-Management und Wiederherstellung nach einem Notfall. Und sie verlangt, die Wirksamkeit solcher Maßnahmen zu bewerten. Eine Sicherung, die nie zurückgespielt wurde, ist in diesem Sinn eine Behauptung. Eine, die regelmäßig zurückgespielt wird und darüber Protokoll führt, ist ein Nachweis.

Darum sendet die Probe-Wiederherstellung nach jedem Lauf einen Nachweis, auch bei Erfolg. Er enthält:

• Wann und wo: Appliance, Beginn, Ende und Dauer.
• Was: VM, Plattform, Kette, den genauen Wiederherstellungspunkt (Zeitpunkt und Schritt) und die Zahl der Schritte, aus denen die Platte entstand.
• Wie geprüft: Bei Proxmox wurden alle Dateien der Kette gelesen und gegen ihre SHA-256-Prüfsumme verglichen. Bei VergeOS wurde die Kettenstruktur mit qemu-img check geprüft. Dann wurde die Platte zusammengesetzt, untersucht und das Ergebnis gelöscht.
• Was herauskam: je Platte Partitionstabelle, erkannte Dateisysteme, EFI-Verzeichnis, Hinweise und Fehler, am Ende ein klares Gesamtergebnis.
• Der Systemstart: Bei der wöchentlichen Startprobe zusätzlich die Probe-VM mit Arbeitsspeicher und Kernen, die Beobachtungsdauer, die vom Betriebssystem gelesene Datenmenge, die Zahl der Neustarts, der Ablauf mit Uhrzeiten, die Bestätigung, dass alles wieder gelöscht ist, und das Bildschirmfoto der gestarteten VM als Anhang. Das Foto wird zusätzlich dauerhaft abgelegt.

Auch übersprungene Proben bekommen eine Mail mit dem Grund (zum Beispiel: eine Wiederherstellung lief gerade). Es gibt keine Nacht ohne Beleg. Zusätzlich wird jede Probe fortlaufend in einen Verlauf geschrieben, der nie überschrieben wird. Ein Fehlschlag löst dazu eine Fehlermeldung aus, und der Tagesbericht färbt sich rot.

Wichtig für die Einordnung: Dieses Verfahren unterstützt den Nachweis, es ist kein Zertifikat. Ob es den eigenen NIS-2-Pflichten genügt, ist eine Frage der Gesamtbewertung durch die Verantwortlichen. Die technische Grundlage dafür, ein regelmäßiger, protokollierter und überprüfbarer Wiederherstellungstest ohne manuelle Arbeit, liefert das System.

Unter der Haube

Für alle, die wissen wollen, wie es funktioniert:

Proxmox direkt gesichert. Die VMs liegen auf LVM-Thin. Für jede Platte legt die Appliance über einen schmalen Helfer auf dem Host einen Thin-Snapshot an. Für Inkremente liest der Helfer mit thin_delta die Metadaten des Pools und erfährt so, welche Blöcke sich seit dem letzten Snapshot geändert haben, ohne die Platte zu scannen (Suche unter einer Sekunde). Dabei wird ein Metadaten-Snapshot des Pools gehalten, damit der Zustand während des Auslesens stillsteht. Die geänderten Bereiche kommen als Datenstrom über SSH zur Appliance. Ein Füllstandsschutz (Standard 92 Prozent) verhindert, dass die Sicherung den Pool füllt.

Eigenes, einfaches Dateiformat. Der Strom besteht aus einem Kopf und Rahmen für Daten, Nullbereiche und das Ende, am Schluss steht eine SHA-256-Prüfsumme über alles. Die Appliance prüft sie beim Empfang. Jede Platte und jeder Schritt ist eine Datei in einer Kette (000-… ist die Vollsicherung, danach folgen die Inkremente), dazu kommen eine Konfigurationsdatei und ein Manifest. Mit px.kompression werden die Dateien beim Schreiben mit zstd gepackt (Stufe 3). Die Prüfsumme gilt immer für den ungepackten Strom, die Datei trägt zusätzlich die Prüfsumme des zstd-Formats. Die Wiederherstellung erkennt gepackte und ungepackte Schritte an der Dateikennung und setzt sie gemischt zusammen.

VergeOS über die Standardschnittstelle. Die Appliance nutzt die Änderungsverfolgung (Changed Block Tracking) über die oVirt-kompatible Schnittstelle des Clusters. Jede Nacht wird ein Checkpoint angelegt und nur das Geänderte als qcow2-Schritt abgelegt. Die Schritte zeigen per Backing-File aufeinander, qemu-img kann die Kette also auch ohne unsere Software lesen.

Wiederherstellung. Aus der Kette wird eine dünn besetzte Rohdatei aufgebaut, Schritt für Schritt, Nullbereiche werden als Löcher geschrieben. Danach folgt qemu-img convert zu qcow2 oder der Import auf Proxmox per Dateiübertragung und API. Bei UEFI-VMs werden Boot-Platte, EFI-Platte und TPM-Zustand mitgenommen. Fehlt der Standard-Startpfad in der EFI-Partition, legt die Appliance ihn mit mtools in der wiederhergestellten Kopie an.

Startprobe im Detail. Die Appliance legt die Probe-VM über die Schnittstelle von Proxmox an, mit einem Token, das nur den Pool der Wiederherstellungen, den Importspeicher und die erlaubten Plattenspeicher berührt. Die Platten werden per SFTP in einen abgetrennten Importspeicher übertragen, die EFI-Daten über einen Umweg als Platte importiert und danach als EFI-Disk angehängt, weil Proxmox bei EFI-Disks die Importquelle ignoriert. Das Bildschirmfoto holt ein kleiner Helfer auf dem Host über den QEMU-Monitor (screendump), der nur für Probe-VMs mit festem Namensmuster und aus einem festen ID-Bereich arbeitet. Er wertet das Bild aus (Anteil heller Bildpunkte, Farbvielfalt, vorherrschende Farbe, damit ein Bluescreen auffällt) und liefert es als PNG zurück. Vor dem Start prüft die Appliance Platz im Plattenspeicher und freien Arbeitsspeicher auf dem Host und startet nichts, wenn es eng wäre.

Zwei Appliances, eine Regel. Jede schreibt ein Lebenszeichen auf das NAS. Vor jedem Lauf entscheidet eine Wache: Sichert eine andere gerade, wird nicht gesichert. Ist die bessere Appliance frisch und aktiv, bleibt die Reserve stehen. Erst wenn sie weder Lebenszeichen noch Antwort auf ihre Gesundheitsabfrage liefert, übernimmt die Reserve. Sicherung, Selbstprüfung und Probe teilen sich dieselbe Sperre und laufen nie gleichzeitig.

Trennung der Rechte. Die Weboberfläche ist nur lesend. Löschen und Einstellungen laufen über Auftragsdateien an einen getrennten Dienst, der den Auftrag noch einmal prüft, ausführt, protokolliert und per Mail meldet. Die Einstellungen (rund 40 Werte, mit Wertebereichen) liegen in einer gemeinsamen, versionierten Datei auf dem NAS und gelten für beide Appliances. Die Uhrzeiten werden daraus automatisch in die systemd-Timer übernommen.

Auslieferung. Der Code liegt in einem Git-Repository. Ein Befehl verteilt eine Version an alle Maschinen, prüft vorher die Syntax, sichert die alten Dateien und rollt zurück, wenn der Gesundheitstest nach dem Neustart scheitert.

Getestet, nicht geglaubt

• Eine laufende VM wurde voll und inkrementell gesichert und zurückgeholt. Die SHA-256-Prüfsumme stimmte mit dem Original überein.
• Eine Windows-11-VM mit UEFI und TPM wurde gesichert, als Kopie ohne Netzwerkkarte wiederhergestellt und gestartet. Sie fuhr bis zum Anmeldebildschirm.
• Eine Kette, die eine Appliance geschrieben hatte, wurde von der anderen zusammengesetzt, mit demselben Ergebnis. Die Sicherungen hängen an keiner einzelnen Maschine.
• Beschädigte oder abgeschnittene Dateien werden erkannt, auch in gepackter Form.
• Tägliche Wiederherstellung einer VM als Beweis, dass der Backup- und Restoreprozess funktioniert.

Die Zahlen

Gesichert	10 VergeOS-VMs und 13 Proxmox-VMs
Datenmenge	rund 212 GB (VergeOS) und 578 GB (Proxmox, ungepackt)
Nächtlicher Lauf	Änderungen aller VMs in der Größenordnung von zehn Minuten
Erste Vollsicherung	13 Proxmox-VMs, rund 527 GiB in gut fünf Stunden
Wöchentliche Selbstprüfung	jedes Siebtel in rund einer Stunde, alles in sieben Tagen
Probe-Wiederherstellung	jede Nacht eine VM; 10 GiB in 4 Minuten, 24 GiB in 13 Minuten (im Test)
Startprobe	einmal pro Woche eine Proxmox-VM, ohne Netzwerk, höchstens 5 Minuten beobachtet, danach gelöscht
Nachweis	eine ausführliche Mail pro Probe, dazu ein fortlaufender Verlauf
Speicher	NAS zu etwa 50 Prozent belegt, nach dem Aufräumen alter Altbestände

Wo die Grenzen liegen

Zu einem ehrlichen Bericht gehört auch, was fehlt:

• Alles liegt auf einem NAS. Es gibt noch keine Kopie außer Haus. Das ist das größte verbleibende Risiko.
• Der Start wird beobachtet, nicht bedient. Die Startprobe belegt, dass die wiederhergestellte VM hochfährt und das Betriebssystem arbeitet. Sie meldet sich aber nicht im Gastsystem an und prüft keine Anwendungen. Die Bewertung stützt sich auf Laufzustand, Plattenlesen und Bildschirm. Deshalb bekommt jeder Nachweis das Bildschirmfoto, damit ein Mensch das Urteil nachprüfen kann. Gestartet werden nur Proxmox-VMs bis zu einer einstellbaren Datenmenge, bei VergeOS prüft die Probe die Kettenstruktur und die zusammengesetzte Platte.
• Absturzkonsistent. Die Sicherungen entsprechen dem Zustand nach einem Stromausfall, solange keine VM den Gast-Agenten zum Einfrieren des Dateisystems nutzt.
• Der Weg zum NAS ist der Flaschenhals (rund 30 MB/s). Das spürt nur der erste Durchlauf und neue Vollsicherungen.
• Domänencontroller brauchen bei der Wiederherstellung auf Proxmox einen Handgriff, weil die Generations-ID der VM nicht mitgenommen werden kann.

Technik im Überblick: VergeOS (Änderungsverfolgung über die Cluster-Schnittstelle, qcow2-Ketten), Proxmox VE (LVM-Thin, thin_delta), zstd, Linux-Appliance mit Python und FastAPI, Single Sign-on über OIDC, systemd-Timer, Git-basierte Verteilung mit automatischem Rollback.