Wartung

Zum Inhaltsverzeichnis

Alle Wartungsfunktionen stecken in bkp_maintenance. Sie arbeiten auf Stores, lokal oder direkt auf dem Server (<storage>/<verzeichnis>/<store>.cbs). --search-dir <dir> nimmt alle Stores eines Verzeichnisses, --store <dir> genau einen. Alle Store-Befehle kennen --index-dir, falls der Index nicht im Store liegt. M365-Stores (<name>.m365) werden von prune, scrub, mirror und export ebenso behandelt.

10.1 Überblick: store-info#

bkp_maintenance store-info --store backup/default.cbs

gekürzt

store:        backup/default.cbs
kind:         block
encryption:   none
id hash:      blake3
objects:      56 in 2 pack(s), 14.2 MiB stored
runs:         2 (1 name(s)), oldest 2026-10-15T14:18:25+02:00, newest 2026-10-15T14:18:31+02:00
data in runs: 26.0 MiB (1.84x the stored bytes)
last cleanup: never
last scrub:   never

NAME                               RUNS   FULL  NEWEST                     DATA (NEWEST)
data                                  2      1  2026-10-15T14:18:31+02:00       13.0 MiB

data in runs ist die Summe der Daten aller Runs; geteilt durch die gespeicherten Bytes ergibt das den Deduplizierungsfaktor. --exclusive ergänzt je Name, was nur seine Runs belegen, also was das Löschen aller seiner Runs frei machen würde (liest alle Manifeste, bei großen Stores langsam); --fragmentation zeigt, wie verstreut der neueste Run liegt; --json gibt alles maschinenlesbar aus. Bei Block-Stores folgt die Messung und Empfehlung zur Chunk-Größe (Kapitel 25).

10.2 Aufbewahrung und prune#

Jede Sicherung kann ihre Aufbewahrung selbst mitbringen: bkp_agent --retention <spec> (bzw. retention= im Profil oder im Sink) schreibt sie in den Run. <spec> ist <n>d (Tage), <n>w (Wochen), <n>m (Kalendermonate), <n>y (Kalenderjahre), forever oder ein GFS-Schema wie gfs:7d,4w,12m,5y (unten). Dazu kommt eine optionale Klasse (--retention-class daily|weekly|...). Ohne --retention wird eine Sicherung nie automatisch gelöscht. Über das Netz berechnet bkp_target das Ablaufdatum mit seiner eigenen Uhr.

bkp_maintenance prune --search-dir /backup --dry-run      # nur anzeigen, was gelöscht würde
bkp_maintenance prune --search-dir /backup [--name data]  # löschen; --name: nur Runs dieses Backup-Namens
bkp_maintenance prune --store /backup/default.cbs         # nur diesen Store (mit seinen Generationen)

Ausgabe von --dry-run

[bkp_maintenance] INFO  keep: block run 20261015T121825Z-6aa5d6f2-... 'data' (no retention)
[bkp_maintenance] INFO  keep: block run 20261015T121831Z-8c47f436-... 'data' (newest run of this name)
[bkp_maintenance] INFO  prune backup/default.cbs: would delete 0 run(s), kept 2; objects: would remove 0 (0.0 MiB),
                        packs deleted 0, rewritten 0
[bkp_maintenance] INFO  prune backup: 1 store(s) checked

Regeln: Ein Run wird gelöscht, wenn er abgelaufen ist (mit GFS: wenn keine Regel ihn mehr hält). Danach entfernt prune die Daten, die kein verbliebener Run mehr braucht (Speicherfreigabe: unbenutzte Packs werden gelöscht, teilweise benutzte umgeschrieben). Es wird kein Schlüssel gebraucht.

• Die jeweils neueste Sicherung eines Backup-Namens und die neueste vollständige bleiben immer, auch wenn sie abgelaufen sind (Schutz gegen ausgefallene Jobs oder eine zu kurz gesetzte Aufbewahrung).
• --gc-min-age <sekunden> (Standard 24 h): jüngere Packs werden nie gelöscht oder umgeschrieben (Schutz laufender Sicherungen).
• --pending-max-age <sekunden> (Standard 48 h): ein laufender VM-Run schützt seine bisher gesicherten Disks so lange.
• Ein Store, in den gerade gesichert wird, wird übersprungen; der nächste prune holt es nach.
• Eine Generation ohne Runs wird ganz entfernt.

10.2.1 Großvater-Vater-Sohn (GFS)#

Statt einer festen Dauer kann die Aufbewahrung ein GFS-Schema sein: gfs: und eine Liste aus <n>h (stündlich), <n>d (täglich), <n>w (wöchentlich), <n>m (monatlich) und <n>y (jährlich). gfs:7d,4w,12m,5y hält die neueste Sicherung jedes der letzten 7 Tage, 4 Wochen, 12 Monate und 5 Jahre; ein Job, der täglich (oder öfter) sichert, genügt, es braucht keine eigenen Wochen- oder Monatsjobs.

• Gezählt wird nach Kalender: der laufende Tag, die laufende Woche (beginnt am Montag), der laufende Monat und das laufende Jahr zählen mit. Maßgeblich ist die Ortszeit des Rechners, auf dem prune läuft (beim Netzwerk-Backup der Server).
• Eine Sicherung bleibt, solange eine ihrer Regeln sie hält. Innerhalb eines Zeitraums zählt die neueste vollständige Sicherung; nur wenn es keine gibt, die neueste unvollständige.
• Jede Sicherung trägt ihr eigenes Schema. Wird es geändert, gilt das neue für die neuen Sicherungen; die älteren behalten ihres, bis set-retention (unten) es ändert.
• Sicherungen mit fester Dauer oder ohne Aufbewahrung in derselben Reihe bleiben davon unberührt. Die neueste Sicherung eines Namens bleibt wie immer.
• Als Obergrenze (z. B. für WORM-Sperren und für ein älteres prune) bekommt eine GFS-Sicherung ein Ablaufdatum einen Zeitraum nach ihrer längsten Regel (gfs:7d,4w → 5 Wochen).

bkp_agent --source /dev/vg0/data --target backup.example:9990 ... --name data --retention gfs:7d,4w,12m,5y
bkp_maintenance prune --search-dir /srv/bkp_storage/vm1 --dry-run

Ausgabe von --dry-run mit GFS

[bkp_maintenance] INFO  keep: block run 20261023T020011Z-41c0... 'data' (GFS gfs:7d,4w,12m,5y: daily)
[bkp_maintenance] INFO  keep: block run 20260930T020007Z-9be2... 'data' (GFS gfs:7d,4w,12m,5y: monthly)
[bkp_maintenance] INFO  [dry-run] would delete: block run 20261015T020009Z-c71d... 'data' (GFS gfs:7d,4w,12m,5y keeps it
                        no longer) in /srv/bkp_storage/vm1/default.cbs

10.2.2 Aufbewahrung anzeigen#

bkp_restore --list und bkp_m365_restore --list zeigen je Run die Spalte AUFBEWAHRUNG (englisch RETENTION) in der Sprache des Rechners, lokal wie über das Netz:

• 30 Tage, bis 23.11.2026: feste Dauer, Ablaufdatum in Ortszeit; Für immer: wird nie gelöscht; -: ohne Aufbewahrung, wird ebenfalls nie gelöscht.
• GFS (7 Tage, 4 Wochen, 12 Monate, 5 Jahre), behalten als täglich, wöchentlich: die GFS-Regeln und die Zeiträume, für die sie den Run gerade halten.
• 30 Tage, abgelaufen: die Aufbewahrung ist vorbei, der nächste prune löscht den Run. 30 Tage, als neueste behalten: ebenfalls vorbei, aber prune behält ihn als neueste (vollständige) Sicherung seines Namens. 30 Tage, gesperrt bis 01.12.2026: vorbei, aber ein späterer auffälliger Lauf hält ihn bis dahin.

Die Spalte TYP zeigt Voll oder Inkrementell. Für Programme bleibt --list --json englisch (keep: until, expired, newest …).

10.3 Aufbewahrung nachträglich ändern: set-retention#

set-retention gibt bereits gespeicherten Runs eine neue Aufbewahrung, gerechnet ab ihrem Erstellungszeitpunkt. Danach richten sich prune und die Listen. Der Run selbst bleibt unverändert; die Änderung liegt daneben im Store. Das geht auch, während gesichert wird, und auf dem Server direkt im Storage. Genau eine Auswahl ist nötig: --run (Name oder UUID), --name (alle Runs dieses Backup-Namens, über alle Generationen; bei M365 der Store <name>.m365) oder --all.

bkp_maintenance set-retention --store backup/default.cbs --run 20261015T121825Z-6aa5d6f2-... --retention 1y
bkp_maintenance set-retention --store backup/default.cbs --name data --retention gfs:7d,4w,12m --dry-run
bkp_maintenance set-retention --search-dir /srv/bkp_storage/vm1 --all --retention 90d

Ausgabe:

[bkp_maintenance] INFO  set: block run 20261015T121825Z-6aa5d6f2-... 'data': retention 30d -> 1y (kept until
                        2027-10-15T14:18:25+02:00)

• Kopien, die mirror angelegt hat, behalten ihre eigene Aufbewahrung; dort bei Bedarf ebenfalls set-retention.
• Wird eine Aufbewahrung so verkürzt, dass sie schon vorbei ist, warnt set-retention: der nächste prune löscht den Run (außer der neuesten Sicherung des Namens).
• WORM: nur Verlängern ist erlaubt. worm=extend verlängert zuerst die Sperren der betroffenen Packs und der Run-Datei; bei worm=generation muss die neue Dauer in die Sperre der Generation passen.
• In bkp_sched als Job command=maint-set-retention mit denselben Parametern in args=, meist einmalig mit once=. Über die API ist der Befehl wie maint-prune gesperrt, bis [api] allowed-commands ihn nennt.
• Die Verwaltungskonsole zeigt die Aufbewahrung je Lauf in der Spalte „Aufbewahrung“ (Kapitel „Verwaltungskonsole (Windows)“); bkp_restore --list --json <datei> schreibt die Liste für Programme als JSON.

10.3.1 Vom Client aus ändern, auch auf einem Target#

bkp_restore --set-retention <spec> --run <run> ändert die Aufbewahrung jeder Kopie eines Laufs in den Stores, die bkp_restore erreicht (wie beim Wiederherstellen: --store, --server oder die Sinks eines Profils mit --name und --sink). --run nimmt den Namen, die UUID oder die Run-Gruppe, also alle Sinks einer Sicherung. Erst wird jede Kopie geprüft; lehnt eine ab, ändert sich nichts. --dry-run prüft nur, --extend-only lehnt auch in lokalen Stores eine kürzere Aufbewahrung ab, --json <datei> schreibt das Ergebnis je Kopie.

bkp_restore --name web1 --run <run-gruppe> --set-retention 1y
bkp_restore --server rz1:9990 --server-dir kunde-a --tls-ca rz1.pem --api-key file:/etc/bkp/rz1.key --run <run> --set-retention forever

Auf einem bkp_target entscheidet dessen Betreiber mit client-retention= in bkp_target.cfg: extend (Standard) lässt Clients eine Sicherung nur länger aufbewahren (keine GFS-Regeln, „für immer“ bleibt „für immer“), no gar nicht ändern. Kürzer geht dort nur mit bkp_maintenance oder der Target-Konsole. So kann auch ein Client, dem jemand die Zugangsdaten entwendet hat, keine Sicherung früher verschwinden lassen.

10.4 Einen Run löschen: delete#

delete entfernt genau einen Run, auch den neuesten, und danach die Daten, die kein anderer Run braucht. Andere Runs desselben Namens sind davon nicht betroffen: es gibt keine Abhängigkeiten zwischen Runs. Mit --dry-run wird nur angezeigt, was gelöscht würde.

bkp_maintenance delete --store backup/default.cbs --run 20261015T121825Z-6aa5d6f2-8419-482a-ab3f-0373e33b449d --dry-run

Ausgabe:

[bkp_maintenance] INFO  [dry-run] would delete: block run 20261015T121825Z-6aa5d6f2-... 'data' in backup/default.cbs
[bkp_maintenance] INFO  delete backup/default.cbs: would delete 1 run(s), kept 1; objects: would remove 0 (0.0 MiB),
                        packs deleted 0, rewritten 0

Dass hier keine Daten frei würden, hat zwei Gründe: Der verbleibende Run nutzt die meisten Chunks weiter, und die Packs sind jünger als --gc-min-age. Den Platz der übrigen Chunks gibt ein späterer prune frei.

10.5 Scrub: auf Bitrot prüfen#

bkp_maintenance scrub --store backup/default.cbs [--decrypt-key file:<pfad>] [--result-file <json>]

Ausgabe:

[bkp_maintenance] INFO  scrub backup/default.cbs: 2 run(s), 56 object(s) in 2 pack(s) (14.2 MiB): 56 checked (read back and verified),
                        0 bad, 0 missing, 0 unreadable manifest(s); 0 run(s) damaged
[bkp_maintenance] INFO  scrub backup/default.cbs: result in scrub/20261015T121843.612Z.json

Liest jedes Objekt, prüft seine Prüfsumme und dass jeder Run vollständig ist. Bei unverschlüsselten Stores und mit --decrypt-key wird zusätzlich jeder Inhalt gegen seine ID geprüft. Beschädigte Objekte und betroffene Runs stehen im Log und im Store (scrub/<zeit>.json, store-info zeigt den letzten Scrub). Exit 1 bei einem Schaden. Scrub repariert nichts; lass ihn regelmäßig laufen, zum Beispiel wöchentlich als maint-scrub-Job.

10.6 Repair: Schäden aus einer zweiten Kopie ersetzen#

bkp_maintenance repair --store /backup/default.cbs --from /mnt/spiegel/default.cbs [--dry-run]
bkp_maintenance repair --store /backup/default.cbs --from sink:rz1                  # Sink aus bkp_agent.cfg
bkp_maintenance repair --store /backup/default.cbs --from server:backup.example.org:9990 --from-server-dir vm1 \
                       --from-store default --tls-ca /etc/bkp/target.crt --api-key file:/etc/bkp/vm1.key

repair ersetzt die beim letzten Scrub gefundenen beschädigten Objekte aus einer Kopie: einem anderen Sink derselben Sicherungen oder einem Spiegel. Hat die Kopie denselben ID-Hash und Schlüssel, werden ihre Objekte per ID übernommen. Sonst über die Position: Der Zwillings-Run hat an denselben Stellen dieselben Chunks; jeder wird mit dem Schlüssel der Kopie (--from-key) entschlüsselt, neu gehasht und nur übernommen, wenn er genau die beschädigte ID ergibt. Danach scrub erneut laufen lassen. Exit 1, wenn Objekte nicht ersetzt werden konnten; was sich nicht reparieren lässt, spielt ein Teil-Restore mit Nullen an den beschädigten Stellen zurück (Kapitel 7).

10.7 Mirror: einen Store spiegeln#

bkp_maintenance mirror --store /backup/default.cbs --to /mnt/zweitplatte/default.cbs
bkp_maintenance mirror --search-dir /backup --to server:rz2.example.net:9990 --to-server-dir kunde1 \
                       --to-tls-ca /etc/bkp/rz2.crt --to-api-key file:/etc/bkp/rz2.key

mirror kopiert die Runs eines Stores in einen zweiten, in jede Richtung (lokal → Server, Server → lokal, Server → Server als Job des Target-Schedulers). Das Ziel wird mit ID-Hash, Verschlüsselung und Chunk-Größe der Quelle angelegt, beide haben also dieselben IDs. Kopiert wird nur, was dem Ziel fehlt; ein gespiegelter Run behält ID, Zeit und Aufbewahrung, und ein dort schon gelöschter Run kommt nicht wieder. Im Ziel wird nie etwas gelöscht, das macht dessen eigenes prune. Ein abgebrochener Spiegel-Lauf macht beim nächsten Mal weiter. Ein Schlüssel wird nicht gebraucht.

10.7.1 Stores verschieben#

bkp_maintenance move --store /srv/backups/hosted/G-000007/I-0000042/default.cbs --to /srv/backups/hosted/G-000007/standard/default.cbs --dry-run
bkp_maintenance move --store /backup/default.cbs --name fs01 --to server:rz2.example.net:9990 --to-server-dir kunde1 \
                     --to-tls-ca /etc/bkp/rz2.crt --to-api-key file:/etc/bkp/rz2.key

move zieht einen Store oder nur die Läufe einzelner Backup-Namen (--name) an einen anderen Ort, auf dem Rechner, der den Store hält. Liegt das Ziel frei auf demselben Dateisystem, wird der ganze Store mit allen Generationen umbenannt; sonst wird kopiert wie bei mirror, im Ziel geprüft, das Namensregister zusammengeführt und erst danach in der Quelle gelöscht. Ein WORM-gesperrter Lauf verhindert den Umzug, bevor etwas geschieht. Ein Schlüssel wird nicht gebraucht; in der Target-Konsole heißt das „Verschieben…“ (Reiter „Daten“).

10.7.2 Neu verschlüsseln#

Mit --reencrypt kopieren mirror und move die Läufe in einen Store mit anderem Schlüssel oder ID-Hash: jedes Objekt wird mit dem Schlüssel der Quelle gelesen, mit --to-key neu verschlüsselt und bekommt dort seine eigene ID. Den Quellschlüssel sucht das Programm unter --decrypt-key und --previous-keys anhand des Prüfwerts des Stores. Mit --store sink:<name> und --to sink:<name> kommen Ort, Zugang und Schlüssel aus der Konfiguration von bkp_agent (--sink-store nennt die Stores darin). Die Quelle wird nur gelesen. So kommen die Sicherungen von vor einem Gruppenbeitritt in den Gruppenordner (Abschnitt „Gruppen“, Kapitel 23).

10.8 Export und Import: ein Run als Archiv#

bkp_maintenance export --store /backup/default.cbs --name data [--at <zeit>] --to /mnt/usb/
bkp_maintenance export --store /backup/default.cbs --run <run> --to - | dd of=/dev/nst0 bs=1M
bkp_maintenance import --archive /mnt/usb/data-<run>.cba --to /backup/default.cbs [--dry-run]

Ausgabe:

[bkp_maintenance] INFO  export: run 20261015T121849Z-44fdc352-... 'data' of backup/default.g20261015.cbs
                        -> /mnt/usb/data-20261015T121849Z-44fdc352-....cba
[bkp_maintenance] INFO  export: run 20261015T121849Z-44fdc352-... 'data' exported: 46 object(s) (2 tree(s)), 12.0 MiB stored data,
                        source 16.0 MiB, archive 12588833 bytes

export schreibt einen Run (Block, VM oder M365) in ein in sich geschlossenes Archiv: eine Datei mit allem, was der Run braucht, ohne Store, verschlüsselt bleibt verschlüsselt. Gedacht für Band, USB-Platte, WORM-Dateisystem oder Prüfer. --to <verzeichnis> benennt die Datei <backup>-<run>.cba, --to - schreibt auf stdout; eine vorhandene Archivdatei wird nie ersetzt (Exit 2). Zurückgespielt wird mit bkp_restore --archive (Kapitel 7). import holt den Run eines Archivs in einen neuen Store oder in einen mit gleichem ID-Hash, Verschlüsselung und Schlüssel zurück; import --dry-run prüft ein Archiv vollständig, ohne zu schreiben.

10.9 WORM: Aufbewahrungssperren#

Ein Store kann beim Anlegen als WORM-Store eingerichtet werden (bkp_agent --worm, worm= im [sink:]). Geschriebene Objekte werden nie geändert, Packs und Runs sind bis zu einem Zeitpunkt gegen Löschen gesperrt:

prune löscht unter WORM nur ganze unbenutzte Packs nach dem Ende ihrer Sperre und schreibt nie um; --dry-run nennt tageweise, was wann frei wird. delete weist einen gesperrten Run ab. Auf einem lokalen Dateisystem ist die Sperre ein Metadatum (<datei>.retain), an das sich prune/delete halten; auf S3 ist sie Object Lock und wird vom Anbieter erzwungen (Kapitel 6).

10.10 Index neu aufbauen#

bkp_maintenance reindex --store /backup/default.cbs

Baut index.lmdb aus den Packs neu auf. Das passiert auch automatisch, wenn der Index fehlt oder beschädigt ist.

10.11 Zertifikate und Schlüssel#

tls-init und acl-add sind in Kapitel 4 beschrieben, encrypt-init in Kapitel 6. Zum Erneuern eines Zertifikats: tls-init --force erzeugt ein neues Paar, danach muss target.crt auf alle Clients verteilt und bkp_target neu gestartet werden, weil die Clients auf genau dieses Zertifikat pinnen (Szenario in Kapitel 17).

10.12 Wartung planen#

Regelmäßige Wartung plant man mit maint-*-Jobs in bkp_sched (maint-prune, maint-scrub, maint-mirror, maint-export) oder direkt auf dem Server im Target-Scheduler (/etc/bkp/bkp_target_sched.cfg, siehe README). Dort kann ein Job auch auf ein Ereignis reagieren, zum Beispiel jede neue Sicherung sofort spiegeln:

/etc/bkp/bkp_target_sched.cfg (Ausschnitt)

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

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

10.12.1 Zeitplan-Schreibweise#

schedule= hat in bkp_sched und im Target-Scheduler dieselbe Schreibweise: Minute, Stunde, Tag, Monat, Wochentag und optional das Jahr, in der Ortszeit des Servers. Je Feld gehen *, Zahlen, Bereiche (9-17), Schritte (*/15) und Listen (0,30). Dazu:

10.12.2 Weitere Zeitplan-Angaben#

Ein Job in bkp_sched und im Target-Scheduler kann mehrere Zeitplan-Zeilen haben; er läuft an allen ihren Terminen, abzüglich der Ausnahmen. bkp_sched preview <job> bzw. bkp_target --sched-preview <job> beschreibt den Zeitplan in einem Satz (englisch, z. B. „On the 2nd Tuesday of the month at 22:00, except on public holidays (de-by)“) und zeigt die nächsten Starts, so wie der Dienst sie ausführt; die Konsole zeigt denselben Satz auf Deutsch („Am 2. Dienstag des Monats um 22:00, außer an Feiertagen in Bayern …“):

Dauern schreibt man 90m, 1h30m, 4h oder 2d. Eigene Kalender liegen als <name>.cal in /etc/bkp/calendars (Windows %ProgramData%\AegisGrid\calendars), eine Zeile je Tag oder Bereich: 2026-12-24 Heiligabend, 2026-12-28..2027-01-01 Betriebsferien, *-12-31 Silvester (jedes Jahr), include=de-by.

Werktags 22 Uhr außer an bayerischen Feiertagen, dazu am letzten Freitag im Monat 23:30; nur 22 bis 6 Uhr, bis zu 20 Minuten später

[nacht]
command=agent
profile=srv1
schedule=0 22 * * MON-FRI
rrule=FREQ=MONTHLY;BYDAY=-1FR;BYHOUR=23;BYMINUTE=30
dtstart=2026-11-01T00:00
exclude-calendar=de-by
window=22:00-06:00
window-end=pause
jitter=20m

Sommerzeit: Ein Termin in der Stunde, die am Beginn der Sommerzeit übersprungen wird (02:00 bis 02:59), entfällt an diesem Tag. Am Ende der Sommerzeit läuft die Uhr von 02:00 bis 02:59 zweimal; ein Termin darin gilt einmal, beim ersten Durchlauf, mit dst-repeat=both bei beiden.

10.13 Der Target-Scheduler#

Der Target-Scheduler läuft als eigener Prozess im Prozessbaum von bkp_target und hat keinen Netzwerkkontakt; ein Problem des Schedulers kann deshalb nie eine Sicherung aufhalten. Er ist eingeschaltet, sobald /etc/bkp/bkp_target_sched.cfg existiert. Alle Schlüssel stehen in der Vorlage packaging/bkp_target_sched.cfg.example und im README.

10.13.1 Standardjobs#

bkp_setup --configure-server legt die Datei an, wenn es sie noch nicht gibt (--no-default-jobs verhindert das). Jeder Job lässt sich mit enabled=no einzeln abschalten:

10.13.2 Ereignisse und Ketten#

Ein Job startet nach Zeitplan (alle Angaben aus „Weitere Zeitplan-Angaben“), auf ein Ereignis (on=) oder nach anderen Jobs (after=). Ereignisse sind <art>-<phase> mit der Art backup, mirror-in (ein anderer Server spiegelt hierher), restore oder transfer (Sicherung oder eingehender Spiegel) und der Phase start, success, failed oder finished. after-mode= legt fest, ob der Folgejob nach Erfolg (Standard), nach jedem Ende (finished) oder nur nach einem Fehlschlag (failed) läuft. Folgt ein Job genau einem anderen, übernimmt er dessen Ereignis: {store} ist dann derselbe Store. So entsteht eine Kette Sicherung → Spiegel → Prüfung des eben gesicherten Stores (Beispiel oben: scrub-nach-spiegel mit after=mirror-kunde1).

Ein Ablauf ist eine solche Kette mit Namen: Jobs mit demselben flow=<name> sind seine Schritte. Genau ein erster Schritt hat die Auslöser (Zeitplan, on=, match-*, wait-for=), jeder weitere hat after= auf den Schritt davor; Verzweigungen und Auslöser an späteren Schritten weist die Prüfung ab. Die Target-Konsole zeigt und bearbeitet einen Ablauf als eine Liste (Kapitel Target-Konsole, Abschnitt „Aktionen und Scheduler“) und speichert ihn immer als Ganzes.

Nach bestimmten Sicherungen startet ein Job mit match-backup=<verzeichnis>/<name>[,…]: Verzeichnis (Muster wie in der ACL) und Name gehören zusammen, match-backup=kunde1/srv1,kunde2/db01 passt also genau auf diese beiden – anders als match-dir= mit match-name=, die jede Kombination zulassen. Der Scheduler merkt sich die 40 Sicherungen und Spiegelungen, die zuletzt hereinkamen (je Sicherung ein Eintrag, Datei recent-backups neben state-file=); die Target-Konsole bietet sie als Grundlage eines Jobs an.

Eine Aktion ist ein Job ohne Zeitplan, on= und after=: Er startet nur von Hand (bkp_target --sched-run <job>, Target-API, Target-Konsole). backup=<verzeichnis>/<name> (mit backup-kind=mirror-in für eine Spiegelung) gibt ihm eine Sicherung: Ein Start arbeitet mit ihrem neuesten erfolgreichen Lauf, als wäre er eben hereingekommen – {store}, {uuid} und die Jobs danach verwenden ihn. So läuft etwa ein Prüf-Restore der letzten Sicherung von kunde1/srv1 auf Knopfdruck. backup= nimmt mehrere Sicherungen und Muster (backup=kunde1/*,kunde2/db01, ein Lauf je Sicherung), backup-run=<uuid>@<store> einen bestimmten Lauf statt des neuesten. Kam von der Sicherung noch kein erfolgreicher Lauf, startet die Aktion nicht und sagt das. note= ist eine Notiz ohne Wirkung. Audit-Log, Job-Log, Mail und Nachweisbericht nennen Sicherung, Lauf und wer gestartet hat.

On the Fly heißen Schritte, die während des Eingangs einer Sicherung arbeiten sollen: otf-encrypt (verschlüsseln, key=file:… oder kms:…), otf-restore (wiederherstellen nach restore-path=), otf-forward-target und otf-forward-s3 (weiterleiten an ein Ziel dest=<name>). Der erste Schritt hat on=backup-start (oder mirror-in-start, transfer-start) und match-*, jeder weitere after= auf den Schritt davor. Ziele stehen in Abschnitten [dest:<name>] (kind=target oder kind=s3), ihre Schlüssel nur als file: oder kms:. Diese Version prüft und speichert On-the-Fly-Schritte, führt sie aber noch nicht aus; die Sicherung selbst bleibt davon immer unberührt. Alle Schlüssel stehen im README und in der Vorlage.

Verliert eine Sicherung oder Wiederherstellung die Verbindung, ist sie noch nicht fehlgeschlagen: Der Client verbindet sich während seiner --net-retry-Zeit wieder und macht weiter, auch wenn das Target selbst neu gestartet ist (etwa nach einem Update). Das Target hält backup-failed bzw. restore-failed so lange zurück (Warteschlange, Verlauf, Laufprotokoll: „backup connection lost“). Geht der Lauf weiter, entfällt der Fehlschlag, backup-start kommt kein zweites Mal, und der Verlauf zeigt eine Sicherung ab ihrem ursprünglichen Beginn; erst wenn der Client nicht wiederkommt, zählt sie als fehlgeschlagen. Agenten vor 2.0.0-alpha.027 melden das nicht: Bei ihnen zählt die Unterbrechung sofort als Fehlschlag und der Rest als neue Sicherung.

10.13.3 Zeitfenster im Target-Scheduler#

window= hält jeden Lauf des Jobs zurück, auch einen aus on= oder after=: er wartet in der Warteschlange, bis das Fenster öffnet. So läuft etwa eine Prüfung nach jeder Sicherung nur nachts. Mit window-end=stop endet ein laufender Job, wenn das Fenster schließt; --sched-list zeigt ihn dann als stopped, und der nächste Lauf beginnt die Arbeit neu. window-end=pause gibt es hier nicht, weil ein pausierter Wartungslauf seinen Store gesperrt hielte.

Am letzten Samstag im Monat alle Stores prüfen, nicht an bayerischen Feiertagen, nur 22 bis 6 Uhr

[pruefen-monat]
command=maint-scrub
schedule=0 22 * * SATL
exclude-calendar=de-by
window=22:00-06:00
window-end=stop
jitter=30m
args=--search-dir {storage} --recursive

10.13.4 Parallele Läufe#

Bis zu parallel-jobs Läufe (Abschnitt [sched], Standard 2) laufen gleichzeitig, jeder Job aber nur einmal. Zwei Läufe auf demselben Store laufen nie gleichzeitig; lock=<name> bildet zusätzlich eine eigene Gruppe, z. B. für alle Exporte auf dasselbe Band. Prüfung und Spiegel warten, solange eine Sicherung in ihren Store schreibt.

10.13.5 Warten auf Sicherungen und Jobs#

after= startet einen Job, wenn andere fertig sind. wait-for= dagegen hält einen ohnehin fälligen Lauf (Zeitplan, Ereignis oder after=) in der Warteschlange zurück, bis alles da ist, worauf er warten soll:

Es zählt, was seit der Fälligkeit des Laufs kam; wait-since=12h lässt auch die zwölf Stunden davor gelten. wait-timeout= (Standard 6 Stunden) begrenzt das Warten; danach entscheidet wait-timeout-action=: fail (Standard) wertet den Lauf als fehlgeschlagen und meldet per Mail, was fehlte, skip lässt ihn ausfallen, run startet ihn trotzdem mit einem Hinweis im Job-Log. Ein wartender Lauf sperrt noch keinen Store; von Hand gestartete Läufe warten nicht. Kreise aus after= und wait-for= weist die Prüfung der Datei ab.

Um 6 Uhr prüfen, sobald die Sicherungen der Nacht da sind – spätestens um 9 Uhr trotzdem

[pruefen-morgens]
command=maint-scrub
schedule=0 6 * * *
wait-for=backup:kunde1/**
wait-since=12h
wait-timeout=3h
wait-timeout-action=run
args=--search-dir {storage}/kunde1 --recursive --only-new

--sched-list zeigt, worauf ein Lauf wartet und bis wann („waits for backup:kunde1/** … until …“); jede Wartezeit und ihr Ausgang stehen im Nachweis-Protokoll (nächstes Kapitel).

10.13.6 Anzeigen, starten, abbrechen#

bkp_target --sched-validate                              # Konfiguration prüfen
bkp_target --sched-list --storage /srv/backups           # Jobs, Ketten, Warteschlange
bkp_target --sched-preview check-weekly --count 5       # die nächsten fünf Starts
bkp_target --sched-run prune-all --storage /srv/backups  # sofort im Vordergrund
bkp_target --sched-stop prune-all                        # laufenden Job endgültig abbrechen
bkp_target --sched-pause prune-all --for 2h --reason "Wartung"   # laufenden Job pausieren
bkp_target --sched-resume prune-all                      # pausierten Job fortsetzen

--sched-pause hält das Programm des Laufs an einer sicheren Stelle an; Verbindungen bleiben offen, und die Pausenzeit zählt nicht zum Zeitlimit des Jobs. Mit --for (höchstens 7d) geht der Lauf danach von selbst weiter, sonst erst mit --sched-resume. Ein Target-Job wird nie angehalten: Pausiert er länger als pause-max (Abschnitt [sched], Standard 4h, 10m bis 7d), vermerkt das Log das einmal, und er bleibt pausiert. Exit-Code 1, wenn der Job nicht läuft, sein Programm keine Pause kennt oder er (bei --sched-resume) nicht pausiert ist. Über die Target-API: POST /sched/jobs/{name}/pause bzw. resume (docs/target-api.txt).

--sched-list zeigt die Jobs, darunter die Ketten und die Warteschlange. Für jeden wartenden Lauf steht dort, worauf er wartet:

bkp_target --sched-list --storage /srv/backups

JOB                      COMMAND              RUN-AS    STATUS     LAST RUN         EXIT  NEXT RUN         QUEUED TRIGGER
prune-all                maint-prune          aegisgrid  done       2026-10-24 02:30 0     2026-10-25 02:30 0      schedule=30 2 * * *
check-new                maint-scrub          aegisgrid  done       2026-10-24 21:05 0     -                1      on=backup-success,mirror-in-success
check-weekly             maint-scrub          aegisgrid  never-run  -                -     2026-10-25 04:00 0      schedule=0 4 * * 0
mirror-kunde1            maint-mirror         aegisgrid  running    2026-10-24 21:40 0     -                1      on=backup-success
scrub-nach-spiegel       maint-scrub          aegisgrid  done       2026-10-24 21:12 0     -                0      after=mirror-kunde1

Chains (after=):
  mirror-kunde1
    -> scrub-nach-spiegel (success)

Queue: 2 run(s), 1 of at most 2 running at once (parallel-jobs)
QUEUED           JOB                      TRIGGER                      STORE                            STATE
2026-10-24 21:40 mirror-kunde1            backup-success               kunde1/srv1.cbs                  running (pid 4711)
2026-10-24 21:40 check-new                backup-success               kunde1/srv1.cbs                  waits: job 'mirror-kunde1' works on the same store

Weitere Wartegründe: derselbe Job läuft schon, alle parallelen Läufe sind belegt, ein Job hält dieselbe lock=, ein --sched-run läuft, das Zeitfenster des Jobs ist geschlossen, eine Sicherung schreibt in den Store (nur mit --storage) oder eine abgebrochene Wiederherstellung wartet noch auf die Wiederverbindung des Clients. --sched-run löst die Folgejobs aus after= ebenfalls aus, --no-after nicht. Jeder Lauf schreibt ein Log nach /var/log/bkp/bkp_target-jobs/<job>/. Ohne Mailversand (nächster Abschnitt) wird über den Exit-Code im Job-Log überwacht.

10.13.7 Mails an Betreiber und Kunden#

Mit einem Abschnitt [mail] in bkp_target_sched.cfg verschickt das Target selbst Mails über den SMTP-Server des Betreibers (dieselben SMTP-Schlüssel wie bei bkp_sched, dazu operator-to= als Pflicht). Der Betreiber bekommt zu jedem Job, was notify= verlangt (Standard: Fehlschläge; ein Job, der immer wieder scheitert, höchstens einmal am Tag und einmal „wieder in Ordnung“), mit Ergebnis, Job-Log, nächstem Schritt und den letzten Zeilen des Logs. Jede Mail liegt zuerst im Spool und geht auch nach einem Neustart oder einer Störung des Mailservers nicht verloren.

Ein Target bedient viele Kunden. Jeder Kunde bekommt nur Mails über seine eigenen Stores, ohne Fehlercodes und ohne Job-Log, mit Einordnung („Was das bedeutet“) und nächstem Schritt. Wem welches Verzeichnis gehört, steht für die eigenen Verzeichnisse in /etc/bkp/target-customers.cfg; für Freigaben an andere Konten (hosted/G-…) kommen Firmenname, Kontakte, der betreuende Partner und die Mailziele aus dem Portal über den stündlichen Sync. Wird ein Kunde von einem Partner betreut, verweisen seine Mails für Rückfragen auf „Ihren AegisGrid-Partner“, und Antworten gehen an den Partner.

Nur an den Betreiber geht die Mail Serverzustand (betreiber-serverzustand): sobald eine Meldung der Systemprüfung neu zur Warnung oder zum Fehler wird – etwa „konnte VMs starten, jetzt nicht mehr“, das Zertifikat bei 30, 7 und 0 Tagen, der Store bei 90 und 97 % – und einmal „wieder in Ordnung“, wenn alles behoben ist. Eine Besserung zählt erst, wenn sie eine Stunde anhält; so kommt an einer Grenze keine Mail hin und her und nie täglich dieselbe. Hängende Mails im Spool lösen keine Mail aus.

Je Kunde und Mailart lässt sich das Ziel umleiten: kunde (Standard), an den Partner bzw. bei eigenen Kunden an den Betreiber, an beide oder aus. Hat ein Kunde niemanden mit der passenden Rolle, gehen die Mails an alle seine Kontakte, ohne Kontakte an den Betreiber. Der Betreiber bekommt zusätzlich eine Übersicht mit allen Stores, Kunden und wen das Target benachrichtigt hat.

Mails des Targets prüfen und anpassen

bkp_target --mail-test                                    # Testmail an operator-to=
bkp_target --mail-recipients --dir mueller/srv1           # wem das Verzeichnis gehört, wer welche Mail bekommt
bkp_target --mail-preview schaden --customer mueller      # die Mail mit Beispielwerten
bkp_target --mail-templates-export /etc/bkp/mail-templates # eingebaute Vorlagen zum Anpassen ablegen
bkp_target --mail-templates-check                         # eigene Vorlagen prüfen

Den Wortlaut bestimmen Vorlagen (<mailart>.tmpl, für den Betreiber betreiber-<mailart>.tmpl, auf Wunsch mit HTML-Teil <mailart>.html.tmpl). Eigene liegen in /etc/bkp/mail-templates, für einen einzelnen Kunden in kunden/<id>/, für alle Kunden eines Partners in partner/<A-…>/; das Target füllt vor dem Versand die Platzhalter aus (--mail-preview nennt alle). Eine fehlerhafte Vorlage wird übergangen, die Mail kommt dann aus der nächsten Stufe, und der Betreiber erfährt es einmal per Mail.

Jeder Kunde bekommt seine Mails in seiner Sprache (language= in target-customers.cfg, je Kontakt language=<code> am Ende der Kontaktzeile), sonst in der Sprache des Servers; Mails an den Betreiber stehen immer in der Sprache des Servers. Eine eigene Vorlage für nur eine Sprache heißt <mailart>.<code>.tmpl (z. B. fehler.fr.tmpl); --mail-templates-export <verz> --lang fr legt die eingebauten Vorlagen in dieser Sprache ab.

10.14 Verbrauch der Jobs#

Die Jobs des Target-Schedulers – Prüf-Restores mit VMs, Virenprüfung, Scrub, Spiegel, Export, Prune – brauchen auf dem Server sehr unterschiedlich viel Rechenzeit, Speicher und Plattenzugriffe. Das Target misst deshalb jeden Lauf, rechnet ihn in Recheneinheiten (RE) um, sagt voraus, was der nächste Lauf braucht, und meldet die Tagessummen je Konto an den Lizenzserver. Der Sicherungseingang selbst (die Sitzungen der Agents) zählt nicht dazu; er ist über Punkte bzw. TB-Tage abgegolten.

10.14.1 Voraussetzung: cgroup v2#

Gemessen wird über cgroup v2: Jeder Lauf bekommt eine eigene cgroup, alle seine Unterprozesse (clamscan, qemu-nbd, fsck …) zählen mit; Prüf-VMs, die ihren Job überdauern, laufen in einer cgroup ihrer Kette. Dafür braucht der Dienst Delegate=yes; die mitgelieferte bkp_target.service hat es. Ohne cgroup v2 oder ohne Delegation (Container, von Hand gestartet) misst das Target nur, was der Betriebssystemkern beim Ende eines Prozesses meldet; solche Läufe heißen in Konsole, Bericht und Meldung „geschätzt“, und die Systemprüfung nennt als Hinweis den nächsten Schritt (systemctl edit bkp_target, Delegate=yes eintragen).

Der CPU-Faktor gleicht schnelle und langsame Server aus: Die Systemprüfung misst ihn einmal am Tag mit einer festen Rechenlast; jeder Lauf speichert den Faktor seiner Zeit, damit sich alte Läufe nicht nachträglich ändern.

10.14.2 Recheneinheiten und Klassen#

Eine RE ist standardmäßig 1 normierte CPU-Kernstunde = 8 GiB-Stunden Speicher = 50 GB Plattenzugriff = 500 GB-Stunden Arbeitsplatz = 1 vCPU-Stunde einer VM = 100 GB Netz; die Teile werden addiert. Gewichte, Zeittarife und Preis legt der Lizenzserver fest; das Target bekommt sie mit der Erneuerung und rechnet damit für Anzeige und Vorhersage – maßgeblich ist die Rechnung am Lizenzserver. Jeder Lauf erhält eine Klasse: die Art nach dem größten Anteil (rechenlastig, speicherlastig, IO-lastig, platzlastig, VM-lastig, netzlastig) und die Größe S (unter 0,1 RE), M (unter 1), L (unter 10) oder XL. Hat ein Lauf mehr als ein Fünftel seiner Zeit auf Prozessor oder Platte gewartet, steht dabei „vom Server gebremst“.

Ein Lauf einer Prüfkette gehört dem Besitzer der geprüften Sicherung (Freigabe unter hosted/G-…, sonst Kunde laut target-customers.cfg, sonst das Konto des Targets). Jobs über mehrere Stores (scrub, prune, mirror, export) teilt das Target nach den Bytes je Store auf; ein Lauf ohne Store zählt beim Target selbst (in der Konsole „Target selbst (kein einzelnes Konto)“). Die eigenen Jobs des Target-Kontos kosten nichts.

10.14.3 Grenzen und faire Verteilung#

Je Job lassen sich Grenzen setzen; ohne cgroup werden sie mit einem Hinweis im Log übergangen:

Konkurrieren Läufe mehrerer Konten, teilen sie sich Prozessor und Platten zu gleichen Teilen (fair-share=yes, Standard, in [sched] von bkp_target_sched.cfg); ein Konto mit vielen Jobs verdrängt so kein anderes.

10.14.4 Planen nach Vorhersage#

Aus den letzten 20 Läufen eines Jobs kennt das Target Median und 90-%-Wert jeder Größe; ohne eigene Läufe schätzt es aus der Größe der Sicherung und der Art des Jobs. Mit capacity-planning=yes (Standard) startet ein Job erst, wenn sein erwarteter Speicher und seine Kerne neben den laufenden Jobs Platz haben (Speicher bis 85 %, Kerne bis zur Anzahl der Kerne); bis dahin steht er auf „wartet auf freie Leistung“. Nach capacity-wait-max= (Standard 4h, 10 Minuten bis 7 Tage) startet er trotzdem, mit einem Hinweis im Log; ein Job, neben dem nichts läuft, startet immer.

Ein Lauf, der mehr als das Dreifache oder weniger als ein Drittel des Medians verbraucht (ab 5 Läufen), bekommt den Hinweis Ausreißer. Das Ergebnis des Jobs bleibt, wie es ist; der Hinweis steht in Konsole, Jobmail und Bericht.

10.14.5 Budget#

Ein Monatsbudget gibt es je Job und je Konto:

Bei 80 % und bei 100 % geht die Mail verbrauch-budget an den Betreiber und an den Kunden, je Stufe einmal im Monat. Mit hold startet ein geplanter Lauf nicht mehr und der Job steht gelb auf „Nicht gestartet: Budget erreicht“ – nicht rot, denn nichts ist kaputt. Von Hand gestartet läuft er trotzdem, mit einem Vermerk im Log. Im nächsten Monat geht es von selbst weiter.

10.14.6 Bericht, Nachweise, Energie#

Am Monatsersten erstellt das Target den Verbrauchsbericht des Vormonats als PDF (RE je Job und Art, Klassen, Verlauf über 12 Monate, Vorhersage, Ausreißer, Energie) und schickt ihn mit der Mail verbrauchsbericht: jedem Kunden nur seine Läufe, dem Betreiber alle. Die Berichte bleiben 13 Monate unter usage-reports/ neben dem Zustand des Schedulers. Ins Nachweis-Protokoll kommen je Lauf job-usage, je Tag und Konto usage-day und jede Budgetstufe als job-budget.

Energie und CO₂ schätzt das Target aus den Messwerten; die Faktoren stehen in bkp_target.cfg und sind überall als „Schätzung“ gekennzeichnet:

10.14.7 In der Target-Konsole#

Die Jobliste hat die Spalte Verbrauch (RE des letzten Laufs, Klasse, Ausreißer), die Laufliste die Messwerte je Lauf. Das Kontextmenü eines Jobs öffnet mit „Verbrauch…“ dessen Läufe mit Aufschlüsselung, Verlauf, Vorhersage und Energie; „Verbrauch aller Jobs…“ fasst nach Konto, Tag oder Job zusammen, mit Budget-Stand, und „Exportieren…“ speichert CSV oder JSON. Im Jobdialog öffnet „Verbrauch…“ das Fenster Verbrauch und Grenzen: die Grenzen und das Budget des Jobs, was ein Lauf voraussichtlich verbraucht und kostet, und – wenn der Lizenzserver Zeittarife hat – um wie viel der Job in einem günstigeren Zeitfenster billiger wäre; „Fenster übernehmen“ trägt es als Zeitfenster des Jobs ein. In der Grafik zeigt der Tooltip eines Kastens den Verbrauch der letzten 31 Tage.

Kunden sehen den Verbrauch ihrer Prüfungen auf dem Target bei der nächsten Sicherung dorthin: bkp_sched list und die Scheduler-Konsole nennen die RE des laufenden Monats und den Budget-Stand.