Architektur & Sicherheit

Wie die Teile von JFBackup miteinander sprechen, was mit deinen Daten auf dem Weg ins Repository passiert, wer welchen Schlüssel hält und was JFBackup tut, wenn etwas schiefgeht. Für Admins geschrieben, nach der Dokumentation und dem Quelltext der App.

Vier Programme

Konsole · Server · Agent · bcctl, jeweils für Windows und Linux

JFBackup ist nicht ein Programm, sondern vier. Der Server macht die Arbeit, Konsole und bcctl sprechen nur mit ihm, und Agenten öffnen ihm die Rechner, die er schützt. Server und Agent laufen als Windows-Dienst oder systemd-Unit und schreiben ihr Protokoll auf die Standardausgabe und in Dateien von 10 MB, von denen fünf ältere bleiben.

Programm	Was es tut
Konsoledie Desktop-App	Übersicht, Jobs, Wiederherstellung, Server und Agenten, Repositories, Zugangsdaten, Monitoring, Einstellungen und die Assistenten. Ihr Einrichtungsassistent richtet einen Server ein, verbindet sich mit einem oder macht den Computer zum Agenten.
Serverbc-server, Port 7642	Die REST-API, der Zeitplaner (alle 15 Sekunden: fällige Jobs, abgelaufene Tokens, alte Vorgänge), die Sicherungs- und Wiederherstellungs-Engine, Repositories, Benutzer, Rollen, das Audit-Protokoll und die eigene Zertifizierungsstelle. Lange Aktionen laufen als Vorgänge, höchstens acht gleichzeitig, und lassen sich abbrechen.
Agentbc-agent, Port 7680	Gibt Ordner eines Rechners für genau einen Server frei, über gegenseitiges TLS, und meldet sich alle 30 Sekunden.
bcctlder Kommandozeilen-Client	Alles, was Skripte brauchen: Einrichtung, Anmeldung, Status, Start, Warten, Wiederherstellen, Prüfen, Protokolle, Audit, Updates und das Signieren von Releases. Es liest Bänder ohne Server.

Der Datenordner des Servers

Alles, was der Server weiß, liegt in einem Ordner. Ein eingerichteter Server startet nicht ohne seine Schlüssel: Er könnte seine eigenen Geheimnisse nicht lesen und seine Restore-Points nicht belegen.

data/
db/der Datenspeicher: Abbild und Write-Ahead-Journal, absturzsicher
journal/Audit- und Sitzungsprotokolle
keys/Master-, Signier- und Recovery-Schlüssel
pki/CA-, Server- und Client-Zertifikate, ihre Schlüssel versiegelt
logs/10 MB pro Datei, fünf ältere bleiben
config_backups/verschlüsselte Konfigurationssicherungen
setup.tokennur bis es den ersten Administrator gibt

Verbindungen

HTTP/1.1 und JSON · TLS 1.3 · eigene Zertifizierungsstelle · gepinnte Zertifikate

Der Server bringt seine eigene Zertifizierungsstelle mit (Ed25519, zehn Jahre gültig). Sie stellt das TLS-Zertifikat des Servers für die Namen und Adressen des Rechners aus, erneuert es, wenn sie sich ändern oder 30 Tage vor Ablauf, dazu ein Client-Zertifikat, mit dem sich der Server bei Agenten ausweist, und ein Zertifikat pro Agent, ein Jahr gültig. Bei der ersten Verbindung zeigen Konsole und bcctl den SHA-256-Fingerabdruck der CA und merken ihn sich, sobald du ihm vertraust.

Clients

KonsoleBearer-Token, 24 h
bcctlBearer-Token, 24 h

Servereigene CA

API-Zertifikat von der eigenen CA
Client-Zertifikat für die Agenten
Agenten-Zertifikate, gepinnt

Agenten

Eigenes Zertifikatbeim Koppeln, ein Jahr
Lebenszeichenalle 30 Sekunden

Repositories

Ordner des Serverslokale Platten oder ein NAS

Wer mit wem verbunden ist. Unverschlüsseltes HTTP nimmt der Server nur auf der Loopback-Adresse seines eigenen Rechners an.

Von, nach	Wie	Vertrauen
Konsole, bcctl zum Server	HTTP/1.1 mit JSON und Bearer-Token; im Netzwerk TLS 1.3, unverschlüsselt nur auf Loopback	Die CA des Servers, bestätigt über ihren Fingerabdruck oder als Datei angegeben
Server zum Agenten	Gegenseitiges TLS auf Port 7680, eine gehaltene Sitzung pro Agent	Der Server zeigt sein Client-Zertifikat und nimmt genau das Agenten-Zertifikat an, das er ausgestellt hat
Agent zum Server	Ein Lebenszeichen alle 30 Sekunden: zuletzt gesehen, Adresse, freigegebene Ordner	Das eigene Zertifikat des Agenten
Zentraler Server zu anderen Servern	Ihr Bericht einmal pro Minute	Ein Flotten-Token pro Server, seine CA über den Fingerabdruck gepinnt
Server zu Mail und Web-Hooks	SMTP mit STARTTLS oder TLS, nie ein Passwort im Klartext; JSON über HTTPS	Die Zertifizierungsstellen des Systems, auf Wunsch zusätzlich eine Firmen-CA

Agenten koppeln

Ein Einmal-Code unter Windows und Linux · Installation per SSH unter Linux

Ein Agent gehört zu genau einem Server. Er kommt mit einem Einmal-Code dazu oder wird vom Server selbst per SSH installiert. In beiden Fällen hat er danach einen eigenen Schlüssel, ein Zertifikat der CA des Servers und einen Server, den er über den Fingerabdruck prüft.

Mit Kopplungscode

Agent installierenmit dem Setup unter Windows oder dem .deb-Paket unter Linux.
Code in der Konsole erzeugen15 Minuten gültig und nur einmal verwendbar, zusammen mit der Adresse des Servers und dem Fingerabdruck seiner CA.
Auf dem Rechner koppelnbc-agent pair liest die CA aus dem TLS-Handshake und vergleicht ihren Fingerabdruck, oder fragt dich danach.
Zertifikat erhaltenDer Agent erzeugt einen neuen Ed25519-Schlüssel und meldet sich mit dem Code an; die CA des Servers stellt sein Zertifikat aus. Ab dann gilt gegenseitiges TLS.

bc-agent service install richtet ihn als Windows-Dienst oder systemd-Unit ein, pair … --service erledigt beides auf einmal.

Per SSH

Adresse eingebenDie Konsole zeigt den SSH-Host-Schlüssel des Rechners zum Vergleich, bevor irgendetwas gesendet wird.
Anmeldung wählengespeicherte Zugangsdaten, ein Passwort oder ein Ed25519-Schlüssel, oder ein einmal eingetipptes Passwort.
Hochladen und koppelnDer Server lädt den Agenten hoch, koppelt ihn mit einem frischen Einmal-Code und gibt den Fingerabdruck seiner CA mit, damit der Agent genau diesen Server prüft.
StartenAls root als systemd-Dienst, sonst als Hintergrundprozess dieses Benutzers. Ein zweites Verteilen aktualisiert das Programm und behält die Kopplung.

Für Linux-Rechner mit OpenSSH auf x86-64. Windows-Rechner koppeln sich mit einem Code.

Von der Datei zum Restore-Point

FastCDC · BLAKE3 mit Schlüssel · LZ4 oder zstd · XChaCha20-Poly1305 · Ed25519

Die Engine durchläuft die Quellen des Jobs auf dem Server oder über einen Agenten. Eine Datei mit derselben Größe, Änderungszeit und Datei-ID wie im vorigen Restore-Point übernimmt ihre Stücke, ohne gelesen zu werden; eine „aktive Vollsicherung“ liest alles neu. Jeder Restore-Point bleibt trotzdem ein vollständiges Abbild: „inkrementell“ heißt nur, dass unveränderte Dateien nichts kosten.

Was mit neuen Daten passiert

Nach Inhalt zerlegtFastCDC mit normalisiertem Chunking. Die Grenzen hängen nur vom Inhalt ab: Eine Einfügung am Anfang einer Datei verschiebt eine Grenze, die späteren Stücke bleiben dedupliziert. Die Gear-Tabelle stammt aus dem Repository-Schlüssel, Stückgrößen verraten also keine bekannten Dateien.
Benannt mit einem Hash mit SchlüsselDie Kennung eines Stücks ist der BLAKE3-Hash seines Inhalts mit Schlüssel. Gleiche Daten liegen nur einmal da, und ohne den Schlüssel verraten die Kennungen nichts.
Komprimiert, dann verschlüsseltLZ4 oder zstd (Stufe 3, oder 6 für „Hoch“), nur wenn das etwas spart; dann XChaCha20-Poly1305 mit einer frischen 24-Byte-Nonce, Kennung, Art und Kompression des Stücks mitbeglaubigt.
Gepackt mit IndexVersiegelte Stücke kommen in Pack-Dateien mit einem versiegelten Index. Das Ende jedes Packs wiederholt seinen Index, eine verlorene Indexdatei lässt sich also neu bauen.
BäumeOrdner werden zu Baum-Stücken. Ein unveränderter Ordner ergibt dasselbe Baum-Stück und liegt nur einmal da.
Ein signierter SnapshotDer Restore-Point nennt seine Wurzeln, wird mit dem Ed25519-Schlüssel des Servers signiert und verschlüsselt.
In fester Reihenfolge festgeschriebenPacks, synchronisiert; dann Indizes, synchronisiert; dann der Snapshot durch atomares Umbenennen. Ein Absturz hinterlässt höchstens Packs, auf die nichts verweist, und das Aufräumen entfernt sie. Danach greift die Aufbewahrung.

Das Repository

Format bcrepo-1 · Prüfen · Aufräumen · Unveränderlichkeit

Ein Repository ist ein Ordner des Servers, auf einer lokalen Platte oder einem eingebundenen NAS, und es gehört immer nur einem Prozess. Die Aufbewahrung behält Restore-Points nach Anzahl und nach Großvater-Vater-Sohn. Die Unveränderlichkeit wird je Repository in Tagen eingestellt und lässt sich nur verlängern; solange sie gilt, lehnt der Server das Löschen eines Restore-Points ab.

repository/
repo.jsonder Repository-Schlüssel, dreifach verpackt
data/xx/<pack>.packversiegelte Stücke, am Ende der Index noch einmal
index/<pack>.idxder versiegelte Index jedes Packs
snapshots/<id>.snapRestore-Points, signiert und verschlüsselt
LOCKimmer nur ein Prozess

Prüfen eines Restore-Points: Jedes Stück wird gelesen, entschlüsselt und mit seiner Kennung verglichen.
Prüfen eines Repositorys: Snapshots, Signaturen, Verweise und jeder Block.
Aufräumen: Markieren und Löschen, dünn gewordene Packs werden neu gepackt.
Kopien in ein zweites Repository bauen dort jeden Baum neu, weil die Kennungen je Repository mit einem eigenen Schlüssel gebildet werden; eine Liste schon kopierter Bäume hält spätere Kopien inkrementell.

Schlüssel und das Recovery-Kit

Ein zufälliger Schlüssel pro Repository, dreifach verpackt

Jedes Repository hat einen zufälligen Schlüssel. Er liegt nie im Klartext: repo.json enthält ihn verpackt für den Master-Schlüssel des Servers, für die Passphrasen verschlüsselter Jobs und für das Recovery-Kit. Aus ihm werden die Schlüssel für Kennungen, Daten, Indizes, Snapshots und die Gear-Tabelle abgeleitet.

Master-Schlüssel des Servers32 Zufallsbytes im Schlüsselordner, nur für den Besitzer lesbar

Passphrase des Jobsmindestens 12 Zeichen, mit Argon2id gestreckt

Recovery-Kitein X25519-Schlüsselpaar; der private Schlüssel wird genau einmal gezeigt

Repository-Schlüsselzufällig, einer pro Repository

KennungenDatenIndexSnapshotsGear-Tabelle

Drei Wege zum selben Repository-Schlüssel, und was daraus abgeleitet wird.

Der Master-Schlüssel versiegelt außerdem die Geheimnisse in der Datenbank des Servers, Zugangsdaten und Job-Passphrasen, die die API nie zurückgibt, und den Schlüssel der CA. Ein eigener Signierschlüssel signiert die Restore-Points. Das Recovery-Kit ist für den Tag, an dem der Server weg ist: Der Server behält nur seinen öffentlichen Schlüssel und versiegelt jeden Repository-Schlüssel dafür, der private Schlüssel öffnet jede verschlüsselte Sicherung, auch verschlüsselte Bänder, ohne diesen Server. Bewahre ihn offline und getrennt auf.

Eine Konfigurationssicherung enthält die Datenbank, ohne Tokens und Fehlanmeldungen, und die Schlüssel in einer Datei, verschlüsselt mit einer Passphrase (Argon2id und XChaCha20-Poly1305). Zurückgespielt wird sie beim nächsten Start.

Der Schritt Verschlüsselung im Job-Assistenten: der Schalter Restore-Points verschlüsseln mit XChaCha20-Poly1305, die Passphrase zweimal, der Hinweis, dass das Recovery-Kit die Daten auch ohne sie öffnet, und die Kompressionsstufen Aus, Schnell, Ausgewogen und Hoch. — Verschlüsselung und Kompression eines Jobs.

Benutzer, Rollen und das Audit-Protokoll

Argon2id · Tokens nur als Digest · vier Rollen · jede Änderung protokolliert

Selbst registrieren kann sich niemand: Der erste Administrator entsteht mit dem einmaligen Setup-Token des Servers, jedes weitere Konto legt ein Administrator an. Passwörter haben mindestens 12 Zeichen und werden mit Argon2id gespeichert. Eine Anmeldung bringt ein Token, das 24 Stunden gilt und von dem der Server nur den BLAKE3-Digest behält. Zu viele Fehlanmeldungen innerhalb einer Minute sperren den Benutzernamen, und die Zählung übersteht einen Neustart.

Rolle	Darf
Betrachter	Übersicht, Jobs, Restore-Points, Sitzungen samt Protokoll, Hosts und Repositories sehen; das eigene Passwort ändern
Wiederherstellung	zusätzlich Restore-Points durchsuchen und Dateien zurückholen, aber nur in erlaubte Ordner, nie an den Originalort und ohne je eine Datei zu ersetzen
Operator	zusätzlich Jobs anlegen, ändern, starten, aktivieren und deaktivieren, Restore-Points prüfen, Vorgänge abbrechen, Hosts und Repositories prüfen und an den Originalort zurückholen, auch mit Ersetzen
Administrator	zusätzlich Jobs und Restore-Points löschen (nie unveränderliche), Agenten koppeln, installieren und entfernen, Repositories, Zugangsdaten, Benutzer und Einstellungen verwalten, das Audit-Protokoll lesen, das Recovery-Kit und Konfigurationssicherungen erzeugen

Jede Änderung bekommt einen Eintrag im Audit-Protokoll, auch die von Agenten. bcctl docs listet jede Route der API mit der Rolle, die sie braucht; der Server leitet nach genau dieser Tabelle weiter.

Was ein Agent darf

Nur freigegebene Ordner · keine Links · keine Befehle

Ein Agent ist so gebaut, dass er harmlos bleibt, selbst wenn der Server es nicht wäre. Er führt nie Befehle aus, und die Regeln unten gelten auf dem Agenten selbst, nicht nur im Server.

Er liest nur in seinen Sicherungsordnern und schreibt nur in seinen Sicherungs- und Wiederherstellungsordnern.
Er folgt darunter nie einem symbolischen Link, weder beim Lesen noch beim Auflisten von Ordnern oder beim Wiederherstellen.
Wiederhergestellte Dateien schreibt er in Zwischendateien, die er selbst benennt, und benennt sie um, wenn sie vollständig sind.
Sein Port nimmt nur das Client-Zertifikat des Servers an, ausgestellt von der CA, mit der er gekoppelt wurde. Entfernst du den Host, wird das eigene Zertifikat des Agenten gesperrt.
bc-agent roots --add DIR --restore-add DIR ändert die freigegebenen Ordner auf dem Rechner, und --lock verbietet dem Server, sie zu ändern.

Wiederherstellungen sind überall gleich vorsichtig: Jeder Name aus einem Restore-Point wird geprüft (keine Trennzeichen, kein „..“, kein Laufwerk), ein im Ziel untergeschobener Link stoppt diesen Eintrag, statt ihn umzuleiten, und vorhandene Dateien werden übersprungen, umbenannt oder, für Operatoren, ersetzt.

Signierte Updates

Ein Manifest mit Ed25519-Signatur · SHA-256 je Paket · installiert von einem Admin

Neue Versionen kommen aus einem Update-Kanal. Der Kanal darf HTTPS oder einfaches HTTP sein: Signatur und Prüfsumme schützen den Inhalt so oder so.

Der Herausgeber signiertbcctl release keygen erzeugt einen Herausgeber-Schlüssel; bcctl release manifest schreibt das Manifest und seine Signatur für die Pakete eines Releases, ohne Server.
Der Server prüftvon Hand oder einmal am Tag: Er holt Manifest und Signatur und prüft sie gegen die offiziellen Release-Schlüssel oder den Schlüssel in der Einstellung update.key.
Der Server lädt herunterdas Paket für seine eigene Plattform, Windows oder Linux auf x86-64; Größe und SHA-256 müssen zum Manifest passen.
Ein Administrator installiertDie Konsole zeigt die neue Version; Setup oder Paketverwaltung installieren sie und starten den Dienst neu.

Die Karte Updates in den Einstellungen: diese Version 0.1.0, eine neuere Version 0.2.0 verfügbar, die Knöpfe Jetzt suchen und Herunterladen, die Adresse des Update-Kanals, das Feld für den Ed25519-Schlüssel des Herausgebers und der Schalter für die tägliche Suche. — Die Karte Updates mit Demodaten.

Wenn etwas ausfällt

Was JFBackup tut, Fall für Fall

Wenn	dann
der Server mitten in einer Sicherung stoppt	ist sein Datenspeicher absturzsicher (Abbild und Write-Ahead-Journal), die feste Reihenfolge lässt höchstens unbenutzte Packs zurück, und laufende Sitzungen und Vorgänge werden beim nächsten Start als unterbrochen markiert.
ein geschützter Rechner ausfällt	übernimmt ein Replikat, das nach jedem neuen Restore-Point nachgezogen wird (Failover). Das Failback sichert die Ordner des Replikats als Punkt des Jobs und schreibt sie an die Originalorte zurück, ohne dort etwas zu löschen; Rückgängig verwirft den Failover. Failover-Pläne schalten mehrere Replikate nacheinander um, mit einer Pause dazwischen.
eine Datei gelöscht oder überschrieben wurde	holt jeder Restore-Point sie zurück, an ihren Ort oder in einen anderen Ordner.
ein Backup beschädigt oder verändert wurde	merken es Prüfen und Repository-Prüfung: Jedes Stück ist beglaubigt und wird mit seiner Kennung verglichen, die Signatur jedes Restore-Points wird geprüft.
eine Indexdatei verloren geht	wird sie aus dem Ende ihres Packs neu gebaut.
der Backup-Server selbst verloren ist	bringt eine Konfigurationssicherung Datenbank und Schlüssel auf einen neuen Server; das Recovery-Kit oder die Passphrase des Jobs öffnen die Repositories ohne ihn; Bänder liest `bcctl tape extract` ganz ohne Server.
das Backup einer virtuellen Maschine nicht starten würde	findet die Startprüfung das heraus, bevor du es brauchst.
ein Rechner mit Agent gestohlen wird	entfernst du den Host: Sein Zertifikat wird gesperrt.
jemand Backups löschen will	lassen sich unveränderliche Restore-Points nicht löschen, solange die Sperre gilt, und die Sperre lässt sich nur verlängern.

Bekannte Grenzen

Was JFBackup noch nicht kann, wie es sein README aufführt

Virtuelle Maschinen, Sofortstart, Startprüfung und Volume-Sicherungen laufen auf dem Backup-Server selbst (für virtuelle Maschinen ein Linux-Server mit QEMU/KVM), nicht auf Agenten. Hyper-V wird nicht unterstützt.
Sicherungen laufender virtueller Maschinen sind absturzkonsistent: Kein Agent im Gast bringt die Dateisysteme in einen ruhigen Zustand.
Volume-Sicherungen brauchen Administratorrechte (VSS) oder root (LVM), lesen jedes Mal das ganze Volume (die Deduplizierung hält den Speicher klein) und werden als Abbilddatei wiederhergestellt.
Bänder sind virtuell, Dateien auf der Platte; echte Bandlaufwerke werden nicht angesteuert.
TLS zu öffentlichen Servern prüft keine Sperrlisten (CRL oder OCSP).
Agenten-Zertifikate gelten ein Jahr; erneuern heißt vorerst neu koppeln.
Die SSH-Verteilung installiert nur auf Linux mit x86-64.
Noch sind keine offiziellen Release-Schlüssel eingebaut: Ein Server vertraut Update-Manifesten nur mit der Einstellung update.key.
Das Failback schreibt den Stand des Replikats zurück, löscht am Original aber nichts.