Szenarien Schritt für Schritt

Zum Inhaltsverzeichnis

Die Szenarien verbinden die Einzelfunktionen zu kompletten Abläufen. Hostnamen, Pfade und Schlüssel sind Beispiele.

17.1 Szenario A: KVM-Gast per Netzwerk sichern (täglich, sonntags neue Generation)#

Ausgangslage: Der Gast icinga liegt auf dem LVM-Volume /dev/vg0/icinga.disk eines KVM-Hosts. Der Backup-Server backup.example.org läuft bereits (Kapitel 4). Der Gast soll nachts anwendungskonsistent gesichert werden, 30 Tage aufbewahrt, und jede Woche soll eine physisch unabhängige Basis entstehen.

1. Auf dem Server einen Key für den Host anlegen: bkp_maintenance acl-add --acl-file /etc/bkp/acl --dir kvm01 und systemctl reload bkp_target.
2. Auf dem KVM-Host target.crt nach /etc/bkp/ kopieren, den Key in /etc/bkp/kvm01.key ablegen (chmod 600).
3. Ein Wrapper-Skript anlegen, das zusätzliche Optionen durchreicht.

/usr/local/sbin/bkp_icinga.sh (ausführbar machen mit chmod 755)

#!/bin/sh
# /usr/local/sbin/bkp_icinga.sh [--type full]
set -eu
exec /usr/local/bin/bkp_agent \
    --source /dev/vg0/icinga.disk \
    --target backup.example.org:9990 --target-dir kvm01 \
    --tls-ca /etc/bkp/target.crt --api-key file:/etc/bkp/kvm01.key \
    --name icinga --hash blake3 --retention 30d --threads 4 --no-progress \
    --snapshot-size 5G \
    --pre-snapshot  'virsh domfsfreeze icinga' \
    --post-snapshot 'virsh domfsthaw icinga' "$@"

Zeitplan

# /etc/cron.d/bkp_icinga
30 1 * * 1-6  root  /usr/local/sbin/bkp_icinga.sh             >> /var/log/bkp_icinga.log 2>&1
30 1 * * 0    root  /usr/local/sbin/bkp_icinga.sh --type full >> /var/log/bkp_icinga.log 2>&1

1. Einmal von Hand testen: /usr/local/sbin/bkp_icinga.sh. Im Log muss neben done: full run ... der Hinweis auf den Snapshot und das consistency window erscheinen.
2. Nach einer Woche mit bkp_restore --list prüfen, dass sieben Runs da sind: sonntags Full in einer neuen Generation (Spalte STORE), sonst Incremental.
3. Auf dem Server einen täglichen maint-prune-Job einrichten (Szenario E), damit abgelaufene Runs und leere Generationen verschwinden.
4. Einmal pro Monat den Restore-Test aus Szenario C durchführen.

17.2 Szenario B: Windows-Server per VSS sichern#

1. Auf dem Server einen Key und ein Verzeichnis einrichten (acl-add --dir srv-win01). target.crt und den Key nach C:\ProgramData\AegisGrid\ kopieren.
2. bkp_agent.exe mit aegisgrid-setup.exe installieren (Komponenten agent, restore und sched).
3. Einen ersten Lauf in einer Administrator-Eingabeaufforderung starten:

"C:\Program Files\AegisGrid\bin\bkp_agent.exe" --source \\.\PhysicalDrive0 ^
    --target backup.example.org:9990 --target-dir srv-win01 ^
    --tls-ca C:\ProgramData\AegisGrid\target.crt --api-key file:C:\ProgramData\AegisGrid\srv-win01.key ^
    --name srv-win01 --vss-mode copy

Die Läufe übernimmt der Job-Planer: Komponente sched in bkp_setup. Dann läuft der Dienst aegisgrid-sched (Konto LocalSystem, startet verzögert automatisch), und die Jobs stehen in C:\ProgramData\AegisGrid\bkp_sched.cfg (nur command=agent). Änderungen wirken ohne Neustart. bkp_sched list zeigt den Stand, die Protokolle jedes Laufs liegen unter C:\ProgramData\AegisGrid\logs\bkp_sched-jobs\<Job>\, die des Dienstes selbst in ...\logs\bkp_sched.log. C:\ProgramData\AegisGrid (Einstellungen, Schlüssel) und ...\logs sind nur für SYSTEM und Administratoren lesbar; das richten bkp_setup und bkp_updater ein.

bkp_sched.cfg: täglich um 01:30 (Ortszeit), jeden Monat eine neue Generation

[srv-win01]
command=agent
args=--source \\.\PhysicalDrive0 --target backup.example.org:9990 --target-dir srv-win01 --tls-ca C:\ProgramData\AegisGrid\target.crt --api-key file:C:\ProgramData\AegisGrid\srv-win01.key --name srv-win01 --store-generation 1m
retention=30d
schedule=30 1 * * *

Ein Stopp des Dienstes, ein Update und das Herunterfahren halten eine laufende Sicherung an: Sie setzt eine Minute nach dem nächsten Start des Dienstes dort fort, wo sie stand, ohne Mail. Andere Jobs wartet der Dienst ab. bkp_sched stop <Job> (als Administrator) bricht ihn dagegen ab und verwirft die angefangene Sicherung. Mail ([mail]) und die HTTPS-API ([api], docs/sched-api.txt) übernimmt der Prozess bkp_sched_net, der als NT AUTHORITY\LocalService läuft. Ohne Job-Planer geht es auch mit der Aufgabenplanung (schtasks /create ... /sc daily), dann mit --retention 30d in der Befehlszeile. Jobs ansehen, anlegen und starten lässt sich auch mit der Verwaltungskonsole, vom Server selbst oder von einem Arbeitsplatz aus (Kapitel 14).

17.3 Szenario C: Komplett-Restore nach einem Plattenausfall#

Ausgangslage: Das Volume /dev/vg0/data ist verloren. Es soll auf ein neues Volume /dev/vg0/data_new zurückgespielt werden.

1. Neues Volume in mindestens der Größe der Quelle anlegen (die Quellgröße steht in bkp_restore --list in der Spalte SOURCE): lvcreate -L 100G -n data_new vg0.
2. Verfügbare Sicherungen ansehen:

bkp_restore --server backup.example.org:9990 --server-dir vm1 --tls-ca /etc/bkp/target.crt \
            --api-key file:/etc/bkp/vm1.key --list --name data

1. Die neueste Sicherung zurückspielen (bei einem verschlüsselten Store zusätzlich --decrypt-key file:<pfad>):

bkp_restore --server backup.example.org:9990 --server-dir vm1 --tls-ca /etc/bkp/target.crt \
            --api-key file:/etc/bkp/vm1.key --name data --target /dev/vg0/data_new

1. Den Exit-Code prüfen: 0 heißt vollständig, 3 heißt, dass beschädigte Bereiche mit Nullen gefüllt wurden (Log und --damage-file, Kapitel 7).
2. Das Ergebnis kontrollieren: fsck -n /dev/vg0/data_new, dann in ein Verzeichnis einhängen (mount -o ro) und die Daten stichprobenartig prüfen.
3. Erst danach den Dienst auf das neue Volume umstellen.

Wichtig zum Ausfall des Sicherungsrechners selbst: Der Restore braucht nur bkp_restore, target.crt, den API-Key und gegebenenfalls den Verschlüsselungs-Schlüssel. Halte diese Dinge außerhalb des gesicherten Systems bereit (Passwortmanager, Notfall-USB-Stick), sonst steht man nach einem Totalausfall ohne Zugang zu den Sicherungen da.

17.4 Szenario D: Zu einem bestimmten Zeitpunkt zurückspielen#

Ausgangslage: Vorgestern wurde etwas versehentlich gelöscht. Es wird der Stand von vorgestern Nacht gebraucht, nicht der aktuellste.

1. Mit bkp_restore ... --list --name data nachsehen, welche Sicherungen es gibt; die Spalte CREATED ist Ortszeit.
2. Den Stand mit --at wählen (der neueste Run bis zu diesem Zeitpunkt) oder den Run aus der Liste mit --run:

bkp_restore --server backup.example.org:9990 --server-dir vm1 --tls-ca /etc/bkp/target.crt \
            --api-key file:/etc/bkp/vm1.key --name data --at "2026-10-13 06:00" \
            --target /dev/vg0/data_pit

1. Das zurückgespielte Volume nur lesend einhängen, die gewünschten Dateien herauskopieren und das Volume verwerfen. Das laufende System bleibt unberührt.

17.5 Szenario E: Speicher aufräumen und spiegeln#

Ausgangslage: Der Server speichert seit Monaten Sicherungen von kvm01. Abgelaufene Runs sollen regelmäßig verschwinden, der Speicher soll wöchentlich geprüft werden, und jede neue Sicherung soll zusätzlich auf einem zweiten Server rz2 liegen. Der Stand zum Monatsanfang soll außerdem als Archiv auf eine USB-Platte.

1. Zuerst nachsehen, was der Store belegt und was ein prune löschen würde:

bkp_maintenance store-info --store /srv/backups/kvm01/default.cbs --exclusive
bkp_maintenance prune --search-dir /srv/backups/kvm01 --dry-run

1. Passt die Auswahl, die Wartung im Target-Scheduler einplanen (/etc/bkp/bkp_target_sched.cfg, danach bkp_target --sched-validate):

/etc/bkp/bkp_target_sched.cfg

[prune-kvm01]
command=maint-prune
schedule=30 6 * * *
args=--search-dir {storage}/kvm01

[scrub-kvm01]
command=maint-scrub
schedule=0 8 * * 6
args=--search-dir {storage}/kvm01

[mirror-kvm01]
command=maint-mirror
on=backup-success
match-dir=kvm01
args=--store {store} --to server:rz2.example.net:9990 --to-server-dir kvm01 --to-tls-ca /etc/bkp/rz2.crt --to-api-key file:/etc/bkp/rz2.key

1. Am Monatsanfang den Stand als Archiv schreiben (oder als maint-export-Job):

bkp_maintenance export --store /srv/backups/kvm01/default.cbs --name icinga --at "2026-10-01 03:00" --to /mnt/usb/

1. Meldet ein Scrub einen Schaden (Exit 1 im Job-Log), die betroffenen Objekte aus dem Spiegel ersetzen und erneut prüfen: bkp_maintenance repair --store /srv/backups/kvm01/default.cbs --from server:rz2.example.net:9990 --from-server-dir kvm01 --from-store default --tls-ca /etc/bkp/rz2.crt --api-key file:/etc/bkp/rz2.key.

17.6 Szenario F: Server-Zertifikat erneuern und API-Key austauschen#

1. Neues Zertifikat erzeugen: bkp_maintenance tls-init --cert /etc/bkp/target.crt --key /etc/bkp/target.key --cn backup.example.org --days 3650 --force.
2. target.crt auf alle Clients verteilen (Agents pinnen darauf; ein altes Zertifikat führt zu einem TLS-Fehler, siehe Kapitel 26).
3. systemctl restart bkp_target.
4. Für einen neuen Key: bkp_maintenance acl-add --acl-file /etc/bkp/acl --dir vm1, den ausgegebenen Key auf den Client kopieren, danach die alte Zeile aus der ACL entfernen und den Server neu starten.
5. Auf einem Client mit bkp_restore ... --list prüfen, dass Zertifikat und Key funktionieren.