Verwaltungskonsole (Windows)

Zum Inhaltsverzeichnis

bkp_console.exe ist ein Windows-Programm mit Fenster für die tägliche Arbeit mit dem Scheduler bkp_sched. Es verbindet sich über die HTTPS-API mit einem oder mehreren Rechnern, auf denen bkp_sched läuft (Linux und Windows), und zeigt alle Jobs mit ihrem Zustand, die früheren Läufe mit ihren Kennzahlen und die Protokolle, auch live während eines Laufs. Mit einem Admin-Token legt man darüber Jobs an, ändert und löscht sie, startet sie sofort oder bricht einen Lauf ab und pflegt die Einstellungen des Schedulers und den Mailversand. Auf Wunsch richtet sie auch ein, was gesichert wird und wohin: die Profile mit ihren Quellen und die Ziele (Sinks und Backup-Server).

Die Konsole selbst braucht keine Administratorrechte. Was sie darf, bestimmt allein das Token, das der Scheduler ausgegeben hat. Jede Änderung prüft der Scheduler, bevor er sie übernimmt.

14.1 Installation#

Die Konsole ist die Komponente console von aegisgrid-setup.exe (Windows 10 ab Version 2004, Windows 11, Windows Server 2022 und neuer). Im Assistenten Sie gehört unter Windows zur Vorauswahl „Client“, zusammen mit dem Job-Planer. Für einen reinen Verwaltungsarbeitsplatz unter „Benutzerdefiniert“ nur Kern und Verwaltungskonsole ankreuzen. Danach steht im Startmenü unter „AegisGrid“ der Eintrag „AegisGrid Verwaltungskonsole“.

ohne Fenster, etwa für die Softwareverteilung

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

Ist auf demselben Rechner der Job-Planer installiert, richtet das Setup die Verbindung gleich mit ein (Seite „Verwaltungskonsole“): Die Konsole zeigt beim nächsten Start „Dieser Computer“ (localhost) verbunden, mit dem bestätigten Fingerabdruck und einem eigenen Token. Mit der Auswahl „Jobs, Ziele und Profile ändern, Jobs steuern“ ist es ein Admin-Token, und das Setup erlaubt der API auch Änderungen an Zielen und Profilen (Abschnitt „Den Scheduler vorbereiten“); „Alles nur ansehen“ gibt ein Lese-Token aus. Das Token liegt bis dahin in C:\ProgramData\AegisGrid\konsole\, nur für diesen Benutzer lesbar; die Konsole übernimmt es verschlüsselt und löscht die Datei. Ein erneuter Setup-Lauf stellt das Token neu aus; die Konsole übernimmt es bei ihrem nächsten Start. Die folgenden Abschnitte braucht es dann nur für weitere Rechner.

14.2 Scheduler für andere Konsolen freigeben#

Laufen bei einem Kunden mehrere Rechner mit Job-Planer, muss nicht jede Konsole jeden Scheduler von Hand eintragen. Ein Scheduler lässt sich freigeben: Dann bekommen ihn die Verwaltungskonsolen aller anderen Rechner desselben Kontos (Rechner mit Job-Planer und Verwaltungskonsole) von selbst, jede mit einem eigenen Zugang. Rechner anderer Konten bekommen ihn nicht, auch nicht die eines betreuenden Partners; dort wird er bei Bedarf von Hand eingetragen.

Freigeben lässt sich ein Scheduler in der Konsole unter Scheduler > Für andere Konsolen freigeben... (dafür braucht die Konsole ein Admin-Token), im Setup (Seite „Freigabe für andere Rechner“ bzw. --console-release) oder auf dem Client selbst:

bkp_sched api-release read                     nur ansehen
bkp_sched api-release admin                    ändern und steuern
bkp_sched api-release --address srv1.firma.lan  wie die anderen Rechner ihn erreichen
bkp_sched api-release off                      Freigabe beenden
bkp_sched api-release                          was freigegeben ist und für wen

• Nur ansehen oder ändern und steuern gilt für alle Rechner der Freigabe gleich. Im Zweifel „nur ansehen“ wählen.
• Erreichbar unter: der Name oder die Adresse, unter der die anderen Rechner diesen erreichen (bis zu vier, durch Komma getrennt; die Konsole versucht sie der Reihe nach). Leer gilt der DNS-Name des Rechners. Der Port ist der der API (Standard 8447); eine Firewall muss ihn zulassen (unter Windows richtet das Setup die Regel ein).
• Der Weg läuft über den Standortserver des Kontos (Kapitel „Standortserver“): Der Scheduler meldet die Freigabe beim stündlichen Abgleich, erzeugt für jeden Rechner ein eigenes Token (lic-<Installation> in der Token-Datei, bkp_sched api-token list zeigt, für welchen Rechner) und gibt es verschlüsselt für genau diesen Rechner weiter. Der Standortserver sieht die Tokens nie. Die anderen Rechner bekommen den Scheduler nach ihrem nächsten Abgleich, spätestens nach etwa zwei Stunden; „Jetzt abgleichen“ im Dialog beschleunigt das auf dieser Seite.
• Der Dialog zeigt unter „Stand“, für welche Rechner die Freigabe gerade gilt.
• Ende: „Diesen Scheduler freigeben“ abwählen (oder api-release off). Die Tokens der anderen Rechner sind sofort ungültig; ihre Konsolen nehmen den Scheduler nach dem nächsten Abgleich aus der Liste.

In der Konsole eines Rechners, für den Scheduler freigegeben sind, erscheinen diese von selbst in der Liste (die Statusleiste sagt es). Unter Datei > Scheduler bearbeiten lässt sich bei ihnen nur der Anzeigename ändern; Adresse, Zertifikat und Token hält die Konsole selbst aktuell. Scheduler entfernen blendet einen freigegebenen Scheduler aus; Datei > Ausgeblendete Scheduler wieder anzeigen holt ihn zurück. Dafür muss die Konsole mit dem Scheduler ihres eigenen Rechners („Dieser Computer“) mit einem Admin-Token verbunden sein, denn sie erfährt die Freigaben über ihn.

14.3 Den Scheduler vorbereiten#

Unter Windows schaltet bkp_setup die API ein (auch in einer vorhandenen bkp_sched.cfg ohne enabled; ein ausdrückliches enabled=no bleibt). Unter Linux ist sie ab Werk aus. Auf jedem Rechner, den die Konsole verwalten soll, wird sie einmal eingerichtet (Linux als root, Windows in einer Administrator-Eingabeaufforderung):

1. Zertifikat anlegen. Das hat bkp_setup bei der Installation des Schedulers schon erledigt; ein vorhandenes Zertifikat lässt api-init unverändert.
2. Den Abschnitt [api] in bkp_sched.cfg eintragen (Linux /etc/bkp/, Windows C:\ProgramData\AegisGrid\). bkp_setup --enable-sched-api (Linux) schreibt ihn gleich mit, wenn es die Datei neu anlegt; bkp_sched api-enable schaltet ihn in einer vorhandenen Datei ein. Der Dienst übernimmt Änderungen an [api] ohne Neustart.
3. Ein Token für die Konsole erzeugen. Es wird nur einmal angezeigt.
4. Mit api-info Adresse und Fingerabdruck des Zertifikats ablesen; beides braucht die Konsole.

bkp_sched api-init
bkp_sched api-token add konsole-admin --role admin
bkp_sched api-info

bkp_sched.cfg: API auf allen Adressen, Port 8447

[api]
enabled=yes
listen=0.0.0.0:8447

Unter Windows legt bkp_setup für bkp_sched_net.exe eine Firewall-Regel an. Unter Linux den Port 8447/TCP nur für die Netze der Administratoren öffnen. Weitere Einschränkungen im Abschnitt [api], etwa welche Befehle die API anlegen und starten darf (allowed-commands), ob sie die Konfiguration überhaupt ändern darf (allow-config-write) und ob sie Parameter setzen darf (allow-args), beschreibt docs/sched-api.txt (Abschnitt 2.3).

Ziele, Sinks und Profile (sinks.cfg und bkp_agent.cfg) darf die API nur ändern, wenn [api] allow-agent-config-write=yes gesetzt ist; ab Werk ist das aus. Ohne diesen Schalter zeigt die Konsole Ziele und Profile nur an. Das Windows-Setup setzt ihn, wenn es die Konsole mit „Dieser Computer“ und der Rolle zum Ändern verbindet (ein ausdrückliches no in bkp_sched.cfg bleibt). Von Hand schaltet ihn bkp_sched api-enable --agent-config-write ein, oder man trägt ihn ein:

bkp_sched.cfg: Ziele und Profile über die Konsole ändern

[api]
enabled=yes
allow-agent-config-write=yes

14.4 Einen Scheduler hinzufügen#

„Datei“ › „Scheduler hinzufügen…“ öffnet den Dialog für die Verbindung:

„Verbindung testen“ prüft Zertifikat und Token, bevor der Scheduler gespeichert wird. Die Konsole verbindet sich nie ohne diese Prüfung: Legt der Scheduler ein anderes Zertifikat vor, trennt sie die Verbindung, bevor sie Daten sendet, und zeigt den vorgelegten Fingerabdruck. Das passiert auch, wenn das Zertifikat auf dem Client neu erzeugt wurde (api-init --force); dann den neuen Fingerabdruck mit api-info vergleichen und unter „Scheduler bearbeiten…“ übernehmen.

Die Liste der Scheduler steht in %APPDATA%\AegisGrid\console.cfg. Die Tokens darin sind mit DPAPI für das Windows-Konto verschlüsselt, das sie eingetragen hat; ein anderes Konto oder ein anderer Rechner kann sie nicht lesen. „Scheduler entfernen“ vergisst Adresse und Token nur in der Konsole, beim Scheduler ändert sich nichts.

14.5 Hilfe in den Dialogen#

Jeder Dialog der Konsole hat über den Knöpfen eine Hilfezeile mit einem Info-Zeichen. Sie erklärt in ein, zwei Sätzen das Feld, in dem gerade der Cursor steht, auch wenn man es mit der Tab-Taste erreicht; steht der Cursor nirgends, beschreibt sie den Dialog als Ganzes. In Assistenten nennt sie zu jeder Seite, worum es dort geht.

Ist ein Feld oder Knopf ausgegraut, zeigt ein Tooltip beim Zeigen mit der Maus den Grund, z. B. „Zuerst eine Regel auswählen.“ oder „Der Lizenzserver verwaltet Adresse, Zertifikat und Token.“. Ist ein Dialog nur zum Ansehen geöffnet (Token mit der Rolle read, vom Lizenzserver verwaltete Einträge), sagen die Tooltips das ebenso. Knöpfe, die nur ein Zeichen tragen (‹ › für Monat oder Jahr), haben einen Tooltip mit ihrer Bedeutung.

F1 öffnet dieses Handbuch im Browser beim Abschnitt zum offenen Dialog, im Hauptfenster bei seiner Beschreibung (ohne Verbindung beim Abschnitt „Wenn die Verbindung nicht klappt“). Dasselbe tut „Hilfe“ › „Handbuch“. In der Target-Konsole und im Setup gilt das ebenso; die Target-Konsole springt zum Abschnitt des gewählten Reiters, das Setup zu dem der gezeigten Seite.

14.6 Das Hauptfenster#

Links stehen die Scheduler. Das Zeichen davor fasst ihren Zustand zusammen: grün alles in Ordnung, blau, solange ein Job läuft, ein Warndreieck, wenn der letzte Lauf eines aktiven Jobs fehlgeschlagen oder nur teilweise erfolgreich war oder die Lizenz keine neuen Sicherungen zulässt, rot, wenn keine Verbindung besteht. Rechts zeigt die Kopfzeile Rechnername, Version des Schedulers, Token und Rolle, darunter die Jobs des gewählten Schedulers. Ein gewählter Job zeigt unten seine Läufe.

Hat der Scheduler eine Testversion oder einen Hinweis zur Lizenz, steht der Satz dazu unter der Kopfzeile: grau die Restlaufzeit des Testzeitraums, braun ein Hinweis (z. B. Ende in wenigen Tagen, Erneuerung fehlgeschlagen), rot, wenn neue Sicherungen angehalten sind, jeweils mit dem nächsten Schritt (Kapitel „Automatische Updates“, Abschnitt „Testversion und Lizenz“). Hat eine Testversion einen Job nicht gestartet, weil seine neuen Rechner, VMs oder M365-Benutzer über die Punkte gegangen wären, steht braun darunter „Nicht gestartet (Zeitpunkt): …“ mit Grund und nächstem Schritt, solange ein Job „Nicht gestartet (Lizenz)“ zeigt.

Die Läufe zeigen Start, Art (vollständig oder inkrementell), Dauer, übertragene und neu gespeicherte Daten, die Aufbewahrung und das Ergebnis. Die Konsole fragt die Scheduler regelmäßig ab und verbindet sich nach einer Unterbrechung selbst wieder; F5 aktualisiert sofort. Ein Rechtsklick öffnet die passenden Befehle für Scheduler, Job oder Lauf.

Die Spalte Aufbewahrung sagt bei Sicherungsjobs, wie lange die Speicherorte jeden Lauf behalten. Der Scheduler liest dafür die Stores der Ziele des Jobs im Hintergrund, auch die auf einem bkp_target; das dauert einige Sekunden („Wird ermittelt …“), F5 liest sie sofort neu.

Unterscheiden sich die Ziele, stehen die Abweichungen in Klammern dahinter.

14.6.1 Aufbewahrung einer Sicherung ändern#

Rechtsklick auf einen Lauf, Aufbewahrung ändern … (nur mit einem Token der Rolle admin und bei Läufen, die eine Sicherung gespeichert haben). Der Dialog zeigt jede Kopie der Sicherung mit ihrer bisherigen Aufbewahrung. Unter „Neu aufbewahren“ eine Dauer in Tagen, Wochen, Monaten oder Jahren oder „Für immer“ wählen und Ändern; die neue Aufbewahrung zählt ab dem Zeitpunkt der Sicherung. Der Scheduler prüft erst jede Kopie und ändert nichts, wenn eine ablehnt; danach steht in der Liste das Ergebnis je Speicherort.

Ein Scheduler erlaubt von sich aus nur eine längere Aufbewahrung. Kürzer geht in seinen eigenen Ordnern erst mit allow-shorter-retention=yes im Abschnitt [api] von bkp_sched.cfg; die Konsole fragt dann vorher nach, denn eine abgelaufene Sicherung löscht der nächste Prune. Ein Target lässt Clients in der Regel nur verlängern (Kapitel „Wartung“, „Vom Client aus ändern“). Unter Linux geht es außerdem mit bkp_maintenance set-retention oder als Job mit dem Befehl „Aufbewahrung ändern (Set-Retention)“.

14.7 Jobs anlegen und ändern#

„Job“ › „Neu…“ (Strg+N) öffnet den Assistenten für neue Jobs (Abschnitt „Assistent für neue Jobs“). „Bearbeiten…“ und ein Doppelklick öffnen den Job-Dialog; er entspricht einem Abschnitt in bkp_sched.cfg:

Der Scheduler prüft jeden Job, bevor er ihn speichert, und sichert vorher die bisherige Konfiguration (cfg-history). Hat jemand den Job inzwischen auf dem Client oder in einer anderen Konsole geändert, erkennt der Scheduler das und übernimmt nichts ungefragt: Die Konsole fragt, ob Ihre Angaben den neuen Stand ersetzen sollen („Trotzdem speichern“) oder nicht. Das gilt auch für die Einstellungen. Jobs, deren Befehl die API laut [api] allowed-commands nicht ändern darf, öffnen sich nur zum Lesen.

14.8 Zeitplan-Editor#

„Bearbeiten…“ neben dem Zeitplan öffnet den Zeitplan-Editor. Er stellt jeden Zeitplan aus Bausteinen zusammen, ohne dass jemand Cron oder Regeln schreiben muss, und zeigt rechts sofort, was daraus wird: einen Monatskalender mit den Startzeiten je Tag (blätterbar mit ‹ und ›; Feiertage grau mit ihrem Namen als Hinweis, entfallende Termine durchgestrichen, verschobene mit Pfeil, ausgelassene Tage schraffiert), die nächsten 20 Starts und den Zeitplan in einem Satz. Die Vorschau rechnet die Konsole mit demselben Programmteil wie der Dienst; beim „OK“ prüft der Scheduler den Zeitplan noch einmal und ist maßgeblich.

Der Editor schreibt eine Cron-Zeile, wo sie reicht, sonst eine Regel nach RFC 5545. Angaben, die er nicht als Baustein zeigen kann, verändert er nie; nicht geänderte Bausteine behalten ihre Zeilen genau so, wie sie waren. Strg+Tab wechselt die Reiter. Mit einem Lese-Token öffnet sich alles nur zum Ansehen.

14.8.1 Feiertagskalender#

„Scheduler“ › „Feiertagskalender…“ (oder „Kalender…“ im Zeitplan-Editor) zeigt links die eigenen Kalender des Schedulers und die eingebauten, rechts das gewählte Jahr. Bei einem eigenen Kalender nimmt ein Klick (oder die Leertaste) einen Tag auf oder heraus; dunkel sind die Tage des Kalenders, hell die aus eingebundenen Kalendern. Unter dem Jahr stehen die Einträge: „Hinzufügen…“ für einen Tag oder Zeitraum mit Bezeichnung, einen Tag in jedem Jahr oder einen anderen Kalender, der dazugehört (etwa die Feiertage eines Landes), „ICS-Datei…“ übernimmt die ganztägigen Termine einer iCalendar-Datei (Termine mit Uhrzeit nennt die Konsole und lässt sie aus). „Speichern“ überträgt den Kalender; der Scheduler prüft ihn und nutzt ihn sofort in allen Zeitplänen. „Neu…“ legt einen Kalender an (Name aus Kleinbuchstaben, Ziffern, - und _), „Löschen“ entfernt ihn, solange ihn kein Job und kein anderer Kalender nennt. Eingebaute Kalender lassen sich nur ansehen; ihre Feiertage des Jahres stehen als Einträge darunter.

14.9 Ziele und Profile#

Was eine Sicherung liest und wohin sie schreibt, steht nicht im Job, sondern in seinem Profil (ein Abschnitt in bkp_agent.cfg, Kapitel 4). Die Ziele stehen in sinks.cfg neben bkp_agent.cfg (Linux /etc/bkp/, Windows C:\ProgramData\AegisGrid\): Sinks ([sink:<name>], ein Store in einem Ordner oder auf einem Backup-Server) und Backup-Server ([targets]). Beides pflegt die Konsole im Menü „Scheduler“, sobald der Scheduler es erlaubt (allow-agent-config-write=yes, Abschnitt „Den Scheduler vorbereiten“). Ohne diesen Schalter oder mit einem Lese-Token öffnen sich die Fenster nur zum Ansehen; bei einem älteren Scheduler sind die Menüpunkte ausgegraut.

14.9.1 Ziele (Sinks)#

„Scheduler“ › „Ziele (Sinks)…“ zeigt die Sinks und die Backup-Server des Schedulers mit der Spalte „Benutzt von“. Mit „Neu…“, „Bearbeiten…“ und „Löschen“ werden sie gepflegt:

Einen erzeugten Schlüssel legt der Scheduler als Datei keys/<Sink>.key neben bkp_agent.cfg ab. Die Konsole zeigt ihn genau einmal im Fenster „Schlüssel aufbewahren“; dort „Kopieren“ oder „Speichern unter…“ wählen und ihn getrennt vom Client aufbewahren. Danach gibt der Scheduler Schlüssel nie wieder heraus, auch keine API-Schlüssel; beim Bearbeiten bleibt ein leeres Feld beim gespeicherten Schlüssel. Schlüsseldateien überschreibt oder löscht der Scheduler nie.

Ein Backup-Server hat Name, Adresse und Port (Standard 9990) und das CA-Zertifikat, mit dem der Agent den Backup-Server prüft: entweder als PEM-Datei von diesem Computer (die Konsole lädt sie hoch, der Scheduler legt sie unter ca/ neben bkp_agent.cfg ab) oder als Pfad einer Datei, die schon auf dem Client liegt.

Löschen entfernt nur den Eintrag aus sinks.cfg; Store, Sicherungen und Schlüsseldatei bleiben. Wird ein Sink oder Backup-Server noch benutzt, nennt die Konsole, wer ihn braucht (Profile, Sinks, bkp_proxmox.cfg, bkp_xenv.cfg, bkp_m365.cfg), und löscht nichts. Einträge, die direkt in bkp_agent.cfg stehen, lassen sich nur dort von Hand ändern.

Targets über den Lizenzserver (Abschnitte „Target für andere Konten freigeben“ und „Target im eigenen Konto verteilen“, Kapitel 23) stehen in derselben Liste. Die Spalte „Speicherort“ nennt, woher sie kommen: „Freigabe von <Betreiber>“, „Eigenes Target „<Name>““ oder „Beendete Freigabe von …“. Sie stehen in sinks.hosted.cfg und lassen sich nicht löschen. Fest vorgegeben sind nur Adresse, Zertifikat, Verzeichnis und API-Schlüssel; der Backup-Server selbst zeigt deshalb nur „Anzeigen…“. Beim Sink öffnet „Bearbeiten…“ den Sink-Dialog mit gesperrtem Speicherort: Verschlüsselung, Schlüssel und „Die Sicherung scheitert, wenn dieser Sink scheitert“ sind frei (z. B. „Keine“ statt der Vorgabe AES-256-GCM, solange der Store noch nicht angelegt ist). Gespeichert wird das als Abschnitt gleichen Namens in sinks.cfg, den der Abgleich nie anrührt; „Vorgaben wiederherstellen“ entfernt ihn wieder. „Freigabe…“ zeigt Backup-Server, Betreiber, Zustand, die Belegung aller Rechner des Kontos mit dem Kontingent („1,9 TB von 2,0 TB belegt“, ab 90 % gelb, voll rot) und die Schlüsseldatei auf dem Scheduler. Diesen Schlüssel hat nur dieser Client, auch der Betreiber des Targets nicht: die Datei getrennt vom Client aufbewahren. Der Sink einer beendeten Freigabe lässt sich nur noch anzeigen.

Im selben Fenster steht der Bereich „Gruppe“: in welcher Gruppe der Rechner ist, mit Mitgliedern, Belegung und Ersparnis, und die Knöpfe „Beitreten…“ bzw. „Ändern…“, „Verlassen“, „Neuer Schlüssel“ und „Schlüssel sichern…“ (nur mit einem Token der Rolle admin). Beim Sink <sink>-vorher übernimmt „In die Gruppe übernehmen…“ die älteren Sicherungen. Einzelheiten im Abschnitt „Gruppen“ (Kapitel 23).

Eigene Sinks auf einem freigegebenen Backup-Server: „Sink auf diesem Backup-Server anlegen…“ im Fenster des Backup-Servers, oder „Neu…“ und den Backup-Server in der Liste wählen („<Name> (Freigabe von <Betreiber>)“). Die Konsole schlägt ein eigenes Verzeichnis unter dem der Freigabe vor (hosted/<Freigabe>/<Installations-ID>-<Sinkname>) und verwendet den API-Schlüssel der Freigabe; Verschlüsselung und alles Übrige wählt man wie bei jedem Sink. So sichert ein Profil z. B. unverschlüsselt oder mit eigener Aufbewahrung auf dasselbe Target. Das Verzeichnis muss unter dem der Freigabe liegen (nur dort darf das Konto schreiben) und darf sich nicht mit dem eines anderen Sinks überschneiden. Endet die Freigabe, gilt das auch für diese Sinks.

Der Scheduler gleicht die Ziele stündlich mit dem Lizenzserver ab. „Jetzt abgleichen“ unten im Fenster holt neue, geänderte und beendete Freigaben sofort (Token der Rolle admin; die Installation muss freigeschaltet sein). Daneben steht, wann zuletzt abgeglichen wurde; scheitert ein Abgleich, steht der Grund auf dem Client in sync.log im Lizenzverzeichnis. Ein Profil, das einen Sink einer beendeten Freigabe nennt, zeigt im Profil-Dialog einen Hinweis.

14.9.2 Profile und Quellen#

„Scheduler“ › „Profile…“ zeigt die Profile mit Quelle (in Worten), Ziel und den Jobs, die sie benutzen. Der Profil-Dialog hat drei Teile:

• Name des Profils (bis 63 Zeichen). Er ist zugleich der Name der Sicherung (--name, Kapitel 4).
• Quelle: die Platten und Volumes des Clients (Windows: Laufwerksbuchstaben; Linux: Partitionen und logische Volumes), so wie der Scheduler sie gerade meldet, mit Größe und einer Spalte „Hinweis“, etwa welches Profil die Quelle schon sichert. Ganze Platten speichert das Profil mit ihrer festen Kennung, unter Windows disk-id:{…} bzw. disk-id:mbr-…, unter Linux mit ihrem Link in /dev/disk/by-id (ZFS-Volumes mit /dev/zvol/…); so sichert es auch dann die richtige Platte, wenn sich nach einem Neustart die Nummer ändert (Kapitel 5, Abschnitt „Windows: VSS-Schattenkopie“).
• Ziel (Sinks): ein oder mehrere Sinks (höchstens 8); jeder bekommt eine vollständige Sicherung. „Ziele…“ öffnet die Liste der Ziele, etwa um einen Sink anzulegen.

Ein neues Profil aus der Profilliste darf mehrere Quellen haben: Die Konsole legt dann je Quelle ein eigenes Profil mit denselben Sinks an und hängt die Quelle an den Namen (aus server werden etwa server-c und server-disk0). Aus dem Job-Dialog heraus hat ein neues Profil genau eine Quelle. Die Zeile über den Knöpfen sagt vor dem Speichern, was angelegt wird, oder warnt:

Wechselt bei einem Profil, mit dem schon gesichert wurde, die Quelle oder das Ziel, beginnt eine neue Sicherungskette: Der nächste Lauf ist wieder vollständig. Die Konsole erklärt das und speichert erst nach „Neue Kette beginnen“; die bisherigen Sicherungen bleiben erhalten. Wählt man für ein Profil, das bisher direkt in einen Ordner oder auf einen Backup-Server schrieb (out=, target=), Sinks aus, ersetzen diese das alte Ziel.

Ein Profil, das noch ein Job nennt, lässt sich nicht löschen; die Konsole nennt die Jobs. Löschen entfernt nur den Abschnitt aus bkp_agent.cfg; Sicherungen, Index und Schlüssel bleiben. Profile mit * oder ? im Namen gelten für mehrere Jobs und lassen sich nur auf dem Client ändern; Hooks (pre-snapshot, post-snapshot) setzt man ebenfalls nur dort, die Konsole lässt sie beim Speichern unverändert.

Wie bei den Jobs prüft der Scheduler jede Änderung mit dem Parser von bkp_agent, bevor er sie übernimmt, legt die bisherige Fassung im Verlauf ab (cfg-history, sinks-<Zeit>-NNN.cfg bzw. bkp_agent-<Zeit>-NNN.cfg) und meldet geänderte Zeilen per Mail (Schlüssel als ***). Hat jemand die Datei inzwischen geändert, lädt die Konsole den neuen Stand und übernimmt nichts ungefragt.

14.9.3 VM-Profile (Proxmox, Xen, Hyper-V)#

Kann der Scheduler seine VMs auflisten (Linux mit bkp_proxmox oder bkp_xenv, Windows mit bkp_hyperV), hat die Profilliste oben die Auswahl Befehl: Neben „Sicherung (bkp_agent)“ stehen dort die VM-Programme, und die Liste zeigt deren Profile (bkp_proxmox.cfg, bkp_xenv.cfg bzw. bkp_hyperv.cfg). Im Profil-Dialog tritt an die Stelle der Platten die Liste der VMs mit Name, ID, Zustand und „Gesichert von“ (Profile und Jobs):

• Der Profilname wird aus dem VM-Namen vorgeschlagen. Bei Xen ist er fest der Name der Domain; Domains, deren Name kein gültiger Profilname ist, sind ausgegraut und nennen den Grund.
• VMs anderer Knoten eines Proxmox-Clusters sind ausgegraut („wird auf Knoten X gesichert“): Gesichert wird jede VM von dem Knoten, auf dem sie läuft.
• Unter der Liste stehen die Disks der gewählten VM mit Häkchen. Sind alle angehakt, sichert das Profil auch später hinzugefügte Disks (kein disks=); sonst nur die angehakten (disks=scsi0,scsi1).
• Unter Hyper-V speichert die Konsole die VM mit ihrer GUID (vm=), damit ein Umbenennen der VM die Sicherung nicht trennt; ältere Profile mit dem VM-Namen stellt sie beim nächsten Speichern um, ohne neue Kette.

Prüfen speichert das Profil und lässt das Programm einen Trockenlauf machen (--check): VM finden, Disks und Speicher bewerten, Sinks erreichen; gesichert wird nichts. Das Ergebnis steht in der Zeile über den Knöpfen, mit Symbol für OK, Warnung oder Fehler und dem nächsten Schritt (etwa: Gast-Agent in der VM einschalten). Ist eine VM nicht mehr da, zeigt die Profilliste das an, und die Jobliste nennt im Status „VM nicht gefunden“ bzw. „VM auf Knoten X“.

Lässt sich die Liste der VMs gerade nicht ermitteln (etwa ohne Quorum im Cluster), sagt der Dialog das in einem Satz; die Einzelheiten stehen im Protokoll von bkp_sched. In der Statusleiste erscheint nach dem Verbinden ein Hinweis, wenn VMs dieses Clients von keinem eingeschalteten Job gesichert werden („Kein Job sichert 2 VMs.“). Sein Kontextmenü bietet „VM-Sicherung einrichten…“ und „Diesen Hinweis nicht mehr anzeigen“; wieder einschalten lässt er sich im Menü „Scheduler“ › „Hinweis auf ungesicherte VMs“.

14.9.4 Dateiprofile#

Ein Profil mit path= öffnet in der Profilliste den Dialog Dateiprofil. Die Spalte „Quelle“ der Liste zeigt seinen ersten Pfad, bei mehreren „… und N weitere“. Neue Dateiprofile entstehen über den Assistenten (Art „Dateien und Ordner“). Der Dialog hat diese Teile:

• Ordner und Dateien zum Sichern: der Baum des Clients (Windows: die Laufwerke, Linux: ab /), der beim Aufklappen nachlädt. Ein Häkchen an einem Ordner heißt „mit allem darunter“. Nimmt man darunter etwas wieder heraus, schreibt die Konsole dafür eine Zeile exclude= mit dem vollen Pfad; ein Klick auf einen teilweise gewählten Ordner wählt ihn ganz. Das Kontextmenü bietet „Mit allem darunter sichern“, „Nur die Dateien in diesem Ordner“ (<ordner>/*) und „Auslassen“. Ordner auf dem Weg zu gewählten Pfaden klappen von selbst auf. Leertaste setzt und nimmt das Häkchen, die Pfeiltasten klappen auf und zu.
• Ausschließen (eine pro Zeile): die Muster aus „Ausschlüsse“ (Kapitel 9).
• Übliche temporäre Dateien überspringen schaltet die Standardausschlüsse ein oder aus; „Welche?“ zeigt die Liste dieses Clients. Unter Windows kommt Alternative Datenströme hinzu.
• Größe ermitteln zählt Dateien und Bytes der Auswahl auf dem Client, mit „Stopp“ während der Messung. Ändert man die Auswahl, bricht die Messung ab bzw. das Ergebnis gilt als veraltet.
• Ziel (Sinks): mindestens ein Sink; ein Dateiprofil schreibt nicht direkt in einen Ordner oder auf einen Backup-Server (out=, target=).

Die Zeile über den Knöpfen weist darauf hin, wenn ein Linux-Pfad ohne Snapshot gelesen wird. one-file-system= hat keinen Schalter und bleibt, wie es in der Datei steht. Darf die Konsole das Profil nur lesen, ist der Baum bedienbar, alles andere ausgegraut, und nichts wird gespeichert.

14.9.5 Assistent für neue Jobs#

„Job“ › „Neu…“ (Strg+N) führt in drei Schritten durch Quelle, Ziel und Zeitplan. Oben auf der ersten Seite wählt man die Job-Art. Die Liste enthält nur Programme, die der Scheduler kennt und die der Token erlauben, zuerst die Sicherungen, dann Restore, Prüfen und Wartung. Wechselt man die Art, beginnen die Seiten 1 und 2 neu. Wie es weitergeht, hängt von der Art ab:

Die erste Sicherung: Hat ein Scheduler noch keinen Job, zeigt die Konsole statt der leeren Liste „In diesem Scheduler ist noch keine Sicherung eingerichtet.“ und die Schaltfläche „Erste Sicherung einrichten…“; mit --first-run (aus dem Setup) öffnet sie den Assistenten selbst. Er beginnt dann mit der Art Sicherung, hakt die Systemfestplatte an (sonst das Systemvolume), schlägt 30 Tage Aufbewahrung und täglich um 21:00 vor und erklärt, wenn es noch kein Ziel gibt, wie man unter „Ziele…“ mit „Neu…“ eine USB-Festplatte oder einen NAS-Ordner anlegt. Ist die erste Sicherung gelaufen, fragt die Konsole einmal, ob man zur Probe etwas wiederherstellen möchte, und öffnet auf Wunsch „Dateien wiederherstellen“ bzw. „Wiederherstellen“.

Im dritten Schritt wählt man Nach Zeitplan (Cron-Schreibweise, vorbelegt täglich um 03:00) oder Nur von Hand starten; ein solcher Job steht ohne Zeitplan und ausgeschaltet in der Liste und läuft nur mit „Jetzt starten“. Das ist etwa für Restore oder Wartung sinnvoll. Entstehen mehrere Jobs, startet jeder mit diesem Zeitplan, oder sie laufen nacheinander: Der erste startet nach dem Zeitplan, jeder weitere, wenn der vorige beendet ist (auch nach einem Fehler; after-mode=finished). Die Liste darunter zeigt, was angelegt wird. Die Zeile über den Knöpfen sagt auf jeder Seite, was noch fehlt; „Weiter >“ ist erst dann bedienbar.

„Fertig stellen“ legt je Quelle bzw. VM erst das Profil (mit source= bzw. der VM und sinks=) und dann den Job an. Scheitert das unterwegs (etwa weil der Scheduler gerade nicht erreichbar ist), nennt die Konsole, was vollständig angelegt ist, welches Profil ohne Job blieb und was fehlt; das Fehlende legt man erneut mit „Job“ › „Neu…“ bzw. „Scheduler“ › „Profile…“ an. Regeln, Ausnahmen, Feiertage, Hintergrundbetrieb und Fortschrittsfenster ergänzt man danach im Job-Dialog („Bearbeiten…“). Der Hinweis auf ungesicherte VMs in der Statusleiste öffnet über „VM-Sicherung einrichten…“ denselben Assistenten mit vorgewählter VM-Art.

14.10 Starten, abbrechen, Protokolle#

• Jetzt starten (Strg+R) startet den Job sofort, unabhängig vom Zeitplan. Folgen ihm andere Jobs (after=), starten sie danach wie gewohnt.
• Ohne Folgejobs starten startet den Job ebenso, löst aber keinen der Jobs aus, die ihm folgen (wie bkp_sched run <job> --no-after auf dem Client); der nächste Lauf ohne diese Wahl löst sie wieder aus. Der Befehl ist nur bei Jobs mit Folgejobs wählbar und braucht einen Scheduler ab Version 2.0.0-alpha.025.
• Lauf abbrechen… fragt nach und beendet den laufenden Lauf: bkp_agent beendet ihn auf die Anweisung über den Laufkanal selbst (sonst nach 60 Sekunden Strg+Unterbrechen bzw. SIGTERM, Kapitel 4) und verwirft danach die angefangene Sicherung samt Snapshot. Der Lauf erscheint als „Abgebrochen“.
• Protokoll anzeigen (Strg+L) öffnet das Protokoll des gewählten Laufs in einem eigenen Fenster. Bei einem laufenden Job wächst es mit; mit „Neuen Läufen folgen“ springt das Fenster selbst zum nächsten Lauf. „Speichern unter…“ legt das Protokoll als Datei ab.

14.11 Jobs aus- und einschalten#

Ein Job lässt sich aus dem Scheduler nehmen, ohne ihn zu löschen oder seine Einstellungen zu ändern, etwa während eines Umzugs oder einer Wartung. Jobs in der Liste wählen (mit Umschalt- bzw. Strg-Taste auch mehrere) und „Job“ › „Ausschalten…“ (auch im Kontextmenü). Der Dialog „Job ausschalten“ fragt:

Unter den Feldern steht, was mit den Folgejobs geschieht. „Einschalten“ schaltet die gewählten Jobs ohne Rückfrage wieder ein; bei einer gemischten Auswahl stehen beide Befehle im Menü. Danach nennt die Statusleiste das Ergebnis, etwa „„srv-db“ ist ausgeschaltet. Der Folgejob „spiegel“ läuft weiter; „srv-db“ wird übersprungen.“ Beides braucht ein Token der Rolle admin; auch mit allow-config-write=no ist es erlaubt, weil es wie „Jetzt starten“ ein Bedienschritt ist.

Der Hinweis beim Zeigen auf einen ausgeschalteten Job nennt den Grund und seit wann er aus ist. Im Job-Dialog sind ausgeschaltete Vorgänger entsprechend gekennzeichnet, ein Vorgänger ohne eigenen Zeitplan als „(ausgeschaltet, ohne Zeitplan)“: über ihn läuft eine Kette nicht weiter, seine Folgejobs warten, bis er wieder eingeschaltet ist. Ist ein Job länger ausgeschaltet als in den E-Mail-Einstellungen vorgesehen (remind-disabled-days, Standard 7 Tage), erinnert die Statusleiste daran („„srv-db“ ist seit 9 Tagen ausgeschaltet.“) und der Scheduler mailt es den Empfängern, danach wöchentlich.

Auf dem Client selbst geht dasselbe mit bkp_sched; ein laufender Daemon übernimmt die Änderung von selbst, die bisherige Fassung bleibt in cfg-history:

--for 12h|3d|2w oder --until (Ortszeit), --all für alle Jobs, --stop beendet den laufenden Lauf

bkp_sched deactivate srv-db --for 3d --reason "Umzug der Datenbank"
bkp_sched deactivate --profile web1 --until "2026-11-03 08:00" --stop
bkp_sched activate srv-db

In bkp_sched.cfg steht das als enabled=no mit disabled-since=, disabled-until= und disabled-reason=; bkp_sched list zeigt unter dem Job, seit wann und bis wann er aus ist, wann er das nächste Mal übersprungen wird und den Grund. Über die API: POST /jobs/{name}/deactivate bzw. activate (docs/sched-api.txt, 7.36).

14.12 Laufende Sicherungen anhalten#

„Job“ › „Lauf anhalten…“ (auch im Kontextmenü, für einen oder mehrere markierte Jobs) hält eine laufende Sicherung an, statt sie abzubrechen (wie bkp_sched hold auf dem Client, Kapitel 4). Der Dialog fragt nach einem Grund (optional, höchstens 200 Zeichen) und danach, wann es weitergeht: mit dem nächsten regulären Lauf, nach einer Zahl von Minuten, Stunden oder Tagen oder um ein Datum und eine Uhrzeit (Ortszeit). Länger als hold-max (Standard 7 Tage) darf ein Halt nicht dauern; der Dialog nennt die Grenze. Anhalten lassen sich nur Sicherungen (agent, proxmox, xenv, hyperv), kein Prüf-Restore und keine Wiederherstellung.

• Der Job steht danach in der Liste als „Angehalten bis …“, „Angehalten bis zum nächsten Lauf“ oder – bei einem Halt durch das Target – „Vom Target-Administrator angehalten bis …“ bzw. „Angehalten, während das Target neu startet“; sein Lauf erscheint als „Angehalten“. Der Tooltip nennt, seit wann, von wem und warum.
• Halt ändern… steht an derselben Stelle, solange der Job angehalten ist, und setzt eine neue Zeit oder einen neuen Grund.
• Halt aufheben lässt die Sicherung mit ihrem nächsten regulären Lauf fortsetzen; Fortsetzen (Strg+R, an der Stelle von „Jetzt starten“) setzt sie sofort fort und hebt den Halt damit auf.
• Folgejobs (after=) warten, bis die angehaltene Sicherung fertig ist. Mit einem Scheduler vor Version 2.0.0-alpha.042 sind die Befehle ausgegraut.

Nichts geht verloren: Die Fortsetzung ist ein neuer Lauf mit demselben Snapshot, der übertragene Daten über die Deduplizierung nicht noch einmal sendet. Anhalten braucht eine Rolle admin. Nach remind-held-days Tagen (Standard 3) weist die Konsole in der Statusleiste darauf hin, dass ein Job noch angehalten ist.

14.13 Fortschritt und Steuerung laufender Jobs#

Solange ein Job läuft, zeigt das Hauptfenster seinen Fortschritt knapp: die Spalte „Status“ etwa „Läuft – 42 %“ oder „Pausiert – 42 %“, die Zeile des Laufs zusätzlich die geschätzte Restzeit („Läuft – 42 %, noch etwa 12 Min.“) und die schon neu gespeicherten Daten. Über den Läufen stehen ein Fortschrittsbalken, die Restzeit und die Verweise „Pausieren“ bzw. „Fortsetzen“ und „Details“.

„Details“ oder „Job“ › „Fortschritt anzeigen“ (Strg+F) öffnet das Fortschrittsfenster des Jobs: Phase (z. B. „Der Snapshot wird erstellt“), Sicherungsname, Quelle, gelesene und neu gespeicherte Daten, Laufzeit (mit der Zeit, die der Lauf pausiert war) und Restzeit; bei einer Wiederherstellung Ziel und geschriebene Daten, bei einer virtuellen Maschine die gerade gesicherte Disk. Ist der Lauf beendet, zeigt das Fenster sein Ergebnis und wechselt von selbst zum nächsten Lauf des Jobs, sobald er startet.

„Job“ › „Pausieren…“ (Strg+P, auch im Kontextmenü) fragt nach einem Grund (optional, höchstens 200 Zeichen) und danach, wie lange: bis zum Fortsetzen oder für eine Zahl von Minuten, Stunden oder Tagen (höchstens hold-max); danach geht der Lauf von selbst weiter. Der Job steht dann als „Pausiert“ bzw. „Pausiert bis …“ in der Liste, der Tooltip nennt, seit wann, von wem und warum. Fortsetzen (Strg+R, an der Stelle von „Jetzt starten“) setzt einen pausierten Lauf sofort fort. Eine Sicherung, die länger als pause-max (Standard 4 Stunden) bis zum Fortsetzen pausiert, hält der Scheduler an (siehe oben); andere Läufe gehen dann weiter. Mit einem Scheduler vor Version 2.0.0-alpha.043 pausiert der Eintrag „Lauf pausieren“ sofort und ohne Dialog.

Diese Änderungen gelten nur für den laufenden Lauf; der nächste startet wieder so, wie der Job eingestellt ist. Steuern kann nur ein Token mit der Rolle admin. Auch Läufe, die auf dem Client von Hand mit bkp_sched run oder start gestartet wurden, lassen sich steuern; nicht steuerbar sind Programme mit --no-progress, sie lassen sich nur abbrechen. Ein Agent folgt einer Pause erst nach dem Snapshot; eine lange Pause kann einen LVM-Snapshot volllaufen lassen (Kapitel 13).

14.14 Dateien wiederherstellen#

„Job“ › „Dateien wiederherstellen…“ (auch im Kontextmenü eines Jobs) holt Dateien und Ordner aus einer Dateisicherung zurück. Der Scheduler erlaubt Restores über die API Tokens mit der Rolle admin. Ist im Abschnitt [api] von bkp_sched.cfg auf dem Client eine Zeile allowed-commands= gesetzt, die restore nicht nennt, sagt die Konsole, dass diese Zeile das Wiederherstellen sperrt. Das Fenster liest die Sicherungen aus dem ersten Sink des Jobs, der weder out= noch target= ist.

• Sicherung: die Läufe des Jobs in Ortszeit. Ein Lauf, der nicht zu Ende kam oder bei dem Dateien fehlen, ist gekennzeichnet, ebenso einer mit „ungewöhnlichen Änderungen“ (Ransomware-Warnung, Kapitel 9); daneben steht dann, dass man im Zweifel eine ältere Sicherung wählt.
• Ordner links, die Einträge des gewählten Ordners rechts mit Größe und Änderungszeit. Häkchen wählen aus, was zurückkommt; ein Ordner mit allem darunter. Die Zeile unter der Liste zählt die Auswahl.
• Suchen: ein Muster wie *.docx und „Finden“ suchen über alle Sicherungen des Jobs; die Treffer nennen, in wie vielen Sicherungen sie vorkommen. „In der Sicherung anzeigen“ springt zum Treffer.
• Nur Änderungen seit der Sicherung davor zeigt nur, was neu, geändert oder gelöscht ist. Gelöschte Einträge lassen sich nicht anhaken; sie stecken in der Sicherung davor.
• Frühere Versionen… (Kontextmenü einer Datei) listet die verschiedenen Fassungen über alle Sicherungen. „In ihrer Sicherung anzeigen“ wählt den Lauf, „Neben dem Original wiederherstellen“ legt die Fassung mit dem Zeitpunkt im Namen neben die aktuelle Datei.

Unter Wiederherstellen nach wählt man „Den ursprünglichen Ort“ oder „Einen anderen Ordner auf dem Client“ (mit „Durchsuchen…“), dazu, was mit vorhandenen Dateien geschieht: „Vorhandene Datei behalten“, „Ersetzen, wenn sie älter ist“, „Immer ersetzen“ oder „Beide behalten (die wiederhergestellte daneben)“. Vor dem Ersetzen am ursprünglichen Ort fragt die Konsole nach. „Wiederherstellen“ startet auf dem Client den Job <job>-restore (ausgeschaltet, ohne Zeitplan angelegt); „Fortschritt anzeigen“ öffnet sein Fortschrittsfenster, das Ergebnis steht danach in der Laufliste. Läuft schon ein Restore dieses Jobs, wartet man, bis er fertig ist.

Als ZIP speichern… stellt die Auswahl beim Scheduler zu einem Archiv zusammen und speichert es auf diesem Rechner. Als Ordner anzeigen… zeigt die gewählte Sicherung schreibgeschützt als Ordner auf dem Client (Abschnitt „Lauf als Ordner“). Das Fenster „Sicherung als Ordner“ nennt den Pfad, mit „Kopieren“ für die Zwischenablage, „Im Explorer öffnen“ (nur, wenn der Scheduler auf diesem Rechner läuft) und „Ordner entfernen“. Läuft der Scheduler auf diesem Rechner, darf das Windows-Konto, mit dem die Konsole läuft, den Ordner lesen; so öffnet ihn auch der Explorer, der ohne Administratorrechte läuft. In den Volumes einer Platten-Sicherung gelten dabei die gesicherten Berechtigungen: fremde Benutzerprofile bleiben wie auf dem Original verschlossen. Schließt man es, bleibt der Ordner, bis er 60 Minuten nicht benutzt wurde. Fehlt unter Windows das Projected File System, fragt die Konsole „Projected File System auf dem Client einschalten?“; „Einschalten“ richtet es mit Fortschritt ein, danach braucht Windows meist einen Neustart des Clients.

Bei Platten- und VM-Jobs steht über dem Baum die Auswahl Volume: Partitionen und logische Volumes der Sicherung (Abschnitt „Dateien aus Platten- und VM-Sicherungen“). Volumes, die sich auf dem Client nicht lesen lassen (verschlüsselt, kein Dateisystem, ein Linux-Dateisystem auf einem Windows-Client), sind ausgegraut, mit dem Grund dahinter. Dateien aus einem Volume gehen immer in einen Ordner, nicht an den ursprünglichen Ort. „Als Ordner anzeigen…“ zeigt alle lesbaren Volumes des Laufs, je Volume einen schreibgeschützten Ordner im Ordner des Laufs. Für andere Jobs antwortet der Scheduler, dass sie keine Dateisicherung sind. Auf einen anderen Client stellt die Konsole nicht wieder her; dafür ruft man auf diesem Rechner bkp_restore auf (Kapitel 9, „Dateien wiederherstellen“).

14.15 Laufwerk, Platte oder VM wiederherstellen#

Ein Assistent spielt eine Sicherung eines Laufwerks, einer Platte oder einer VM über den Scheduler zurück. Es gibt drei Einstiege: „Scheduler“ › „Wiederherstellen…“ beginnt mit allen Sicherungen auf den Zielen des Clients, „Job“ › „Laufwerk oder VM wiederherstellen…“ (auch im Kontextmenü eines Jobs) mit den Ständen dieses Jobs, und „Diesen Stand wiederherstellen…“ im Kontextmenü der Laufliste mit genau diesem Stand. Wie bei den Dateien braucht es ein Token mit der Rolle admin. Nennt die Zeile allowed-commands= im Abschnitt [api] von bkp_sched.cfg auf dem Client restore (bei einer neuen VM hyperv-restore, proxmox-restore bzw. xenv-restore) nicht, sagt der Assistent das gleich nach der Wahl der Sicherung, und „Weiter“ bleibt aus.

• Sicherung: Name, Art, neuester Stand und Ziel. Eine Datei-Sicherung öffnet stattdessen „Dateien wiederherstellen“. VM-Sicherungen, die nur ein Host anderer Art zurückspielt, fehlen in der Liste; ein Satz darunter nennt ihre Zahl und den passenden Host, ebenso Ziele, die sich nicht lesen ließen.
• Stand: die Läufe der Sicherung, neueste zuerst, mit Ergebnis, Größe und Ziel. Ein Lauf, der nicht zu Ende kam, lässt sich nicht wählen; ein unvollständiger VM-Lauf schon, dann nur mit den Platten, die er enthält.
• Was: die ganze Platte oder ein einzelnes Volume daraus (Liste aus der Partitionstabelle des Laufs); bei einer VM die ganze VM als neue VM oder eine ihrer Platten. Ältere Läufe ohne Plattenaufbau lassen sich nur ganz zurückspielen.
• Ziel: „An den ursprünglichen Ort“ (ausgegraut mit Grund, wenn das Original nicht mehr im Rechner steckt), „Auf einen anderen Datenträger“ (ungeeignete wie die Systemplatte, eine Platte mit Auslagerungsdatei, schreibgeschützte, unter Linux eingehängte oder anderweitig belegte (Swap, LVM, RAID, Verschlüsselung, laufende VM) oder zu kleine sind grau, ihr Grund steht in der Spalte „Hinweis“ und beim Anklicken unten) oder „In eine neue VHDX-Datei“ (Windows) bzw. ein Rohabbild (Linux). Für eine neue VM: Name, Ordner, Netzwerkkarten mit ihrem Switch, „MAC-Adressen behalten“ und die Zertifikate des vTPM-Guardians; der Scheduler prüft das mit einem Probelauf.
• Prüfen: eine Zusammenfassung in Sätzen. Wird etwas überschrieben, wird „Wiederherstellen“ erst nach dem Häkchen „Alle Daten auf … werden überschrieben“ aktiv.

An Ort und Stelle: Bei einer Proxmox- oder Xen-Sicherung bietet die Seite „Was“ zusätzlich „An Ort und Stelle der vorhandenen VM (ersetzt ihre Datenträger)“. Der Scheduler prüft das sofort mit einem Probelauf; läuft die VM, ist sie gesperrt, von HA verwaltet, auf einem anderen Knoten, eine andere VM oder fehlt der Platz, sagt der Assistent das mit dem nächsten Schritt. Häkchen: „Die VM zuerst herunterfahren, wenn sie läuft“, „Bisherige Datenträger danach löschen“, „VM nach der Wiederherstellung starten“ und „Nur geänderte Blöcke direkt in die vorhandenen Datenträger schreiben (schneller; kein Rückweg)“ – Letzteres fragt vor dem Start noch einmal nach. Die Seite „Prüfen“ nennt VM, Stand und Zeitpunkt; „Wiederherstellen“ wird erst nach dem Häkchen „Datenträger der VM … durch den Stand vom … ersetzen“ aktiv. Was dahinter passiert, steht in Kapitel 7, „VM an Ort und Stelle wiederherstellen“.

„Wiederherstellen“ startet auf dem Client den Job restore-<sicherung> und öffnet sein Fortschrittsfenster; die letzte Seite nennt den nächsten Schritt: eine VHDX in der Datenträgerverwaltung (Aktion › Virtuelle Festplatte anfügen) oder per Doppelklick im Explorer anfügen, eine neue VM ist ausgeschaltet angelegt (erst das Netzwerk prüfen, dann starten), auf einem größeren Ziel lässt sich das Volume danach erweitern. Ein Volume wird für den Restore gesperrt und getrennt, eine Platte ist währenddessen offline; benutzt ein Programm das Ziel, endet der Restore, bevor etwas geschrieben ist. Unter Linux schreibt der Restore nicht auf eine Platte, eine Partition oder ein LV, die eingehängt, als Swap benutzt, von LVM, RAID oder einer Verschlüsselung belegt oder von einem Programm offen gehalten sind (etwa von einer laufenden VM); die Meldung nennt den Einhängepunkt bzw. was das Ziel belegt. Hat sich die Platte zwischen Auswahl und Start geändert (andere Größe oder Kennung), schreibt der Scheduler nichts und der Assistent liest die Ziele neu. Eine VHDX ist mindestens 3 MB groß und wächst mit den Daten; eine vorhandene Datei wird nie überschrieben. Die Befehle dahinter stehen bei bkp_restore (--target, --partition, --target-format, --new-disk-id).

14.16 Scheduler- und E-Mail-Einstellungen#

Im Menü „Scheduler“ stehen die Einstellungen des gewählten Schedulers. Scheduler-Einstellungen sind Abfrageintervall, Wartezeit bis zum erneuten Versuch bei belegtem Ziel, Zeitlimit je Lauf, aufbewahrte Protokolle je Job und die Zahl gleichzeitiger Jobs (1 bis 64). Sie wirken erst nach einem Neustart des Dienstes; leere Felder bedeuten den Standard. Bei einem Windows-Client kommt das Fortschrittsfenster auf dem Desktop dazu: ob es erscheint, wo es liegt („Darstellung“), ob die angemeldeten Benutzer dort pausieren dürfen und nach wie vielen Minuten so eine Pause von selbst endet (leer: 60). Diese wirken sofort.

Unter Angaben an Targets steht, wie sich die Jobs dieses Rechners bei einem Target melden: der Name dieses Rechners (leer: der Hostname; Buchstaben ohne Umlaute, Ziffern, Leerzeichen, Punkt, Unterstrich und Bindestrich), die übermittelten Angaben (alle; ohne FQDN, Lizenz und Pfade; nur den Namen) und wie oft eine Sicherung ihren Fortschritt meldet (leer: alle 5 Sekunden, 0: nie). Die Target-Konsole zeigt das unter „Sitzungen“. Diese Angaben gelten ab dem nächsten Job und gehen den Einstellungen in den Profilen vor.

E-Mail-Einstellungen: SMTP-Server und Port, Verschlüsselung (STARTTLS, SMTPS oder keine), Absender, bis zu 16 Empfänger, Benutzer und Kennwort, eine CA-Datei auf dem Client, Zeitlimit und wann benachrichtigt wird (nie, nur bei Fehlern, nach jedem Lauf). Das Kennwort zeigt die Konsole nie an; ein leeres Feld behält das gespeicherte, „Kennwort entfernen“ löscht es. „Testmail senden“ speichert geänderte Angaben und verschickt über den Scheduler eine Probemail an die eingetragenen Empfänger. Ein Kennwort geht nur über eine verschlüsselte Verbindung (STARTTLS oder SMTPS).

Mit [api] notify-changes=yes (Standard) schickt der Scheduler bei jeder Änderung über die API eine Mail mit den geänderten Zeilen, sofern der Mailversand eingerichtet ist.

14.17 Nachweise#

Der Reiter zeigt das Nachweis-Protokoll des Schedulers (Kapitel „Nachweise nach NIS2 und BSI“), die neuesten Einträge zuerst, je 200 Einträge („Weitere laden“). Filtern lässt sich nach Zeitraum, Art (Sicherungen und Spiegel, Wiederherstellungen, Prüf-Restores, Jobs, Eingriffe in die Daten, Schutz des Protokolls), Kunde und einem Suchtext; ein Doppelklick zeigt alle Felder eines Eintrags. Über der Liste steht, wie das Protokoll geschützt ist: letztes Siegel, letzte Prüfung, Kopie an einem zweiten Ort und der Schlüssel – rot, wenn etwas Aufmerksamkeit braucht.

• Kette prüfen prüft den gewählten Zeitraum auf dem Client und nennt das Ergebnis; Befunde zeigt ein eigenes Fenster.
• Exportieren… speichert die gefilterten Einträge als CSV oder JSON, daneben die Signatur (.sig).
• Bericht erstellen… erzeugt den Nachweisbericht eines Monats als PDF, für das ganze Target oder einen Kunden, mit Signatur.

Exporte und Berichte prüft bkp_target --audit-check <datei> auf jedem Target, das den öffentlichen Schlüssel kennt.

14.18 Wenn die Verbindung nicht klappt#