Standortserver (bkp_sitesrv) – Handbuch

Zum Inhaltsverzeichnis

Was die Rechner eines Kontos untereinander teilen, gleicht der Standortserver ab: die Targets, die ein Konto an seine eigenen Rechner verteilt (Abschnitt „Target im eigenen Konto verteilen“), und die Job-Planer, die für Verwaltungskonsolen freigegeben sind. Lizenzen, Punkte, Bestellungen, Branding und Targets, die an andere Konten freigegeben sind, bleiben beim Lizenzserver.

Standardmäßig nutzt jedes Konto den gehosteten Standortserver von AegisGrid (site.aegisgrid.de); dafür ist nichts einzurichten. Einen eigenen Standortserver braucht, wer diese Angaben (Adressen, Fingerabdrücke und Schlüssel der eigenen Targets und Planer) im eigenen Netz behalten möchte oder ein Netz ohne Verbindung ins Internet hat. Ein Partner kann einen Standortserver für seine Kunden betreiben.

Betriebsart	`mode`	Wo	Bedient
gehostet	–	bei AegisGrid (`site.aegisgrid.de`)	alle Konten ohne eigenen Standortserver; kostet nichts
eigener Standortserver	`own`	beim Kunden	genau das eigene Konto; 1 Punkt
abgeschottetes Netz	`own`, `offline = yes`	beim Kunden, ohne Verbindung zum Lizenzserver	genau das eigene Konto; 1 Punkt
Partner-Server	`shared`	beim Partner	die Kunden des Partners, die er übernommen hat; 1 Punkt beim Partner

Welcher Standortserver für ein Konto zuständig ist, legt der Lizenzserver in einer signierten Zuweisung fest. Die Rechner holen sie bei ihrem stündlichen Abgleich (bkp_license sync) und gleichen danach mit dem genannten Standortserver ab. Ein Standortserver bedient nur Rechner, die der Lizenzserver ihm in einer signierten Mitgliederliste nennt; jeder Rechner meldet sich mit seinem Installationszertifikat an. Die Schnittstellen beschreibt docs/site-api.txt.

22.1 Was die Rechner davon zeigen#

bkp_license status nennt den Standortserver, solange ein Umzug läuft auch dessen Fortschritt:

Ausgabe:

Eigene Targets:   „nas.firma.lan“ als Ziel „nas.firma.lan“: belegt 640 GB, kein Kontingent.
Standortserver:   I-0000105 (https://standort.firma.lan:8472)
                  Ein Umzug auf diesen Server läuft: 2 von 3 Rechnern umgestellt.
                  Letzter Abgleich: 2026-11-03T09:14:02+01:00.

Beim gehosteten Standortserver steht dort gehostet (https://site.aegisgrid.de). Die Verwaltungskonsole zeigt im Kopf eine Zeile „Standortserver“, wenn ein eigener oder ein Partner-Server zuständig ist, ein Umzug läuft oder der Abgleich scheitert; die Target-Konsole zeigt den Standortserver immer im Reiter „Freigaben“. Erreicht ein Job-Planer den Standortserver 24 Stunden lang nicht, schickt er eine Mail und eine zweite, sobald es wieder geht.

22.2 Eigener Standortserver#

22.2.1 Voraussetzungen#

Ein Linux- oder Windows-Rechner im eigenen Netz, der ständig läuft. Der Standortserver braucht wenig: eine kleine SQLite-Datenbank, kaum Rechenzeit.
Ein Name und/oder eine Adresse, unter der alle Rechner des Kontos ihn erreichen, z. B. standort.firma.lan, und Port 8472/tcp in der Firewall (Windows: das Setup legt die Regel an; Linux: von Hand freigeben).
Ein Freischaltcode des Kontos mit einem freien Platz. Der Standortserver belegt 1 Punkt.
Für Sicherung und Überwachung eine Verbindung zum Lizenzserver (lizenz.aegisgrid.de) und zum gehosteten Standortserver (site.aegisgrid.de), beide über HTTPS. Ohne diese Verbindung siehe „Abgeschottetes Netz“.

22.2.2 Installieren und freischalten#

Die Komponente heißt site („Standortserver“). Das Setup legt die Konfiguration (/etc/bkp/bkp_sitesrv.cfg bzw. %ProgramData%\AegisGrid\bkp_sitesrv.cfg, Vorlage packaging/bkp_sitesrv.cfg.example), den Datenordner (/var/lib/bkp_sitesrv bzw. %ProgramData%\AegisGrid\site) und den Dienst aegisgrid-site an. Gestartet wird der Dienst erst, wenn der Server freigeschaltet ist.

Linux: Komponente hinzufügen und freischalten (Windows: im Setup „Standortserver“ wählen, dann dasselbe activate als Administrator)

bkp_setup --modify --components core,site
bkp_sitesrv activate --code <Freischaltcode> --name standort.firma.lan --ip 192.168.10.5

--name und --ip sind die Namen und Adressen, unter denen die Rechner den Server erreichen; für sie wird sein Serverzertifikat ausgestellt (mehrere --name und --ip sind möglich). Die Freischaltung zeigt einmal den Wiederherstellungsschlüssel:

Ausgabe:

Diese Installation ist freigeschaltet (I-0000105, Beispiel GmbH).

Wiederherstellungsschlüssel dieses Standortservers (wird nur dieses eine Mal angezeigt):

    1SMR-A2E2-DQ93-9HZ2-HNAV-A4WE

Bitte schreiben Sie ihn auf oder drucken Sie ihn aus und bewahren Sie ihn an einem sicheren Ort getrennt von diesem Server auf. Die
täglichen Sicherungen dieses Servers werden damit verschlüsselt; nur mit ihm lassen sie sich auf einem neuen Server wiederherstellen
(„bkp_sitesrv restore --recovery-key ...“). AegisGrid kann die Sicherungen nicht lesen und den Schlüssel nicht wiederbeschaffen.

Das Konto wird bisher von einem anderen Standortserver bedient; dieser ist als sein Nachfolger vermerkt. Nächster Schritt: den Server
starten („bkp_sitesrv serve“ oder der Dienst) und die Daten mit „bkp_sitesrv adopt“ übernehmen.

Achtung: Ohne den Wiederherstellungsschlüssel lässt sich der Standortserver nach einem Totalausfall nicht wiederherstellen; dann müssen alle eigenen Targets und Planer-Freigaben neu gemeldet werden. Den Schlüssel getrennt vom Server aufbewahren. bkp_sitesrv recovery-key --new erzeugt einen neuen (ältere Sicherungen brauchen weiter den alten).

Dann den Dienst starten: systemctl start aegisgrid-site (Linux) bzw. den Dienst „AegisGrid Standortserver“ (Windows). Hat das Konto schon einen anderen eigenen Standortserver, der ersetzt werden soll, gehört --takeover zur Freischaltung (siehe „Auf neue Hardware umziehen“).

22.2.3 Das Konto übernehmen#

Bisher bedient der gehostete Standortserver das Konto. adopt holt dessen Daten und stellt die Zuweisung um:

bkp_sitesrv adopt

Ausgabe:

Das Konto A-000042 zieht auf diesen Standortserver um: Targets 1, Freigaben 1 und freigegebene Planer 0 von I-0000001 übernommen. Die
Rechner wechseln bei ihrem nächsten Abgleich (spätestens innerhalb einer Stunde); bis dahin bedient sie der alte Standortserver weiter.

Die Rechner stellen bei ihrem nächsten Abgleich um. Was ein Rechner in der Zwischenzeit noch dem alten Server meldet, gleicht der neue alle 5 Minuten nach. migrate-status zeigt, wer schon umgestellt hat:

bkp_sitesrv migrate-status

Ausgabe:

Umzug des Kontos A-000042 auf diesen Standortserver
  von:            I-0000001 (gehosteter Standortserver)
  Zustand:        läuft
  begonnen:       2026-11-03T09:12:40+01:00
  Abgleich:       noch nicht (alle 5 Minuten, solange der Server läuft)
  Rechner:        2 von 3 umgestellt

I-0000102  nas (target, sched)
  Zustand:        umgestellt
  alter Server:   2026-11-03T08:59:31+01:00
  dieser Server:  2026-11-03T09:14:02+01:00

I-0000103  buero-pc1 (sched)
  Zustand:        umgestellt
  alter Server:   2026-11-03T09:02:17+01:00
  dieser Server:  2026-11-03T09:13:55+01:00

I-0000104  laptop-7 (sched)
  Zustand:        wartet
  alter Server:   2026-11-03T09:05:48+01:00
  dieser Server:  -

Die wartenden Rechner stellen bei ihrem nächsten Abgleich um, spätestens innerhalb einer Stunde, solange sie laufen.

Haben alle Rechner umgestellt, schließt der Server den Umzug selbst ab: Der alte Standortserver löscht die Daten des Kontos und bestätigt das mit einem signierten Löschnachweis, der im Datenordner liegt. Ist ein Rechner länger weg (Laptop im Urlaub), schließt migrate-finish --force trotzdem ab; er bekommt die neue Zuweisung, sobald er wieder da ist:

bkp_sitesrv migrate-finish --force

Ausgabe:

1 Rechner des Kontos A-000042 ist noch nicht auf diesen Standortserver umgestellt:
  I-0000104  laptop-7  wartet, zuletzt am alten Server gesehen: 2026-11-03T09:05:48+01:00
Sie erhalten die neue Zuweisung später vom Lizenzserver oder vom alten Standortserver, der für dieses Konto dann nur noch die Zuweisung
ausgibt.
Der Umzug des Kontos A-000042 ist abgeschlossen. Der alte Standortserver I-0000001 hat dessen Daten gelöscht (Freigaben: 1,
freigegebene Planer: 0, versiegelte Pakete: 0, Endpunkte: 1) und das mit einem signierten Löschnachweis bestätigt.
Löschnachweis: /var/lib/bkp_sitesrv/deletion-proof-A-000042-20261103-091822.json (prüfen mit „bkp_sitesrv proof <datei>“).
1 Rechner hatte noch nicht umgestellt; er erhält die neue Zuweisung bei seinem nächsten Abgleich vom Lizenzserver.

Ohne --force lehnt migrate-finish ab, solange Rechner warten, und nennt den nächsten Schritt; mit --yes entfällt die Nachfrage. bkp_sitesrv proof <datei> prüft einen Löschnachweis (Signatur, Zertifikat, Nachweiskette):

Ausgabe:

Der Löschnachweis ist gültig: signiert vom Standortserver I-0000001 (Konto A-000001) mit einem Zertifikat der AegisGrid-Install-CA.
  Konto:          A-000042
  umgezogen nach: I-0000105
  gelöscht:       2026-11-03T09:18:22+01:00
  Targets:        1
  Freigaben:      1
  Schlüssel:      3
  freigegebene Planer: 0
  versiegelte Pakete: 0
  Endpunkte:      1
  Rechner:        3
  letzter Export: SHA-256 6087591aa3c3f5dc6f8e508b2302e1c8b26355bd3e9e254985adce1f59d3daeb
  Nachweiskette:  Eintrag 1, b24eac6f7c632cd9c9b4a925b66116b63c368f728bde57119abc3aaa86acf2bb

bkp_sitesrv migrate-abort bricht einen laufenden Umzug ab: Das Konto bleibt beim alten Standortserver, und dieser bekommt alles zurück, was die Rechner inzwischen dem neuen gemeldet haben.

22.2.4 Stand ansehen#

bkp_sitesrv status

Ausgabe:

Standortserver:   I-0000105, A-000042
Modus:            eigen (ein Konto)
Lauscht auf:      0.0.0.0:8472
Mitgliederliste:  aktuell
  ausgestellt:    2026-11-03T09:00:12+01:00
  gültig bis:     2026-12-03T09:00:12+01:00
  zuletzt geholt: 2026-11-03T09:00:12+01:00
  Konten:         1, aktive Installationen: 4
Sperrliste:       2026-11-03T09:00:12+01:00
Clients:          3
Endpunkte:        1
Sicherung:        täglich um 02:30, beim gehosteten Standortserver
  zuletzt:        2026-11-04T02:41:07+01:00
  nächste:        2026-11-05T02:54:58+01:00

Clients sind die Rechner, die mit dem Server abgleichen, Endpunkte die gemeldeten Targets und freigegebenen Planer. Die Mitgliederliste holt der Server stündlich vom Lizenzserver, einen frisch freigeschalteten Rechner sofort; status --json gibt dasselbe maschinenlesbar aus.

22.2.5 Sicherung und Totalausfall#

Der Server sichert seine Datenbank täglich um 02:30 Uhr Ortszeit (mit einer zufälligen Verzögerung bis 30 Minuten), verschlüsselt mit dem Wiederherstellungsschlüssel, auf dem gehosteten Standortserver; dort bleiben 7 tägliche und 4 wöchentliche Sicherungen. backup-dir in der Konfiguration legt sie zusätzlich in einen Ordner (z. B. ein Netzlaufwerk). bkp_sitesrv backup sichert sofort:

Ausgabe:

Sicherung erstellt (169 KiB): beim gehosteten Standortserver abgelegt.

Fällt der Server ganz aus, wird ein neuer freigeschaltet, der den alten sofort ersetzt, und die letzte Sicherung zurückgeholt:

bkp_sitesrv activate --code <Freischaltcode> --name standort.firma.lan --ip 192.168.10.5 --replace --yes
bkp_sitesrv restore --recovery-key 1SMR-A2E2-DQ93-9HZ2-HNAV-A4WE --yes
systemctl start aegisgrid-site

Ausgabe:

Diese Installation ist freigeschaltet (I-0000107, Beispiel GmbH).
Der alte Standortserver ist abgeschaltet; dieser bedient jetzt das Konto. Nächster Schritt: seine letzte Sicherung mit „bkp_sitesrv
restore --recovery-key <Schlüssel>“ zurückholen (der Wiederherstellungsschlüssel des alten Standortservers), dann den Server starten
(„bkp_sitesrv serve“ oder der Dienst).

Ausgabe:

Sicherung des Standortservers I-0000105 (Konto A-000042) vom 2026-11-04T02:41:07+01:00.
Wiederhergestellt: der Stand von I-0000105 vom 2026-11-04T02:41:07+01:00. Die bisherige Datenbank bleibt als
/var/lib/bkp_sitesrv/site.db.before-restore erhalten. Nächster Schritt: den Server starten („bkp_sitesrv serve“ oder der Dienst); die
Rechner des Kontos gleichen ab ihrem nächsten Abgleich mit ihm ab.

Die Rechner müssen nichts tun: Sie bekommen beim nächsten Abgleich die neue Zuweisung und gleichen dann mit dem neuen Server ab.
restore nimmt den Wiederherstellungsschlüssel der Sicherung, also den des alten Servers; er gilt danach weiter. --from-file <datei> nimmt eine Sicherung aus backup-dir. Den Server vor restore anhalten.
Die Sicherung ist höchstens einen Tag alt. Eigene Targets und freigegebene Planer melden die Rechner bei jedem Abgleich; was danach dazukam, ist so nach dem nächsten Abgleich wieder da.

22.2.6 Auf neue Hardware umziehen#

Läuft der alte eigene Server noch, zieht das Konto ohne Unterbrechung um: den neuen mit --takeover freischalten, starten und übernehmen. Der Umzug schließt sich selbst ab, sobald alle Rechner umgestellt haben; danach ist der alte Server deaktiviert und kostet keinen Punkt mehr.

bkp_sitesrv activate --code <Freischaltcode> --name standort2.firma.lan --takeover
systemctl start aegisgrid-site
bkp_sitesrv adopt

22.2.7 Zurück zum gehosteten Standortserver#

bkp_sitesrv migrate-to hosted

Ausgabe:

Der Rückzug des Kontos A-000042 auf den gehosteten Standortserver ist beantragt. Der gehostete Standortserver übernimmt die Daten
innerhalb einer Stunde; die Rechner stellen dann bei ihrem nächsten Abgleich um, bis dahin betreut sie dieser Standortserver weiter.
„bkp_sitesrv status“ zeigt den Fortschritt.
Sobald alle Rechner umgestellt haben, wird dieser Standortserver deaktiviert; sein Punkt wird nicht mehr berechnet.

22.3 Abgeschottetes Netz#

Ein Standortserver mit offline = yes versucht nie, den Lizenzserver zu erreichen. Er wird einmal mit Verbindung freigeschaltet; danach hält ihn ein Bündel am Laufen, das als Datei ins Netz kommt: die Mitgliederliste (90 Tage gültig), die Sperrliste und, wenn sein Serverzertifikat innerhalb von 120 Tagen endet, ein neues. Das Bündel gibt es im Kundenportal oder von AegisGrid; eingespielt wird es mit bundle-import:

bkp_sitesrv bundle-import /media/usb/bundle.json

Ausgabe:

Bündel eingespielt: Die Mitgliederliste gilt bis 2027-02-01T09:30:04+01:00.

Der laufende Server übernimmt das Bündel innerhalb einer Minute; ein neues Serverzertifikat öffnet den Port neu. status zeigt das Bündel und warnt 14 Tage vor Ablauf.
Ein abgeschotteter Server mailt selbst, wenn [mail] in der Konfiguration steht (Vorlage in bkp_sitesrv.cfg.example): Bündel endet in 14 Tagen oder ist abgelaufen, Sicherung fehlgeschlagen und wieder gut, Umzug per Datei wartet. bkp_sitesrv mails listet diese Mails.
Die Sicherung geht nur in backup-dir; ohne backup-dir zeigt status „Sicherung: kein Ziel“.
Virensignaturen für die Targets (Virenprüfung, pruef-virus): virus-db-dir = nennt den Ordner, den der Betreiber mit den ClamAV-Datenbanken füllt; Targets mit virus-db-source=site holen daraus neue Dateien (Kapitel „Prüf-Restore“, Abschnitt „Auf Viren prüfen“).
Die Rechner im Netz bekommen ihre Zuweisung als Datei: bkp_sitesrv assignment --file <datei> auf dem Server, dann bkp_license site-import <datei> auf jedem Rechner oder bkp_setup --site-assignment <datei> bei der Installation.

Umzug in das abgeschottete Netz (bisher bedient der gehostete Standortserver das Konto):

Den neuen Server mit Verbindung freischalten, dann offline = yes in die Konfiguration schreiben und den Dienst neu starten.
Den Export des Kontos vom alten Server holen (beim gehosteten Standortserver von AegisGrid: bkp_sitesrv export --account <konto> --file move.json) und auf dem neuen Server bkp_sitesrv adopt --from-file move.json ausführen. Der Export enthält die eigenen Freigaben; nach dem Umzug löschen.
Das Bündel mit Übernahme anfordern (im Kundenportal) und mit bundle-import einspielen. Ab jetzt ist das Konto dem neuen Server zugewiesen.
bkp_sitesrv assignment --file assignment.json und auf jedem Rechner bkp_license site-import assignment.json.
Der alte Server löscht die Daten mit drop --account <konto> --to <neuer Server> --file <datei> und schreibt einen Löschnachweis; den kopiert man auf den neuen Server und schließt dort mit bkp_sitesrv migrate-finish --account <konto> --proof-file <datei> ab.

adopt --from-file auf dem neuen Server nennt die nächsten Schritte

Aus der Datei übernommen: Targets 1, Freigaben 1, freigegebene Planer 0 des Kontos A-000042. Nächste Schritte: das Bündel mit Übernahme
aus dem Kundenportal und hier „bkp_sitesrv bundle-import“; danach „bkp_sitesrv assignment --file <Datei>“ für die Rechner
(„bkp_license site-import <Datei>“ dort) und „bkp_sitesrv drop“ auf dem alten Standortserver.

bkp_license site-import auf einem Rechner

Die Zuweisung ist übernommen: Diese Installation nutzt ab dem nächsten Abgleich den Standortserver I-0000111 (https://standort.firma.lan:8472).

Umzug heraus geht genauso, nur andersherum: export --file auf dem abgeschotteten Server, adopt --from-file auf dem neuen, drop --account <konto> --to <neuer Server> auf dem alten und migrate-finish --proof-file <datei> auf dem neuen.

22.4 Standortserver für Partner#

Ein Partner kann die Kunden seines Unterbaums auf einem eigenen Standortserver bedienen. Partnerkonten haben keine Freischaltcodes und kein Abo; der Server läuft deshalb in einem Standortkonto: einem Kundenkonto direkt unter dem Partner, das im Kundenportal als Standortkonto gekennzeichnet wird (höchstens eines je Partner). Der Punkt des Servers wird über dieses Konto abgerechnet und landet so beim Partner.

Nach dem Kennzeichnen als Standortkonto

Das Konto A-000077 betreibt den Standortserver des Partners A-000017: Schalten Sie bkp_sitesrv dort frei (mode = shared); Kunden des
Partners übernimmt er mit „bkp_sitesrv adopt --account <Konto>“.

Komponente site installieren und in bkp_sitesrv.cfg mode = shared setzen.
Mit einem Freischaltcode des Standortkontos freischalten (bkp_sitesrv activate --code … --name site.partner.example) und den Dienst starten. Der Wiederherstellungsschlüssel gilt wie beim eigenen Server; die Sicherungen liegen beim gehosteten Standortserver.
Jeden Kunden einzeln übernehmen: bkp_sitesrv adopt --account <konto>. Der Lizenzserver prüft, dass das Konto unter dem Partner liegt. Abschluss wie beim eigenen Server, mit --account bei migrate-status, migrate-finish und migrate-abort.

bkp_sitesrv adopt --account A-000123
bkp_sitesrv migrate-status --account A-000123

Ausgabe:

Das Konto A-000123 zieht auf diesen Standortserver um: Targets 2, Freigaben 2 und freigegebene Planer 1 von I-0000001 übernommen. Die
Rechner wechseln bei ihrem nächsten Abgleich (spätestens innerhalb einer Stunde); bis dahin bedient sie der alte Standortserver weiter.

status zeigt „Modus: gemeinsam (mehrere Konten)“ und die Zahl der Konten. Kunden, die nicht übernommen sind, bleiben beim gehosteten Standortserver.
Ein Kunde des Partners kann später einen eigenen Standortserver bekommen; dann ist der Partner-Server der alte Server des Umzugs.
Das Standortkonto lässt sich nur abschalten, solange der Server keine Kunden mehr bedient.

22.5 Überwachung und Verwaltungs-API#

Eigene und Partner-Server überwacht der Lizenzserver. Er mailt den technischen Kontakten des Kontos, wenn ein Standortserver sich 24 Stunden nicht gemeldet hat, seit 3 Tagen keine Sicherung gelungen ist, ein Umzug nach 7 Tagen noch nicht abgeschlossen ist oder Rechner den Standortserver nicht erreichen, jeweils mit Entwarnung, wenn es wieder gut ist. Nach einem Umzug kommt eine Mail mit dem Löschnachweis.

Für eigene Überwachung hat der Standortserver auf demselben Port eine Verwaltungs-API unter /admin/v1/ (status, clients, endpoints, backups, migrate; Einzelheiten in docs/site-api.txt). Ein Token zum Lesen:

bkp_sitesrv api-token add monitoring --role read

Ausgabe:

Token „monitoring“ (read) hinzugefügt. Es wird nur jetzt angezeigt; bitte bewahren Sie es sicher auf:

    monitoring.ebb-TDLFbbB9rJR3Mj9pntjZSD3F1A43Z5JaCMKNZGQ

Senden Sie es als „Authorization: Bearer monitoring.<Geheimnis>“, oder signieren Sie die Anfragen (docs/site-api.txt).

Stand als JSON; das Serverzertifikat stammt von der AegisGrid-Install-CA

curl --cacert /var/lib/bkp_license/install-ca.crt \
     -H "Authorization: Bearer monitoring.ebb-TDLFbbB9rJR3Mj9pntjZSD3F1A43Z5JaCMKNZGQ" \
     https://standort.firma.lan:8472/admin/v1/status

read-Tokens dürfen nur lesen. admin-Tokens (--role admin) dürfen auch Umzüge übernehmen, abbrechen und abschließen, müssen ihre Anfragen aber signieren. Auf einem Partner-Server gilt ein Token mit --account nur für dieses Konto. api-token list zeigt die Tokens, api-token remove <name> entfernt eines.

22.6 Wenn etwas nicht stimmt#

Meldung	Bedeutung und nächster Schritt
„Dieser Standortserver bedient das Konto dieser Installation nicht …“ (auf einem Rechner)	Der Rechner ist gerade erst freigeschaltet oder die Zuweisung ist noch nicht angekommen. Er wird beim nächsten Abgleich bedient; sofort: `bkp_license sync`.
„Bisher nutzen 2 von 3 Rechnern … diesen Standortserver“ (`migrate-finish`)	Es warten noch Rechner. Abwarten (der Server schließt selbst ab) oder `migrate-finish --force`.
`status`: Mitgliederliste „seit mehr als 3 Tagen nicht erneuert“ oder „abgelaufen …“	Der Server erreicht den Lizenzserver nicht (Firewall, Proxy, DNS). Bis die Liste abläuft, bedient er weiter alle Rechner, danach nur noch die bekannten.
`status` im abgeschotteten Netz: „endet innerhalb von 14 Tagen“	Ein neues Bündel holen und mit `bundle-import` einspielen.
Mail „Standortserver nicht erreichbar“ vom Job-Planer	Der Rechner erreicht den Standortserver seit 24 Stunden nicht: Dienst `aegisgrid-site` läuft? Port 8472/tcp offen? Name auflösbar?

Bis ein Problem behoben ist, arbeiten die Rechner mit dem zuletzt abgeglichenen Stand weiter; Sicherungen und Wiederherstellungen laufen ungestört.