Überwachung

Zum Inhaltsverzeichnis

13.1 Live-Anzeige: bkp_monitor#

Agent und Restore schreiben ihren Fortschritt in den Laufkanal, ein Shared-Memory-Segment: bei einem Job des Planers in den Kanal, den bkp_sched für diesen Lauf anlegt (/dev/shm/bkp_runctl.<pid>.<n>), bei einem von Hand gestarteten Programm in einen eigenen (/dev/shm/bkp_runctl.<pid>). bkp_monitor zeigt ihn an: Durchsatz, Kompressionsrate, Daten und Löcher (davon dateisystem-frei), Chunks und wie viele davon neu waren (Deduplizierungsquote), Füllstand von Lese-, Bearbeitungs- und Schreib-Queue, Auslastung der Worker, das aktuelle zstd-Level und die verwendeten CPU-Funktionen (AVX2, SHA-NI). Das Segment entsteht gleich beim Programmstart: Während der Vorbereitung (Snapshot samt Hooks, Verbindung, Öffnen des Stores, Dateisystem-Bitmap, Vorbelegen des Restore-Ziels) steht der Job auf starting und die Statuszeile nennt die aktuelle Phase. Die ETA rechnet erst ab Beginn der Datenübertragung. bkp_proxmox, bkp_xenV und ihre Restore-Programme legen ebenfalls ein eigenes Segment an (Phase: Freeze, Snapshots, Platte n/m, ...); bkp_monitor zeigt den Orchestrator als einen Eintrag und folgt darin automatisch dem gerade laufenden bkp_agent/bkp_restore (auch mit --dump).

bkp_monitor                  # erster laufender Job, links die Liste aller Jobs (Pfeil hoch/runter wechselt)
bkp_monitor --pid <pid>      # einen bestimmten Prozess anzeigen

Der Monitor hilft, den Engpass zu finden: ist die Lese-Queue meist leer, ist die Quelle zu langsam; ist die Schreib-Queue voll, bremst das Ziel; sind alle Worker ausgelastet, fehlt CPU (mehr --threads oder eine niedrigere Kompressionsstufe).

13.2 Jobs des Planers im Überblick: bkp_sched list#

bkp_sched list zeigt alle Jobs des Planers auf diesem Rechner in einer Tabelle, nur lesend. Die Zeiten stehen kurz in Ortszeit („01:30“, „gestern 02:40“, „So 03:00“, weiter entfernte mit Datum), den Abstand zu UTC nennt die Zeile über der Tabelle; --full zeigt stattdessen die vollen Zeitstempel. „DAUER“ ist die Dauer des letzten Laufs, bei einem laufenden Job die bisherige Laufzeit mit geschätzter Restzeit. Ein laufender Job zeigt seinen Fortschritt in Prozent, ein fehlgeschlagener oder teilweise gelungener seinen Exit-Code. Unter einem wartenden Job steht, auf welche after=-Jobs er noch wartet, unter einem gesperrten der Grund, unter einem angehaltenen (ANGEHALTEN, bkp_sched hold), seit wann, von wem, wann er fortgesetzt wird und der Grund, etwa „angehalten seit 22:00 · von bkp_sched hold (root) · wird morgen 06:00 fortgesetzt · Grund: Umzug“. Eine Zusammenfassung schließt die Liste ab.

bkp_sched list

Zeiten in Ortszeit (UTC+01:00)
NAME          BEFEHL        STATUS              NÄCHSTER LAUF  LETZTER LAUF      DAUER                  NACH
srv-db        agent         LÄUFT 43 %          morgen 01:30   01:30             18 min (noch ~24 min)  -
m365-mail     m365          FEHLGESCHLAGEN (1)  morgen 02:00   02:00             3 min                  -
spiegel       maint-mirror  WARTEND             -              gestern 02:40     1 h 12 min             srv-db,m365-mail
  wartet auf: srv-db (LÄUFT), m365-mail (FEHLGESCHLAGEN)
prune         maint-prune   FERTIG              So 03:00       So 03:00          45 s                   -
restore-test  restore       AUS                 -              24.10.2026 10:15  6 min                  -

5 Jobs: 1 fertig, 1 läuft, 1 fehlgeschlagen, 1 wartet, 1 deaktiviert

Im Terminal ist nur die Spalte „STATUS“ eingefärbt: fertig grün, läuft türkis, fehlgeschlagen rot, teilweise und gesperrt gelb (auf hellem Hintergrund braun), wartend, angehalten und deaktiviert ohne Farbe. Die Farbtöne passen sich einem dunklen oder hellen Hintergrund an, wenn das Terminal ihn verrät (COLORFGBG oder die Abfrage der Hintergrundfarbe); NO_COLOR=1 schaltet die Farben ab. Ist das Terminal zu schmal, werden zuerst „NACH“, dann „NAME“ gekürzt. In eine Datei oder Pipe geht die Tabelle immer vollständig und ohne Farben.

13.3 Einen Job im Einzelnen: bkp_sched show#

bkp_sched show <job> zeigt einen Job untereinander: Befehl, Profil (der Name der Sicherung), die Sinks des Profils, den Zeitplan wie in der Konfiguration und in Worten, den nächsten Start, den letzten Lauf mit Status und Dauer, after= und den Zustand (ein, aus, angehalten, pausiert, mit Grund). Bei einem Sicherungs-Job steht zuletzt der fertige Befehl, mit dem man an die Sicherungen kommt: bei einer Dateisicherung die Suche, sonst die Liste der Läufe. Der Befehl liest nur und legt nichts an.

bkp_sched show daten-nacht

Ausgabe:

Zeiten in Ortszeit (UTC+01:00)
Job:              daten-nacht
Befehl:           agent
Profil:           daten
Ziele:            usb1, usb2
Zeitplan:         schedule=0 22 * * *
                  (Täglich um 22:00; verpasste Läufe einmal nachholen)
Nächster Start:   22:00
Letzter Lauf:     noch nie
Nach:             -
Zustand:          eingeschaltet
Wiederherstellen: bkp_restore --name daten --files find "<Muster>"

• Die Sinks kommen bei command=agent aus bkp_agent.cfg, bei Proxmox-, Xen- und Hyper-V-Jobs aus sinks= des Profils in deren Konfiguration; fehlt das Profil dort, sagt die Zeile das. Restore-, M365- und Wartungs-Jobs haben keine Zeile „Ziele“ und keine Zeile „Wiederherstellen“.
• Ein unbekannter Jobname nennt die vorhandenen Jobs (höchstens 20) und bkp_sched list.
• --json gibt dieselben Angaben für Programme aus (name, command, profile, sinks, schedule, next_run, last_run, status, after, restore_hint; Zeiten in UTC, nie übersetzt).

13.4 Für Skripte: --dump#

bkp_monitor --dump --pid <pid> --interval 200 | cut -f1-5,21-27

Ausschnitt (Spalten 1–5 und 21–27)

#elapsed_ms	blocks_done	blocks_total	bytes_raw	bytes_compressed	state	logical_bytes	hole_bytes	fs_free_bytes	chunks	chunks_new	new_bytes
5934	33	48	35487305	35412856	running	35487305	0	0	119	118	35412856
6167	48	48	50331648	50341056	DONE	50331648	0	0	168	168	50341056

Die vollständige Zeile hat 27 Spalten, darunter Füllstände der Queues, Worker, zstd-Level und die Werte der Selbstdrosselung (bg_*, bei --background). blocks_* zählt hier gelesene Einheiten der Quelle, chunks/chunks_new die erzeugten und davon neu gespeicherten Chunks.

Je Intervall (Standard 500 ms) gibt --dump eine tab-getrennte Zeile aus und endet, wenn der Prozess fertig ist. --wait <s> (Standard 10) bestimmt, wie lange auf das Segment des Prozesses gewartet wird. Damit lässt sich zum Beispiel der Fortschritt in ein Log oder eine Monitoring-Software übernehmen.

bkp_agent ... --name data &
bkp_monitor --dump --pid $! --interval 5000 >> /var/log/bkp/progress.tsv

13.5 Laufende Jobs steuern: Pause, Hintergrundmodus, Bandbreite#

Über denselben Laufkanal nimmt ein Job des Planers Anweisungen entgegen, solange er läuft. Gesteuert wird über die API von bkp_sched (GET /jobs/{name}/progress zeigt den Fortschritt jedes Programms des Laufs, PUT /jobs/{name}/control ändert, was verlangt ist; Einzelheiten in docs/sched-api.txt, Abschnitte 7.17 und 7.18):

bkp_agent und bkp_restore folgen allen Anweisungen, bkp_m365 allen außer dem Hintergrundmodus. Bei VM-Jobs (bkp_proxmox, bkp_xenV und ihre Restores) übernimmt der bkp_agent bzw. bkp_restore der gerade übertragenen Disk die Anweisung, auch die Programme der folgenden Disks. Eine Anweisung gilt nur für den laufenden Lauf; der nächste beginnt wieder so, wie der Job eingerichtet ist.

Auf dem Server selbst geht dasselbe mit bkp_sched pause, resume und throttle (Kapitel 4), auch für Läufe, die mit bkp_sched run/start gestartet wurden. Nicht steuerbar sind Programme mit --no-progress und die Aufräumphase nach einem Abbruch.

13.6 Fortschrittsfenster auf dem Windows-Desktop#

Startet der Planer unter Windows eine Sicherung oder Wiederherstellung, sehen die angemeldeten Benutzer das in einem kleinen Fenster oben rechts auf dem Bildschirm: je Lauf der Job, ein Balken und eine Zeile wie „42 % · 1,3 GB von 3,0 GB · 85,0 MB/s · noch etwa 5 Min.“. Das Fenster liegt (in der Standard-Darstellung) über den anderen Fenstern, ist leicht durchsichtig und lässt Klicks durch: Wer darunter arbeitet, wird nicht gestört. Ruht die Maus kurz darauf, wird es deckend und zeigt „Pausieren“ (bzw. „Fortsetzen“) und „Ausblenden“; so lässt es sich auch an eine andere Stelle ziehen, die es sich für den Benutzer merkt. Mehr als drei Läufe fasst es als „und 2 weitere Läufe“ zusammen; das Ende eines Laufs („Abgeschlossen“, „Mit Fehlern beendet – Einzelheiten im Protokoll“, bei einem angehaltenen Lauf „Angehalten – wird später fortgesetzt“) steht noch zehn Sekunden da.

Darstellung: Wo das Fenster liegt, lässt sich wählen. „Im Vordergrund“ (Standard) ist das oben beschriebene Verhalten. „Auf dem Desktop“ legt es auf den Desktop: über Hintergrundbild und Symbolen, aber hinter allen Programmfenstern; mit „Desktop anzeigen“ (Windows-Taste+D) ist es zu sehen, und auch dort lässt es sich mit der Maus bedienen und verschieben. „Im Desktop-Hintergrund“ macht es zu einem Teil des Hintergrundbilds, hinter den Desktopsymbolen; dort nimmt es keine Maus an. Die Vorgabe für den Rechner ist [sched] overlay-mode (bzw. die Konsole, „Planer-Einstellungen“).

Solange das Fenster läuft, hat es ein Symbol im Infobereich der Taskleiste (unten rechts; Windows 11 und Server 2025 zeigen ein neues Symbol zunächst hinter dem Pfeil ^). Sein Tooltip zeigt den Fortschritt, ein Klick öffnet ein Menü: „Darstellung“ mit „Wie auf diesem Computer eingestellt“ und den drei Lagen, „Sicherung „…“ pausieren“ bzw. „fortsetzen“, „Ausblenden“ und „Wieder einblenden“. Die Wahl gilt sofort und nur für diesen Benutzer (gemerkt in HKCU\Software\AegisGrid\overlay, Wert mode); „Wie auf diesem Computer eingestellt“ folgt wieder der Vorgabe. Startet man bkp_overlay.exe von Hand mit --mode top|desktop|wallpaper, gilt diese Lage, und das Menü lässt sie nicht ändern. Wird der Explorer neu gestartet, erscheint das Fenster nach etwa einer Sekunde wieder; ausgeblendete Läufe sind dann wieder zu sehen.

Der Dienst startet das Programm bkp_overlay.exe (Komponente „Job-Planer“) selbst in jeder angemeldeten Sitzung, auch in Remotedesktop-Sitzungen und bei einer Anmeldung während eines Laufs, und zwar unter dem Konto des jeweiligen Benutzers. Es fragt den Dienst über eine Named Pipe, die nur auf dem Rechner selbst erreichbar ist (docs/sched-api.txt, Anhang A), und beendet sich, wenn nichts mehr zu zeigen ist. Während ein Programm den ganzen Bildschirm belegt (Präsentation, Spiel, Video), bleibt es verborgen. Von Hand mit bkp_sched run/start gestartete Läufe zeigt es nicht.

Pausieren darf jeder angemeldete Benutzer. Der Lauf hält an einer sicheren Stelle an (wie über die Konsole) und geht nach 60 Minuten von selbst weiter; das Fenster zeigt, wann. Das Jobprotokoll vermerkt, wer pausiert und fortgesetzt hat. „Fortsetzen“ gibt es nur für eine Pause aus dem Fenster: Einen über die Konsole oder bkp_sched pause pausierten Lauf zeigt es als „Pausiert über die Verwaltung“. Pausiert die Konsole einen im Fenster pausierten Lauf oder setzt ihn fort, gilt ihre Entscheidung, und die Pause endet nicht mehr von selbst. Anhalten (bkp_sched hold, Kapitel 4) lässt sich ein Lauf im Fenster nicht.

Die Einstellungen in [sched] wirken sofort, ohne Neustart des Dienstes; in der Konsole stehen sie unter „Planer-Einstellungen“ und im Job-Dialog.

13.7 Erfolg von Sicherungen überwachen#

• Der Exit-Code von bkp_agent ist 0 nur, wenn alle Sinks ihren Run abgeschlossen haben, 3 bei einem ausgefallenen optionalen Sink, 75 wenn derselbe Auftrag schon läuft, 77 wenn die Lizenz keine neuen Sicherungen zulässt (Kapitel „Automatische Updates“, Abschnitt „Testversion und Lizenz“), 78 wenn der Lauf angehalten wurde und später fortgesetzt wird (bkp_sched hold, kein Fehler). Andere Werte sind Fehler, in einem Cronjob also Grund für eine Alarmmail. bkp_sched verschickt die Mail selbst und zeigt die Kennzahlen des Laufs darin.
• Die Zeile done: ... chunks N, new M (x% deduplicated); ... newly stored am Ende des Logs zeigt, wie viel neu war. Ein plötzlich sehr großer Wert für newly stored (oder über Tage 100 % dedupliziert bei einer aktiven Quelle) ist verdächtig. Ein ungewöhnlich großer Zuwachs kann auch auf Verschlüsselung durch Schadsoftware hindeuten.
• bkp_restore --list gegen den Server zeigt, ob die erwartete Sicherung des Tages vorhanden ist (Spalten NEW und STATUS); bkp_maintenance store-info zeigt Deduplizierung, letzte Bereinigung und letzten Scrub.
• scrub regelmäßig laufen lassen (Kapitel 10).

13.8 Windows-Ereignisprotokoll#

Unter Windows schreiben der Scheduler-Dienst bkp_sched und bkp_updater die wichtigsten Ereignisse zusätzlich ins Ereignisprotokoll Anwendung, Quelle AegisGrid. Überwachungswerkzeuge (etwa ein RMM-System oder eine geplante Aufgabe auf ein Ereignis) können so nach festen Ereignis-IDs filtern. Der Text ist ein ganzer Satz in der Sprache des Systems und nennt bei Fehlern das Job-Log. Das Setup trägt die Quelle ein und entfernt sie bei der Deinstallation; die geschriebenen Ereignisse bleiben im Protokoll. Fehlt die Quelle (etwa nach einem Update einer älteren Installation), trägt der Dienst sie beim Start selbst ein.

Läufe, die angehalten wurden und von selbst fortsetzen (bkp_sched hold, Neustart, Update), und Fehlversuche, auf die mit retry= noch ein Versuch folgt, erscheinen nicht. Unter Linux gibt es kein Gegenstück; dort gelten das Log und die Mails.