CLI-Tool
nicotsx/zerobyte avatar
nicotsx/zerobyte

Zerobyte: Backup-Automatisierung für Self-Hoster auf Basis von restic

nicotsx/zerobyte bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.

6.954 Sterne174 ForksTypeScriptAGPL-3.0

Auf einen Blick

Was ist das?
Zerobyte ist ein Backup-Automatisierungstool für Self-Hoster, das auf restic aufbaut und eine Weboberfläche für die Planung, Verwaltung und Überwachung verschlüsselter Backups bietet.
Für wen ist es gedacht?
Zerobyte befindet sich noch in einer 0.x-Version, und die README warnt ausdrücklich davor, dass es zwischen den Versionen zu größeren Änderungen kommen kann. Die Bereitstellung erfolgt über Docker Compose, es basiert auf restic und optional rclone, und die Konfiguration dreht sich um Umgebungsvariablen.
Darf ich es kommerziell nutzen?
Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 3 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Projektstatus und Einordnung

Die Repository-Metadaten beschreiben Zerobyte als "Backup-Automatisierung für Self-Hoster. Aufgebaut auf restic". Die README ergänzt, dass es sich um ein Backup-Automatisierungstool handelt, das hilft, Daten über mehrere Speicher-Backends zu sichern, und das eine moderne Weboberfläche bietet, um verschlüsselte Backups von Remote-Speichern zu planen, zu verwalten und zu überwachen. Das Projekt befindet sich derzeit in Version 0.x.x. Die README warnt, dass es von Version zu Version größeren Änderungen unterliegt und dass Kernfunktionen noch entwickelt werden und Feedback gesammelt wird. Wer den Einsatz in der Produktion erwägt, sollte sich darüber im Klaren sein, dass Schnittstellen und Verhalten potenziell instabil sind.

Installation und Bereitstellung

Laut README erfordert der Betrieb von Zerobyte Docker und Docker Compose auf dem Server. Die bereitgestellte compose.yaml-Beispieldatei verwendet das Image ghcr.io/nicotsx/zerobyte:v0.41, enthält die SYS_ADMIN-Capability und das Gerät /dev/fuse für das Mounten von Remote-Freigaben und setzt die Umgebungsvariablen TZ, BASE_URL und APP_SECRET. Das Beispiel mappt /var/lib/zerobyte als persistentes Volume. Der Startbefehl lautet docker compose up -d, danach ist die Weboberfläche unter http://<your-server-ip>:4096 erreichbar. Die README rät ausdrücklich davon ab, Zerobyte auf einem Server zu betreiben, der aus dem Internet erreichbar ist, und empfiehlt stattdessen, nur an 127.0.0.1 zu binden und einen sicheren Tunnel mit Authentifizierung zu verwenden. Sie warnt außerdem davor, /var/lib/zerobyte auf eine Netzwerkfreigabe zu legen, und gibt TrueNAS-Benutzern eine Alternative mit einem dedizierten ZFS-Dataset.

Umgebungsvariablen und Kernkonfiguration

Zerobyte wird hauptsächlich über Umgebungsvariablen konfiguriert. Die README listet BASE_URL und APP_SECRET als erforderlich auf: Ersteres definiert die Instanz-URL und das Cookie-Sicherheitsverhalten, Letzteres ist ein zufälliger geheimer Schlüssel mit mindestens 32 Zeichen, der zum Verschlüsseln sensibler Daten in der Datenbank verwendet wird. APP_SECRET_FILE ist eine alternative, sich gegenseitig ausschließende Option für Docker- oder Kubernetes-Secrets. PORT hat den Standardwert 4096, RESTIC_HOSTNAME den Standardwert zerobyte, TZ wird als entscheidend für eine genaue Backup-Planung beschrieben, und TRUST_PROXY und TRUSTED_ORIGINS decken Reverse-Proxy- und CORS-Szenarien ab. Weitere Variablen sind WEBHOOK_ALLOWED_ORIGINS, WEBHOOK_TIMEOUT, LOG_LEVEL, SERVER_IDLE_TIMEOUT, RCLONE_CONFIG_DIR und PROVISIONING_PATH. Mit GOMAXPROCS lassen sich die Go-Scheduler-Threads von Restic-Prozessen begrenzen, um die CPU-Last während Backups zu reduzieren.

Backup-Workflow: Volumes, Repositories und Jobs

Die README beschreibt die Nutzung von Zerobyte in drei Schritten: Volume hinzufügen, Repository erstellen und Backup-Job konfigurieren. Ein Volume repräsentiert die Quelldaten, die gesichert werden sollen; unterstützte Backends sind NFS, SMB, WebDAV, SFTP und lokale Verzeichnisse. Ein Repository ist der Ort, an dem Backups verschlüsselt gespeichert werden; unterstützte Backends sind lokale Verzeichnisse, S3-kompatible Speicher, Google Cloud Storage, Azure Blob Storage und rclone-Remotes für über 40 Cloud-Anbieter. Ein Backup-Job definiert den Zeitplan, die Aufbewahrungsrichtlinie und die einzuschließenden Pfade. Die Wiederherstellung erfolgt, indem man einen Backup-Job auswählt, einen bestimmten Snapshot wählt und ausgewählte Dateien oder Verzeichnisse an ihren ursprünglichen Ort wiederherstellt.

Authentifizierung und Zugriffskontrolle

Zerobyte verwendet better-auth für Authentifizierung und Sitzungsverwaltung. Die README stellt fest, dass das Projekt derzeit keine granulare RBAC für Backup-Operationen bietet. Authentifizierte Organisationsmitglieder gelten als vertrauenswürdige Operatoren für Repositories, Volumes, Backup-Zeitpläne, Wiederherstellungen und Benachrichtigungsziele in ihrer Organisation. Organisationsrollen schränken hauptsächlich Organisationsverwaltungs- und Instanzverwaltungsaktionen ein. Die Cookie-Sicherheit wird durch BASE_URL bestimmt: Eine http://-URL mit IP-Adresse deaktiviert das Secure-Flag, während eine https://-Domain es aktiviert. Bei Reverse-Proxy-Bereitstellungen muss BASE_URL auf die HTTPS-Domain gesetzt werden und der Proxy muss den X-Forwarded-Proto-Header durchreichen. Die README weist außerdem darauf hin, dass Browser bei HTTPS-BASE_URL Auth-Cookies nur über HTTPS senden, sodass authentifizierte Abläufe über einfaches HTTP nicht funktionieren.

Netzwerkrichtlinie und bereitgestellte Ressourcen

Zerobyte wendet eine Netzwerkrichtlinie auf Backup-Webhooks und ausgehende Benachrichtigungen an. WEBHOOK_ALLOWED_ORIGINS schränkt ein, welche HTTP-Origins als Ziele erlaubt sind, und der Abgleich ist exakt: Schema, Host und Port müssen übereinstimmen, Pfade werden ignoriert. Die Richtlinie gilt für Backup-Webhook-URLs (vor/nach), generische HTTP-Benachrichtigungs-URLs, Gotify-Server-URLs, selbst gehostete ntfy-Server-URLs und benutzerdefinierte Shoutrrr-URLs, die auf generische HTTP- oder SMTP-Ziele zeigen. Der öffentliche ntfy.sh-Dienst und feste Anbieter wie Slack, Discord, Pushover und Telegram benötigen die Whitelist nicht. Backup-Webhooks folgen keinen Weiterleitungen. Außerdem können Betreiber über PROVISIONING_PATH beim Start Repositories und Volumes aus einer JSON-Datei synchronisieren, wobei Anmeldedaten aus Umgebungsvariablen oder /run/secrets/* aufgelöst werden.

Lizenz und Drittanbieterkomponenten

Zerobyte wird unter der AGPL-3.0-Lizenz veröffentlicht. Laut Lizenzauszug handelt es sich um eine Copyleft-Lizenz, die speziell für Netzwerkserversoftware entwickelt wurde: Sie verlangt, dass der Betreiber eines Netzwerkservers den Benutzern den Quellcode der dort laufenden modifizierten Version zur Verfügung stellt. Die Lizenz erlaubt das Kopieren, Verteilen und Modifizieren der Software und verlangt, dass der Quellcode verfügbar ist. Die README listet auch Drittanbieterkomponenten auf: restic ist unter der BSD-2-Clause-Lizenz enthalten, Urheberrecht Alexander Neumann, Status "Included unchanged". Eine vollständige Liste der Drittanbieterlizenzen wird in NOTICES.md referenziert. Der Lizenztext selbst macht keine Aussagen zu Sicherheitslage, Support oder Garantie, und auch die README bietet keinerlei solche Zusicherungen.

Redaktionelles Fazit

Zerobyte befindet sich noch in einer 0.x-Version, und die README warnt ausdrücklich davor, dass es zwischen den Versionen zu größeren Änderungen kommen kann. Die Bereitstellung erfolgt über Docker Compose, es basiert auf restic und optional rclone, und die Konfiguration dreht sich um Umgebungsvariablen. Die AGPL-3.0-Lizenz verlangt, dass Betreiber von Netzwerkservern den geänderten Quellcode bereitstellen, aber weder die README noch der Lizenzauszug machen Zusagen zu Support, Garantie oder Sicherheit. Geeignet ist es nur, wenn diese konkreten Voraussetzungen zur eigenen Umgebung passen.

Offizielle Quellen

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community-Notizen

Community-Notizen