Automatische Updates (Betreiber)

Zum Inhaltsverzeichnis

bkp_updater aktualisiert die Programme, sobald auf einem per HTTPS erreichbaren Server ein neues Update liegt. Er ist kein Dauerdienst, sondern ein kurzes Programm, das ein systemd-Timer bzw. die Windows-Aufgabenplanung täglich startet. Ohne konfigurierte url tut er nichts.

23.1 Kommandos#

bkp_updater --status                # Konfiguration, erkanntes System, zuletzt gesehene Manifest-Nummer
bkp_updater --check                 # Manifest laden und prüfen; Exit 10 = für dieses System gibt es ein Update
bkp_updater --update                # prüfen und installieren (das startet der Timer); Exit 75 = später nochmal
bkp_updater --update --dry-run      # nur melden
bkp_updater --rollback              # zurück zur vorherigen Version
bkp_updater --adopt /usr/local/bin  # vorhandene, von Hand kopierte Installation übernehmen

Weitere Optionen: --config <datei>, --url, --channel, --public-key, --ca-file, --proxy, --state-dir überschreiben die Konfiguration; --fetch <dir> lädt das Paket nur herunter (Größe und SHA-256 werden geprüft); --force versucht eine als fehlgeschlagen vermerkte Version erneut; --to <version> wählt eine bestimmte Version; --allow-downgrade erlaubt ein Downgrade (nur zusammen mit --to); --restart-now startet bkp_target gleich nach dem Update neu, ohne auf laufende Sitzungen zu warten.

23.2 Einrichten#

packaging/updater.conf.example nach /etc/bkp/updater.conf kopieren (Windows: %ProgramData%\AegisGrid\updater.conf) und mindestens url und public_key eintragen:

# /etc/bkp/updater.conf
url = https://updates.example.com/aegisgrid
channel = alpha
public_key = lLUdSf+bz5nFZEHOddf3m4ROKcOdmmwTfLW+wnTXMfw=

# Bibliotheken, die eine neue Version braucht: auto (Standard) | system | bundled
dependencies = auto
allow_package_install = no

# Nach dem Umschalten den langlaufenden Server neu starten (bkp_target beendet sich sanft):
restart_command = systemctl restart bkp_target
# höchstens so lange (Sekunden) auf laufende Sitzungen von bkp_target warten, 0 = sofort:
#target_restart_wait = 1800

#ca_file = /etc/bkp/update-ca.pem
#proxy = http://proxy.example.com:3128
#install_dir = /opt/aegisgrid
#link_dir = /usr/local/bin
#state_dir = /var/lib/bkp_updater

Danach mit bkp_updater --status prüfen und einen ersten Trockenlauf machen: bkp_updater --update --dry-run.

23.2.1 Linux: systemd-Timer#

cp packaging/systemd/bkp_updater.service packaging/systemd/bkp_updater.timer /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now bkp_updater.timer
systemctl list-timers bkp_updater.timer

Auszug: Uhrzeit an das eigene Backup-Fenster anpassen

# bkp_updater.timer
[Timer]
OnCalendar=*-*-* 11:00:00
RandomizedDelaySec=2h
Persistent=true

Die Service-Unit setzt SuccessExitStatus=75, damit ein ausgesetzter Lauf (es läuft gerade ein anderer Updater) nicht als Fehler gilt. Alternativ zum Timer gibt es packaging/cron/bkp_updater (/etc/cron.d/bkp_updater, täglich 11:17, Ausgabe nach /var/log/bkp_updater.log).

Verzeichnisstruktur nach --adopt bzw. dem ersten Update: die Programme liegen unter /opt/aegisgrid/versions/<version>/, /opt/aegisgrid/current zeigt auf die aktive Version und /usr/local/bin/bkp_* auf current/bin/*. Eine von Hand kopierte Datei in /usr/local/bin wird nie überschrieben.

23.2.2 Windows: Aufgabenplanung#

bkp_updater.exe --install-task      # legt die Aufgabe "AegisGrid updater" an
bkp_updater.exe --remove-task       # entfernt sie

Die Aufgabe läuft täglich als SYSTEM mit bis zu 1 h zufälligem Versatz. Die Programme liegen in <install_dir>\bin, jede Version zusätzlich in versions\. Laufende .exe-Dateien werden umbenannt und die neue kopiert; das laufende Programm arbeitet mit der alten Datei zu Ende, sie wird beim nächsten Lauf gelöscht. Hat der Job-Planer-Dienst gerade einen Job, nimmt er danach keinen neuen mehr an, lässt die laufenden zu Ende laufen und startet dann mit dem neuen Programm.

23.3 Was bei einem Lauf passiert#

1. Bei einer mit Freischaltcode freigeschalteten Installation die Lizenz erneuern, wenn das fällig ist (Abschnitt „Testversion und Lizenz“).
2. Manifest und Signatur laden und prüfen.
3. Das zum System passende Paket wählen.
4. Laufen gerade ein Backup, ein Restore, eine Wartung oder ein Job des Job-Planers, wird trotzdem installiert: Sie arbeiten mit ihrer bisherigen Version zu Ende (Linux: ihr Versionsverzeichnis bleibt, bis nichts mehr daraus läuft; Windows: die laufende .exe wird umbenannt). Nur ein anderer Updater lässt den Lauf aussetzen (Exit 75).
5. Paket laden (Größe und SHA-256 aus dem signierten Manifest), in ein Staging-Verzeichnis entpacken.
6. Jedes neue Programm mit --version und --selftest ausprobieren.
7. Atomar umschalten (Linux: Symlink; Windows: laufende .exe umbenennen, neue kopieren), gegebenenfalls restart_command ausführen (vorher warten, bis auf bkp_target keine Sitzung mehr läuft, höchstens target_restart_wait). bkp_sched hält laufende Sicherungen an, startet neu, sobald seine übrigen Jobs fertig sind, und setzt die angehaltenen Sicherungen danach fort.
8. Die Selbsttests noch einmal am Installationsort ausführen und bei einem Fehler automatisch zurückschalten.

Die letzten zwei Versionen bleiben erhalten. Eine Version, die hier scheiterte, wird nicht erneut versucht, bis eine neuere erscheint (--force erzwingt es).

Unter Linux startet der Updater nach dem Umschalten auch bkp_sched.service und bkp_target.service neu (ohne restart_command als Rückfall), und ein untätiger Job-Planer wird für die Dauer des Updates angehalten. Das gilt nur für Dienste, deren Programm aus der eigenen Installation (install_dir, Verknüpfungen aufgelöst) stammt; Dienste einer anderen Installation auf demselben Rechner bleiben unberührt.

Bevor er bkp_target neu startet, sieht der Updater in der Sitzungsliste des Targets nach (dieselbe, die die Target-Konsole unter „Sitzungen“ zeigt) und wartet, bis keine Sitzung mehr läuft, höchstens target_restart_wait Sekunden (Standard 30 Minuten). Der Job-Planer läuft in dieser Zeit schon wieder. Ist die Zeit um, startet er trotzdem neu: bkp_target lässt laufende Sitzungen noch bis drain-timeout zu Ende laufen und schließt den Rest geordnet; diese Sicherungen setzen nach dem Neustart als derselbe Lauf fort. bkp_setup und bkp_updater --update --restart-now warten nicht.

23.4 Welches Update für welches System#

Das Manifest ordnet jedem Paket eine Auswahl (match) zu: Betriebssystem, Architektur; bei Linux Distribution (auch über ID_LIKE, Ubuntu zählt für Debian-Einträge), Version (VERSION_ID, zum Beispiel Debian 12, Ubuntu 22.04) und Mindest-glibc; bei Windows der Build-Bereich (Windows 10 = Build 19041 bis 21999, Windows 11 ab 22000) und Server/Client. Gibt es für ein System kein passendes Paket, ist das kein Fehler: es passiert einfach nichts. Ein gestaffelter Rollout (rollout_percent) bietet ein Release nur einem Teil der Rechner an (stabil pro Rechner und Version).

23.5 Fehlende Bibliotheken#

Fehlt trotzdem etwas, wird das Update abgelehnt, die alte Version bleibt aktiv und die Meldung nennt die fehlenden Bibliotheken und Pakete; der nächste Lauf versucht es erneut. Unter Windows entfällt das: die Programme sind statisch gebaut und brauchen nur Windows-eigene DLLs.

23.6 Rollback#

bkp_updater --rollback

Schaltet auf die vorherige Version zurück (Linux: Symlink, Windows: Dateien aus versions\). Ein automatischer Rollback erfolgt schon während des Updates, wenn die Selbsttests am Installationsort oder der restart_command scheitern.

23.7 Freischaltung der Installation (bkp_license)#

Der Update-Server kann die Update-Kanäle auf freigeschaltete Installationen beschränken. Eine freigeschaltete Installation hat ein eigenes Zertifikat, das Updater und Setup beim Laden mitschicken. Ohne Freischaltung meldet der Updater dann: „the update site serves this channel to activated installations only (HTTP 403)“. Die installierte Version läuft weiter; Sicherungen und Wiederherstellungen sind davon nicht betroffen.

Freigeschaltet wird mit dem Freischaltcode über den AegisGrid-Lizenzserver oder, ohne Code oder ohne Internetverbindung, über eine Anfrage- und eine Antwortdatei (beides als root bzw. Administrator):

bkp_license activate                    # fragt nach dem Freischaltcode
bkp_license activate --code-file code.txt

# per Datei:
bkp_license offline-request             # schreibt aegisgrid-anfrage-<rechner>.json
# die Datei an den AegisGrid-Support senden, die Antwortdatei kommt zurück
bkp_license offline-apply AegisGrid-freischaltung-<rechner>.json
bkp_license status                      # zeigt Freischaltung, Gültigkeit und Lizenz
bkp_license renew                       # Lizenz und Zertifikat jetzt erneuern (sonst täglich von selbst)
bkp_license deactivate                  # Platz freigeben (macht die Deinstallation selbst)

Ausgabe:

Freischaltung:    aktiv, Zertifikat gültig bis 19.10.2027
Installation:     I-00017
Kundenkonto:      A-000042
Rollen:           agent, restore, sched
Lizenz:           keine Lizenzdatei vorhanden.
Hardware-Kennung: 2cfbec4b-9865-8663-81a9-172b9108380a

• Die Anfrage enthält Rechnername, Version, die installierten Komponenten, ein Zertifikat-Request und die Hardware-Kennung nur als Prüfsummen (keine Seriennummern oder MAC-Adressen im Klartext). Ohne root fehlen Teile der Hardware-Kennung; bkp_license warnt dann.
• Der Schlüssel entsteht auf dem Rechner und verlässt ihn nie. Ablage: /var/lib/bkp_license (Windows: %ProgramData%\AegisGrid\license), nur für root bzw. SYSTEM und Administratoren lesbar.
• Das Zertifikat gilt bei einer Freischaltung per Datei ein Jahr, bei einer Testversion bis eine Woche nach ihrem Ende, bei einer gekauften Lizenz so lange wie das Abo, höchstens ein Jahr. Eine mit Freischaltcode freigeschaltete Installation erneuert es selbst bei der täglichen Erneuerung (Abschnitt „Testversion und Lizenz“), sobald es in weniger als 30 Tagen abläuft. Eine per Datei freigeschaltete Installation stellt dafür rechtzeitig eine neue Anfrage; die bisherige Freischaltung gilt weiter, bis die neue Antwort eingespielt ist.
• bkp_license status endet mit Exit-Code 0, wenn die Installation freigeschaltet und das Zertifikat gültig ist, sonst mit 1.

23.8 Testversion und Lizenz#

Eine Testversion wird mit dem Testcode freigeschaltet, wie oben beschrieben. Sie läuft 30 Tage ab der Freischaltung, mit allen Modulen und mit Updates. Danach macht sie keine neuen Sicherungen mehr. Alles andere geht weiter: Wiederherstellen, Prüfen, Exportieren und die Wartung der Stores. Zum Weitersichern eine Lizenz erwerben: Wir wandeln das Konto der Testversion in ein Kundenkonto um, und jede Installation bekommt bei ihrer nächsten Erneuerung die gekaufte Lizenz, ohne neuen Code und ohne Neuinstallation. Wer schneller weitersichern will, ruft danach bkp_license renew auf.

Eine gekaufte Lizenz läuft als Abo (monatlich oder mit einer Laufzeit von 1, 3 oder 5 Jahren) und umfasst so viele Punkte, wie gekauft sind, mit allen Modulen und mit Updates. Sie hält Sicherungen erst an, wenn sie abgelaufen und die Kulanzzeit von 14 Tagen vorbei ist (Abschnitt „Gekaufte Lizenz“). Passt sie nicht mehr zum Rechner, scheitert die Erneuerung oder sind mehr Punkte belegt als gekauft, gibt es vorher nur Hinweise.

23.8.1 Tägliche Erneuerung#

Die Lizenz einer Testversion gilt jeweils 3 Tage, eine gekaufte 30 Tage; beide werden täglich beim AegisGrid-Lizenzserver erneuert (ausgehendes HTTPS, mit dem Installationszertifikat). Das erledigt bkp_sched selbst: eine Minute nach seinem Start, danach täglich, nach einem Fehlschlag stündlich. Auf Rechnern ohne Planer erneuert bkp_updater --update vor jedem Update. Von Hand geht es mit bkp_license renew.

• Scheitert die Erneuerung, meldet die Installation das sofort (Konsole, bkp_license status, Protokoll jeder Sicherung, Mail des Planers), mit dem Datum, ab dem neue Sicherungen anhalten. Gelingt eine spätere Erneuerung, ist der Hinweis wieder weg.
• Erst wenn die Lizenz 3 Tage (Testversion) bzw. 30 Tage und 14 Tage Kulanz (gekauft) lang nicht erneuert wurde, halten neue Sicherungen an. Nach der nächsten erfolgreichen Erneuerung laufen sie von selbst wieder.
• Lehnt der Lizenzserver die Erneuerung ab (z. B. weil die Testversion beendet wurde oder das Abo abgelaufen ist), nennt die Meldung seinen Grund und an wen Sie sich wenden. Warten hilft dann nicht.
• Die Ausgabe der Erneuerung durch den Planer steht in renew.log im Lizenzverzeichnis (/var/lib/bkp_license, Windows: %ProgramData%\AegisGrid\license).

23.8.2 Hinweise vor dem Ende#

Konsole und bkp_license status zeigen während des ganzen Testzeitraums, wie lange er noch läuft. Ab 7 Tagen vor dem Ende wird daraus ein Hinweis, der auch im Protokoll jeder Sicherung steht. Bei einer gekauften Lizenz gilt dasselbe ab 14 Tagen vor dem Ende eines Abos, wenn das Ende feststeht (eine Laufzeit, die nicht verlängert wurde, oder ein gekündigtes Monats-Abo); ein Monats-Abo verlängert sich ohne Hinweis. Der Planer schickt außerdem Mails, wenn ein Mailserver eingerichtet ist ([mail] in bkp_sched.cfg oder ein Job, der Fehlschläge mailt). Jede Mail kommt nur einmal, auch nach einem Neustart des Planers. Die Mails sind wie alle Planer-Mails englisch:

23.8.3 Punkte#

Eine Testversion umfasst 10 Punkte, eine gekaufte Lizenz so viele, wie ihre Abos zusammen haben. Die Installation selbst kostet nichts; erst eine Sicherung belegt Punkte. Die Programme melden nur, was sie sichern; was das kostet, legt der Lizenzserver fest und schreibt es in die Lizenz. Derzeit:

• Gezählt wird beim Start einer Sicherung, egal ob der Planer, die Aufgabenplanung, cron oder ein Mensch sie startet, und egal was gesichert wird (Laufwerk, Volume, LV, USB-Platte) und wohin. Eine Einheit zählt, bis ihre letzte Sicherung 7 Tage zurückliegt: Eine aus dem Plan genommene VM gibt ihre Punkte eine Woche später frei.
• Ein VM-Host kostet nichts, außer er sichert sich selbst mit bkp_agent. Läuft bkp_agent in einer VM, zählt sie als Rechner; wird die VM am Host gesichert, zählt sie als VM.
• Eine Sicherung muss als Administrator (unter Linux als root) laufen, damit sie gezählt werden kann; ohne diese Rechte startet sie nicht und sagt das.
• Brächte eine Sicherung einer Testversion neue Einheiten über die Grenze, startet sie nicht. Schon gezählte Einheiten und die übrigen Jobs laufen weiter. Ein M365-Job startet ganz oder gar nicht, damit nie nur ein Teil der Benutzer gesichert ist.
• Bei der Erneuerung meldet die Installation ihre Belegung an den Lizenzserver. Liegen alle Installationen der Testversion zusammen über der Grenze, gibt es nur einen Hinweis; jede Installation hält nur an, wenn sie allein die Grenze überschreitet.
• Bei einer gekauften Lizenz hält die Grenze keine Sicherung an. Werden mehr Punkte belegt als gekauft, gibt es einen Hinweis, und wir berechnen die Differenz nach.

23.8.4 Öffentliches Target#

Ein öffentliches Target betreibt AegisGrid für seine Kunden. Wer dorthin sichert, zahlt keine Punkte, sondern den Speicher, den seine Sicherungen auf dem Target belegen, je TB und Tag. Was ein TB-Tag kostet, steht in Ihrem Vertrag, nicht im Programm. Das eigene Target eines Kunden zählt dagegen über seine Rolle (1 Punkt, Tabelle oben).

Auf dem Target sagt /etc/bkp/hosted.conf, welche Ordner unter dem Speicher welchem Kundenkonto gehören. Ein Ordner zählt mit allen Unterordnern; Ordner dürfen sich nicht überschneiden, ein Konto darf mehrere haben. Ohne diese Datei ist ein Target kein öffentliches.

storage = /srv/backups
kunde1        A-000042
msd/kunde2    A-000043

• bkp_license renew (als root, täglich durch den Planer bzw. den Updater) misst einmal am Tag, was jeder Ordner auf den Platten belegt, also nach Deduplizierung und Kompression, und meldet es bei der Erneuerung an den Lizenzserver. War das Target an einem Tag aus, gilt für ihn die letzte Messung.
• Die Messungen übernimmt der Lizenzserver nur von einem Target, dessen Konto als Betreiber öffentlicher Targets eingetragen ist. Sonst sagt bkp_license status das in der Zeile „Öff. Target:“; dann bitte den AegisGrid-Vertrieb informieren.
• Abgerechnet wird je Monat, drei Tage nach seinem Ende, in Gigabyte-Tagen (1000 Gigabyte-Tage = 1 TB-Tag).

Auf dem Target zeigt bkp_license status die letzte Messung:

Ausgabe:

Öff. Target:      2 Kunden belegen 3,250 TB (gemessen am 23.10.2026 02:10). Der Lizenzserver hat die
                  Messungen bis zum 23.10.2026 übernommen.

23.8.5 Target für andere Konten freigeben#

Jedes Konto mit einem eigenen Target kann es anderen Konten freigeben, etwa ein Systemhaus seinen Kunden. Der Kunde nimmt die Freigabe an, seine Rechner richten das Target danach selbst als Ziel ein. Den API-Key erzeugt jeder Rechner des Kunden selbst; über den Lizenzserver reist nur seine Prüfsumme. Je Freigabe gibt es ein Kontingent, hart (volle Sicherungen werden abgelehnt) oder weich (nur ein Hinweis). Abgerechnet wird der belegte Speicher wie beim öffentlichen Target in Gigabyte-Tagen, und zwar über die Partnerkette des Kontos, dem das Target gehört.

Angeboten und angenommen wird im Kundenportal (cloud.aegisgrid.de): Der Betreiber wählt sein Target, nennt die Konto-ID des Kunden (A-…), das Kontingent und den Modus; der Kunde oder sein Partner nimmt dort an oder lehnt ab. Im Portal sehen beide Seiten Zustand und Belegung, ändert der Betreiber das Kontingent, beendet eine Freigabe oder lässt ihre Daten löschen, und der Kunde kündigt. Für die eigene Rechnung an seine Kunden zeigt das Portal dem Betreiber je Monat, wie viele Gigabyte-Tage jeder Kunde auf seinen Targets belegt hat.

Auf dem Target meldet eine Zeile public in /etc/bkp/hosted.conf es beim Lizenzserver an. Kundenordner von Hand braucht es dafür nicht:

storage = /srv/backups
public  = backup.example.de:9990
name    = Backup Beispiel GmbH

• public ist die Adresse, unter der die Rechner der Kunden das Target erreichen; name sehen die Kunden (ohne Angabe: die Adresse). Ändern sich Zertifikat (certificate, Standard /etc/bkp/target.crt) oder ACL (acl, Standard /etc/bkp/acl), gehören die Pfade ebenfalls in die Datei.
• bkp_license sync (als root, stündlich durch den Timer bkp_license-sync.timer, den das Setup mit dem Target einrichtet, bzw. durch den Planer) meldet das Target an und holt seine Freigaben. Es legt je Freigabe den Ordner hosted/<Freigabe> unter dem Speicher an, schreibt die Zugänge der Kundenrechner nach /etc/bkp/acl.hosted und die Kontingente nach hosted/quota und lädt bkp_target neu, wenn sich etwas geändert hat. Beide Dateien bitte nicht von Hand ändern.
• Jeder Rechner des Kunden sichert in einen eigenen Unterordner seiner Freigabe und darf alle Unterordner lesen, damit ein neuer Rechner wiederherstellen kann.
• Bei einem harten Kontingent misst das Target den Ordner der Freigabe vor jeder Sicherung neu und lehnt sie ab, wenn er voll ist. Ein laufender Lauf wird nicht abgebrochen und darf das Kontingent überschreiten; der nächste wird abgelehnt.
• Wird eine Freigabe beendet, nimmt das Target dafür keine Sicherungen mehr an. Die Rechner des Kunden können ihre Sicherungen aber noch auflisten und wiederherstellen, etwa um sie zu einem anderen Ziel zu holen. Die Daten bleiben und zählen weiter, bis die Seite des Targets sie löschen lässt; dann löscht das Target den Ordner beim nächsten Abgleich.
• Der Ordner hosted unter dem Speicher gehört den Freigaben; in hosted.conf darf kein Kundenordner darin liegen.

Den Stand zeigt bkp_license status in der Zeile „Freigaben:“:

Ausgabe:

Freigaben:        Target T-000001: 2 Freigaben an andere Konten, davon 2 aktiv.

23.8.6 Ein freigegebenes Target nutzen#

Hat ein anderes Konto dem eigenen Konto ein Target freigegeben und ist die Freigabe angenommen, richtet jeder freigeschaltete Rechner des Kontos es beim nächsten Abgleich selbst als Sink ein (stündlich durch den Planer, sofort mit bkp_license sync als Administrator bzw. root). Dabei entstehen neben bkp_agent.cfg (/etc/bkp, Windows %ProgramData%\AegisGrid):

• sinks.hosted.cfg mit einer Zeile in [targets] und einem Abschnitt [sink:<Name>] je Freigabe. Der Name kommt aus dem Namen des Targets (z. B. „Backup Beispiel GmbH“ wird backup-beispiel, bei einem schon vergebenen Namen mit Zähler) und ändert sich danach nie. Alle Programme lesen die Datei wie sinks.cfg mit; sie wird bei jedem Abgleich neu geschrieben und darf nicht von Hand geändert werden. Eigene Einstellungen gehören in sinks.cfg (siehe unten).
• keys/hosted-<Freigabe>.apikey, der eigene API-Key dieses Rechners. Zum Lizenzserver geht nur seine Prüfsumme.
• keys/hosted-<Freigabe>.key, der Schlüssel, mit dem dieser Rechner seine Sicherungen auf dem Target verschlüsselt (AES-256-GCM). Diese Datei an einem sicheren Ort außerhalb des Rechners aufbewahren: Ohne sie lassen sich die Sicherungen dort nicht wiederherstellen, und der Betreiber des Targets kann sie nicht lesen. Fehlt sie, legt der Abgleich keinen neuen Schlüssel an, sondern meldet das.
• ca/hosted-<Freigabe>.pem, das Zertifikat des Targets.

Jeder Rechner sichert in einen eigenen Unterordner der Freigabe (hosted/<Freigabe>/<Installations-ID>). Ein Profil nutzt das Target wie jeden anderen Sink:

[fileserver]
source = /dev/vg0/data
sinks  = lokal,backup-beispiel

Vorgegeben sind nur Target, Verzeichnis und API-Key. Verschlüsselung, Schlüssel, Prüfsumme (hash), required und Aufbewahrung sind Sache des Kunden: Ein Abschnitt gleichen Namens in sinks.cfg setzt sie statt der Vorgabe (mit encryption = none entfällt auch der Schlüssel der Vorgabe), und eigene Sinks dürfen das Target mit einem Verzeichnis unter dem der Freigabe und dem API-Key der Freigabe nutzen. Die Konsole schreibt beides; von Hand:

# sinks.cfg
[sink:backup-beispiel]
encryption = none

[sink:beispiel-lang]
type       = target
target     = backup-beispiel
target-dir = hosted/G-000007/I-0000042-beispiel-lang
api-key    = file:/etc/bkp/keys/hosted-G-000007.apikey
retention  = 1y

bkp_license status zeigt die freigegebenen Targets mit Kontingent und Belegung (Stand des letzten Abgleichs, alle Rechner des Kontos zusammen):

Ausgabe:

Fremde Targets:   „Backup Beispiel GmbH“ von Systemhaus Muster als Sink „backup-beispiel“: belegt 1,85 TB
                  von 2,00 TB (hart).

• Der Planer mailt (an die Adresse für Fehler), wenn ein freigegebenes Target 90 % seines Kontingents erreicht, wenn es voll ist und wenn die Freigabe endet. Bei einem harten Kontingent lehnt das Target neue Sicherungen ab, sobald es voll ist; Wiederherstellen geht weiter. Platz schaffen alte Sicherungen löschen (Aufbewahrung, bkp_maintenance prune) oder ein größeres Kontingent beim Betreiber.
• Endet die Freigabe, bleibt der Sink in sinks.hosted.cfg (damit Profile, die ihn nennen, lesbar bleiben), aber Sicherungen dorthin brechen mit einer klaren Meldung ab, bis das Profil einen anderen Sink bekommt. Wiederherstellen geht weiter, bis der Betreiber die Daten löscht; danach lässt bkp_restore den Sink mit einem Hinweis aus.

23.8.7 Target im eigenen Konto verteilen#

Ein Target, das nur für das eigene Unternehmen sichert, muss nicht auf jedem Rechner von Hand eingetragen werden. Eine Zeile internal in /etc/bkp/hosted.conf meldet es beim Standortserver des Kontos an, und jeder freigeschaltete Rechner desselben Kontos richtet es beim nächsten Abgleich selbst als Sink ein, genau wie ein freigegebenes Target (eigener API-Key, eigener Schlüssel, eigener Unterordner). Andere Konten bekommen davon nichts. Es gibt nichts anzubieten oder anzunehmen, und es wird nichts abgerechnet. Wer die Adressen der eigenen Targets im eigenen Netz behalten möchte, betreibt einen eigenen Standortserver (Kapitel „Standortserver“).

storage  = /srv/backups
internal = nas.firma.lan:9990
name     = Backup Zentrale

• internal ist die Adresse, unter der die eigenen Rechner das Target in ihrem Netz erreichen; name ist der Anzeigename (ohne Angabe: die Adresse). public darf zusätzlich stehen, wenn das Target auch anderen Konten freigegeben wird; ein Target nur mit internal lässt sich anderen Konten nicht anbieten.
• Ein Kontingent gibt es standardmäßig nicht. Wer eins möchte, setzt es im Kundenportal an der Freigabe „eigenes Konto“, hart oder weich, und kann es dort wieder entfernen.
• Beendet wird die Verteilung, indem die Zeile internal aus der hosted.conf entfernt wird. Danach nimmt das Target keine Sicherungen der eigenen Rechner mehr an; sie bleiben lesbar, bis die Daten im Portal gelöscht werden. Kommt die Zeile zurück, solange die Daten noch da sind, geht es mit denselben Sicherungen weiter.

Auf dem Target zeigt bkp_license status die Anmeldung, auf den Rechnern des Kontos steht das Target unter „Eigene Targets:“:

Ausgabe:

Freigaben:        Target T-500000003 angemeldet, keine angenommene Freigabe an andere Konten; für die
                  Rechner des eigenen Kontos unter nas.firma.lan:9990.

Ausgabe:

Eigene Targets:   „Backup Zentrale“ als Sink „backup-zentrale“: belegt 640 GB, kein Kontingent.

23.8.8 Gruppen: ein gemeinsamer Ordner für mehrere Rechner#

Ohne Gruppe sichert jeder Rechner in seinen eigenen Unterordner einer Freigabe, mit eigenem Schlüssel; gleiche Daten verschiedener Rechner liegen dann mehrfach auf dem Target. In einer Gruppe sichern die Rechner einer Abteilung oder eines Standorts in den gemeinsamen Ordner hosted/<Freigabe>/<Gruppe> mit einem gemeinsamen Gruppenschlüssel; was sie gemeinsam haben (Betriebssystem, Programme, Vorlagen), liegt dort nur einmal. Gruppen gibt es je Freigabe, auch bei „eigenes Konto“; ein Rechner ist je Freigabe in höchstens einer Gruppe.

• Gruppen legt die Kundenseite im Kundenportal an der Freigabe an, benennt sie um und löscht sie (nur ohne Mitglieder); dort gibt es auch ein Kontingent je Gruppe (hart oder weich, zusätzlich zu dem der Freigabe) und eine Standardgruppe, der neue Rechner der Freigabe selbst beitreten.
• Beitreten, Wechseln und Austreten geht im Portal, in der Verwaltungskonsole (Fenster „Freigabe…“ eines Sinks, Bereich „Gruppe“) oder auf dem Rechner mit bkp_license group join --grant G-… --group <name> bzw. group leave. Beitreten geht nur, wenn die Backup-Namen des Rechners im Ordner der Gruppe frei sind (Abschnitt „Backup-Namen je Store“, Kapitel 6); sonst nennt die Konsole den Namen und schlägt einen freien vor.
• Den Gruppenschlüssel erzeugt der erste Rechner der Gruppe. Die anderen bekommen ihn versiegelt über den Lizenz- bzw. Standortserver, jeweils nur für das geprüfte Zertifikat des Empfängers; der Server selbst kann ihn nie lesen. Erst wenn der Schlüssel bestätigt ist, sichert der Sink in den Gruppenordner. Die Schlüssel liegen in keys/hosted-<Freigabe>-<Gruppe>.v<n>.key.
• Die bisherigen Sicherungen bleiben lesbar: Beim Beitritt entsteht der schreibgeschützte Sink <sink>-vorher mit dem alten Ordner und dem alten Schlüssel, beim Austritt einer für den Ordner der verlassenen Gruppe. Restore und --list sehen beide wie jeden anderen Sink.
• Gruppen-Stores verwenden immer den ID-Hash blake3. Aufgeräumt (nicht mehr gebrauchte Daten) wird nur auf dem Target: dort legt die Freigabe den Job gc-hosted-<Freigabe> an (täglich 03:30), weil ein einzelner Rechner nicht wissen kann, was die anderen noch brauchen.

Notfallkopie des Gruppenschlüssels. Gehen alle Rechner einer Gruppe verloren, ist der Schlüssel nur noch in einer Notfallkopie vorhanden. Sie gehört an einen sicheren Ort fern von den Rechnern der Gruppe, mit einem Kennwort versiegelt. Solange es keine bestätigte Kopie gibt, zeigt die Konsole einen Hinweis, und der Job-Planer mailt, wenn nur dieser Rechner den Schlüssel hat.

Notfallkopie und Schlüsselwechsel

bkp_license group-key export --grant G-000007 --to /media/usb/gruppe-standard.txt --password-file /root/kennwort.txt
bkp_license group-key import --grant G-000007 --from /media/usb/gruppe-standard.txt --password-file /root/kennwort.txt   # Rechner neu eingerichtet
bkp_license group-key rotate --grant G-000007                                                                          # neuer Schlüssel

• In der Konsole: „Schlüssel sichern…“ im Bereich „Gruppe“ fragt nach Kennwort und Datei; die Kopie gilt als gemacht, sobald der Server sie vermerkt hat.
• Ein Schlüsselwechsel („Neuer Schlüssel“, group-key rotate) gilt für alle Rechner der Gruppe. Neue Sicherungen beginnen damit eine neue Store-Generation; die älteren bleiben mit den früheren Schlüsseln lesbar (previous-keys= im Sink). Danach eine neue Notfallkopie sichern.
• Tritt ein Rechner aus, wird er herausgenommen oder lange nicht mehr gesehen, bekommt die Gruppe automatisch eine neue Schlüsselversion: der frühere Rechner kann neue Sicherungen der Gruppe nicht mehr lesen.

Ältere Sicherungen in die Gruppe übernehmen. Die Sicherungen von vor dem Beitritt sind mit dem alten Schlüssel verschlüsselt und lassen sich deshalb nicht einfach in den Gruppenordner verschieben. In der Verwaltungskonsole zeigt das Fenster „Freigabe…“ des Sinks <sink>-vorher den Knopf „In die Gruppe übernehmen…“: Der Job-Planer legt den Job move-into-<sink> an (ein Job von Hand, ohne Zeitplan) und startet ihn. Er liest jede Sicherung mit dem alten Schlüssel, verschlüsselt sie mit dem Gruppenschlüssel neu und schreibt sie in den Gruppenordner; was dort schon liegt, wird nicht noch einmal gespeichert. Danach lassen sich die Sicherungen aus der Gruppe wie neue wiederherstellen und zählen zu deren Aufbewahrung. Der alte Ordner bleibt unverändert, bis die Freigabe ihn entfernt. Das geht nur auf Linux-Rechnern; von Hand:

Ältere Sicherungen neu verschlüsselt in die Gruppe

bkp_maintenance mirror --reencrypt --store sink:msp-vorher --to sink:msp --sink-store default,files

Gehören alte Ordner zusammen, die mit demselben Schlüssel geschrieben sind (oder unverschlüsselt), zieht sie der Betreiber des Targets ohne Schlüssel um: in der Target-Konsole „Daten“ › „Verschieben…“ bzw. bkp_maintenance move (Kapitel 10).

Den Stand einer Gruppe zeigt das Fenster „Freigabe…“: Mitglieder, Belegung des Gruppenordners mit Kontingent und Ersparnis („240 GB gespart (38 %)“), Schlüsselversion und Notfallkopie. In der Target-Konsole stehen die Gruppenordner im Reiter „Freigaben“ eingerückt unter ihrer Freigabe.

23.8.9 Stand ansehen#

bkp_license status

Ausgabe:

Freischaltung:    aktiv, Zertifikat gültig bis 22.11.2026
Installation:     I-00017
Kundenkonto:      A-000042
Rollen:           agent, restore, sched
Lizenz:           Testversion: Der Testzeitraum läuft bis zum 19.11.2026 (noch 30 Tage).
Erneuerung:       zuletzt am 20.10.2026 09:14
Punkte:           Diese Installation belegt 4 von 10 Punkten (1 Server, 2 VMs, 3 M365-Benutzer).
                  Über alle Installationen 6 (Stand der letzten Erneuerung). Was 7 Tage lang nicht
                  gesichert wurde, zählt nicht mehr mit.
Hardware-Kennung: 2cfbec4b-9865-8663-81a9-172b9108380a

Die Zeile „Lizenz:“ zeigt denselben Satz, den auch die Sicherungen, die Konsole und der Planer sehen: verbleibende Tage, Hinweise oder warum neue Sicherungen angehalten sind, jeweils mit dem nächsten Schritt. Wurde eine Sicherung wegen der Punkte nicht gestartet, folgt die Zeile „Nicht gestartet:“ mit Zeitpunkt und Grund.

23.8.10 Wenn neue Sicherungen angehalten sind#

bkp_agent, bkp_m365, bkp_proxmox, bkp_xenV und bkp_hyperV fragen die Lizenz vor jeder Sicherung, noch vor Snapshot, Checkpoint und Einfrieren einer VM. Sind neue Sicherungen angehalten, beenden sie sich sofort mit Exit-Code 77, ohne etwas zu verändern. Der Planer führt den Lauf als „Nicht gestartet (Lizenz)“ (API: BLOCKED), nicht als Fehler, und mailt nur beim ersten so angehaltenen Lauf in Folge. Wiederherstellen, Prüfen, Exportieren und Wartung fragen die Lizenz nie.

23.8.11 Gekaufte Lizenz#

• Die Lizenz gilt jeweils 30 Tage und wird täglich erneuert, solange das Abo läuft. Ein Monats-Abo verlängert sich jeden Monat von selbst, bis es gekündigt ist, und läuft dann bis zum Ende des Monats. Ein Abo mit Laufzeit (1, 3 oder 5 Jahre) endet an seinem Enddatum, wenn es nicht vorher verlängert wird.
• Weitere Plätze, Punkte, ein neues Abo oder eine Verlängerung bestellen Sie beim AegisGrid-Vertrieb bzw. bei Ihrem Partner; mehr Punkte gelten sofort, weniger ab dem nächsten Monat bzw. dem Ende der Laufzeit.
• Endet ein Abo, stellt der Lizenzserver danach keine Lizenz mehr aus. Die Installation sichert bis zum Ende ihrer Lizenz weiter, danach noch 14 Tage Kulanz mit täglichem Hinweis, dann hält sie neue Sicherungen an. Wiederherstellen geht immer.
• Hat jemand die Lizenz über einen Partner (Systemhaus) gekauft, nennen bkp_license status („Betreut von:“) und alle Hinweise diesen Partner als Ansprechpartner.
• Updates gibt es, solange das Installationszertifikat gilt. Es läuft mit dem Abo und wird bei der Erneuerung von selbst verlängert. Ist es nach einer langen Pause abgelaufen, die Installation mit ihrem Freischaltcode neu aktivieren; der Lizenzserver erkennt den Rechner wieder.

bkp_license status

Ausgabe:

Freischaltung:    aktiv, Zertifikat gültig bis 12.12.2026
Installation:     I-00017
Kundenkonto:      A-000042
Rollen:           agent, restore, sched
Lizenz:           Die Lizenz ist gültig bis 20.11.2026 und wird automatisch erneuert, solange das Abo läuft.
Betreut von:      Systemhaus Muster GmbH
Erneuerung:       zuletzt am 21.10.2026 09:14
Punkte:           Diese Installation belegt 4 von 25 Punkten (1 Server, 2 VMs, 3 M365-Benutzer).
                  Über alle Installationen 18 (Stand der letzten Erneuerung). Was 7 Tage lang nicht
                  gesichert wurde, zählt nicht mehr mit.
Hardware-Kennung: 2cfbec4b-9865-8663-81a9-172b9108380a

Steht das Ende des Abos fest, sagt die Zeile „Lizenz:“ „Das Abo endet am …“, und die Zeile „Abo:“ nennt das Datum.

23.8.12 Platz freigeben#

Jede freigeschaltete Installation belegt einen Platz ihres Freischaltcodes. Ein Ablauf der Lizenz gibt ihn nicht frei: Die Installation macht dann nur keine neuen Sicherungen mehr. Frei wird der Platz erst, wenn die Installation ihn zurückgibt:

• Die Deinstallation (bkp_setup --uninstall, unter Windows „Apps & Features“) gibt ihn beim Lizenzserver frei und meldet „Der Lizenzplatz dieser Installation (I-…) ist wieder frei.“ Ist der Lizenzserver gerade nicht erreichbar, werden die Programme trotzdem entfernt; die Meldung nennt dann die Installation, deren Platz belegt bleibt, bis ihn der AegisGrid-Vertrieb freigibt.
• Ohne Deinstallation, z. B. vor einem Rechnerwechsel: bkp_license deactivate (fragt nach, --yes ohne Rückfrage).
• Ist ein Rechner ausgefallen und lässt sich nicht mehr deinstallieren, gibt der AegisGrid-Vertrieb den Platz frei (bitte die Installations-ID aus bkp_license status bzw. der Konsole nennen). Kommt der Rechner doch wieder ans Netz, erfährt er das bei seiner nächsten täglichen Erneuerung.

Nach der Freigabe arbeitet auf dem Rechner kein AegisGrid-Programm mehr, auch keine Wiederherstellung, bis er mit einem Freischaltcode neu freigeschaltet ist (bkp_license activate oder das Setup). Die Programme enden mit dem Exit-Code 77 und einem Satz im Protokoll, der Planer hält an, die Konsole zeigt eine Meldung. Eine neue Freischaltung braucht wieder einen freien Platz.