Target-Konsole (Windows)

Zum Inhaltsverzeichnis

bkp_target_console.exe ist das Windows-Programm für Betreiber von Backup-Servern. Es verbindet sich über die Target-API (HTTPS, Port 9991) mit einem oder mehreren bkp_target und zeigt auf einen Blick, wie es ihnen geht: Speicher und Prognose, laufende Sitzungen, Stores und Läufe, die Jobs des Target-Schedulers, Zugänge, Freigaben, Einstellungen, den Verlauf und das Protokoll. Mit einem Admin-Token lässt sich der Server darüber auch steuern und einrichten, ohne eine Shell zu öffnen.

Wie bei der Verwaltungskonsole braucht das Programm selbst keine Administratorrechte; was es darf, bestimmt das Token, und jede Änderung prüft bkp_target mit denselben Regeln wie auf der Kommandozeile, bevor er sie übernimmt.

15.1 Installation#

Die Konsole ist die Komponente tconsole („Target-Konsole“) von aegisgrid-setup.exe, unabhängig von Agent und Job-Planer. Für einen reinen Verwaltungsarbeitsplatz unter „Benutzerdefiniert“ nur Kern und Target-Konsole ankreuzen. Danach steht im Startmenü unter „AegisGrid“ der Eintrag „AegisGrid Target-Konsole“; wird die Komponente später abgewählt, verschwindet er wieder.

ohne Fenster, etwa für die Softwareverteilung

aegisgrid-setup.exe --silent --accept-eula --components core,tconsole

15.2 Den Backup-Server vorbereiten#

Die Target-API ist ab Werk aus. Am einfachsten schaltet sie das Setup bei der Einrichtung des Servers ein (Kapitel 4, „Verwaltung über die Target-API“):

bkp_setup --silent --accept-eula --preset server --configure-server --server-storage /srv/backups --enable-target-api

Der Bericht am Ende nennt Port, Fingerabdruck des API-Zertifikats und das Token des Zugangs target-konsole mit der Rolle admin. Das Token erscheint nur dieses eine Mal; es gehört in die Konsole und sonst nirgendwohin. Auf einem schon eingerichteten Server geht es von Hand:

bkp_target --api-init
bkp_target --api-enable
bkp_target --api-token-add konsole-admin --role admin
systemctl reload bkp_target
bkp_target --api-info                 # Adresse und Fingerabdruck für die Konsole

Drei Schalter im Abschnitt [api] von /etc/bkp/bkp_target.cfg begrenzen auch ein Admin-Token: allow-config-write (Dateien ändern, ab Werk ja), allow-delete (Läufe löschen, Bereinigen, Aufbewahrung ändern; ab Werk nein) und allow-exec (Jobs, die beliebige Programme starten; ab Werk nein). Was so gesperrt ist, zeigt die Konsole als „nur auf dem Server“. Port 9991/TCP nur für die Rechner der Betreiber in der Firewall öffnen.

15.3 Einen Server hinzufügen#

„Datei“ › „Server hinzufügen…“ öffnet denselben Verbindungsdialog wie in der Verwaltungskonsole:

„Verbindung testen“ prüft Zertifikat und Token, bevor der Server gespeichert wird; ohne bestätigtes Zertifikat sendet die Konsole nichts. „Datei“ › „Gruppe zuordnen…“ ordnet Server in Gruppen, etwa nach Standort; eine Gruppe zeigt, wie viele ihrer Server nicht verbunden sind. Serverliste, Gruppen und Fensterlage stehen in %APPDATA%\AegisGrid\tconsole.cfg, die Tokens darin mit DPAPI für das Windows-Konto verschlüsselt. „Server entfernen“ vergisst Adresse und Token nur in der Konsole.

15.4 Das Hauptfenster#

Links stehen die Server, nach Gruppen geordnet, mit einem Zeichen für den Zustand: grün in Ordnung, blau mit laufenden Sitzungen, ein gelbes Dreieck bei einem fehlgeschlagenen Job, gesperrter Lizenz oder einer Warnung des Servers, rot ohne Verbindung oder bei einer Fehlermeldung des Servers, grau während des Verbindens; eine Gruppe zeigt den schlechtesten Zustand ihrer Server, der Tooltip nennt die Gründe. Über den Reitern nennt der Kopf Rechnername, Version von bkp_target, das Token und seine Rolle. Die Konsole aktualisiert den gewählten Server im Hintergrund; „Ansicht“ › „Aktualisieren“ (F5) holt sofort neue Daten, Strg+1 bis Strg+9 wechseln die Reiter. „Ansicht“ › „Serverliste“ (Strg+B) blendet die Liste links aus, um den Reitern mehr Platz zu geben; ebenso ein Doppelklick auf die Trennlinie oder die Linie ganz nach links ziehen. Der Knopf „»“ im schmalen Streifen holt sie wieder, in der zuletzt gewählten Breite. Das Kontextmenü eines Servers und das Menü „Server“ bieten „Dienst neu laden“ (Zertifikat, Zugänge, Scheduler und [api] neu einlesen, Sitzungen bleiben) und „Dienst neu starten…“: Laufende Sitzungen dürfen dann bis zur Wartezeit drain-timeout fertig werden, was sie übertragen haben, bleibt erhalten, und ihr nächster Lauf setzt dort fort.

15.4.1 Meldungen#

Was der Server über sich selbst meldet (Systemprüfung, Zertifikat, Store-Füllstand, Update, Mails, ausstehender Neustart; Kapitel „Prüf-Restore“, Abschnitt „Kann der Server das?“), steht in der Statusleiste links neben „x Server“: mit dem Zeichen der Stufe (Fehler, Warnung, Hinweis), bei mehreren mit „2/3“ davor; sie wechseln alle 6 Sekunden, Fehler zuerst, und bleiben stehen, solange die Maus darauf zeigt. Der Tooltip zeigt alle Meldungen, bei einer Gruppe mit dem Namen des Servers davor. Ohne Meldung bleibt das Feld leer; ein älteres bkp_target liefert keine.

Ein Klick auf das Feld oder „Ansicht“ › „Meldungen…“ öffnet das Fenster Meldungen: je Meldung Stufe, Server (bei einer Gruppe), Meldung und nächster Schritt, darunter die Einzelheiten und – wo etwas zu installieren ist – der Befehl dazu mit „Kopieren“. „Jetzt prüfen“ startet die Systemprüfung (nur mit einem Admin-Token, höchstens einmal je Minute) und zeigt den Fortschritt, bis das neue Ergebnis da ist. Hinweise lassen sich mit „Nicht mehr anzeigen“ je Server ausblenden, „Ausgeblendete Hinweise zeigen“ holt sie zurück; wird aus einem ausgeblendeten Hinweis eine Warnung, erscheint sie wieder.

Auch der Jobdialog sagt, was dem Server für den Job fehlt: Bei pruef-vm-start steht statt der Hilfe unter den Zeilen etwa „Auf diesem Server fehlt KVM …“, rot, wenn der Job so scheitert, sonst orange; bei pruef-fsck und pruef-mount die fehlenden Programme. Der Hinweis folgt dem Befehl, während man tippt. Fehlt nur KVM und kann QEMU emulieren, setzt „Emuliert starten (--no-kvm tcg)“ die Option in args= (die VMs starten dann deutlich langsamer). Das gilt ebenso für die Schritte eines Ablaufs.

15.4.2 Sicherungen anhalten und Wartungsmodus#

Im Reiter „Sitzungen“ hält Anhalten… (Knopf, Kontextmenü und Sitzungsfenster) eine oder mehrere markierte Sicherungen an der nächsten sicheren Stelle an. Das ist kein Fehler: Der Client behält, was er schon gesendet hat, und setzt später mit demselben Snapshot fort. Der Dialog fragt nach einem Grund (optional, höchstens 200 Zeichen), wann es weitergeht (mit dem nächsten geplanten Lauf, nach Minuten/Stunden/Tagen oder um eine Uhrzeit) und bei mehreren Sitzungen, über wie viele Minuten sich die Fortsetzung verteilen soll (Standard 10, 0 bis 1440), damit nicht alle Clients zugleich zurückkommen. Länger als hold-max (Standard 7 Tage) dauert ein Halt nicht. Wiederherstellungen lassen sich nicht anhalten.

Clients vor Version 2.0.0-alpha.042 können nicht anhalten; die Konsole sagt das und bietet stattdessen an, ihre Sitzung zu beenden. Der Kunde erhält bei eingerichteten Target-Mails die Vorlage angehalten mit Grund und Fortsetzungszeit (Kapitel 13).

„Server“ › Wartungsmodus… hält alle laufenden Sicherungen an und weist bis zum Ende des Wartungsmodus jede neue ab; der Dialog fragt, wann er endet. Die Statusleiste zeigt dann „Wartungsmodus bis …“. Ein zweiter Aufruf bietet an, den Wartungsmodus vorzeitig zu beenden; die angehaltenen Sicherungen dürfen danach wieder starten und kommen mit ihrem nächsten Versuch zurück. Ein Neustart des Dienstes hält laufende Sicherungen ebenfalls an (restart-hold, Standard 5 Minuten), statt sie zu beenden. hold-max und restart-hold stehen in bkp_target.cfg; dieselben Funktionen bietet die Target-API (POST /sessions/{id}/hold, /maintenance, GET /holds, docs/target-api.txt).

„Server“ › Angehaltene Sicherungen… listet jeden Halt mit Sicherung, Verzeichnis, Fortsetzung, Art (Betreiber, Neustart, Client, Zeitfenster, Herunterfahren, Zeitlimit), wer angehalten hat und dem Grund. Aufheben lässt eine Sicherung sofort wieder zu, auch während des Wartungsmodus; ihr Client setzt mit seinem nächsten Versuch fort. Anhalten und der Wartungsmodus brauchen ein Token mit der Rolle admin, die Liste lesen darf jedes.

15.5 Daten: Stores und Läufe#

Der Reiter „Daten“ führt vom Verzeichnis (Kunde) über den Store zu seinen Läufen; „< Zurück“ geht eine Ebene hinauf. Belegung, Dedup-Faktor und die Liste der Läufe liest der Server im Hintergrund als Dienstkonto aegisgrid; die Konsole zeigt, wann gemessen wurde, und „Neu lesen“ misst sofort neu. Eine Sicherung, die gerade in den Store läuft, steht vom Start an oben in der Liste der Läufe, mit Beginn und übertragener Menge; sobald alle Daten im Store liegen, wird sie dort zum fertigen Lauf. In der Liste der Stores steht bei einem solchen Store „Läuft gerade“. Die Aktionen laufen auf dem Server weiter, auch wenn die Konsole geschlossen wird; ihr Protokoll erscheint in einem eigenen Fenster.

15.6 Dateien durchsuchen#

Im Reiter „Daten“ öffnet das Kontextmenü eines Stores „Dateien durchsuchen…“ (mit einem Token mit Admin-Rechten; nicht bei Microsoft-365-Stores). Das Fenster zeigt die Sicherungen des Stores, bei Dateisicherungen die Ordner und Dateien, bei Platten- und VM-Sicherungen zuerst die Auswahl Volume (der Server öffnet sie wie in Kapitel 9 beschrieben). Ein Doppelklick öffnet einen Ordner, „Hoch“ geht zurück. Gewählte Einträge speichert „Als ZIP speichern…“ auf diesem Rechner; einen Restore auf Rechner des Kunden gibt es hier bewusst nicht.

Ein verschlüsselter Store braucht den Store-Schlüssel des Kunden (64 Hex-Zeichen), dann „Öffnen“. Die Konsole hält ihn nur im Speicher, solange das Fenster offen ist, und schickt ihn bei jeder Anfrage über die TLS-Verbindung mit. Der Server schreibt ihn nie in Log, Verlauf oder Nachweis. Ein falscher Schlüssel ergibt „Schlüssel passt nicht zu diesem Store“.

Jeder Zugriff ist ein Nachweis „Datei-Zugriff durch Betreiber“ mit Token, Store, Lauf, Pfaden und ob der Kundenschlüssel benutzt wurde (Kapitel 12). Lädt der Betreiber ein ZIP herunter, bekommt der Kunde die Mail betreiberzugriff; mit route.betreiberzugriff=aus in target-customers.cfg lässt sie sich für einen Kunden abschalten.

15.7 Aktionen und Scheduler#

Der Reiter „Aktionen“ zeigt die Jobs des Target-Schedulers (Kapitel 10, bkp_target_sched.cfg) in zwei Bereichen. Unter „Aktion“ stehen Aufgaben, die man für bestimmte Sicherungen von Hand startet – ein Prüf-Restore vor dem Monatsabschluss, eine Prüfung, ein Export, ein Spiegel. Unter „Scheduler/On the Fly“ steht alles, was von selbst läuft: nach Zeitplan, nach dem Eingang einer Sicherung, nach einem anderen Job oder – als On-the-Fly-Schritt – schon während des Eingangs. Zu welchem Bereich ein Job gehört, ergibt sich aus seinen Zeilen: Ein Job ohne Zeitplan, on= und after= ist eine Aktion; ein Job mit after= gehört zum Bereich des Jobs, dem er folgt.

Die Filterzeile gilt für Liste, Grafik und Zeitachse: Kunde (aus der Kundendatei des Targets, aus Freigaben oder nach Verzeichnis), Suchen in Name, Verzeichnis und Notiz (Groß- und Kleinschreibung und Umlaute gleich) und Zeigen: alle, fehlgeschlagene, laufende, Sicherungen ohne Job oder ungeprüfte. „Ungeprüft“ heißt: seit einer Anzahl Tagen (Standard 30, „Ansicht“ › „Ungeprüft nach …“) lief für die Sicherung keine Prüfung und kein Prüf-Restore. Die Konsole merkt sich die Filter je Server.

15.7.1 Aktion#

Die Liste nennt jede Aktion mit Befehl, Sicherung(en), Lauf („Neuester“ oder ein bestimmter), Zustand, letztem Lauf, geplantem Start und Notiz; darunter stehen die Läufe der gewählten Aktion mit Protokoll. „Neu…“ bietet Vorlagen an (Prüf-Restore, Prüfen, Exportieren, Spiegeln, Kopie nach S3). Im Aktionsdialog werden die Sicherungen angehakt oder als Muster angegeben (kunde1/*), der Lauf gewählt (der neueste beim Start oder einer aus der Liste der Läufe des Stores), bei Export und Spiegel das Ziel, dazu Mail und Notiz. Die Konsole schreibt das als backup=, backup-kind= und backup-run= (Kapitel 10). „Kopie nach S3“ kopiert den ganzen Store in ein S3-Ziel aus „Ziele…“ (dest=, Kapitel 6).

Zum Starten die Aktionen ankreuzen und „Starten…“ wählen. Die Start-Übersicht zeigt jeden Lauf, der eingereiht wird – bei Mustern einen je Sicherung –, mit dem Lauf, mit dem er arbeitet; sie fragt das Target vorher in einem Probelauf. Aktionen, die Daten löschen (Bereinigen, Aufräumen nach einem Prüf-Restore, ein eigenes Programm), sind gekennzeichnet. Die Läufe starten gleichzeitig (so viele, wie der Scheduler zulässt) oder nacheinander, sofort oder zu einem Zeitpunkt. Einen geplanten Start nimmt „Start zurücknehmen“ zurück, solange er noch nicht begonnen hat; zurückgenommen wird der ganze Start mit allen seinen Aktionen.

15.7.2 Scheduler und On the Fly#

Unter „Scheduler/On the Fly“ › „Liste“ bearbeitet die Konsole die Jobs als ihre Zeilen Schlüssel=Wert, genau wie in der Datei. „Zeitplan bearbeiten…“ öffnet für die Zeitplan-Zeilen den Zeitplan-Editor (Kapitel „Verwaltungskonsole“, Abschnitt „Zeitplan-Editor“; am Fensterende ohne „anhalten“, das kennt der Target-Scheduler nicht) und setzt die neuen Zeilen an die Stelle der alten. „Server“ › „Feiertagskalender…“ pflegt die eigenen Feiertagskalender des Servers. „Zeitplan prüfen“ beschreibt den Zeitplan in Worten und nennt die nächsten Starttermine, bevor gespeichert wird. „Jetzt starten“ reiht einen Lauf ein; er beginnt, sobald der Scheduler ihn darf (Anzahl paralleler Jobs, Sperren je Store), auch außerhalb eines Zeitfensters. Bei einem Job, dem andere folgen (after=), bietet das Kontextmenü zusätzlich „Ohne Folgejobs starten“: dieser Lauf reiht keinen seiner Folgejobs ein (wie bkp_target --sched-run <job> --no-after). „Abbrechen“ beendet den Lauf eines laufenden Jobs (nach 5 Minuten ohne Ende hart); der nächste Start nach Zeitplan bleibt. „Pausieren…“ pausiert den laufenden Job nach einer Rückfrage (wie --sched-pause), die Liste zeigt ihn dann als „Pausiert“ bzw. „Pausiert bis …“; „Fortsetzen“ setzt ihn fort. „Deaktivieren“ lässt einen Job stehen, er startet aber nicht mehr (enabled=no); ein Lauf, der gerade läuft, endet noch, „Aktivieren“ hebt das auf. „Löschen“ geht nur bei einem deaktivierten Job, der nicht läuft: er wird aus bkp_target_sched.cfg entfernt, und die Kette schließt sich um ihn – ein Job, der nur ihm folgte, rückt an seine Stelle und übernimmt, wann er startete (seinen Vorgänger, Zeitplan oder Ereignisse), ein Job, der mehreren folgt, folgt danach dessen Vorgängern, und wer auf ihn wartete (wait-for=), wartet nicht mehr auf ihn. Die Rückfrage nennt jede dieser Änderungen; alles wird in einem Zug geschrieben. „Einstellungen…“ ändert den Abschnitt [sched]. Unten stehen die Läufe des gewählten Jobs mit Ergebnis und Dauer; „Protokoll anzeigen“ öffnet das Protokoll eines Laufs, bei einem laufenden Job fortlaufend.

On the Fly: „Neu“ › „Neuer On-the-Fly-Schritt…“ legt einen Schritt an, der während des Eingangs einer Sicherung arbeiten soll: verschlüsseln, wiederherstellen (etwa für eine Standby-VM), an ein anderes Target oder an einen S3-Speicher weiterleiten. Schritte lassen sich zu einer Kette verbinden; bei einem Fehler meldet der Schritt ihn oder holt später nach, max-rate= begrenzt die Bandbreite. „Ziele…“ pflegt die Ziele des Weiterleitens (anderes Target oder S3); ihre Schlüssel nimmt die Konsole nur als Datei (file:) oder KMS-Angabe (kms:) an, nie den Schlüssel selbst. Diese Version speichert On-the-Fly-Schritte nur, sie wirken noch nicht: Die Konsole schreibt das an jeden Schritt, die Grafik zeichnet sie lila und gestrichelt, und ein Start von Hand wird abgewiesen.

Wartet ein Lauf auf eine Sicherung oder einen anderen Job (wait-for=), steht in der Spalte „Zustand“, worauf und bis wann; ist seine Wartefrist abgelaufen, „Nicht gestartet: Wartefrist abgelaufen“. „Zeitplan prüfen“ beschreibt auch das Warten in Worten.

15.7.3 Abläufe#

Mehrere Jobs, die nacheinander laufen sollen, fasst ein Ablauf zusammen: „Neu“ › „Neuer Ablauf…“ legt einen an. Oben stehen sein Name und sein Auslöser in Worten; „Auslöser ändern…“ legt fest, wann er startet (Zeitplan mit dem Zeitplan-Editor, Ereignisse wie on=backup-success, vorher warten mit wait-for=). Eine Vorlage füllt einen neuen Ablauf vor, etwa mit allen Schritten eines wöchentlichen Prüf-Restores. Einen Schritt fügt man ein, indem man die Job-Art im Feld „Job-Art“ wählt und „Einfügen“ klickt, oder indem man sie aus der Liste „Verfügbare Job-Arten“ in die Schritte zieht; die Linie zeigt, wo er landet. Ein Doppelklick auf einen Schritt öffnet seine Zeilen (Parameter, run-as= …) und die Auswahl, ob er nach dem vorigen nur nach Erfolg, auch nach einem Fehler oder nur nach einem Fehler startet. Die Reihenfolge der Liste ist die Reihenfolge der Ausführung: Schritte lassen sich ziehen, mit „Nach oben“/„Nach unten“ oder Alt+Pfeiltaste verschieben.

„OK“ schreibt alle geänderten Schritte in einem Zug (POST /sched/batch); ist danach etwas ungültig, lehnt der Server alles ab und ändert nichts. Jeder Schritt ist ein Job namens <ablauf>-<art> mit flow=<ablauf>; beim Umsortieren behält er seinen Namen, seine Läufe und Protokolle. In der Jobliste stehen die Schritte eines Ablaufs zusammen in ihrer Reihenfolge, „Bearbeiten“ öffnet den ganzen Ablauf, „Löschen“ nimmt einen einzelnen (deaktivierten) Schritt heraus, „Ganzen Ablauf löschen…“ im Kontextmenü löscht alle Schritte, wenn keiner läuft und der erste deaktiviert ist. „Jetzt starten“ beim ersten Schritt startet den ganzen Ablauf, bei einem späteren Schritt den Rest ab dort.

15.7.4 Grafische Ansicht#

Beide Bereiche haben neben der „Liste“ eine „Grafik“ und eine „Zeitachse“. Die Grafik zeigt Sicherungen und Jobs und ihre Auslöser als beschriftete Linien. Links stehen die eingegangenen Sicherungen (die 40, die zuletzt hereinkamen, mit Ergebnis, dazu jede gerade laufende Sicherung aus „Sitzungen“) und alle Jobs; ein Doppelklick, „In die Grafik“ oder Ziehen auf die Fläche nimmt sie in die Grafik auf. Eine Verbindung entsteht, indem man vom Punkt am rechten Rand einer Sicherung oder eines Jobs zu einem Job zieht oder „Verbinden…“ wählt; danach fragt die Konsole, wann der Job startet: nach erfolgreicher, nach fehlgeschlagener, nach jeder Sicherung oder bei ihrem Beginn – zwischen Jobs nach Erfolg, nach Abschluss oder nur nach einem Fehler. Eine Linie von einer Sicherung schreibt on= und match-backup= des Jobs, eine Linie zwischen Jobs after= und after-mode=. Weil diese Angaben für den ganzen Job gelten, haben alle Linien derselben Art in einen Job dieselbe Bedeutung; der Dialog sagt das. Ein Prüf-Restore startet immer nach erfolgreichem Eingang.

Ein Doppelklick auf einen Job öffnet den Jobdialog (bei einem Ablauf den Ablaufdialog), auf eine Sicherung ihre Einzelheiten mit „Store anzeigen“, auf eine Linie die Frage, wann der Job startet. Das Kontextmenü eines Jobs bietet wie die Liste „Abbrechen“, „Deaktivieren“ (Leertaste) und „Löschen“ (Entf; nur für einen deaktivierten Job, der nicht läuft, die Kette schließt sich wie in der Liste). „Entfernen“ (Entf) an einer Linie entfernt die Verbindung, an einer Sicherung nimmt es sie samt ihren Linien aus der Grafik. Hat ein Job danach keinen Auslöser mehr, deaktiviert die Konsole ihn nach Rückfrage. Gestrichelte Linien kommen aus eigenen Filtern des Jobs (match-dir= …, in der Grafik „Ereignis“) oder aus einem Ablauf und werden im Jobdialog geändert; gestrichelt ist auch eine Linie zu einem Job, der zusätzlich on= hat – dort ist after= eine Bedingung. Die Schritte eines Ablaufs liegen in einem gemeinsamen Rahmen.

Ein laufender Job füllt sich in der Grafik von links. Schritte eines Prüf-Restores, Prüfen und Spiegeln melden ihren echten Fortschritt („Prüft scsi1 Partition 2 (2 von 5) · 40 %“, „Wartet auf …“, „Spiegelt kunde1/srv1 (3 von 8)“, mit Restzeit); sonst ist er geschätzt aus der Dauer seiner letzten erfolgreichen Läufe („ca. 60 %“, mit Restzeit), ohne frühere Läufe als wanderndes Band; eine laufende Sicherung mit dem Fortschritt, den ihr Client meldet, sonst ebenso geschätzt aus der Dauer ihrer letzten erfolgreichen Läufe im Verlauf. Endet ein Job, leuchtet er kurz grün oder rot. Jeder Job zeigt neben seinem Symbol, was er ist („Prüfen“, „Store“, „Kopieren“, „Programm“, „On the Fly“), darunter, was er tut und woran („Dateisystem prüfen · scsi1/part2 (Daten)“, „Wiederherstellung · kunde1/srv1“, „Blöcke prüfen“), dann Zustand, letzten Lauf und nächsten Start; der Tooltip zeigt alles ausführlich mit dem Namen des Jobs, der Jobdialog (Doppelklick) ebenso. Wo Jobs und Sicherungen stehen, speichert das Target (bkp_target_sched.layout.json), jede Konsole sieht also dieselbe Grafik; „Anordnen“ ordnet alles neu. „Vollbild“ (F11) öffnet die Grafik in einem eigenen Fenster, Esc kehrt zurück. Tastatur: Tab läuft durch Jobs, Sicherungen und Linien, die Pfeiltasten verschieben den gewählten Job oder die Sicherung (Strg: in kleinen Schritten), Umschalt+Pfeiltasten machen ihn breiter oder schmaler und zeigen eine Zeile mehr oder weniger, Eingabe öffnet ihn. Das Mausrad scrollt, Umschalt+Mausrad seitwärts, Strg+Mausrad zoomt um die Mausposition (Strg+Plus/Minus um die Mitte); die Fläche verschiebt man durch Ziehen auf einer freien Stelle oder mit den Bildlaufleisten. Im Jobdialog setzt „Sicherung wählen…“ eine der eingegangenen Sicherungen als match-backup= ein.

Größe in der Grafik. Jeder Job und jede Sicherung ist so breit, wie die bleibenden Texte es brauchen (Titel, was der Job tut, Andockpunkte, Urteil). Am rechten Rand zieht man einen Job oder eine Sicherung breiter oder schmaler, an der Unterkante zeigt er Zeile für Zeile mehr oder weniger (bis nur der Titel bleibt; Andockpunkte und Urteil stehen immer darunter), an der Ecke beides; der Mauszeiger zeigt den Griff an. Mehrere markierte ändern sich gemeinsam. „Optimale Größe“ im Kontextmenü (oder ein Doppelklick auf den Rand) macht ihn so breit, wie alles braucht, was er gerade zeigt, mit allen Zeilen; „Optimale Größe für alle“ im Kontextmenü der Fläche tut das für alle. Die Größe speichert das Target mit der Anordnung (ältere Targets nur bis zum nächsten Laden). Beim Verschieben und Größerziehen rastet alles auf ein Raster von 10 Punkten ein und an den Kanten der anderen; eine gepunktete Linie zeigt die Kante, an der er steht, und eine Linie wird beim Einrasten waagerecht. Mit gedrückter Alt-Taste rastet nichts ein. Strg+Z nimmt Verschieben, Größe und Anordnen zurück (in derselben Reihenfolge wie Änderungen an Jobs), Strg+Y holt es wieder; das Kontextmenü der Fläche nennt, was zurückgenommen würde.

Die erste Linie aus einer Sicherung in einen Job fragt, ob er nach dem Eingang laufen soll (Job) oder schon während des Eingangs (On the Fly). Unter „Aktion“ verbindet eine Linie „von Hand“ eine Sicherung mit einer Aktion (backup=); sie startet dadurch nicht von selbst. Jede Ansicht – Bereich und Filter – merkt sich ihre eigene Anordnung. An einer Sicherung in der Grafik steht „Ungeprüft“, wenn sie lange nicht geprüft wurde, und ein Hinweis, wenn ihr Kunde bei Fehlern eine Mail bekommt. Ihr Kontextmenü legt eine Aktion aus einer Vorlage an, „Gleiche Jobs auch für …“ überträgt Jobs auf weitere Sicherungen, dazu Prüfen, Bereinigen (Vorschau), Aufbewahrung und eine Notiz.

Änderungen sammeln. Was in der Grafik geändert wird (Linien, Bausteine, Deaktivieren, Löschen), gilt erst nach „Übernehmen…“: bis dahin sind neue und geänderte Jobs gestrichelt und mit „neu“ bzw. „geändert“ beschriftet, Strg+Z und Strg+Y nehmen Schritte zurück und wieder vor. „Übernehmen…“ zeigt jede Zeile vorher und nachher und schreibt alles in einem Zug (POST /sched/batch); hat jemand anderes die Jobs inzwischen geändert, sagt die Konsole das, statt etwas zu überschreiben. „Verwerfen“ lässt alles beim Alten; beim Verlassen der Grafik, beim Wechsel des Servers und beim Beenden fragt die Konsole nach. Dialoge (Job, Ablauf, Aktion, On the Fly, Ziele) speichern wie bisher sofort.

Bausteine. Die Liste „Bausteine“ links bietet Prüfen, Bereinigen, Prüf-Restore, Spiegeln, Exportieren, Programm, die vier On-the-Fly-Arten und ein Ziel an; auf eine Sicherung oder einen Job gezogen (oder mit Enter) entsteht ein passender Job dahinter. „Empfohlene Absicherung“ im Kontextmenü einer Sicherung legt in einem Schritt an, was jede Sicherung haben sollte: eine Prüfung nach jedem Eingang, ein wöchentliches Prüf-Restore mit Aufräumen danach und – wenn das Target Mails verschickt – eine Mail bei Fehlern; mit mehreren markierten Sicherungen für alle.

Übersicht behalten. Mehrere Jobs und Sicherungen markiert man mit Strg+Klick, mit einem Rahmen bei gedrückter Strg- oder Umschalttaste oder mit Strg+A; sie lassen sich gemeinsam verschieben und deaktivieren oder aktivieren (Leertaste, deaktivierte tragen „deaktiviert“). Die Sicherungen eines Kunden stehen in einem Rahmen; ein Klick auf seinen Titel klappt ihn zu einem Eintrag mit Zusammenfassung zusammen. Am Titel oder an der Rahmenlinie gezogen, wandert der ganze Kunde mit; ein zugeklappter Eintrag nimmt beim Verschieben alles mit, was er zusammenfasst. Was die Konsole selbst platziert (neue Jobs, „In die Grafik“, „Anordnen“), kommt in den Rahmen seines Kunden, ein neuer Kunde außerhalb aller Rahmen; braucht ein Rahmen mehr Platz, rücken die Kunden darunter nach unten. Jeder Job und jede Sicherung trägt ein Symbol seiner Art und als Punktreihe die letzten zehn Ergebnisse; der Tooltip nennt die letzten Läufe, das Kontextmenü öffnet ihre Protokolle. Ist die Grafik deutlich größer als eine große Fläche, zeigt unten rechts eine Übersichtskarte das Ganze (nie über dem gewählten Job); Strg+0 auf der Fläche zeigt alles.

Andockpunkte eines Prüf-Restores. Ein Prüf-Restore, dessen Sicherungen bekannt sind (backup= oder match-backup=), zeigt am rechten Rand je Platte und Partition einen Andockpunkt mit Bezeichnung und Dateisystem (etwa „scsi1 · Partition 2 · Daten (xfs)“); der Punkt am Titel steht für alle Platten. Eine Linie von einem Andockpunkt zu einem Prüfschritt setzt dessen --disk und --part; zieht man einen Baustein auf einen Andockpunkt, entsteht der Schritt gleich für diese Partition. Ausgegraut sind Partitionen, die sich nicht prüfen lassen (verschlüsselt, Swap, leer). „Dateisystem durchlaufen“ (Dateien zählen und lesen) hängt hinter „Dateisystem einbinden“ oder direkt an einer Partition von „Dateisystem prüfen“ und bindet sie dann selbst ein; „Optionen…“ im Kontextmenü (oder im Job-Dialog) zeigt jede Einstellung des Zählens in einem Fenster: Einhängeordner und Trennen am Ende, Lesen mit Verfahren, Vergleich, Stichprobe, Höchstmenge und schonendem Lesen, die Prüfungen und was ausgelassen wird. Folgen einem Schritt weitere Prüfungen derselben Partition (prüfen → einhängen → zählen), stehen sie als Zweig nebeneinander; das Aufräumen hängt an allen Zweigen. „Prüfkette vollständig anlegen…“ im Kontextmenü des Prüf-Restores ergänzt nach Rückfrage in einem Zug, was noch fehlt: je Platte die Prüfung der Dateisysteme, je Partition Einhängen und Zählen, für VMs den Start und am Ende das Aufräumen. Linien laufen in weichen Bögen um Jobs und Sicherungen herum, nie durch sie hindurch; steigt oder fällt eine Linie, verlässt sie Job oder Sicherung waagerecht (dort steht ihre Beschriftung) und biegt erst kurz vor ihrem Ziel ab. Mehrere Linien derselben Art in denselben Job (etwa „nach Abschluss“ aus allen Zweigen in „Dateisystem trennen“) laufen vor ihm zu einer Sammellinie mit einer Beschriftung zusammen; eine Beschriftung, die nicht in die Lücke vor der Pfeilspitze passt, steht dort auf mehreren Zeilen.

Prüfketten im Blick. Wird ein Prüf-Restore auf eine Sicherung gezogen, fragt die Konsole, ob gleich die vollständige Prüfkette entstehen soll (empfohlen, mit der Anzahl der Jobs) oder nur der Prüf-Restore. Die Kette steht als Tabelle: je Partition eine Zeile mit „Dateisystem prüfen“, „Dateisystem einbinden“ und „Dateisystem durchlaufen“, darunter die VMs, rechts „Dateisystem trennen“ und „Aufräumen“; „Prüfkette neu anordnen“ im Kontextmenü ordnet eine bestehende Kette so (Strg+Z stellt die vorige Anordnung wieder her).

• Ampel an den Punkten: Jeder Andockpunkt zeigt das letzte Ergebnis seines Schritts – Haken (bestanden), Kreuz (Befund), Kreis (übersprungen) –, der Tooltip nennt den Befund. Unter den Punkten des Prüf-Restores steht das Urteil des letzten Prüfberichts, etwa „Bestanden am 28.10. · 5 von 5 geprüft“. Gezählt werden Dateisysteme; Swap und leere Partitionen zählen nicht mit. Ist ein Schritt der Kette fehlgeschlagen oder abgebrochen worden (etwa ein VM-Start), lautet das Urteil „nicht bestanden“ und nennt diesen Schritt („Schritt „VMs starten“ fehlgeschlagen“), auch wenn alle Dateisysteme in Ordnung waren.
• Fortschritt: Läuft eine Kette, zeigt der Prüf-Restore „Prüfkette: 3 von 7 Schritten“ mit Balken; Linien zu laufenden Jobs bewegen sich (nicht bei hohem Kontrast oder abgeschalteten Animationen von Windows).
• Weg hervorheben: Ein gewählter Job oder eine Sicherung – oder einer, auf dem die Maus kurz ruht – hebt seinen Weg von der Sicherung bis zum Ende der Kette hervor, der Rest wird blass. Esc oder ein Klick ins Leere hebt das auf.
• Zuklappen: Das Zeichen „−“ am Titel des Prüf-Restores (oder „Prüfkette zuklappen“) macht die ganze Kette zu einem Kasten mit der Tabelle des letzten Prüfberichts: je Platte, Partition und VM eine Zeile, je Prüfung eine Spalte. Ein Doppelklick auf eine Zelle öffnet ihren Job, „+“ oder Enter klappt die Kette wieder auf. Die Konsole merkt sich das je Kette.
• Hinweise mit Aktion: Ein „!“ vor einem Punkt heißt: neu in der letzten Sicherung, noch nicht geprüft. Ein Klick darauf oder „Prüfung ergänzen“ legt die fehlenden Schritte an und hängt sie an „Dateisystem trennen“. Fehlt eine Platte oder Partition in der letzten Sicherung, entfernt „Schritte entfernen“ ihren Zweig nach Rückfrage.

Hinweise beim Planen. Die Konsole prüft die Grafik bei jeder Änderung und kennzeichnet betroffene Jobs und Sicherungen mit „Hinweis“; der Tooltip sagt, worum es geht, die Infozeile nennt die Anzahl. Hingewiesen wird auf mehr gleichzeitige Läufe, als parallel-jobs erlaubt, auf einen Prüf-Restore, der größer ist als der freie Platz des Targets, auf eine Kette mit einem deaktivierten Glied (die Schritte dahinter laufen nie), auf eine Sicherung, die überfällig ist, und auf einen On-the-Fly-Schritt ohne sein Ziel.

Was passiert, wenn sie eingeht? Dieser Eintrag im Kontextmenü einer Sicherung (Grafik oder Liste) fragt das Target, was ein erfolgreicher Eingang auslösen würde. Die Grafik markiert die Kette, die starten würde; ein Fenster nennt jeden Job mit Grund – auch die, die nicht starten, und warum (deaktiviert, anderer Filter, anderer Zeitpunkt der Sicherung, wartet auf etwas, On the Fly wirkt noch nicht).

15.7.5 Zeitachse#

Die „Zeitachse“ zeigt die nächsten 24 Stunden oder 7 Tage: je Job eine Zeile mit seinen geplanten Starts als Balken (so lang wie seine letzten Läufe), je Sicherung die erwarteten Eingänge als Rauten (aus den bisherigen Abständen). Wo mehr Läufe zusammenfallen, als parallel-jobs erlaubt, ist die Achse rot markiert. Strg+Mausrad zoomt, „Jetzt“ springt zurück an den Anfang und liest neu, ein Doppelklick öffnet den Job.

15.7.6 Aufbau exportieren und importieren#

„Datei“ › „Aufbau exportieren…“ schreibt den Aufbau des gewählten Servers in eine Datei <server>-aufbau-<datum>.json: alle Jobs, Aktionen und On-the-Fly-Schritte, die Ziele ohne ihre Schlüssel, die Anordnung der Grafik mit Notizen und eingeklappten Gruppen. „Aufbau importieren…“ spielt eine solche Datei auf einem anderen Server ein, etwa um ein zweites Rechenzentrum gleich einzurichten. Für jedes Ziel fragt die Konsole, wo dessen Schlüssel auf diesem Server liegt (file: oder kms:); bleibt die Angabe leer, werden das Ziel und die Schritte, die es nutzen, nicht übernommen. Eine Vorschau zeigt vorher, was neu angelegt, was ersetzt (gleicher Name) und was nicht übernommen wird und welche Sicherungen auf diesem Server noch nie eingegangen sind. „Importieren“ schreibt die Ziele und alle Jobs in einem Zug; der Server prüft dabei die ganze Konfiguration und ändert bei einem Fehler nichts. Ein Target, das Aktionen oder On the Fly noch nicht kennt, lehnt den Import mit einem Hinweis auf das nötige Update ab.

15.8 Zugänge, Freigaben, Einstellungen#

Zugänge: „Neu…“ legt einen Key für ein bis acht Verzeichnisse an (kunde1, kunde1/* für die Unterverzeichnisse, kunde1/** für alles darunter, kunde1/*** für kunde1 selbst und alles darunter), auf Wunsch nur zum Lesen. Der Server erzeugt den Key und zeigt ihn einmal an („Kopieren“); in der Zugangsdatei steht nur seine Prüfsumme. Ein geänderter oder gelöschter Zugang gilt sofort; eine laufende Sitzung mit einem gelöschten Key endet. Zugänge aus Freigaben des Lizenzservers zeigt die Spalte „Herkunft“; sie werden beim Abgleich gepflegt, nicht hier.

Freigaben: Ein Target mit hosted.conf stellt Speicher für andere Konten bereit. Die Liste zeigt jede Freigabe mit Konto, Kontingent und Belegung; darunter lässt sich hosted.conf bearbeiten („Speichern“, „Verwerfen“). „Jetzt abgleichen“ holt die Freigaben vom Lizenzserver im Hintergrund.

Einstellungen: Die Liste nennt für jeden Schlüssel von bkp_target.cfg, was in der Datei steht, womit der Dienst gerade läuft, den Standard und ob eine Änderung sofort, nach „Dienst neu laden“ oder erst nach einem Neustart wirkt. „Ändern…“ setzt einen Wert oder entfernt die Zeile („Standard verwenden“); der Server prüft die ganze Datei mit dem neuen Wert und lässt sie bei einem Fehler unverändert.

15.9 E-Mail-Einstellungen#

„Server › E-Mail-Einstellungen…“ (ebenso die Schaltfläche im Fenster „Meldungen“) öffnet alles, was die Mails des Targets bestimmt: den Abschnitt [mail] in bkp_target_sched.cfg, die Kunden in target-customers.cfg und die Berichte. Was die Mails enthalten und wann sie kommen, beschreibt Kapitel 10 („Mails an Betreiber und Kunden“). Ändern dürfen nur Zugänge mit Admin-Recht auf einem Server mit allow-config-write=yes; sonst zeigt der Dialog alles nur an und nennt den Grund. Hat jemand die Datei inzwischen geändert, meldet die Konsole das, statt fremde Änderungen zu überschreiben, und bietet an, neu zu laden.

• Versand: „Benachrichtigungen per E-Mail versenden“ schaltet den Abschnitt [mail] ein oder aus. Darunter SMTP-Server, Port, Verschlüsselung, Benutzer, Kennwort, Absender, CA-Datei und Zeitlimit. Das Kennwort zeigt die Konsole nie an: leer lassen behält es, „Kennwort entfernen“ löscht es; steht es in einer Datei (file:), sagt ein Hinweis das. „Verbindung prüfen“ meldet sich beim Mailserver an und prüft Absender und Empfänger, ohne eine Mail zu senden; ein Fehler kommt mit Einordnung (Name, Verbindung, Zertifikat, Anmeldung, Absender oder Empfänger abgelehnt) und nächstem Schritt. „Testmail senden“ schickt eine echte Mail, „Vorlagen prüfen“ prüft die eigenen Vorlagen des Servers.
• Empfänger: die Adressen des Betreibers (höchstens 16), „Antwort an“, wann Jobs ohne eigenes notify= melden, „Ausbleibend nach“ und die Liste aller Mailarten mit Erklärung. Je Art ein Häkchen, ob der Betreiber sie bekommt (operator.<art>=), „Adressen…“ für eigene Adressen nur dieser Art (operator-to.<art>=) und die Wahl „sofort“ oder „in der täglichen Sammelmail“. „Tägliche Sammelmail…“ stellt Uhrzeit und Mailarten der Sammelmail ein, „Erinnerung erneut nach“ den Abstand für Jobs, die weiter scheitern (repeat-after=). Dazu Nachweisbericht (monatlich, wöchentlich, aus) und Verbrauchsbericht (monatlich, aus). „Vorschau…“ zeigt eine Mail der gewählten Art mit Beispielwerten und schickt sie auf Wunsch als Testmail an eine Adresse.
• Kunden: alle Kunden mit Ordnern, Kontakten und Herkunft. Eigene Kunden (Datei) lassen sich anlegen, bearbeiten und löschen; Kunden aus Freigaben kommen vom Lizenzserver und sind nur zu sehen. Der Kundendialog nimmt Kürzel, Name, Sprache, Kontakte (mit technischen und kaufmännischen Mails), „Ausbleibend nach“, den Nachweisbericht und je Mailart, an wen sie geht (Kunde, Betreiber bzw. Partner, beide oder niemand).
• Wer bekommt was?: die Empfänger so, wie der Server sie auflöst – je Mailart die Adressen des Betreibers und je Kunde, mit Filter auf einen Kunden. Ordner der Zugangsliste ohne Kunden stehen gesondert da; über sie bekommt niemand außer dem Betreiber eine Mail.
• Warteschlange: Mails, die noch nicht zugestellt sind oder aufgegeben wurden, mit Versuchen und letztem Fehler; „Erneut versuchen“ oder „Verwerfen“.
• Verlauf: jede zugestellte oder aufgegebene Mail der letzten 13 Monate (Zeit, Art, Kunde, Empfänger, Betreff, Ergebnis), mit Filtern und „Exportieren…“ als CSV. Der Mailtext wird nicht aufbewahrt.

Ordner im Kundendialog: Die Liste unter „Ordner“ zeigt alle Ordner der Zugangsliste des Servers mit dem Zugang, zu dem sie gehören, und dem Kunden, der den Ordner schon hat. Ein Häkchen trägt den Ordner in das Textfeld darunter ein; dort lassen sich auch Unterordner und Muster wie mueller/** eintippen, und die Häkchen folgen dem Text. Gehört ein Ordner schon einem anderen eigenen Kunden, nennt die Konsole ihn in Rot und lässt „OK“ ausgegraut, denn jeder Ordner darf nur einem Kunden gehören. Ordner legt der Dialog nicht an.

Auf andere Server übertragen: „Auf andere Server übertragen…“ kopiert die Einstellungen auf weitere Server der Konsole: die Server (oder ganze Gruppen) ankreuzen und wählen, was mitgeht – Versand, Empfänger und Mailarten mit Sammelmail und Erinnerungen, Kunden. Ungespeicherte Änderungen speichert die Konsole vorher. Das Kennwort wird nie übertragen; fehlt es auf einem Ziel, sagt das Ergebnis, dass es dort noch einzutragen ist. Pfade wie die CA-Datei bleiben auf dem Ziel, wie sie sind, Kunden aus Freigaben und die Berichte werden nicht übertragen. Die Liste nennt je Server, ob es geklappt hat, ob er nur lesen darf, ob er inzwischen geändert wurde oder nicht erreichbar war.

Welche Mailart standardmäßig an wen geht (Spalte „Betreiber“: das Häkchen im Reiter „Empfänger“; Spalte „Kunde“: der Weg im Kundendialog):

Immer an den Betreiber, auch wenn alle Häkchen fehlen: Testmails, Probleme mit dem Nachweis-Log und fehlerhafte Vorlagen.

15.10 Verlauf#

Der Verlauf beruht auf den Aufzeichnungen des Servers: Läuft bkp_target mit der Parameterdatei bkp_target.cfg, schreibt sein Scheduler-Prozess jede Sicherung, jedes Ende eines Scheduler-Jobs und einmal am Tag die Belegung jedes Stores, des Dateisystems und der Kontingente nach /var/lib/bkp_target/history/ (abschalten mit history=no, Aufbewahrung history-months=, Standard 24 Monate). Die Zahlen beginnen mit dem Einschalten. „Bereich“ wählt das ganze Target oder eine Gruppe (Kunde, Freigabe), „Zeitraum“ die letzten 30, 90 oder 180 Tage, das letzte Jahr oder zwei Jahre.

• Kennzahlen: Belegung, Wachstum pro Tag, „Voll am …“ (lineare Fortschreibung über den gewählten Zeitraum, braucht Messungen an mindestens 3 Tagen; die Übersicht rechnet mit den letzten 30 Tagen), Sicherungen nach Ergebnis.
• Diagramme: Belegung im Dateisystem und durch Sicherungen, Sicherungen je Tag nach Ergebnis, übertragene und neu gespeicherte Daten, Durchsatz. Ein Fadenkreuz mit Tooltip zeigt die Werte des Tages unter der Maus.
• Überfällige Sicherungen: Sicherungen, deren letzter Erfolg länger zurückliegt als das Doppelte ihres üblichen Abstands (geschätzt aus den letzten 12 Sicherungen, mindestens 6 Stunden).
• Fehlschläge nach Gruppen und die Scheduler-Jobs mit ihren Ergebnissen im Zeitraum.

15.11 Wenn die Verbindung nicht klappt#