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. Danach führt Einrichtungsassistent durch den geführten Erststart, und Erste Schritte behandelt das Verbinden einer Quelle und den Nachweis Ihrer ersten Sicherung.

Voraussetzungen

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). 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-/SMB-Freigabe verlagert dieses Wachstum vom Restow-Host weg (siehe Backups und Zeitpläne).

Restow 0.1.0 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 ghcr.io/restow-backup/restow und ghcr.io/restow-backup/restow-web (signiert, mit SBOM) oder bauen es mit der Compose-Datei des Repositorys aus dem Quellcode; beide Wege stehen unten unter Installation. Node.js 22 und pnpm 9 brauchen Sie nur, um Restow zu entwickeln, nicht um einen der beiden Stacks zu betreiben.

Siehe die Release-Notes zu 0.1.0 für den Lieferumfang und bekannte Lücken. Der Quellcode liegt auf GitHub.

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 und Entra-SSO für Endnutzer werden darin nicht angeboten (siehe Einrichtungsassistent).

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; der Release-Stack bindet den eigenen Port des api-Containers ausschließlich an Loopback und veröffentlicht keinen PostgreSQL-Port (der Quell-Stack bindet PostgreSQL an Loopback). 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

1. Stack und Umgebungsdatei holen

Der Release-Stack startet die veröffentlichten Images und baut nichts. Seine docker-compose.yml und env.example liegen unter deploy/release im Repository und hängen an jedem GitHub-Release. Laden Sie die beiden Dateien des gewünschten Releases (hier 0.1.0) 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.1.0/docker-compose.yml
curl -fsSLO https://github.com/restow-backup/restow/releases/download/v0.1.0/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.

Die Release-Images heißen ghcr.io/restow-backup/restow (die Anwendung: api, worker und scheduler) und ghcr.io/restow-backup/restow-web (Caddy-Edge und Web-Oberfläche). Beide tragen dasselbe Tag, die Release-Version ohne führendes v, und beide werden für amd64 und arm64 gebaut. Jedes Release 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 leeren Wert in den Abschnitten Images, Address, Database und Secrets aus; die Kommentare in der Datei sagen, wie. Mindestens:

Variable	Was sie ist
`RESTOW_IMAGE`	Das Anwendungs-Image mit Version, zum Beispiel `ghcr.io/restow-backup/restow:0.1.0`. Compose startet ohne diesen Wert nicht.
`RESTOW_WEB_IMAGE`	Das Web-Image mit derselben Version, zum Beispiel `ghcr.io/restow-backup/restow-web:0.1.0`.
`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 (im Kommentar über der Variable) und kann leer bleiben, solange Sie ihn nicht ändern müssen; die in env.example als optional gekennzeichneten Abschnitte funktionieren ohne Wert. 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:

Eigentümer (DATABASE_MIGRATION_URL, Composes POSTGRES_USER): führt die Migrationen aus und besitzt jede Tabelle. Zur Laufzeit nutzt nichts anderes diese Rolle.
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.
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.

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 ist der Hinweis für Betreiber, den Sie vor allem anderen akzeptieren müssen.

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.1.0 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Ein Release verifizieren erklärt das, die SBOM und die signierte Prüfsummenliste ausführlich.

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. Der Updater bindet den Docker-Socket ein, und der ist auf dem Host gleichbedeutend mit root. Lesen Sie Updates, bevor Sie eines von beiden einschalten.

Stattdessen aus dem Quellcode bauen

Die docker-compose.yml des Repositorys baut beide Images aus dem Quellcode, statt sie zu laden. Holen Sie das Repository auf den Server, führen Sie cp .env.example .env aus, füllen Sie dieselben Werte wie oben aus (lassen Sie RESTOW_IMAGE und RESTOW_WEB_IMAGE leer: Compose baut und startet dann restow:local und restow-web:local) und starten Sie den Stack:

docker compose up -d

Der erste Start baut die Images (Dockerfile-Target runtime für api/worker/scheduler, Target web für Caddy); das dauert einige Minuten. Nach dem Holen einer neuen Version docker compose up -d --build ausführen. Alles andere auf dieser Seite gilt unverändert.

Editionen und Lizenzschlüssel

Das Image oben ist für jede Edition dasselbe. Community (Backup, Restore, Archiv, Endpoint-Backup sowie Mail-Import und -Export) ist kostenlos und braucht keinen Schlüssel: AGPL-3.0, kein Postfachlimit. Business und Service Provider schalten zusätzliche Funktionen in derselben Installation per offline geprüftem Lizenzschlüssel 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.