Prüf-Restore: Sicherungen zur Probe wiederherstellen

Zum Inhaltsverzeichnis

Eine Sicherung ist erst belegt, wenn sie sich wiederherstellen lässt. Auf dem Backup-Server (Linux) stellt bkp_pruefrestore Läufe zur Probe wieder her, prüft und zählt ihre Dateisysteme und startet ihre VMs in einer abgeschotteten Sandbox. Die Sicherungen selbst bleiben dabei unverändert. Jeder Schritt ist ein eigener Job des Target-Schedulers; die Jobs hängen mit after= aneinander und teilen sich den Ordner --path, in dem der erste Schritt das Manifest pruefrestore.json anlegt. Einen Standardjob gibt es nicht: Die Kette legt der Betreiber an, die Vorlage steht in bkp_target_sched.cfg.example, und die Target-Konsole bietet jeden Schritt unter „Neu… → Vorlage“ an.

11.1 Die Schritte#

pruef-fsck, pruef-mount und pruef-count arbeiten ohne weitere Angabe mit allen Platten des Prüf-Restores. Mit --disk <platte> (so, wie bkp_pruefrestore status sie nennt, etwa scsi1 oder disk) nehmen sie nur diese Platte, pruef-mount und pruef-count mit --part <n> nur eine Partition (die Nummer, wie Linux sie zählt) samt den LVM-Volumes darin. So lässt sich etwa das Datenvolume eines Servers jede Woche zählen, das Systemvolume nur prüfen. Welche Platten und Partitionen eine Sicherung hat, mit Dateisystem und Bezeichnung, hält jeder neue Lauf fest; bkp_restore --show-layout zeigt es.

11.2 Dateien zählen und lesen#

pruef-count läuft durch jedes eingebundene Dateisystem, zählt Ordner, Dateien, Links und Bytes und liest jede Datei ganz, mit einer Prüfsumme (Standard SHA-256). Das Protokoll des Jobs nennt je Dateisystem und je Sicherung, was gezählt und gelesen wurde, die neueste Änderung und den Vergleich mit der letzten Prüfung; die Prüfsummen stehen als Liste im Format von sha256sum bzw. b3sum unter <path>/<lauf>/hashes/ (das Aufräumen löscht sie mit). Für den Vergleich mit der nächsten Prüfung bleiben sie neben dem Zählverlauf im Ordner history/ neben dem Store der Sicherung (nächster Abschnitt).

Ein Befund macht den Schritt „fehlgeschlagen“ (Exit 3) und steht im Prüfbericht:

Wie viel gelesen wird: --read-sample <prozent> liest nur einen zufälligen Teil der Dateien, --read-max hört nach einer Datenmenge (500G) oder Zeit (2h) auf zu lesen – gezählt wird trotzdem alles. --background liest mit niedriger Priorität und je nach Last des Targets nur --background-min bis --background-max Prozent der Zeit (Standard 5 bis 50). --hash blake3 oder xxh3-128 rechnet schneller als SHA-256. --exclude lässt Namen (überall) oder Pfade ab der Wurzel aus, mit * und ?, mehrere durch Kommas getrennt; pagefile.sys, hiberfil.sys, swapfile.sys, $Recycle.Bin und System Volume Information bleiben ohnehin außen vor, außer mit --no-default-excludes.

Direkt an einer Partition. Mit --disk, --part und --mount-point braucht pruef-count keinen Schritt „einbinden“ davor: Er bindet die Partition selbst nur lesend ein und trennt sie am Ende wieder (--keep-mounted lässt sie eingebunden, etwa für weitere Schritte). Eine Partition, in der „Dateisystem prüfen“ Fehler fand, wird wie beim Einbinden übersprungen. Hat eine Platte keine Partitionstabelle, sondern nur ein Dateisystem, genügen --disk und --mount-point; in der Target-Konsole dockt „Dateisystem durchlaufen“ dann direkt am Punkt dieser Platte von „Prüfen – Wiederherstellung“ an.

11.3 Auf Viren prüfen#

pruef-virus (in der Target-Konsole der Kasten „Prüfen: Auf Viren prüfen“) prüft die Dateien eines Prüf-Restores mit ClamAV auf Schadsoftware. Er hängt wie „Dateisystem durchlaufen“ hinter „Dateisystem einbinden“ oder direkt an einer Partition (--disk, --part, --mount-point) und liest nur; die Sicherung selbst bleibt unverändert. So fällt auf, wenn ein Schädling mitgesichert wurde, und vor allem, seit welcher Sicherung er darin steckt und welche Sicherung die letzte saubere ist – das ist die, aus der man nach einem Befall wiederherstellt.

11.3.1 ClamAV einrichten#

ClamAV kommt aus den Paketen der Distribution; die Systemprüfung des Targets nennt den Befehl, sobald ein pruef-virus-Job eingerichtet ist. freshclam hält die Signaturen aktuell, am einfachsten als Dienst:

ClamAV installieren

apt install clamav clamav-freshclam      # Debian, Ubuntu
dnf install clamav clamav-update         # RHEL, Rocky, Alma (dann: freshclam einmal von Hand)
zypper install clamav                    # SUSE
systemctl enable --now clamav-freshclam  # Signaturen täglich aktualisieren

Läuft zusätzlich der Dienst clamd, prüft pruef-virus über ihn (clamdscan, mehrere Dateien gleichzeitig, die Signaturen sind schon geladen); sonst startet er einmal clamscan für die ganze Auswahl. Was clamd nicht kann – PUA, eigene Regeln, Größengrenzen, Archive auslassen –, prüft von selbst clamscan; das Protokoll nennt den Grund. --engine clamscan nimmt immer clamscan. Die Systemprüfung meldet Signaturen, die älter als drei Tage sind (oder als das kleinste --max-db-age der Jobs), als Warnung „Virensignaturen veraltet“, mit dem Befehl zum Beheben.

11.3.2 Targets ohne Internetzugang#

Ein Target, das freshclam nicht erreichen kann, bekommt die Signaturen vom Standortserver der Installation: Dort füllt der Betreiber den Ordner aus virus-db-dir = in bkp_sitesrv.cfg (etwa mit cvdupdate oder per Kopie von einem Rechner mit Internet), auf dem Target steht virus-db-source=site in bkp_target.cfg. Bei jeder Systemprüfung (Start, alle 25 Stunden, nach jedem Update) holt das Target neuere Dateien über seine Verbindung zum Standortserver, prüft Größe, SHA-256 und Signatur (sigtool --info) und legt sie in den Signaturordner von ClamAV (DatabaseDirectory aus freshclam.conf, Standard /var/lib/clamav). Ohne Standortserver geht es von Hand:

Signaturen auf einem abgeschotteten Target einspielen

bkp_target --virus-db-import /media/usb/clamav/        # alle .cvd, .cld und .cud des Ordners
bkp_target --virus-db-import /media/usb/daily.cvd      # eine Datei

11.3.3 Eigene Regeln#

Eigene Signaturen (.hdb, .hsb, .ndb, .ldb …, etwa die SHA-256 einer Schadsoftware aus einem Vorfall) und YARA-Regeln (.yar, .yara) legt der Betreiber nach /etc/aegisgrid/virus-rules/; ist der Ordner da, nimmt pruef-virus ihn mit. --rules <ordner> nimmt einen anderen, --no-rules keinen. In der Target-Konsole zeigt der Jobdialog, ob der Server den Ordner hat.

11.3.4 Optionen#

In der Target-Konsole stellt „Optionen…“ im Jobdialog bzw. im Kontextmenü des Kastens alles davon ein (Fenster „Auf Viren prüfen – Optionen“).

11.3.5 Bewertung#

Jeder Fund nennt Datei, Dateisystem, Signatur, seit welcher Sicherung die Datei darin ist und die letzte Sicherung ohne den Fund. Der Prüfbericht hat die Spalte „Virenfrei“ und nennt den Signaturstand; findet „Dateisystem durchlaufen“ in derselben Partition einen Ransomware-Verdacht, steht beides in derselben, hervorgehobenen Zeile. Ein Fund schickt sofort die Mail virenfund (statt fehler) und kommt ins Nachweis-Protokoll (virus-found; jede Prüfung als virus-scan).

11.3.6 Funde ansehen, Fehlalarme ausnehmen#

Ein Doppelklick auf den Lauf in der Target-Konsole öffnet das Ergebnis; „Virenfunde…“ zeigt alle Funde einer Sicherung, seitenweise, mit Datei, Signatur, „in den Sicherungen seit“ und „letzte Sicherung ohne den Fund“; „Kopieren“ legt den gewählten Fund in die Zwischenablage. Ist ein Fund ein Fehlalarm – etwa ein eigenes Werkzeug, das ClamAV für verdächtig hält –, trägt „Als Fehlalarm markieren…“ seine Signatur unter --ignore-signature in den Job ein; ab der nächsten Prüfung zählt sie nicht mehr.

11.3.7 Was der Kunde sieht#

Liegt der Fund in der Sicherung eines Kunden, erfährt dessen Rechner es bei der nächsten Sicherung zu diesem Target: Der Agent schreibt es ins Protokoll, bkp_sched list zeigt am Job „virus found by the check restore of the target in the backup of …“ mit Datei und Signatur, die Scheduler-Konsole einen Warnpunkt mit „Virenfund im Prüf-Restore“. Die Einzelheiten kennt der Betreiber des Targets. Eine spätere saubere Prüfung derselben Sicherung hebt die Meldung auf; schlägt eine Prüfung fehl, bleibt der frühere Fund stehen.

Jede Woche nur Neues prüfen, alle 7 Tage alles, höchstens 4 Stunden (/etc/bkp/bkp_target_sched.cfg)

[pruef-viren]
command=pruef-virus
after=pruef-einbinden
run-as=root
args=--path /srv/pruefrestore/woche --changed-only --full-every 7 --max-time 4h --background

11.4 Wo die Prüf-Daten liegen#

Alles, was die Prüfungen einer Sicherung brauchen, liegt in einem Ordner neben ihrem Store und zählt so zum Speicherplatz des Kunden oder der Abteilung: die wiederhergestellten Platten (--path), das Manifest und der Verlauf von „Dateisystem durchlaufen“ (Zahlen und Prüfsummen der letzten Prüfung) in history/. Das Aufräumen löscht die Platten, der Verlauf bleibt für den nächsten Vergleich.

Ordner neben dem Store

/srv/backups/kunde-weber/srv-app01.cbs            der Store der Sicherung srv-app01
/srv/backups/kunde-weber/srv-app01.pruef/          die wiederhergestellten Platten, pruefrestore.json
/srv/backups/kunde-weber/srv-app01.pruef/history/  Zählverlauf und Prüfsummen

Neue Prüf-Restores der Target-Konsole bekommen --path {storage}/<verzeichnis>/<name>.pruef. Bestehende Ketten behalten ihren Ordner; „Ordner neben die Sicherung legen…“ im Kontextmenü von „Prüfen – Wiederherstellung“ stellt --path und die Einhängepunkte aller Schritte der Kette auf einmal um (rückgängig mit Strg+Z). Ein Verlauf vom früheren Ort /var/lib/bkp_target/pruefrestore/ zieht bei der nächsten Zählung von selbst um. Eine Stichprobe über mehrere Sicherungen (--sample, Beispiel unten) hat keinen einzelnen Store und bleibt in ihrem eigenen Ordner.

Kontingent. Liegt die Sicherung in einer Freigabe mit hartem Kontingent, prüft pruef-restore vorher, ob der Prüf-Restore samt Reserve hineinpasst. Wenn nicht, wird er übersprungen (Code quota): Sicherungen gehen vor, die Kette endet, und der Betreiber erfährt es über die Mails des Targets. Bei einem weichen Kontingent steht nur ein Hinweis im Protokoll, der Prüf-Restore läuft. --quota ignore stellt einen einzelnen Job trotzdem wieder her.

Die Werte lassen sich auch in der Target-Konsole unter „Einstellungen“ ändern und gelten wie die übrigen Werte dieser Datei nach einem Neustart von bkp_target.

11.5 Eine Kette einrichten#

Jeden Samstag drei zufällig gewählte Läufe (/etc/bkp/bkp_target_sched.cfg)

[pruef-wiederherstellen]
command=pruef-restore
schedule=0 5 * * 6
run-as=root
args=--path /srv/pruefrestore/woche --search-dir {storage} --recursive --sample 3

[pruef-fsck]
command=pruef-fsck
after=pruef-wiederherstellen
run-as=root
args=--path /srv/pruefrestore/woche

[pruef-vm-start]
command=pruef-vm-start
after=pruef-fsck
run-as=root
args=--path /srv/pruefrestore/woche --check screen --wait 5m

[pruef-aufraeumen]
command=pruef-delete
after=pruef-vm-start
after-mode=finished
run-as=root
args=--path /srv/pruefrestore/woche --force

Alle Test-Jobs laufen als root (Loop-Geräte, Einhängen, VMs) und brauchen --path. Der Aufräum-Job hängt mit after-mode=finished an seinem Vorgänger und läuft deshalb auch, wenn ein Schritt davor nicht bestanden hat. bkp_target --sched-validate nennt je Job, was dem Server noch fehlt, mit den Paketnamen (QEMU, OVMF, swtpm, die Werkzeuge der Dateisysteme, lvm2, /dev/kvm).

11.6 Die Sandbox der VMs#

• Die VM bekommt Firmware (BIOS, UEFI, Secure Boot), Plattenbusse, Netzwerkkarten, Arbeitsspeicher und Prozessoren aus ihrer gesicherten Konfiguration; --max-memory (Standard 4096 MiB) und --max-cpus (Standard 2) begrenzen sie.
• Die Platten laufen als Snapshot: was die VM schreibt, verwirft QEMU beim Beenden.
• Netz: --net none (Standard) ohne Netzwerkkarte, --net isolated mit einem eigenen Netz, das keine Verbindung nach außen hat.
• Bestanden heißt bei --check screen: Der Bildschirm zeigt ein Bild, keinen schwarzen oder blauen Fehlerbildschirm, und die VM hat auf ihre Platten geschrieben (ein Betriebssystem tut das immer, eine Meldung der Firmware nie).
• Ohne KVM bricht der Schritt mit einem Hinweis ab; --no-kvm tcg emuliert stattdessen (deutlich langsamer, die Wartezeit wird vervierfacht).

11.7 Kann der Server das? Die Systemprüfung#

Ob ein Server die Prüf-Restores ausführen kann, prüft bkp_target selbst: beim Start, danach alle 25 Stunden (nach einem Fehlschlag stündlich), nach jedem Lauf des Updaters und auf Anforderung („Jetzt prüfen“ in der Target-Konsole). So fällt eine fehlende Voraussetzung auf, bevor ein Job nachts daran scheitert.

Ohne pruef-vm-start-Job ist ein Fund nur ein Hinweis, mit einem solchen Job eine Warnung oder ein Fehler. Fehlt ein Programm, nennt das Ergebnis den Befehl, der es installiert (apt install, dnf install oder zypper install, je nach Distribution). Das Ergebnis steht im Log (nur bei einer Änderung) und in /var/lib/bkp_target/vmcheck.json; von Hand:

Systemprüfung von Hand

bkp_target --vm-check            # prüfen und anzeigen: Exit 0 alles da, 3 etwas fehlt, 1 Fehler
bkp_target --sched-validate      # nennt je Job, was ihm fehlt, mit dem Befehl zum Installieren

Daneben meldet der Server, was sonst den Betrieb gefährdet: das TLS-Zertifikat läuft in weniger als 30 Tagen ab (Warnung) oder in weniger als 7 Tagen bzw. ist abgelaufen (Fehler; dann nimmt das Target keine Sicherungen mehr an), der Store ist zu 90 % (Warnung) oder 97 % (Fehler) belegt, Mails hängen im Spool, das letzte automatische Update ist fehlgeschlagen oder liegt trotz eingeschaltetem Timer länger als drei Tage zurück, ein Neustart des Dienstes steht aus. Die Target-Konsole zeigt alle Meldungen an (Kapitel „Target-Konsole (Windows)“, Abschnitt „Meldungen“); mit Mails bekommt der Betreiber die Mail „Serverzustand“ (Abschnitt „Mails an Betreiber und Kunden“).

11.8 Abhängige VMs: erst der DC, dann Exchange#

Manche VMs starten nur sinnvoll, wenn eine andere schon läuft: Ein Exchange-Server braucht seinen Domänencontroller. pruef-vm-start --vm <name> startet nur die genannten VMs des Prüf-Restores (Name der Sicherung oder ihr Ordner) in dieser Reihenfolge, und --ready legt fest, wann eine VM bereit ist; die nächste startet erst danach:

Alle angegebenen Prüfungen müssen gelten; --ready <vm>=… gilt nur für eine VM. --probe-ip <ip>/<präfix> gibt dem Prüfer eine Adresse im Netz der VMs – er prüft im Netzwerk-Namespace des Prüf-Restores, die Routen des Servers bleiben unberührt. Ist eine VM nach --ready-timeout (Standard 15 Minuten) nicht bereit, gilt der Schritt als nicht bestanden und die VMs danach starten nicht.

Erst der DC (LDAP und DNS antworten), dann Exchange (HTTPS antwortet)

[sandbox-dc]
command=pruef-vm-start
after=pruef-zaehlen
run-as=root
args=--path /srv/pruefrestore/woche --net isolated --vm dc01 --probe-ip 10.0.0.250/24 --ready tcp:10.0.0.10:389,tcp:10.0.0.10:53 --ready-timeout 20m

[sandbox-exchange]
command=pruef-vm-start
after=sandbox-dc
run-as=root
args=--path /srv/pruefrestore/woche --net isolated --vm exch01 --probe-ip 10.0.0.250/24 --ready tcp:10.0.0.20:443 --ready-timeout 30m

Statt after=sandbox-dc kann der Exchange-Job auch eigene Auslöser haben und mit wait-for=job:sandbox-dc und einer Frist (wait-timeout=) auf den DC warten. Beide Varianten stehen in bkp_target_sched.cfg.example; die Target-Konsole bietet sie unter „Neu… → Vorlage“ an.

11.9 Berichte und Bildschirmfotos#

Eine Prüfkette – der pruef-restore und die pruef-*-Jobs, die ihm über after= folgen – schickt einen Prüfbericht, sobald ihr letzter Schritt fertig ist und keiner mehr wartet (eine Minute nach dem letzten Ende). Er beginnt mit dem Urteil („Bestanden“ oder der erste Befund) und zeigt eine Ampel-Tabelle: je Platte, Partition und VM eine Zeile, je Prüfung (Dateisystem geprüft, eingehängt, gezählt, VM gestartet) eine Spalte mit „bestanden“, „Befund“, „übersprungen“ oder „nicht geprüft“. Die einzelnen Schritte der Kette schicken keinen eigenen Bericht mehr, bei einem Fehler aber weiterhin ihre Fehlermail. Die Mails haben die Mailart pruefbericht: Der Betreiber bekommt den ganzen Bericht, jeder Kunde den seiner eigenen Sicherungen, mit den Bildschirmfotos der VMs im Anhang (zusammen höchstens 5 MB je Mail). Die Bilder liegen außerdem neben dem Job-Log. In der Target-Konsole öffnet ein Doppelklick auf einen Lauf eines Test-Jobs das Ergebnis mit Befund und Bildschirmfoto; „Bild speichern…“ legt es als PNG ab.