Erste Schritte als Administrator

Dieser Teil der Dokumentation richtet sich an die Person, die Restow für eine Organisation installiert, konfiguriert und betreibt, in der Service-Provider-Edition auch für mehrere Mandanten. Wenn Sie nur Ihr eigenes Postfach im Blick behalten, lesen Sie stattdessen Für Endnutzer → Erste Schritte.

Bis zu einer laufenden Installation sind es zwei Schritte, die diese Seite behandelt: Voraussetzungen, dann Installation, entweder mit dem Installationsskript (empfohlen) oder von Hand mit Docker Compose. Danach führt Einrichtungsassistent durch den geführten Erststart, und Erste Schritte behandelt das Verbinden einer Quelle und den Nachweis Ihrer ersten Sicherung.

Voraussetzungen

Plattform

Betreiben Sie Restow auf einer eigenen Linux-VM (was sie braucht, steht weiter unten). Stellen Sie diese VM auf andere Hardware als die Systeme, die sie sichert: Eine Sicherung, die zusammen mit dem Host ausfällt, den sie schützt, ist keine Sicherung. Halten Sie die Sicherungen außerdem außer Haus, am besten auf S3-kompatiblem Objektspeicher mit Object Lock; das Standardziel, ein Docker-Volume auf der VM selbst, ist für einen ersten Test gedacht.

• LXC-Container funktionieren nur nach bestem Bemühen: Docker braucht dort Nesting und Keyctl, und manche Hosts machen es trotzdem kaputt.
• Restow nativ ohne Docker zu betreiben, wird nicht unterstützt.
• Auf jedem anderen Linux-System mit Docker installieren Sie von Hand mit Docker Compose; das Installationsskript unterstützt nur die Systeme unten.

Was das Installationsskript prüft

Bevor es etwas ändert, prüft das Installationsskript die folgenden Punkte. Scheitert eine Prüfung, hält es an und ändert nichts; eine Warnung hält es nicht auf.

Was	Anforderung	Das Installationsskript
Betriebssystem	Debian 12 oder 13; Ubuntu 22.04, 24.04 oder 26.04 LTS	Hält bei jedem anderen System an.
Architektur	amd64 oder arm64	Hält bei jeder anderen an.
Maschine	Eine eigene VM. LXC, OpenVZ und andere Container funktionieren nur nach bestem Bemühen (in LXC braucht Docker Nesting und Keyctl, und manche Hosts machen es trotzdem kaputt).	Hält in Docker, Podman und WSL an; warnt in LXC, OpenVZ und anderen Containern.
Arbeitsspeicher	Mindestens 4 GiB, der VM zugewiesen, empfohlen 8 GiB (die Hilfsprozesse zum Lesen von Mails brauchen bis zu 512 MB je Prozess, siehe IMPORT_PARSE_WORKERS unter Umgebungsvariablen).	Ab 0.2.0: zählt, was das System meldet, plus den Speicher, den der Kernel für kdump reserviert. Warnt unter 7 GiB (eine VM mit 8 GiB zeigt etwas weniger), hält unter 3 GiB an. Siehe Arbeitsspeicher unter Proxmox und anderen Hypervisoren. Das Skript von 0.1.0 hält unter 3,5 GiB dessen an, was das System meldet.
Platte	Mindestens 1 GiB frei für /opt/restow; mindestens 10 GiB frei für das Datenverzeichnis von Docker (standardmäßig /var/lib/docker; Images und Datenbank), empfohlen 50 GiB oder mehr, weil die Sicherungen dort in einem Docker-Volume liegen, bis Sie ein weiteres Speicherziel hinzufügen.	Hält unter 1 GiB für /opt/restow oder unter 10 GiB für Docker an; warnt unter 50 GiB für Docker. Ab 0.2.0: Auf einem LVM-Volume, dessen Volume Group freien Platz hat, gibt es den Befehl aus, der es vergrößert, siehe Festplatte unter Ubuntu mit LVM.
Uhr	Synchronisiert (NTP): Zertifikate, Signaturprüfungen und Authenticator-Codes brauchen die richtige Zeit.	Warnt, wenn sie es nicht ist.
Rechte	root oder sudo	Hält ohne an.
Werkzeuge	curl, awk, sed, od, base64, tr, df und mktemp	Hält an, wenn eines fehlt.
Docker	Das Skript installiert es aus dem apt-Repository von Docker, wenn es fehlt. Docker aus snap wird nicht unterstützt. Ein vorhandenes Docker braucht Engine 24.0 und Compose 2.20 oder neuer.	Hält an bei Docker aus snap, bei einer älteren Version und wenn Docker fehlt, aber Pakete installiert sind, die mit Dockers eigenen kollidieren (zum Beispiel docker.io, containerd, runc).
Ausgehendes HTTPS	Port 443 zu github.com, ghcr.io, registry-1.docker.io, tuf-repo-cdn.sigstore.dev (Signaturprüfungen) und, wenn Docker fehlt, download.docker.com	Hält an, wenn einer nicht antwortet.
Images	Die Images des Builds und der Version, die Sie installieren, lassen sich ohne Anmeldung von ghcr.io laden.	Ab 0.2.0: fragt die Registry, bevor es etwas ändert. Hält an, wenn ein Image nicht öffentlich ist oder nicht existiert (prüfen Sie --version und --edition). Das Skript von 0.1.0 meldet nur einen fehlgeschlagenen Abruf, nachdem Docker installiert ist.
Ports	80 und 443 frei auf dem Host (die Caddy-Edge, siehe Ports). Hinter einem Reverse-Proxy (ab 0.2.0) nur der eine Port, an den der Proxy weiterleitet: 443, bei der unverschlüsselten HTTP-Strecke 80. Ein Journal-Empfänger für Exchange Online und für Kopien, die ein Mailanbieter weiterleitet (Business und Service Provider), braucht einen weiteren Port, meist 25; Sie richten ihn nach der Installation ein, siehe Exchange-Journaling.	Hält an, wenn 80 oder 443 belegt ist (hinter einem Reverse-Proxy: wenn der eine Port belegt ist, den er braucht). Prüft den Journal-Port nicht.
Domain	Öffentliche Installation: eine Domain, deren A- oder AAAA-Record auf den Server zeigt, mit aus dem Internet erreichbaren Ports 80 und 443; dort bekommt Caddy das Let’s-Encrypt-Zertifikat (siehe DNS und TLS). Mit --local (nur Evaluierung) nicht nötig. Hinter einem Reverse-Proxy: der Name, den Ihr Proxy ausliefert; dieser Host braucht keinen eigenen DNS-Eintrag und keinen eingehenden Port aus dem Internet.	Warnt, wenn die Domain nicht auf diesen Host zeigt. Hinter einem Reverse-Proxy (ab 0.2.0) zeigt der Name auf den Proxy, DNS wird deshalb nicht geprüft.

Arbeitsspeicher unter Proxmox und anderen Hypervisoren

Dieser Abschnitt geht um den Arbeitsspeicher der virtuellen Maschine, in der Restow läuft. Wie Sie die VMs und Container von Proxmox VE mit Restow sichern (eine Preview), steht unter Proxmox-VE-Backup.

Eine VM sieht weniger Arbeitsspeicher, als ihr zugewiesen ist: Der Kernel und die Firmware behalten etwas, und wo kdump (Absturzabbilder) aktiviert ist, wie es unter Ubuntu sein kann, legt der Kernel weitere 320 bis 512 MB für einen Crash-Kernel beiseite (crashkernel= in der Kernel-Befehlszeile; Ubuntus Standard sind 320 MB bei einer Maschine mit 2 bis 4 GiB und 512 MB bei 4 bis 32 GiB). free zählt diesen Speicher nicht mit. Ab 0.2.0 rechnet das Installationsskript ihn wieder hinzu, bevor es den Arbeitsspeicher beurteilt; eine VM mit 4 GiB, die nur 3,3 GiB zeigen kann, bekommt deshalb nur eine Warnung, und die Installation läuft weiter.

• Weisen Sie der VM mindestens 4 GiB zu, empfohlen 8 GiB.
• Mit Ballooning (Proxmox VE: ein „Minimum memory“ unter „Memory“) kann der VM weniger bleiben, als Sie zugewiesen haben. Setzen Sie „Minimum memory“ gleich „Memory“.
• Fahren Sie die VM nach einer Änderung des Arbeitsspeichers herunter und starten Sie sie neu. Ein Neustart von innen übernimmt die Änderung nicht.
• Prüfen Sie in der VM: free -h zeigt, was das System sieht, und cat /sys/kernel/kexec_crash_size die für kdump reservierten Bytes (0 oder keine solche Datei: Es ist nichts reserviert; neuere Kernel bieten auch /sys/kernel/kexec/crash_size).

Festplatte unter Ubuntu mit LVM

Der Installer von Ubuntu Server richtet LVM ein und macht das Root-Logical-Volume oft kleiner als die Platte: Auf einer 30-GB-Platte kann / 15 GB groß sein, und der Rest der Volume Group bleibt ungenutzt. Dockers Datenverzeichnis (/var/lib/docker) liegt auf /; die Plattenprüfung kann das Installationsskript deshalb auf einer VM anhalten, deren Platte groß genug wäre. Prüfen Sie, wie viel der Volume Group ungenutzt ist (Spalte VFree), und vergrößern Sie dann das Root-Volume samt Dateisystem in einem Schritt:

sudo vgs
sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

ubuntu-vg und ubuntu-lv sind Ubuntus Standardnamen; sudo lvs zeigt Ihre, und ab 0.2.0 gibt das Installationsskript diesen Befehl mit den richtigen Namen aus, wenn es ungenutzten Platz findet. Ist VFree 0, gibt es nichts zu erweitern: Die Platte selbst muss größer sein.

Server

Restow läuft als ein Anwendungs-Image mit drei Rollen (api, worker und scheduler), einem Web-Image mit der Caddy-Edge und PostgreSQL 16, alles in einer Compose-Datei definiert. Sie brauchen:

• Einen Linux-Host mit Docker Engine und dem Docker-Compose-Plugin (der Befehl docker compose, nicht das ältere eigenständige docker-compose v1). Das Installationsskript installiert beides aus dem signierten apt-Repository von Docker, wenn Docker fehlt. Die Release-Images gibt es für amd64 und arm64.
• Genug Speicherplatz für das Datenvolumen von PostgreSQL und, falls Sie das lokale Standard-Speicherziel nutzen, den Chunk-Store (STORAGE_LOCAL_PATH, /data/chunks im Container). Der Speicherbedarf wächst mit der Menge geschützter Daten und deren Aufbewahrungsdauer, verringert durch Deduplizierung innerhalb eines Mandanten; ein S3-kompatibles Ziel oder eine eingebundene NFS-Freigabe verlagert dieses Wachstum vom Restow-Host weg (siehe Backups und Zeitpläne).

Restow 0.4.7 ist eine öffentliche Beta: testen Sie sie, bevor Sie sich darauf verlassen, und führen Sie daneben eine unabhängige Sicherung, solange sie neu ist. Sie installieren es aus den veröffentlichten Release-Images (signiert, mit SBOM), in einem von zwei Builds: den vollständigen Images ghcr.io/restow-backup/restow und ghcr.io/restow-backup/restow-web oder den Community-Images ghcr.io/restow-backup/restow-community und ghcr.io/restow-backup/restow-web-community, wie unten unter Installation beschrieben.

Siehe die Release-Notes zu 0.4.7 für den Lieferumfang und bekannte Lücken. Der Quellcode liegt auf GitHub. Ein Release verifizieren sagt, was die Release-Prüfungen abgedeckt haben und was nicht: Backup und Restore von Microsoft 365 wurden noch nicht gegen einen echten Microsoft-365-Mandanten ausgeführt (sie sind durch Tests gegen eine simulierte Graph-API abgedeckt), und der Endpoint-Agent für macOS gehörte nicht zu den Release-Prüfungen.

DNS und TLS

• Öffentlicher Modus (eine aus dem Internet erreichbare Installation): ein Domainname mit A- und/oder AAAA-Records, die auf die IP-Adresse des Servers zeigen, sowie die eingehenden Ports 80 und 443, erreichbar aus dem Internet. Caddy bezieht und erneuert automatisch ein Let’s-Encrypt-Zertifikat für die Domain, die Sie als RESTOW_APP_DOMAIN setzen. Eine manuelle Zertifikatsverwaltung entfällt.
• Lokaler Modus (nur über IP oder localhost erreichbar): keine Domain und kein eingehender Internetzugriff nötig. Das ist der Entwicklungs-/Evaluierungsmodus; Passkeys werden darin nicht angeboten (siehe Einrichtungsassistent).
• Hinter einem Reverse-Proxy (der Proxy hält Namen und Zertifikat): für den Assistenten eine öffentliche Installation mit https://<Name> als öffentlicher URL, aber Restow selbst braucht keinen DNS-Eintrag, keine Zertifikatsanforderung und keinen eingehenden Port aus dem Internet. Siehe Hinter einem Reverse-Proxy.

Der Betriebsmodus wird einmal im Einrichtungsassistenten gewählt und lässt sich später in den Einstellungen ändern.

Ports

Nur 80 und 443 (Caddy) müssen im öffentlichen Modus von außerhalb des Hosts erreichbar sein (hinter einem Reverse-Proxy: nur der Proxy muss einen von beiden erreichen, siehe Hinter einem Reverse-Proxy); der Release-Stack bindet den eigenen Port des api-Containers ausschließlich an Loopback und veröffentlicht keinen PostgreSQL-Port. Server und Clients, die mit dem Restow-Agent gesichert werden, erreichen dieselbe Adresse per HTTPS; einen weiteren Port brauchen sie nicht. Die vollständige Tabelle steht unter Referenz → Ports und Rollen.

Dimensionierung

Restow veröffentlicht noch keine offiziellen Dimensionierungs-Benchmarks (frühe Beta), und die Drosselung durch Microsoft Graph selbst ist meist der begrenzende Faktor dafür, wie schnell eine erste Sicherung eines großen Mandanten abgeschlossen ist (das kann Tage statt Stunden dauern; Restow zeigt diese Wartezeit an, statt sie zu verbergen). Was per Design gilt:

• PostgreSQL enthält Metadaten, die Job-Warteschlange und das Audit-Log, nicht die gesicherten Inhalte selbst. Die liegen im Chunk-Store.
• Der Worker-Durchsatz ist konfigurierbar: WORKER_CONCURRENCY (parallele Jobs je Warteschlange in einem Worker-Prozess) und WORKER_TENANT_CONCURRENCY (parallele Jobs je Mandant), beide standardmäßig 2. Für weitere Skalierung starten Sie mehr als einen worker-Container.
• Der Speicher wächst mit aufbewahrten, deduplizierten, verschlüsselten Daten; eine wöchentliche Stichproben-Prüfung und eine monatliche Vollprüfung kontrollieren die Integrität der Packs unabhängig von der Zielgröße.

Installation mit dem Skript (empfohlen)

Jedes Release enthält install.sh, das den Release-Stack auf einer VM wie unter Plattform beschrieben einrichtet, in /opt/restow. Laden Sie es mit seiner Prüfsummendatei herunter, prüfen Sie es, und führen Sie es dann aus:

curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/install.sh
curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/install.sh.sha256
sha256sum -c install.sh.sha256
sudo bash install.sh

install.sh.sha256 belegt nur, dass der Download vollständig ist. Um zu prüfen, dass das Skript dasjenige ist, das der Release-Workflow veröffentlicht hat, prüfen Sie zuerst die signierte Prüfsummenliste des Releases mit cosign (siehe Ein Release verifizieren):

curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/SHA256SUMS
curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/SHA256SUMS.sigstore.json
cosign verify-blob SHA256SUMS --bundle SHA256SUMS.sigstore.json \
  --certificate-identity https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v0.4.7 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c --ignore-missing SHA256SUMS

Der Einzeiler (Abkürzung)

Dasselbe Skript lässt sich auch in einer Zeile laden und ausführen:

curl -fsSL https://github.com/restow-backup/restow/releases/latest/download/install.sh | sudo bash

Unbeaufsichtigt, ohne Fragen:

curl -fsSL https://github.com/restow-backup/restow/releases/latest/download/install.sh | sudo bash -s -- --non-interactive --domain backup.example.com --edition full

Mit --non-interactive zeigt das Skript den Master-Key nicht an. Kopieren Sie RESTOW_MASTER_KEY sofort aus /opt/restow/.env an einen Offline-Ort (siehe Optionen).

Der Weg oben mit Herunterladen, Prüfen und Ausführen bleibt der empfohlene. Beim Einzeiler läuft das Skript als root, sobald es ankommt; nichts prüft es vorher gegen die signierte Prüfsummenliste des Releases, Sie vertrauen stattdessen der Verbindung zu GitHub. In beiden Fällen prüft das Skript selbst die Release-Dateien und Images, die es lädt (Prüfsummen und cosign-Signaturen), und es tut nichts, bevor es vollständig heruntergeladen ist.

latest oder eine feste Version. releases/latest/download/install.sh leitet auf das neueste Release weiter, holt also immer das Skript der neuesten Version, und dieses Skript installiert seine eigene Version (heute 0.4.7). releases/download/v0.4.7/install.sh holt immer das Skript von genau 0.4.7, das 0.4.7 installiert. Nehmen Sie die feste Form, wenn Server oder Anleitungen auf einer bekannten Version bleiben sollen; Pre-Releases sind nie latest.

Alle Befehle für den Betrieb einer Installation stehen in der Befehlsübersicht.

Was das Skript tut

1. In einem Terminal und ohne Optionen beginnt es mit einer kurzen Einführung (was es tun wird, etwa 10 bis 20 Minuten, was Sie brauchen), ab 0.2.0. Dann prüft es den Rechner: root-Rechte, Betriebssystem, Architektur, Virtualisierung, Arbeitsspeicher, Platte, die Ports 80 und 443, ausgehendes HTTPS, die Uhr, den DNS-Eintrag der Domain, ob sich die Images ohne Anmeldung laden lassen (ab 0.2.0), und eine frühere Installation. Scheitert eine Prüfung, hält es an und ändert nichts. Was das Installationsskript prüft nennt, was jede Prüfung braucht.
2. Es fragt, wie Restow erreicht wird (ab 0.2.0): 1 öffentlich, mit eigenem Zertifikat (eine Domain, die auf den Server zeigt, Ports 80 und 443 offen zum Internet); 2 hinter einem Reverse-Proxy, den Sie bereits betreiben und der Namen und Zertifikat hält; 3 eine lokale Evaluierung, dasselbe wie --local. Es fragt nach der Domain (bei Option 2 auch nach der Adresse des Proxys) und dem Build (vollständig oder Community, siehe die beiden Builds) und zeigt seinen Plan, bevor es etwas ändert. Das Skript von 0.1.0 fragt nur nach der Domain und dem Build.
3. Es installiert Docker Engine und das Compose-Plugin aus dem signierten apt-Repository von Docker, wenn Docker fehlt. Docker aus snap lehnt es ab.
4. Es lädt docker-compose.yml und env.example des Releases und prüft sie gegen die SHA256SUMS des Releases und deren cosign-Signatur.
5. Es schreibt /opt/restow/.env (Modus 0600) mit Secrets aus dem Zufallsgenerator des Kernels.
6. Es zeigt RESTOW_MASTER_KEY einmal an, im Terminal und nie in seinem Log, und bittet Sie zu bestätigen, dass Sie ihn offline aufbewahrt haben. Bewahren Sie ihn dann offline auf: Er wird nicht noch einmal angezeigt (er bleibt in .env).
7. Es lädt die beiden Images des gewählten Builds, prüft ihre cosign-Signaturen gegen den Release-Workflow genau dieser Version (ein Image ohne gültige Signatur wird wieder entfernt, und nichts wird gestartet) und startet den Stack. Seit 0.4.0 startet es auch den Mounter (Compose-Profil mounts), weil die Sicherung von Freigaben darüber läuft; --no-mounter lässt ihn aus (siehe Optionen).
8. Am Ende wartet es, bis die api gesund ist, liest das einmalige Setup-Token aus dem Log der api und gibt als letzte Zeilen einen Kasten mit der Adresse zum Öffnen und dem Token aus, ab 0.2.0. Das Token geht nur ans Terminal, nie ins Installations-Log, und bei einem Lauf, dessen Ausgabe eingesammelt wird (kein Terminal), steht stattdessen, wie man es liest. Es bleibt gültig, bis die Einrichtung abgeschlossen ist; lesen Sie es auf dem Server erneut mit cd /opt/restow && sudo docker compose logs api | grep 'SETUP TOKEN'. Das Skript von 0.1.0 gibt die Setup-URL und diesen Befehl aus. Der Einrichtungsassistent fragt zuerst nach der Sprache, dann nach dem Token.

Sein Log ist /var/log/restow-install.log, ohne Secrets.

Optionen

bash install.sh --help listet jede Option und die Exit-Codes. Die, die Sie am ehesten brauchen:

Option	Wirkung
--local	Eine Evaluierung ohne öffentliche Domain: Die Edge liefert https://localhost oder einen internen Namen wie restow.internal per HTTPS aus, mit einem Zertifikat von Caddys eigener Zertifizierungsstelle. Browser warnen davor, und Passkeys werden nicht angeboten. Nicht für den Produktivbetrieb.
--with-updater	Startet zusätzlich den Opt-in-Updater, der aus bleibt, solange Sie ihn nicht anfordern. Er bindet den Docker-Socket ein: Lesen Sie zuerst Updates.
--no-mounter (oder --without-mounter)	Seit 0.4.0 startet eine neue Installation den Mounter standardmäßig (Compose-Profil mounts): Die Sicherung von Freigaben läuft darüber, und er bindet NFS-Freigaben als Repository-Speicher aus der Weboberfläche ein. Er bindet den Docker-Socket ein, was Root-Zugriff auf den Host bedeutet: Lesen Sie zuerst Mounter und NFS-Speicher. Skriptgesteuerte Installationen, die ihn nicht wollen, übergeben --no-mounter; Sie können ihn später starten (Netzlaufwerke einschalten in der Weboberfläche, wenn der Updater läuft, oder docker compose --profile mounts up -d mounter). Ist der Updater an, folgt der Mounter jedem signierten Update von selbst.
--with-mounter	Startet den Mounter ausdrücklich. Bis 0.3.6 war er aus, solange Sie diese Option nicht übergaben; seit 0.4.0 ist er der Standard. Braucht Release 0.3.1 oder neuer; ein älteres Release hat keinen Mounter.
--behind-proxy --domain <name> --proxy-ip <adresse>	Ab 0.2.0: eine Installation hinter einem Reverse-Proxy, den Sie bereits betreiben und der Namen und Zertifikat hält. --proxy-ip ist die Adresse des Proxys selbst (wiederholen oder mehrere durch Leerzeichen trennen; eine einzelne Adresse bekommt /32 oder /128), bei --non-interactive Pflicht. Standardmäßig ist die Strecke zum Proxy verschlüsselt (an https://<dieser Host>:443 weiterleiten). Siehe Hinter einem Reverse-Proxy.
--proxy-hop http	Mit --behind-proxy, jedes Release: Der Proxy leitet stattdessen an http://<dieser Host>:80 weiter. Die Strecke ist nicht verschlüsselt; nur für einen Proxy auf demselben Host oder in einem abgeschotteten Netz.
--non-interactive --domain <name> --edition full|community	Eine unbeaufsichtigte Installation: keine Fragen, die Antworten kommen aus den Optionen (--edition ist standardmäßig full). Der Master-Key wird dann nicht angezeigt; kopieren Sie ihn deshalb sofort aus /opt/restow/.env an einen Offline-Ort.
--dry-run	Führt die Prüfungen aus und zeigt, was es tun würde; ändert nichts.
--help	Listet jede Option, darunter --version, --dir (Standard /opt/restow) und --skip-signature-check (nur für Tests und unsignierte Spiegel, nie für den Produktivbetrieb), und die Exit-Codes.

Zum Beispiel:

sudo bash install.sh --non-interactive --domain backup.example.com --edition community

Erneut ausführen

Das Skript erneut auszuführen ist sicher: Es findet die Installation, ändert nie .env, ein Secret oder Daten, prüft die in .env genannten Images und sorgt dafür, dass der Stack läuft. Es startet nicht, wenn Docker Daten einer früheren Installation ohne deren .env hält. Es aktualisiert nie eine Installation (siehe Updates), und es hat keine Deinstallation, mit Absicht, denn das Entfernen einer Installation kann Sicherungen zerstören; die Schritte von Hand stehen in der README, „Removing Restow“.

Ab 0.3.6 aktualisiert es auch docker-compose.yml. Eine Installation behält die Datei, mit der sie installiert wurde, und ein Update, auch über den Updater, ändert nur die Images in .env. Eine ältere Datei hat deshalb neuere Dienste wie den Mounter nicht. Ab 0.3.6 bringt das erneute Ausführen des Skripts docker-compose.yml auf die geprüfte Datei des in .env genannten Releases (geprüft gegen die signierte SHA256SUMS des Releases). Eine abweichende Datei bleibt als docker-compose.yml.bak-<Zeit> erhalten, und .env wird nie geändert. Eigene Änderungen gehören in docker-compose.override.yml (Release-Stack-Referenz), nicht in docker-compose.yml. Nennt RESTOW_IMAGE keine Release-Version, bleibt die Datei unverändert.

Seit 0.4.0: Die Mounter-Wahl bleibt, und eine verschobene Datenbank ist geschützt. Wenn Sie den Installer von 0.4.0 oder neuer erneut auf einer bestehenden Installation ausführen, behält er deren Wahl zum Mounter: Er startet keinen Mounter, den Sie ausgelassen haben. Die Sicherung von Freigaben und das Verschieben der Datenbank brauchen die docker-compose.yml von 0.4.0 oder neuer; führen Sie das Installationsskript daher nach dem Update auf 0.4.0 erneut aus (siehe Update auf 0.4.0). Wurde die Datenbank auf einen anderen Datenträger verschoben (Installation → Datenbank), verweigert der Installer mit Exit-Code 8 und ohne etwas zu ändern, eine docker-compose.yml einzusetzen oder zu starten, die RESTOW_POSTGRES_DATA nicht aus der .env liest: Eine ältere Release-Datei würde den Stack ohne seine Datenbank starten. Verwenden Sie die docker-compose.yml von Release 0.4.0 oder neuer; die Datei von 0.3.6 liest diese Einstellung nicht.

Hinter einem Reverse-Proxy

Wenn ein Reverse-Proxy, den Sie bereits betreiben (Nginx Proxy Manager, Traefik, Caddy, HAProxy und ähnliche), Ihre öffentlichen Namen und Zertifikate hält, braucht Restow weder einen öffentlichen DNS-Eintrag auf seinem eigenen Host noch die Ports 80 und 443 aus dem Internet, und es holt sich kein eigenes Zertifikat von Let’s Encrypt. Der Proxy beendet TLS für den öffentlichen Namen und leitet an die Caddy-Edge von Restow auf dem Restow-Host weiter.

Standardmäßig ist auch die Verbindung zwischen Proxy und Restow verschlüsselt: Die Edge liefert HTTPS mit einem Zertifikat von Caddys eigener Zertifizierungsstelle aus, und der Proxy leitet an https://<Restow-Host>:443 weiter. Eine unverschlüsselte HTTP-Strecke ist als Ausnahme möglich, siehe Die unverschlüsselte HTTP-Strecke.

Ab 0.2.0

Die Option --behind-proxy des Installationsskripts und die verschlüsselte Strecke (RESTOW_EDGE_TLS) kommen mit 0.2.0. Wenn Sie 0.1.0 betreiben, siehe Mit 0.1.0: von Hand.

Leiten Sie an Port 443 weiter (bei der unverschlüsselten Strecke an 80), nie an 3000. Port 3000 ist die api, die der Release-Stack mit Absicht nur an den Loopback des Restow-Hosts bindet; ein Proxy erreicht ihn nicht, und er liefert die Weboberfläche nicht aus.

Mit dem Installationsskript (ab 0.2.0)

sudo bash install.sh --behind-proxy --domain backup.example.com --proxy-ip 192.168.1.20

Ohne Optionen antworten Sie auf die Frage „How will people reach Restow?“ mit 2; das Skript fragt dann nach dem Namen und der Adresse des Proxys. --domain ist der Name, den Ihr Proxy ausliefert. --proxy-ip ist die Adresse des Proxys selbst, wie der Restow-Host sie sieht, nicht Ihr Netz: Restow glaubt die Client-Adresse, die diese Gegenstellen melden (X-Forwarded-For), für sein Audit-Log und seine Anmeldegrenzen, tragen Sie also nur den Proxy ein. Mehrere Proxys: Option wiederholen oder die Adressen durch Leerzeichen trennen. Eine einzelne Adresse bekommt /32 (IPv4) oder /128 (IPv6); ein Netz wie 192.168.1.0/29 gilt, wie angegeben. Wenn Sie nicht sicher sind, von welcher Adresse der Proxy verbindet, laden Sie die Seite einmal und führen Sie auf dem Restow-Host sudo ss -tn state established '( sport = :443 )' aus. Bei einem unbeaufsichtigten Lauf (--non-interactive) sind beide Optionen Pflicht.

Das Skript prüft, ob Port 443 frei ist (Port 80 braucht es nicht), schaut nicht auf DNS (der Name zeigt auf Ihren Proxy, nicht auf diesen Host) und zeigt in seinem Plan, wohin der Proxy weiterleiten muss. Es schreibt diese Werte in /opt/restow/.env:

Variable	Wert	Wirkung
RESTOW_APP_DOMAIN	backup.example.com	Der Name, den die Edge ausliefert. Ohne Schema: Die Edge liefert dafür HTTPS aus.
RESTOW_PUBLIC_URL	https://backup.example.com	Die Adresse, die Browser verwenden; sie bestimmt die Passkey-Domain und die Links in Mails.
RESTOW_EDGE_TLS	internal	Die Edge zeigt ein Zertifikat von Caddys eigener Zertifizierungsstelle, statt Let’s Encrypt zu fragen. Ein Proxy, der keinen Servernamen sendet (nginx sendet für eine Adresse keinen), bekommt trotzdem das Zertifikat des Namens. Nicht gesetzt oder acme ist das Verhalten jeder anderen Installation.
RESTOW_EDGE_TRUSTED_PROXIES	192.168.1.20/32	Die Proxys, deren Client-Adresse geglaubt wird.
RESTOW_HTTP_PORT	127.0.0.1:	Port 80 wird nicht gebraucht. Er wird nur auf dem Loopback veröffentlicht, auf einem Port, den Docker wählt; so kann ihm nichts anderes auf dem Host im Weg sein, und das Netz erreicht ihn nicht.
RESTOW_EDGE_HSTS	leer	HSTS gehört zum Proxy, der das Zertifikat hält, siehe unten.

Läuft der Stack, kopiert das Skript das Root-Zertifikat der eigenen Zertifizierungsstelle der Edge nach /opt/restow/edge-root-ca.crt. Der Proxy kann die Edge damit prüfen; nötig ist das nicht. Am Ende gibt es die Adresse und das Setup-Token in einem Kasten aus, und in diesem Kasten auch, wohin der Proxy weiterleiten muss.

Den Proxy einrichten

Nginx Proxy Manager, Proxy Host:

1. Details: Domain Names backup.example.com; Scheme https; Forward Hostname / IP die Adresse des Restow-Hosts; Forward Port 443. Websockets Support ist nicht nötig: Restow nutzt Server-Sent Events, keine WebSockets (der Schalter kann aber an bleiben).

2. SSL: Ihr Zertifikat für den Namen (zum Beispiel von Let’s Encrypt, vom Nginx Proxy Manager angefordert), Force SSL, HTTP/2 Support. Schalten Sie HSTS hier ein, wenn Sie es wollen; Restows Edge sendet in diesem Modus keines.

3. Advanced: die benutzerdefinierte Konfiguration

   proxy_ssl_server_name on;
   proxy_ssl_name $host;
   proxy_buffering off;

   proxy_ssl_server_name on und proxy_ssl_name $host senden den öffentlichen Namen als TLS-Servernamen, damit die Edge mit dem Zertifikat dieses Namens antwortet. proxy_buffering off lässt Live-Aktualisierungen sofort im Browser ankommen: Es sind Server-Sent Events, die nginx zurückhält, solange es Antworten puffert.

Um die Edge zusätzlich zu prüfen, kopieren Sie /opt/restow/edge-root-ca.crt dorthin, wo der Container des Proxys es lesen kann, und ergänzen Sie (der Pfad ist der im Container des Proxys):

proxy_ssl_verify on;
proxy_ssl_trusted_certificate /data/restow-edge-root-ca.crt;

Andere Proxys brauchen dasselbe: Upstream https://<Restow-Host>:443; den öffentlichen Namen als TLS-Servernamen senden und den Host-Header beibehalten (die Edge antwortet nur für diesen Namen); X-Forwarded-For weiterreichen; Antworten nicht puffern (Restows Live-Kanal sind Server-Sent Events über eine normale Anfrage, kein WebSocket: Puffern der Antworten ausschalten, bei nginx proxy_buffering off;); und Request-Größen und Timeouts, die zu Uploads passen (Agents senden Packs von bis zu 128 MiB, Importe Segmente von 32 MiB; nginx’ Standardgrenze von 1 MB ist zu klein). Mit Caddy davor:

backup.example.com {
  reverse_proxy https://192.168.1.50:443 {
    transport http {
      tls_server_name backup.example.com
      tls_trust_pool file /etc/caddy/restow-edge-root-ca.crt
    }
  }
}

Mit Traefik, in der dynamischen Konfiguration:

http:
  serversTransports:
    restow:
      serverName: backup.example.com
      rootCAs:
        - /etc/traefik/restow-edge-root-ca.crt
  services:
    restow:
      loadBalancer:
        serversTransport: restow
        servers:
          - url: https://192.168.1.50:443

Prüfen Sie die Edge auf dem Restow-Host: curl -k --resolve backup.example.com:443:127.0.0.1 https://backup.example.com/healthz antwortet mit 200. Öffnen Sie dann https://backup.example.com über den Proxy.

Firewall (optional)

Docker veröffentlicht den Port der Edge über seine eigenen Firewall-Regeln, die Regeln von ufw und firewalld für den Host nicht erfassen: ufw allow from 192.168.1.20 to any port 443 hält niemand anderen draußen. Wenn andere Rechner als der Proxy den Restow-Host erreichen können, schränken Sie den Port auf eine von zwei Arten ein.

• Auf einer Adresse veröffentlichen. Setzen Sie RESTOW_HTTPS_PORT=192.168.1.50:443 in /opt/restow/.env (die Adresse des Restow-Hosts im Netz des Proxys) und führen Sie docker compose up -d aus. Die Edge ist dann auf den anderen Schnittstellen des Hosts nicht veröffentlicht.

• Nur den Proxy zulassen, in Dockers eigener Kette. Regeln in DOCKER-USER laufen vor denen von Docker. Ersetzen Sie eth0 durch die Schnittstelle zum Netz des Proxys und die Adresse durch die des Proxys:

  sudo iptables -I DOCKER-USER -i eth0 -p tcp --dport 443 ! -s 192.168.1.20 -j DROP

  --dport 443 ist der Port im Container; den sieht diese Kette nach Dockers Port-Zuordnung. Die Regel ist nach einem Neustart weg: Legen Sie sie dorthin, wo Ihr System Firewall-Regeln wiederherstellt (zum Beispiel mit iptables-persistent), und wiederholen Sie sie mit ip6tables, wenn der Host IPv6 hat. Testen Sie von einem anderen Rechner als dem Proxy.

Die unverschlüsselte HTTP-Strecke (Ausnahme)

Mit --proxy-hop http (jedes Release) läuft alles zwischen Proxy und Restow, Sitzungs-Cookies, Passwörter und wiederhergestellte Daten eingeschlossen, unverschlüsselt, und Port 80 des Restow-Hosts steht jedem Rechner offen, der ihn erreicht. Nutzen Sie das nur, wenn Proxy und Restow auf einem Host oder in einem abgeschotteten Netz laufen. Das Skript braucht dann Port 80 statt 443 und schreibt RESTOW_APP_DOMAIN=http://backup.example.com (das http:// lässt die Edge für diesen Namen einfaches HTTP ausliefern, statt auf HTTPS umzuleiten und ein Zertifikat zu verlangen), RESTOW_PUBLIC_URL=https://backup.example.com und RESTOW_EDGE_TRUSTED_PROXIES wie oben, und es veröffentlicht Port 443 nur auf dem Loopback (RESTOW_HTTPS_PORT=127.0.0.1:). Im Proxy gelten Scheme http und Forward Port 80; die übrigen Einstellungen oben (proxy_buffering off;, HSTS am Proxy) bleiben.

Mit 0.1.0: von Hand

Nur im LAN, unverschlüsselte Strecke

Das ist der Weg für eine Installation mit dem Skript von 0.1.0, deren Edge keine verschlüsselte Strecke ausliefern kann. Die Strecke zwischen Proxy und Restow ist nicht verschlüsselt: Nutzen Sie sie nur in einem Netz, das Sie kontrollieren, und wechseln Sie auf die verschlüsselte Strecke, sobald Sie auf 0.2.0 aktualisiert haben (unten).

Setzen Sie in /opt/restow/.env die drei Variablen und führen Sie dann cd /opt/restow && docker compose up -d aus:

RESTOW_APP_DOMAIN=http://backup.example.com
RESTOW_PUBLIC_URL=https://backup.example.com
RESTOW_EDGE_TRUSTED_PROXIES=192.168.1.20/32

Ohne das Präfix http:// behandelt die Edge den Namen als öffentliche Seite: Sie beantwortet Port 80 mit einer Weiterleitung auf HTTPS (308) und will ein Zertifikat für den Namen; ein Proxy, der an Port 80 weiterleitet, bekommt also die Weiterleitung, und einer, der an 443 weiterleitet, findet kein brauchbares Zertifikat. Stellen Sie im Proxy Scheme http und Forward Port 80 ein (nicht 3000) und ergänzen Sie proxy_buffering off;. Prüfen Sie auf dem Restow-Host: curl -i -H 'Host: backup.example.com' http://127.0.0.1/ antwortet mit 200.

Wechsel auf die verschlüsselte Strecke nach dem Update auf 0.2.0:

1. Aktualisieren Sie wie unter Updates beschrieben. Das Ändern der Image-Zeilen in .env ersetzt die Compose-Datei nicht.
2. Ersetzen Sie /opt/restow/docker-compose.yml durch die aus den Release-Dateien von 0.2.0; sie reicht RESTOW_EDGE_TLS an die Edge weiter, die Datei von 0.1.0 nicht.
3. Setzen Sie in .env RESTOW_APP_DOMAIN=backup.example.com (ohne http://), RESTOW_EDGE_TLS=internal und RESTOW_HTTP_PORT=127.0.0.1: und führen Sie docker compose up -d aus.
4. Stellen Sie im Proxy Scheme https und Forward Port 443 ein und ergänzen Sie die Zeilen des Reiters Advanced von oben.

Installation von Hand mit Docker Compose

Auf jedem Linux-Host mit Docker und dem Docker-Compose-Plugin; das sind die Schritte, die das Skript automatisiert.

1. Stack und Umgebungsdatei holen

Der Release-Stack startet die veröffentlichten Images und baut nichts. Seine docker-compose.yml und env.example hängen an jedem GitHub-Release und liegen außerdem unter deploy/release im Repository (dort heißt die Beispieldatei .env.example). Laden Sie die beiden Dateien des gewünschten Releases (hier 0.4.7) in ein leeres Verzeichnis auf dem Server und erstellen Sie dann Ihre Umgebungsdatei aus dem Beispiel:

mkdir -p /opt/restow && cd /opt/restow
curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/docker-compose.yml
curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.4.7/env.example
cp env.example .env

In env.example selbst steht kein verwendbares Geheimnis. Jeder Wert muss erzeugt oder ausgefüllt werden. Committen oder teilen Sie .env niemals.

Jedes Release gibt es in zwei Builds. Wählen Sie einen und verwenden Sie beide seiner Images, ein Anwendungs-Image (api, worker und scheduler) und ein Web-Image (Caddy-Edge und Web-Oberfläche):

Build	RESTOW_IMAGE	RESTOW_WEB_IMAGE	Enthält
Vollständig	ghcr.io/restow-backup/restow:0.4.7	ghcr.io/restow-backup/restow-web:0.4.7	Den Apache-2.0-Kern plus die Business- und Service-Provider-Module, die gesperrt bleiben, bis ein Lizenzschlüssel installiert ist. Ohne Schlüssel läuft er als Community.
Community	ghcr.io/restow-backup/restow-community:0.4.7	ghcr.io/restow-backup/restow-web-community:0.4.7	Nur den Apache-2.0-Kern, für einen Mandanten. Kein Code von Business oder Service Provider und keine Lizenzeinstellungen.

Nehmen Sie den vollständigen Build, wenn Sie Business oder Service Provider später vielleicht brauchen: Ein Lizenzschlüssel schaltet sie frei, ohne die Images zu wechseln. Nehmen Sie den Community-Build, wenn Sie den Apache-2.0-Kern und nichts anderes möchten. Beide Builds nutzen dasselbe Datenbankschema; Sie können also später wechseln, indem Sie die beiden Image-Zeilen in .env ändern und docker compose up -d ausführen.

Alle vier Images tragen dasselbe Tag, die Release-Version ohne führendes v (ein Tag latest gibt es nicht), und werden für amd64 und arm64 gebaut. Jedes Image ist signiert und enthält eine SBOM; wie Sie die Signatur prüfen, bevor Sie den Stack starten, steht unter Ein Release verifizieren.

2. Erforderliche Werte ausfüllen

Füllen Sie jeden Wert im Abschnitt Required von env.example aus; die Kommentare in der Datei sagen, wie Sie jeden erzeugen. Mindestens:

Variable	Was sie ist
RESTOW_IMAGE	Das Anwendungs-Image mit Version, zum Beispiel ghcr.io/restow-backup/restow:0.4.7 (vollständig) oder ghcr.io/restow-backup/restow-community:0.4.7 (Community). Compose startet ohne diesen Wert nicht.
RESTOW_WEB_IMAGE	Das Web-Image desselben Builds mit derselben Version, zum Beispiel ghcr.io/restow-backup/restow-web:0.4.7 oder ghcr.io/restow-backup/restow-web-community:0.4.7.
POSTGRES_PASSWORD	Passwort für den Postgres-Superuser, den Docker Compose anlegt (POSTGRES_USER, Standard restow).
DATABASE_MIGRATION_URL	Verbindungszeichenfolge für dieselbe Eigentümer-Rolle, führt nur Migrationen aus.
DATABASE_URL	Die Anwendungsrolle, der Row Level Security unterliegt. Der Migrationsschritt legt diese Rolle mit dem hier angegebenen Namen und Passwort an.
DATABASE_PROVIDER_URL	Die Installationsrolle (BYPASSRLS), für installationsweite Abfragen. Wird genauso angelegt.
RESTOW_MASTER_KEY	32-Byte-Schlüsselverschlüsselungsschlüssel (KEK), base64. Siehe die Warnung unten.
BETTER_AUTH_SECRET	Secret für die eigenen Tokens und Sitzungen des Auth-Systems.
RESTOW_APP_DOMAIN	Die reine Domain, die Caddy ausliefert. Im öffentlichen Modus fordert Caddy dafür ein Zertifikat an. Compose startet ohne sie nicht.
RESTOW_PUBLIC_URL	Genau die Adresse, die Browser öffnen, z. B. https://restow.example.com oder http://localhost:5173. Legt die Passkey-Origin, die Entra-Redirect-URI und den Journal-Hostnamen fest.

Erzeugen Sie die beiden Secrets mit:

openssl rand -base64 32   # RESTOW_MASTER_KEY
openssl rand -base64 32   # BETTER_AUTH_SECRET

Erzeugen Sie ein eigenes Passwort für jede Datenbankrolle sowie für POSTGRES_PASSWORD auf dieselbe Weise, zum Beispiel:

openssl rand -hex 16

Alles andere hat einen dokumentierten Standardwert und kann leer bleiben, solange Sie ihn nicht ändern müssen; alles unter Optional in env.example funktioniert ohne Wert. Die Release-Stack-Referenz erklärt jede Variable aus env.example mit ihrem Standardwert, und die vollständige Liste steht unter Referenz → Umgebungsvariablen.

Die drei Datenbank-Rollen

Restow verbindet sich absichtlich mit drei verschiedenen Rollen zu PostgreSQL, damit Row Level Security von der Datenbank erzwungen wird und nicht nur vom Anwendungscode:

1. Eigentümer (DATABASE_MIGRATION_URL, Composes POSTGRES_USER): führt die Migrationen aus und besitzt jede Tabelle. Zur Laufzeit nutzt nichts anderes diese Rolle.
2. Anwendungsrolle (DATABASE_URL): NOSUPERUSER, kann Row Level Security nicht umgehen, besitzt keine Tabelle. Die gesamte alltägliche Mandantenarbeit läuft über diese Rolle; eine Abfrage ohne festgelegten Mandanten sieht nichts, eine mit festgelegtem Mandanten sieht nur diesen.
3. Installationsrolle (DATABASE_PROVIDER_URL, BYPASSRLS), nur für Arbeiten, die mandantenübergreifend sehen müssen oder bevor ein Mandant bekannt ist: Sitzungs-/API-Schlüssel-Abfragen, die Mandantenliste, installationsweite Einstellungen und Lizenzstatus, den Scheduler, die Webhook-Zustellung und das eigene Schema von pg-boss.

Der Migrationsschritt legt die Anwendungs- und die Installationsrolle mit den Namen und Passwörtern aus diesen beiden Verbindungszeichenfolgen an. Sie legen sie nicht von Hand an. api, worker und scheduler prüfen jeweils beim Start, dass ihre Anwendungsrolle Row Level Security nicht umgehen kann, und starten nicht, wenn sie es doch könnte.

Die Anmeldung hat seit 0.3.5 eine eigene Rolle. Die Auth-Rolle ist neben der Installationsrolle die einzige, die die Anmelde-Tabellen erreicht (Sitzungen, Passwörter, Passkeys, Zwei-Faktor-Geheimnisse), und der Code für Anmeldung, Konten und Mitgliedschaften läuft auf ihr, ebenfalls unter Row Level Security. Die Anwendungsrolle bleibt bei den Mandantendaten: Von den Anmelde-Tabellen sieht sie nur den Namen und die E-Mail-Adresse einer Person, sie erreicht keine Installationstabelle (Einstellungen, Lizenz, Provider, Dienst-Heartbeats, Provider-Team), und in der Job-Warteschlange darf sie nur einen Job hinzufügen. Die Migration legt die Auth-Rolle an und hält sie aktuell, mit einem Login, der von den beiden anderen abgeleitet wird (<Anwendungsrolle>_auth, zum Beispiel restow_app_auth). Dafür setzen Sie nichts; DATABASE_AUTH_URL ist optional, für einen eigenen Login. Siehe Umgebungsvariablen → Datenbank.

Sichern Sie RESTOW_MASTER_KEY offline, bevor Sie sich auf diese Installation verlassen

RESTOW_MASTER_KEY umschließt den Datenverschlüsselungsschlüssel jedes Mandanten. Geht er verloren, wird jede verschlüsselte Sicherung und jedes Archivobjekt dieser Installation dauerhaft unlesbar. Es gibt keinen Wiederherstellungsweg. Legen Sie eine Offline-Kopie an (zum Beispiel ausgedruckt oder auf verschlüsseltem Wechseldatenträger, getrennt vom Server selbst aufbewahrt), bevor Ihre erste echte Sicherung läuft, nicht danach. Siehe Restow selbst sichern.

3. Stack starten

docker compose up -d

Compose lädt beim ersten Start die beiden Images und baut nichts. Für ein späteres Update ändern Sie die beiden Image-Zeilen in .env und führen docker compose pull && docker compose up -d aus; siehe Updates.

Datenbankmigrationen laufen automatisch als Teil des Starts des api-Containers, bevor er Anfragen bedient. Es gibt keinen separaten Migrationsbefehl, den Sie von Hand ausführen müssten.

4. Funktionsfähigkeit prüfen

curl http://127.0.0.1:3000/healthz
curl http://127.0.0.1:3000/readyz

Beide sollten erfolgreich antworten, sobald die Container postgres, api, worker und scheduler laufen (docker compose ps). Öffnen Sie dann RESTOW_PUBLIC_URL in einem Browser. Restow zeigt beim ersten Zugriff den Einrichtungsassistenten.

Dessen erster Schritt fragt nach der Sprache (ab 0.2.0), dann nach dem einmaligen Setup-Token, das nachweist, dass Sie den Server betreiben. Bis die Einrichtung abgeschlossen ist, gibt die api es bei jedem Start in ihrem Log aus:

docker compose logs api | grep 'SETUP TOKEN'

Jeder Neustart der api erzeugt ein neues Token; verwenden Sie das zuletzt ausgegebene. Für eine unbeaufsichtigte Installation setzen Sie ein eigenes Token als RESTOW_SETUP_TOKEN in .env (mindestens 16 Zeichen, zum Beispiel openssl rand -hex 16); es wird dann nie ins Log geschrieben. Der nächste Schritt ist der Hinweis für Betreiber, den Sie akzeptieren müssen, bevor die Einrichtung gespeichert werden kann.

Verliert ein Inhaber später seinen Passkey, seine Authenticator-App oder sein Passwort, wird der Zugang auf dem Server mit docker compose exec api restow admin recover --email <inhaber> wiederhergestellt; siehe Admin-Zugang wiederherstellen.

Images prüfen (optional)

Jedes Release-Image ist mit cosign signiert (keyless, über die OIDC-Identität von GitHub). So können Sie prüfen, dass ein Image vom Release-Workflow des Projekts gebaut wurde:

cosign verify ghcr.io/restow-backup/restow:0.4.7 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Prüfen Sie restow-web, beim Community-Build restow-community und restow-web-community, auf dieselbe Weise. Ein Release verifizieren erklärt das, die genaue Identität für eine Version, die SBOM und die signierten Prüfsummenlisten ausführlich.

Nach der Installation

Import-Ordner

Der Release-Stack bindet einen Ordner des Hosts schreibgeschützt in die Container api und worker unter /var/lib/restow/import ein, für den Mail-Datei-Import. RESTOW_IMPORT_DIR legt den Host-Ordner fest (Standard ./import neben der Compose-Datei). Jeder Mandant nutzt seinen eigenen Unterordner, <Ordner>/<Mandanten-Slug>/, den Sie selbst anlegen. Restow schreibt nie in diesen Ordner und löscht nie daraus; er muss für den Benutzer lesbar sein, unter dem die Container laufen. Die Variable können Sie leer lassen, bis Sie sie brauchen.

Updates sind Opt-in

Restow aktualisiert sich nicht selbst. Die Update-Prüfung unter Einstellungen, Updates ist aus, bis eine Administration sie einschaltet, und der optionale Updater läuft nur, wenn Sie ihn mit docker compose --profile updater up -d starten, dafür braucht es keine Zeile in .env (er fixiert sein eigenes Image seit 0.2.1 selbst). Der Updater bindet den Docker-Socket ein, und der ist auf dem Host gleichbedeutend mit root; er installiert nur Release-Images, deren Signatur er geprüft hat. Lesen Sie Updates, bevor Sie eines von beiden einschalten.

Editionen und Lizenzschlüssel

Community (Backup, Restore, Archiv, Endpoint-Backup sowie Mail-Import und -Export) ist kostenlos und braucht keinen Schlüssel: Open Source unter der Apache License 2.0, kein Postfachlimit. Sie läuft mit beiden Builds. Business und Service Provider brauchen die vollständigen Images: Dort schaltet ein offline geprüfter Lizenzschlüssel, installiert unter Installation → Lizenz, die zusätzlichen Funktionen in derselben Installation frei, ohne separaten Download oder Neuinstallation. Siehe Lizenz und Editionen für den Funktionsumfang je Edition, den heutigen Stand und die Prüfung des Schlüssels.