Release-Stack-Referenz

Der Release-Stack besteht aus zwei Dateien, docker-compose.yml und env.example. Beide hängen an jedem GitHub-Release und liegen im Repository unter deploy/release (dort heißt die Beispieldatei .env.example). Die Compose-Datei startet die veröffentlichten Images und baut nichts; die docker-compose.yml im Stammverzeichnis des Repositorys baut Restow stattdessen aus dem Quellcode. Die Release-Pipeline führt ihre Smoke-Checks genau gegen diese Datei aus, mit beiden Builds.

Bis 0.3.5 standen die Erklärungen dieser Seite als Kommentare in den beiden Dateien. Ab 0.3.6 enthalten die Dateien fast keine Kommentare mehr und verweisen hierher. Diese Seite ist die Referenz: was jeder Dienst tut, welche Ports und Volumes er hat und warum, und was jede Variable der .env bedeutet. Die Installationsschritte stehen unter Erste Schritte; alle übrigen Variablen und die langen Erklärungen stehen unter Umgebungsvariablen.

cp env.example .env     # dann die erforderlichen Werte ausfüllen
docker compose up -d

Auf einer dedizierten VM erledigt das Installationsskript das für Sie, in /opt/restow.

In der Compose-Datei steht kein Secret: Jeder Wert kommt aus der .env. Committen Sie die .env oder echte Werte nie.

Das Compose-Projekt heißt restow (name: restow am Anfang der Datei). Das Installationsskript, der Updater und der Mounter verlassen sich auf diesen Namen, ebenso die Volume-Namen: Compose leitet sie daraus ab, die Datenbank liegt also in restow_pgdata und der Chunk-Store in restow_restow-data. Siehe Einstellungen, die gefährlich zu ändern sind.

Dienste im Überblick

docker compose up -d startet die ersten fünf Dienste. Die letzten beiden gehören zu einem Compose-Profil und starten nur, wenn Sie es verlangen, einmal, mit ihrem eigenen Befehl. Seit 0.4.0 verlangt das Installationsskript das Profil mounts standardmäßig, eine neue Installation betreibt den Mounter also mit (--no-mounter lässt ihn aus).

Dienst	Image	Profil	Veröffentlichte Ports	Was er ist
`postgres`	`postgres:16-alpine`	keins	keine	Die Datenbank.
`api`	`RESTOW_IMAGE`, `ROLE=api`	keins	`127.0.0.1:3000`, der Journal-Empfänger	Die REST-API, die Migrationen, der Journal-Empfänger.
`worker`	`RESTOW_IMAGE`, `ROLE=worker`	keins	keine	Führt die Jobs in der Warteschlange aus und stellt Webhooks zu.
`scheduler`	`RESTOW_IMAGE`, `ROLE=scheduler`	keins	keine	Plant die fälligen Zeitpläne.
`caddy`	`RESTOW_WEB_IMAGE`	keins	80 und 443	Die Web-Edge: Weboberfläche, TLS, Proxy zur `api`.
`updater`	`RESTOW_UPDATER_IMAGE`, sonst `RESTOW_IMAGE`, `ROLE=updater`	`updater`	keine (8090 im Compose-Netz)	Opt-in: wendet Updates aus der Weboberfläche an.
`mounter`	`RESTOW_MOUNTER_IMAGE`, sonst `RESTOW_IMAGE`, `ROLE=mounter`	`mounts`	keine (8091 im Compose-Netz)	Führt die Container aus, die Freigaben sichern und wiederherstellen (seit 0.4.0), und bindet NFS-Freigaben als Repository-Speicher aus der Weboberfläche ein. Wird vom Installationsskript standardmäßig gestartet, sonst Opt-in.

api, worker, scheduler, updater und mounter starten ein und dasselbe Anwendungs-Image; die Variable ROLE bestimmt, was der Prozess tut.

Die zwei Builds

Jedes Release hat zwei Builds, und RESTOW_IMAGE und RESTOW_WEB_IMAGE in der .env wählen einen. Nutzen Sie beide Images eines Builds in derselben Version:

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 (Restow Enterprise License), die gesperrt bleiben, bis ein Lizenzschlüssel installiert ist.
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: keine Business- oder Service-Provider-Module, ein Mandant.

Alle vier Images tragen dasselbe Tag, die Release-Version ohne führendes v. Ein Tag latest gibt es nicht. Der optionale Updater schreibt beide Zeilen bei jedem Update selbst um, mit den Images des Builds, aus dem er läuft. Ohne ihn ändern Sie die beiden Zeilen selbst, um zu aktualisieren oder den Build zu wechseln, und führen dann docker compose pull && docker compose up -d aus (siehe Updates). Setzen Sie RESTOW_VERSION nicht in der .env: Das Image trägt seine Version selbst. Wie Sie die Signaturen prüfen, steht unter Ein Release verifizieren.

Ein Update ändert nur die .env, nie die docker-compose.yml. Führen Sie das Installationsskript (ab 0.3.6) erneut auf einer Installation aus, bringt es docker-compose.yml auf die Datei des in der .env genannten Releases, geprüft gegen die signierte SHA256SUMS des Releases; eine abweichende Datei bleibt als docker-compose.yml.bak-<Zeit> erhalten. Eigene Änderungen gehören in docker-compose.override.yml, nicht in docker-compose.yml (siehe docker-compose.override.yml und Erneut ausführen).

Der gemeinsame Block `x-restow-app`

Die drei Server-Rollen api, worker und scheduler teilen sich einen Block, den jede mit <<: *restow-app einbindet:

x-restow-app: &restow-app
  image: ${RESTOW_IMAGE:?set RESTOW_IMAGE in .env (for example ghcr.io/restow-backup/restow:0.4.7 or ghcr.io/restow-backup/restow-community:0.4.7)}
  env_file:
    - .env
  depends_on:
    postgres:
      condition: service_healthy
  restart: unless-stopped

image ist RESTOW_IMAGE. Compose bricht mit der obigen Meldung ab, wenn die Variable leer ist.
env_file reicht die gesamte .env als Umgebung an die drei Rollen weiter; jede Variable, die Sie dort setzen, erreicht also api, worker und scheduler gleichermaßen. caddy bekommt nur vier Variablen (unten), updater und mounter keine.
depends_on wartet auf ein gesundes postgres. worker und scheduler schreiben ihr eigenes depends_on, weil der eigene Schlüssel eines Dienstes den gemeinsamen ersetzt: Er nennt postgres noch einmal und ergänzt die api.
restart: unless-stopped startet den Container nach einem Absturz oder einem Neustart des Hosts neu, außer Sie haben ihn gestoppt.

Die Dienste

postgres

PostgreSQL 16 (postgres:16-alpine). Es hält Metadaten, die Job-Warteschlange und das Audit-Log; die gesicherten Inhalte liegen im Chunk-Store, nicht hier. Die Datenbankmigrationen wendet die api an.

Einstellungen: POSTGRES_USER und POSTGRES_DB (beide Standard restow) und POSTGRES_PASSWORD, das erforderlich ist: Compose startet postgres ohne es nicht. Ändern Sie Benutzer und Datenbanknamen nur vor dem ersten Start, und nutzen Sie dieselben Namen in DATABASE_MIGRATION_URL.
Ports: keine. Der Release-Stack veröffentlicht keinen PostgreSQL-Port; die anderen Dienste erreichen es über das Compose-Netz als postgres:5432.
Volume: die Datenbankdateien unter /var/lib/postgresql/data. Seit 0.4.0 ist der Mount typisiert und kommt aus der .env: type: ${RESTOW_POSTGRES_DATA_TYPE:-volume}, source: ${RESTOW_POSTGRES_DATA:-pgdata}, bind.create_host_path: false. Mit beiden leeren Variablen ist es das Docker-Volume pgdata; nach einem Verschieben auf einen anderen Datenträger (Installation → Datenbank) ist es dieses Host-Verzeichnis. create_host_path: false lässt Docker den Start von PostgreSQL verweigern, wenn das Verzeichnis fehlt, statt ein leeres anzulegen. Behalten Sie diesen Mount unverändert, siehe Datenbank.
Health-Check: pg_isready -U ${POSTGRES_USER:-restow} -d ${POSTGRES_DB:-restow} alle 10 Sekunden, Timeout 5 Sekunden, 5 Wiederholungen, 10 Sekunden Startphase.
Hängt ab von: nichts. Neustart: unless-stopped.

api

Das Anwendungs-Image mit ROLE=api: die REST-API, die die Weboberfläche und die Agents nutzen, der Journal-Empfänger des Archivs und die Datenbankmigrationen. Die api führt die Migrationen als Datenbankeigentümer aus, bevor sie /healthz beantwortet, und startet nicht, wenn eine fehlschlägt. Der Migrationsschritt legt außerdem die Anwendungs-Datenbankrollen an, mit denen sich die anderen Prozesse anmelden.

Einstellungen: die gesamte .env, dazu ROLE=api, RESTOW_UPDATER_URL (Standard http://updater:8090, wo die api den optionalen Updater sucht) und RESTOW_MOUNTER_URL (Standard http://mounter:8091, dasselbe für den Mounter). Unter diesen beiden Adressen antwortet nichts, solange das passende Profil nicht läuft.

Ports:

Zuordnung Warum

127.0.0.1:${RESTOW_API_PORT:-3000}:3000 Nur Loopback: Health-Checks und die REST-API auf dem Host selbst. Caddy erreicht die api über das Compose-Netz und nutzt diesen Port nicht.

${JOURNAL_SMTP_BIND:-127.0.0.1}:${JOURNAL_SMTP_PORT:-2525}:${JOURNAL_SMTP_PORT:-2525} Der SMTP-Journal-Empfänger des Archivs (Business und Service Provider). Er lauscht nur, wenn JOURNAL_SMTP_PORT in der .env gesetzt ist; bis dahin bildet das einen geschlossenen Port (2525) auf der Loopback-Schnittstelle ab, sodass eine Standardinstallation keinen Mail-Port zum Netz öffnet. Exchange Online liefert an Port 25 und muss den Empfänger direkt erreichen, nicht über Caddy: Setzen Sie JOURNAL_SMTP_PORT=25 und JOURNAL_SMTP_BIND=0.0.0.0. Der Empfänger braucht ein TLS-Zertifikat, siehe Das Zertifikat des Journal-Empfängers.

Netzwerke (seit 0.4.0): default und das interne Netz runners. Runner für Freigaben erreichen die api nur über runners, das keine Route nach außen hat (siehe Netzwerke).

Zuordnung	Warum
`127.0.0.1:${RESTOW_API_PORT:-3000}:3000`	Nur Loopback: Health-Checks und die REST-API auf dem Host selbst. Caddy erreicht die `api` über das Compose-Netz und nutzt diesen Port nicht.
`${JOURNAL_SMTP_BIND:-127.0.0.1}:${JOURNAL_SMTP_PORT:-2525}:${JOURNAL_SMTP_PORT:-2525}`	Der SMTP-Journal-Empfänger des Archivs (Business und Service Provider). Er lauscht nur, wenn `JOURNAL_SMTP_PORT` in der `.env` gesetzt ist; bis dahin bildet das einen geschlossenen Port (2525) auf der Loopback-Schnittstelle ab, sodass eine Standardinstallation keinen Mail-Port zum Netz öffnet. Exchange Online liefert an Port 25 und muss den Empfänger direkt erreichen, nicht über Caddy: Setzen Sie `JOURNAL_SMTP_PORT=25` und `JOURNAL_SMTP_BIND=0.0.0.0`. Der Empfänger braucht ein TLS-Zertifikat, siehe Das Zertifikat des Journal-Empfängers.

Volumes:

Mount	Warum
`restow-data` unter `/data`	Der lokale Standard-Chunk-Store: `STORAGE_LOCAL_PATH=/data/chunks` liegt hier.
`${RESTOW_IMPORT_DIR:-./import}` unter `/var/lib/restow/import`, schreibgeschützt	Der Import-Ordner auf dem Server: Die `api` listet ihn auf, der `worker` liest ihn. Mit Absicht schreibgeschützt, denn Restow schreibt nie in ihn und löscht nie daraus. Siehe Mail-Dateien importieren und exportieren.
`${JOURNAL_TLS_DIR:-./journal-tls}` unter `/etc/restow/journal-tls`, schreibgeschützt	Die TLS-Zertifikatskette und der private Schlüssel (PEM) des Journal-Empfängers. Exchange Online verlangt TLS, und der Empfänger startet nicht ohne Zertifikat. Ein Verzeichnis und nicht zwei einzelne Dateien, damit eine Erneuerung, die die Dateien ersetzt, bemerkt wird: Der Empfänger liest sie alle paar Minuten neu, ohne Neustart. Legen Sie dort `fullchain.pem` und `privkey.pem` ab und richten Sie `JOURNAL_TLS_CERT_PATH` und `JOURNAL_TLS_KEY_PATH` in der `.env` auf `/etc/restow/journal-tls/<Datei>`. Wann die `api` selbst neu gestartet werden muss, steht unter Das Zertifikat des Journal-Empfängers.
`restow-updater-shared` unter `/updater-shared`, schreibgeschützt	Das gemeinsame Secret des Updaters, das die `api` mit jeder Anfrage sendet. Leer, bis das Profil `updater` einmal gelaufen ist. Behalten Sie diese Zeile.
`restow-mounter-shared` unter `/mounter-shared`, schreibgeschützt	Dasselbe für den Mounter. Leer, bis das Profil `mounts` einmal gelaufen ist. Behalten Sie diese Zeile. Eine `api` ohne diesen Mount wurde aus einer Compose-Datei gestartet, die älter ist als der Mounter, siehe mounter.

Health-Check: node -e "fetch('http://127.0.0.1:3000/healthz')…" alle 30 Sekunden, Timeout 5 Sekunden, 5 Wiederholungen, 20 Sekunden Startphase.
Hängt ab von: einem gesunden postgres. Neustart: unless-stopped.

worker

Das Anwendungs-Image mit ROLE=worker: führt die Jobs in der Warteschlange aus (Backups, Restores, Prüfungen, Importe und Exporte) und stellt Webhooks zu.

Einstellungen (seit 0.4.0): ROLE=worker, RESTOW_MOUNTER_URL (Standard http://mounter:8091: Der Worker bittet den Mounter, Runner für Freigaben zu starten), RESTOW_MOUNTER_MAX_RUNNERS (Standard 8) und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB (Standard 16384), dieselben Obergrenzen, die der Mounter bekommt. Ohne Mounter warten Läufe für Freigaben mit share.mounter_unavailable.
Ports: keine.
Volumes: restow-data unter /data, derselbe Chunk-Store wie bei der api, der Import-Ordner, schreibgeschützt, und (seit 0.4.0) restow-mounter-shared unter /mounter-shared, schreibgeschützt, das gemeinsame Secret des Mounters. Der Worker hat kein Journal-Verzeichnis und kein Secret des Updaters.
stop_grace_period: 60s (seit 0.3.5): die Zeit, die laufende Jobs bekommen, um einen Prüfpunkt zu speichern, wenn der Worker stoppt, bei einem Update oder einem docker compose up -d. Dockers Standard von 10 Sekunden schnitt das ab. Ein Job, der nach einem gespeicherten Prüfpunkt unterbrochen wurde, setzt sich fort, ohne einen Wiederholungsversuch zu verbrauchen. Das eigene Herunterfahren des Workers wartet höchstens WORKER_SHUTDOWN_TIMEOUT_MS (50 Sekunden), und das muss unter den 60 Sekunden bleiben. Eine Compose-Datei, die Sie von Hand pflegen, braucht diese Zeile; siehe Updates.
Hängt ab von: einem gesunden postgres und einer gesunden api: Die api wendet die Migrationen an und legt die Anwendungs-Datenbankrollen an, bevor sie /healthz beantwortet, und der Worker meldet sich mit ihnen an.
Health-Check: keiner. Neustart: unless-stopped.

scheduler

Das Anwendungs-Image mit ROLE=scheduler: plant die fälligen Zeitpläne, standardmäßig im Takt von 30 Sekunden (siehe Scheduler).

Ports und Volumes: keine.
Hängt ab von: einem gesunden postgres und einer gesunden api, aus demselben Grund wie der worker.
Health-Check: keiner. Neustart: unless-stopped.

caddy

Das Web-Image (RESTOW_WEB_IMAGE): die gebaute Weboberfläche und die Caddy-Edge. Sie liefert die Weboberfläche aus, terminiert TLS und leitet /api/* (und die Agent- und Install-Pfade, siehe Ports und Rollen) an die api weiter. Für ihr Zertifikat muss RESTOW_APP_DOMAIN auf diesen Host zeigen, mit erreichbaren Ports 80 und 443.

Image: RESTOW_WEB_IMAGE, erforderlich. Compose bricht ohne es ab, und die Meldung nennt ein Beispiel wie ghcr.io/restow-backup/restow-web:0.4.7 oder ghcr.io/restow-backup/restow-web-community:0.4.7.
Einstellungen: nur vier Variablen, kein env_file. RESTOW_APP_DOMAIN ist erforderlich, zum Beispiel app.example.com (Compose bricht ohne sie ab). RESTOW_EDGE_HSTS und RESTOW_EDGE_TRUSTED_PROXIES sind standardmäßig leer. RESTOW_EDGE_TLS ist standardmäßig acme, und ein leerer Wert bedeutet ebenfalls acme.
RESTOW_EDGE_TLS: acme holt das Zertifikat von Let’s Encrypt für eine öffentliche Domain oder von Caddys eigener Zertifizierungsstelle für localhost und interne Namen. internal nutzt Caddys eigene Zertifizierungsstelle für RESTOW_APP_DOMAIN, egal bei welchem Namen, ohne öffentlichen DNS-Eintrag und ohne eingehenden Port 80. Nutzen Sie es, wenn ein weiterer Reverse-Proxy vor dieser Edge steht und sie über HTTPS erreicht (die Option --behind-proxy des Installationsskripts, ab 0.2.0). Das Root-Zertifikat, mit dem Sie die Edge prüfen, ist /data/caddy/pki/authorities/local/root.crt im Volume caddy-data, zum Beispiel docker compose cp caddy:/data/caddy/pki/authorities/local/root.crt .. Siehe Hinter einem Reverse-Proxy.
Ports: ${RESTOW_HTTP_PORT:-80}:80 und ${RESTOW_HTTPS_PORT:-443}:443, für die Weboberfläche, die Agents und die Let’s-Encrypt-Prüfung. Jede Variable nimmt einen Port oder eine Adresse mit Port (127.0.0.1:8443), um ihn nur auf dieser Schnittstelle zu veröffentlichen. Let’s Encrypt braucht beide auf den Standardports; ändern Sie sie daher nur hinter einem weiteren Reverse-Proxy oder für eine lokale Evaluierung. Siehe Netzwerk und Ports.
Volumes: caddy-data unter /data (die Zertifikate und Caddys eigene Zertifizierungsstelle) und caddy-config unter /config.
Hängt ab von: api (gestartet, keine Health-Bedingung). Health-Check: keiner. Neustart: unless-stopped.

updater

Der optionale Updater, Profil updater. Er wendet ein Update aus Installation → Updates an: Er prüft und zieht die neuen Images, sichert die Datenbank, erstellt die Dienste neu und setzt zurück, wenn die neue Version nicht hochkommt. Lesen Sie zuerst Updates.

Image: Es gibt kein eigenes Updater-Image. Es ist das Anwendungs-Image, gestartet mit ROLE=updater: RESTOW_UPDATER_IMAGE, falls gesetzt, sonst RESTOW_IMAGE. Siehe Wie Updater und Mounter ihr Image fixieren.
Einstellungen: ROLE=updater, RESTOW_UPDATER_PROJECT_DIR (aus RESTOW_PROJECT_DIR), RESTOW_UPDATER_SELF_UPDATE (Standard true), RESTOW_UPDATER_API_URL (http://api:3000), RESTOW_UPDATER_SOURCE_HOSTS, RESTOW_UPDATER_IMAGE_REPOSITORY und RESTOW_UPDATER_WEB_IMAGE_REPOSITORY. Kein env_file: Er hat keinen Datenbankzugriff und hält kein Anwendungs-Secret.
Ports: keine veröffentlicht. Der Dienst legt 8090 nur im Compose-Netz offen; die api erreicht ihn unter RESTOW_UPDATER_URL.

Volumes:

Mount	Warum
`/var/run/docker.sock`	Um `docker` und `docker compose` gegen das Docker des Hosts auszuführen. Root auf dem Host.
`${RESTOW_PROJECT_DIR:-.}` unter `${RESTOW_PROJECT_DIR:-/project}`	Das Verzeichnis mit `docker-compose.yml` und `.env`. Es wird unter `/project` eingehängt, und der Updater liest seinen Host-Pfad aus dem Mount. Setzen Sie `RESTOW_PROJECT_DIR` (den absoluten Pfad, zum Beispiel `/opt/restow`) nur, um es stattdessen unter demselben Pfad einzuhängen; das Installationsskript tut das.
`restow-updater` unter `/state`	Der Zustand des Updaters und die Datenbank-Dumps, die er vor einem Update zieht.
`restow-updater-shared` unter `/updater-shared`	Das gemeinsame Secret, das der Updater beim ersten Start schreibt und die `api` liest.

security_opt: no-new-privileges:true.
Health-Check: /healthz auf Port 8090 alle 30 Sekunden, Timeout 5 Sekunden, 3 Wiederholungen, 10 Sekunden Startphase. Neustart: unless-stopped.

mounter

Der Mounter, Profil mounts. Seit 0.4.0 startet er außerdem die kurzlebigen Runner-Container, die eine Freigabe für einen Lauf einbinden, sichern oder hineinwiederherstellen und danach entfernt werden: Dieser Weg berührt die Compose-Override-Datei nie und startet api und worker nie neu (Freigaben). Er bindet NFS-Freigaben als Backup-Speicher über die Weboberfläche ein (Installation → Standard-Repository & Netzlaufwerke): Er trägt sie als Docker-Volumes in docker-compose.override.yml im Projektverzeichnis ein, hängt sie unter /mnt/restow/<name> in api und worker ein und erstellt diese beiden Dienste neu. Lesen Sie zuerst NFS-Freigaben (Mounter).

Image: das Anwendungs-Image, gestartet mit ROLE=mounter: RESTOW_MOUNTER_IMAGE, falls gesetzt, sonst RESTOW_IMAGE.
Einstellungen: ROLE=mounter, RESTOW_MOUNTER_PROJECT_DIR (aus RESTOW_PROJECT_DIR) und, seit 0.4.0, RESTOW_MOUNTER_MAX_RUNNERS (Standard 8, die harte Obergrenze der Runner für Freigaben) und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB (Standard 16384, die Obergrenze des Arbeitsspeichers je Runner). Kein env_file: Er hält keine Zugangsdaten der Anwendung. Die weiteren Einstellungen des Mounters stehen in den Umgebungsvariablen.
Ports: keine veröffentlicht. Der Dienst legt 8091 nur im Compose-Netz offen, und niemand außer der api erreicht ihn.
Volumes: der Docker-Socket, das Projektverzeichnis (eingehängt wie beim Updater), restow-mounter unter /state (sein Vorgangs-Log) und restow-mounter-shared unter /mounter-shared (das gemeinsame Secret, das die api liest).
security_opt: no-new-privileges:true.
Health-Check: /healthz auf Port 8091 alle 30 Sekunden, Timeout 5 Sekunden, 3 Wiederholungen, 10 Sekunden Startphase. Neustart: unless-stopped.
Eine Compose-Datei aus der Zeit vor dem Mounter: Eine Installation, deren docker-compose.yml vor 0.3.1 entstanden ist (0.3.0 wurde nie veröffentlicht), hat keinen Dienst mounter; Compose antwortet daher no such service: mounter, und ihre api hat keinen Mount mounter-shared. Führen Sie das Installationsskript darauf erneut aus, siehe Die zwei Builds und no such service: mounter.

Wie Updater und Mounter ihr Image fixieren

Beide halten den Docker-Socket, ihr Image darf sich also nicht mit dem Umschreiben von RESTOW_IMAGE ändern, das jedes Update vornimmt. Jeder fixiert sein eigenes Image per Digest in der .env.

Der Updater (RESTOW_UPDATER_IMAGE, optional):

Solange sie leer ist, startet der Dienst das Image aus RESTOW_IMAGE. Beim ersten Start schreibt der Updater RESTOW_UPDATER_IMAGE selbst in die .env, per Digest fixiert auf das Image, mit dem er läuft (zum Beispiel ghcr.io/restow-backup/restow:0.4.7@sha256:...).
Von da an folgt sein Image nicht mehr RESTOW_IMAGE. Kann er nicht fixieren (ein lokal gebautes Image hat keinen Registry-Digest, oder die .env ist nicht beschreibbar), zeigt der Reiter Updates die Blockade „Updater-Image nicht fixiert“.
Nach einem gelungenen Update aus einem signierten Release setzt der Updater RESTOW_UPDATER_IMAGE auf das geprüfte Image dieses Releases, per Digest, und erstellt sich neu. Auf ein aus dem Quellcode gebautes Image wechselt er nie. RESTOW_UPDATER_SELF_UPDATE=false schaltet das ab, und Sie ziehen ihn dann von Hand nach.
Setzen Sie RESTOW_UPDATER_IMAGE selbst, nehmen Sie ein Image desselben Builds wie RESTOW_IMAGE (restow-community beim Community-Build).

Der Mounter (RESTOW_MOUNTER_IMAGE, optional):

Solange sie leer ist, startet der Dienst das Image aus RESTOW_IMAGE. Beim ersten Start schreibt der Mounter RESTOW_MOUNTER_IMAGE in die .env, per Digest fixiert auf das Image, mit dem er läuft. Ein lokaler Build hat keinen Digest und wird nicht fixiert.
Läuft der optionale Updater, setzt der Updater sie bei jedem signierten Update, das er installiert, auf das geprüfte Image und erstellt den Mounter neu.
Ohne den Updater setzen Sie RESTOW_MOUNTER_IMAGE auf das Image des neuen Releases (oder leeren sie) und führen docker compose --profile mounts up -d mounter aus, sobald keine Änderung einer Freigabe läuft.

Volumes

Volume	Eingehängt von	Enthält
`pgdata`	`postgres` unter `/var/lib/postgresql/data`	Die Datenbankdateien, sofern `RESTOW_POSTGRES_DATA` nicht auf ein Host-Verzeichnis zeigt (seit 0.4.0, siehe postgres).
`restow-data`	`api` und `worker` unter `/data`	Den lokalen Standard-Chunk-Store (`/data/chunks`). Ein Ordner darauf, zum Beispiel `/data/restic-cache`, kann die restic-Caches halten (`RESTOW_RESTIC_CACHE_DIR`).
`caddy-data`	`caddy` unter `/data`	Caddys Zertifikate und seine eigene Zertifizierungsstelle.
`caddy-config`	`caddy` unter `/config`	Caddys Konfigurationsverzeichnis.
`restow-updater`	`updater` unter `/state`	Zustand und Datenbank-Dumps des Updaters.
`restow-updater-shared`	`updater` (lesen und schreiben), `api` (schreibgeschützt)	Das gemeinsame Secret des Updaters.
`restow-mounter`	`mounter` unter `/state`	Das Vorgangs-Log des Mounters.
`restow-mounter-shared`	`mounter` (lesen und schreiben), `api` und `worker` (schreibgeschützt, der Worker seit 0.4.0)	Das gemeinsame Secret des Mounters.

Compose stellt jedem Volume den Projektnamen voran; auf dem Host heißen sie daher restow_pgdata, restow_restow-data, restow_caddy-data und so weiter (docker volume ls). Das Installationsskript, der Updater und der Mounter verlassen sich auf den Projektnamen und damit auf diese Volume-Namen; siehe Einstellungen, die gefährlich zu ändern sind.

Außerdem hängt die Compose-Datei drei Verzeichnisse des Hosts ein: den Import-Ordner (RESTOW_IMPORT_DIR), das Zertifikatsverzeichnis des Journals (JOURNAL_TLS_DIR) und das Projektverzeichnis. Ein viertes, das Datenbankverzeichnis (RESTOW_POSTGRES_DATA), kommt hinzu, sobald Sie die Datenbank auf einen anderen Datenträger verschieben. Was Sie davon aufbewahren sollten, steht unter Restow selbst sichern.

Netzwerke

Seit 0.4.0 hat die Datei neben dem Standardnetz ein eigenes Netz:

Netzwerk	Genutzt von	Warum
`runners` (`internal: true`)	`api` und die Runner-Container für Freigaben, die der Mounter startet	Runner haben kein eigenes Netz außer diesem: Es erreicht die `api` (die restic-Route des Runners und seine Fortschrittsmeldungen) und sonst nichts und hat keine Route nach außen. Ein Lauf, der es nicht findet, schlägt mit `runner_network_missing` fehl: Die Compose-Datei ist älter als 0.4.0 (führen Sie das Installationsskript erneut aus). Der Docker-Name ist `<Projekt>_runners`, `restow_runners`.

Der Runner erreicht den Dateiserver über den Mount, den der Docker-Host macht, nicht über dieses Netz (Netzwerk und Ports).

docker-compose.override.yml

Der Mounter trägt die NFS-Freigaben in docker-compose.override.yml neben docker-compose.yml ein (oder in die Override-Datei, die schon da ist). Compose liest diese Datei bei jedem docker compose-Befehl im Verzeichnis, sodass die Freigaben Neustarts, Updates und ein docker compose up -d von Hand überstehen.

Was der Mounter anfasst: die Liste x-restow-mounts, Volumes der obersten Ebene, deren Name mit restow-nfs- beginnt (eines je Freigabe, restow-nfs-<name>-<hash>), und die Einträge der Volumes von api und worker, deren Quelle mit restow-nfs- beginnt. Alles andere in der Datei bleibt, wie es ist, Kommentare eingeschlossen. Bearbeiten Sie diese Teile nicht von Hand; ändern Sie Freigaben in der Weboberfläche.
Was dorthin gehört: Ihre eigenen Änderungen am Stack. Halten Sie sie in der Override-Datei und nicht in docker-compose.yml. Ab 0.3.6 ersetzt das Installationsskript beim erneuten Ausführen docker-compose.yml durch die Datei des Releases und behält die alte Datei als Sicherung (siehe Erneut ausführen).
Voraussetzungen: Compose muss die Override-Datei von selbst finden. Das Projekt muss also einen der Standard-Dateinamen nutzen (docker-compose.yml, compose.yaml, …), und die .env darf COMPOSE_FILE nicht setzen.

Die `.env`-Variablen

Kopieren Sie env.example nach .env und füllen Sie die erforderlichen Werte aus. env.example enthält nur leere Platzhalter; committen Sie nie die .env oder echte Werte. Die Datei listet die Variablen in vier Gruppen. Ein leerer Wert fällt auf den hier genannten Standard zurück. Abschnitte der Umgebungsvariablen tragen die langen Erklärungen; die Tabellen unten geben Standard und Bedeutung in Kürze. Variablen, die nicht in env.example stehen, etwa die Einstellungen für Microsoft, den Mail-Transport und S3, stehen auf jener Seite, und die .env.example im Stammverzeichnis des Repositorys ist die vollständige Liste.

Erforderlich (Required)

Compose bricht ohne RESTOW_IMAGE, RESTOW_WEB_IMAGE, RESTOW_APP_DOMAIN und POSTGRES_PASSWORD ab. Es gibt drei Datenbankrollen mit drei verschiedenen Passwörtern; erzeugen Sie jedes mit openssl rand -hex 16.

Variable	Standard	Bedeutung
`RESTOW_IMAGE`	keiner	Das Anwendungs-Image eines Builds, mit Version, zum Beispiel `ghcr.io/restow-backup/restow:0.4.7` oder `ghcr.io/restow-backup/restow-community:0.4.7`. Genutzt von `api`, `worker`, `scheduler` und, standardmäßig, `updater` und `mounter`.
`RESTOW_WEB_IMAGE`	keiner	Das Web-Image desselben Builds und derselben Version, `ghcr.io/restow-backup/restow-web:0.4.7` oder `ghcr.io/restow-backup/restow-web-community:0.4.7`.
`RESTOW_PUBLIC_URL`	keiner	Die Origin, die der Browser nutzt (nur Origin), zum Beispiel `https://app.example.com`.
`RESTOW_APP_DOMAIN`	keiner	Die Domain, die die Edge ausliefert und für die sie ein Zertifikat holt, zum Beispiel `app.example.com`.
`POSTGRES_PASSWORD`	keiner	Passwort der Datenbank-Eigentümerrolle, die der Dienst `postgres` anlegt.
`DATABASE_MIGRATION_URL`	keiner	Der Datenbankeigentümer, der nur die Migrationen ausführt: `postgres://restow:<POSTGRES_PASSWORD>@postgres:5432/restow`.
`DATABASE_URL`	keiner	Die Anwendungsrolle, der Row Level Security unterliegt: `postgres://restow_app:<Passwort>@postgres:5432/restow`.
`DATABASE_PROVIDER_URL`	keiner	Die Installationsrolle: `postgres://restow_provider:<Passwort>@postgres:5432/restow`.
`RESTOW_MASTER_KEY`	keiner	Der 32-Byte-Schlüsselverschlüsselungsschlüssel, aus `openssl rand -base64 32`. Er umschließt jeden Mandantenschlüssel. Bewahren Sie eine Kopie offline auf: Ohne ihn lässt sich kein Backup je wieder lesen.
`BETTER_AUTH_SECRET`	keiner	Das Secret des Anmeldesystems, aus `openssl rand -base64 32`.

Der Migrationsschritt legt die Anwendungsrollen mit den Namen und Passwörtern aus diesen Verbindungszeichenfolgen an, und die Rolle, auf der die Anmeldung läuft (seit 0.3.5), mit einem Login, den er von ihnen ableitet (restow_app_auth). Dafür ist nichts zu setzen. DATABASE_AUTH_URL ist optional, für einen eigenen Login: siehe Datenbank.

Optional

Alles Folgende kann leer bleiben.

Variable	Standard	Bedeutung
`RESTOW_HTTP_PORT`, `RESTOW_HTTPS_PORT`	`80`, `443`	Host-Ports der Caddy-Edge. Let’s Encrypt braucht beide auf den Standardports; ändern Sie sie daher nur hinter einem weiteren Reverse-Proxy oder für eine lokale Evaluierung. Ein Wert darf eine Adresse tragen (`127.0.0.1:8443`), um den Port nur auf dieser Schnittstelle zu veröffentlichen.
`RESTOW_API_PORT`	`3000`	Host-Port, auf dem die `api` nur auf `127.0.0.1` veröffentlicht wird. Die Edge erreicht die `api` über das Compose-Netz und nutzt ihn nicht.
`RESTOW_EDGE_TRUSTED_PROXIES`	nur Loopback	Gegenstellen, deren `X-Forwarded-For` die Edge behält (und ergänzt), statt es durch die eigene Adresse der Gegenstelle zu ersetzen: durch Leerzeichen getrennte CIDR-Bereiche oder `private_ranges`. Nur nötig, wenn ein weiterer Reverse-Proxy davor steht; für eine normale Installation ändert sich nichts. Siehe Edge.
`RESTOW_EDGE_TLS`	`acme`	`acme` (auch wenn leer) oder `internal`: woher die Edge ihr Zertifikat bekommt. `internal` ist Caddys eigene Zertifizierungsstelle für `RESTOW_APP_DOMAIN`, für eine Edge hinter einem weiteren Reverse-Proxy; das Root-Zertifikat ist `/data/caddy/pki/authorities/local/root.crt` im Volume `caddy-data`. Siehe caddy.
`RESTOW_EDGE_HSTS`	`false`	`true` sendet `Strict-Transport-Security`, mit `includeSubDomains`. Erst, wenn `RESTOW_APP_DOMAIN` eine echte, öffentlich auflösbare Domain ist, für die diese Edge ihr eigenes gültiges TLS-Zertifikat terminiert. Der Wert muss genau kleingeschrieben `true` lauten; alles andere lässt HSTS aus. Setzen Sie es nie für eine lokale oder IP-Installation oder eine reine HTTP-Domain: Browser bleiben dann auf HTTPS für einen Host, der es womöglich nie anbietet, bis das `max-age` abläuft.
`POSTGRES_USER`, `POSTGRES_DB`	`restow`, `restow`	Eigentümerrolle und Datenbankname des Dienstes `postgres`. Ändern Sie sie nur vor dem ersten Start, und nutzen Sie dieselben Namen in `DATABASE_MIGRATION_URL`.
`RESTOW_POSTGRES_DATA_TYPE`, `RESTOW_POSTGRES_DATA`	leer: das Volume `pgdata`	Seit 0.4.0. Wo die Datenbank ihre Daten ablegt: `volume` oder `bind`, und der Volume-Name oder das Host-Verzeichnis. Der Updater schreibt sie, wenn er die Datenbank verschiebt (Installation → Datenbank); sind sie gesetzt, starten Sie den Stack nie aus einer Compose-Datei, die sie nicht liest. Siehe Datenbank und Umgebungsvariablen.
`RESTOW_SETUP_TOKEN`	leer	Das einmalige Token, nach dem der Einrichtungsassistent fragt. Leer: Die `api` gibt bei jedem Start ein neues Token in ihrem Log aus, bis die Einrichtung abgeschlossen ist (`docker compose logs api \| grep 'SETUP TOKEN'`). Setzen Sie eines (mindestens 16 Zeichen, zum Beispiel `openssl rand -hex 16`) für eine unbeaufsichtigte Installation oder wenn Container-Logs anderswohin weitergeleitet werden; es wird dann nie geloggt. Nach Abschluss der Einrichtung ohne Wirkung.
`STORAGE_TARGET`	`local`	Das Standard-Speicherziel: `local` oder `s3`.
`STORAGE_LOCAL_PATH`	`/data/chunks`	Der lokale Pfad in den Containern `api` und `worker` (das Volume `restow-data`).
`RESTOW_IMPORT_DIR`	`./import`	Host-Verzeichnis, das schreibgeschützt unter `/var/lib/restow/import` in `api` und `worker` eingehängt wird. Jeder Mandant nutzt seinen eigenen Unterordner `<Verzeichnis>/<Mandanten-Slug>/`, den Sie selbst anlegen: Legen Sie dort EML-, MSG-, MBOX- oder ZIP-Dateien ab und wählen Sie sie unter Quelle hinzufügen → Mail-Dateien importieren aus. Siehe Mail-Dateien importieren und exportieren und Umgebungsvariablen.
`IMPORT_DIR`	`/var/lib/restow/import`	Der Pfad in den Containern. Ändern Sie ihn nur zusammen mit dem Mount oben.
`IMPORT_MAX_FILE_BYTES`	10 GiB	Größte Datei, die der Upload annimmt, in Byte.
`IMPORT_UPLOAD_TTL_HOURS`	`48`	Stunden, die ein unfertiger oder ungenutzter Upload aufbewahrt wird, bevor er gelöscht wird.
`IMPORT_SEGMENT_BYTES`	8 MiB	Größe eines Upload-Stücks in Byte (64 KiB bis 32 MiB).
`IMPORT_MAX_MESSAGE_BYTES`	256 MiB	Größte einzelne Nachricht, die in den Speicher gelesen wird.
`IMPORT_MAX_STAGING_BYTES`	100 GiB	Byte, die die Uploads eines Mandanten zusammen im Staging belegen dürfen, gezählt nach angegebener Dateigröße, bis ihr Import beendet ist. Ein neuer Upload, der nicht mehr passt, wird abgelehnt.
`IMPORT_PARSE_WORKERS`	`2` (1 bis 8)	Parser-Prozesse, die der Worker gleichzeitig für MSG-Dateien und Nachrichten-Metadaten ausführt. Jeder darf bis zu 512 MB nutzen; eine Datei über 8 MiB bekommt einen eigenen Prozess mit bis zu 3 GB. Auf einem kleinen Host senken.
`EXPORT_TTL_HOURS`	`24`	Stunden, die ein fertiger Export heruntergeladen werden kann, bevor seine Datei gelöscht wird.
`EXPORT_MAX_TENANT_BYTES`	50 GiB	Byte, die alle nicht abgelaufenen Exportdateien eines Mandanten zusammen belegen dürfen. Ein neuer Exportauftrag wird abgelehnt, und ein Export, der nicht mehr passt, schlägt mit einer Meldung fehl, bis ältere Exporte abgelaufen sind.
`PREVIEW_PARSE_WORKERS`	`2` (1 bis 8)	Parser-Prozesse, die die `api` gleichzeitig für die Mail-Vorschau und Anhang-Downloads ausführt.
`PREVIEW_TIMEOUT_MS`	`10000`	Wie lange eine Nachricht für ihre formatierte Vorschau brauchen darf. Eine Nachricht, die mehr braucht, wird als Text oder als nicht lesbar angezeigt.
`RESTIC_BINARY`, `RESTOW_AGENT_DIR`, `RESTOW_AGENT_INSTALL_DIR`	`restic` aus dem `PATH`, `/srv/agent`, `/srv/agent/install`	Das Image liefert restic (`/usr/local/bin/restic`), die Agent-Downloads (`/srv/agent/<Version>/<OS>-<Architektur>/`) und die Installationsskripte (`/srv/agent/install`) mit. Die Standardwerte passen zu diesem Stack; richten Sie sie nur für ein eigenes Image anderswohin. Siehe Endpoint-Backup.
`RESTOW_RESTIC_CACHE_DIR`	der Temp-Ordner	Wo restic seine Caches je Endpoint ablegt. Ein Ordner auf dem Daten-Volume, zum Beispiel `/data/restic-cache`, erhält sie über Neustarts hinweg und beschleunigt das Durchsuchen.
`PVE_BLOCK_MAP_CACHE_MB`	`256`	Seit 0.4.0. Arbeitsspeicher in MiB für die Blockkarten der VM-Disks, die gerade durchsucht oder wiederhergestellt werden (Proxmox VE, eine Preview). Wird von der `api` gelesen. Siehe Umgebungsvariablen.
`RESTOW_ENDPOINT_QUOTA_GIB`, `RESTOW_ENDPOINT_TENANT_QUOTA_GIB`	`2048` (2 TiB), `20480` (20 TiB)	Speicherbudget der Endpoint-Repositorys in GiB (ganze oder Dezimalzahlen; `0` heißt kein Budget): je Endpoint und für alle Endpoints eines Mandanten zusammen. Eine Administration kann je Rechner einen anderen Wert setzen. Ein Upload über ein Budget hinaus wird abgelehnt, Restores funktionieren weiter, und die Alarme warnen ab 90 Prozent. Von `api` und `worker` gelesen.

Opt-in: Updater und Mounter

Sie binden den Docker-Socket ein, und der ist auf dem Host gleichbedeutend mit root. Lesen Sie Updates, bevor Sie den Updater einschalten, und Mounter und NFS-Speicher, bevor Sie den Mounter einschalten (eine neue Installation startet ihn seit 0.4.0 standardmäßig). Die Grenzen des Mounters für Freigaben, RESTOW_MOUNTER_MAX_RUNNERS und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB, stehen nicht in env.example: Sie haben Standardwerte in der Compose-Datei und sind in den Umgebungsvariablen beschrieben. Sie einzuschalten braucht keine der folgenden Zeilen: Sie starten jeden mit seinem eigenen Befehl (siehe updater und mounter). Der Mounter nutzt RESTOW_PROJECT_DIR wie der Updater. Alles hier ist optional.

Variable	Standard	Bedeutung
`RESTOW_PROJECT_DIR`	leer	Absoluter Pfad des Verzeichnisses, das `docker-compose.yml` und `.env` auf dem Host enthält, zum Beispiel `/opt/restow`; das Installationsskript setzt ihn. Leer: Das Verzeichnis wird unter `/project` eingehängt, und der Updater und der Mounter lesen seinen Host-Pfad aus dem Mount. Gesetzt: Es wird stattdessen unter demselben Pfad eingehängt. Die `api` liest sie ebenfalls, um Befehle mit `cd <Verzeichnis>` anzuzeigen.
`RESTOW_UPDATER_URL`	`http://updater:8090`	Wo die `api` den Updater sucht. Ändern Sie sie nur für einen Updater, der anderswo läuft.
`RESTOW_UPDATER_IMAGE`	leer	Vom Updater selbst geschrieben, per Digest fixiert; lassen Sie sie leer. Setzen Sie sie selbst, nehmen Sie ein Image desselben Builds wie `RESTOW_IMAGE`. Siehe Wie Updater und Mounter ihr Image fixieren.
`RESTOW_UPDATER_SELF_UPDATE`	`true`	Der Updater zieht sich auf jedes signierte Release nach, das er installiert hat. `false` lässt ihn, wo er ist, und Sie ziehen ihn dann von Hand nach.
`RESTOW_UPDATER_IMAGE_REPOSITORY`, `RESTOW_UPDATER_WEB_IMAGE_REPOSITORY`	leer: die Release-Images des eigenen Builds des Updaters	Woher der Updater das Anwendungs-Image und das Web-Image zieht. Leer: die Release-Images des eigenen Builds (`ghcr.io/restow-backup/restow` und `restow-web`, oder `restow-community` und `restow-web-community`). Setzen Sie beide nur für einen Registry-Spiegel der Release-Images, und kopieren Sie die Signaturen mit.
`RESTOW_UPDATER_SOURCE_HOSTS`	leer: Quellcode-Modus aus	Repositorys (`git.example.com/acme/restow`, `github.com/acme/restow`) oder ganze Hosts (`git.example.com`), kommagetrennt, aus denen der Updater ein Update bauen darf („Quellcode“-Modus, eine eigene Update-Quelle unter Einstellungen, Updates). Leer: Über die Weboberfläche lassen sich nur die signierten Release-Images der Standardquelle installieren. Nur der Betreiber setzt sie, in der `.env` (siehe Zwei Modi). Was aus diesen Repositorys gebaut wird, läuft mit Zugriff auf alle Daten und Schlüssel: Tragen Sie nur Repositorys ein, denen Sie so sehr vertrauen wie dem Release selbst. Tragen Sie nie `github.com` allein ein. Erstellen Sie den Updater nach einer Änderung neu: `docker compose --profile updater up -d updater`.
`RESTOW_MOUNTER_IMAGE`	leer	Vom Mounter selbst geschrieben, per Digest fixiert; lassen Sie sie leer.
`RESTOW_MOUNTER_URL`	`http://mounter:8091`	Wo die `api` den Mounter sucht. Ändern Sie sie nur für einen Mounter, der anderswo läuft.

Weitere (Other)

Variable	Standard	Bedeutung
`RESTOW_PRODUCT_NAME`	`Restow`	Der Produktname, den die Web-App, Mails, Berichte und die API-Dokumentation anzeigen. Nur ein Anzeigename; die Variablennamen, Programme und Header behalten ihre Namen.
`JOURNAL_SMTP_PORT`	leer: Empfänger aus	Port des SMTP-Journal-Empfängers des Archivs (Business und Service Provider). Leer hält ihn geschlossen. Für Journal-Reports von Exchange Online setzen Sie `25` und `JOURNAL_SMTP_BIND=0.0.0.0`: Der Empfänger muss aus dem Internet erreichbar sein.
`JOURNAL_SMTP_BIND`	`127.0.0.1`	Die Host-Adresse, auf der der Port des Empfängers veröffentlicht wird. Ohne Bind-Adresse wird er nur auf der Loopback-Schnittstelle abgebildet.
`JOURNAL_HOSTNAME`	keiner	Der Hostname, an den Exchange Online zustellt, zum Beispiel `archive.example.com`, ohne Schema, Port und Mailadresse. Er bildet die Journal-Adressen der Mandanten, `journal+<token>@<dieser Host>`, die auf der Archivseite stehen; veröffentlichen Sie ihn im DNS.
`JOURNAL_TLS_DIR`	`./journal-tls`	Host-Verzeichnis, schreibgeschützt als `/etc/restow/journal-tls` in die `api` eingehängt, das Zertifikat und Schlüssel enthält.
`JOURNAL_TLS_CERT_PATH`	keiner	`/etc/restow/journal-tls/fullchain.pem`: die Zertifikatskette (PEM, Blatt zuerst).
`JOURNAL_TLS_KEY_PATH`	keiner	`/etc/restow/journal-tls/privkey.pem`: der private Schlüssel (PEM, ohne Passphrase).

Einstellungen, die env.example nicht aufführt (seit 0.4.4). Die Release-Datei und ihre env.example haben sich seit 0.4.3 nur in den Image-Tags geändert. Neue optionale Einstellungen erreichen api und worker trotzdem über die Datei .env, weil env_file die ganze Datei an sie weitergibt: JOURNAL_RATE_PER_IP (600 Verbindungen pro Minute) und JOURNAL_RATE_PER_ADDRESS (300 Zustellungen pro Minute) für den Journal-Empfänger und die Einstellungen ARCHIVE_CAPTURE_*, ARCHIVE_BACKFILL_CONCURRENCY, ARCHIVE_GRAPH_* und ARCHIVE_IMAP_* der Archiv-Erfassung. Seit 0.4.5 gehört RESTOW_RUN_AS_COMMUNITY dazu (standardmäßig leer; die .env.example des Repositorys führt sie auf, die des Release nicht): siehe Lizenz und Editionen. Das gilt seit 0.4.7 auch für ENTRA_CLIENT_SECRET_EXPIRES_AT (standardmäßig leer; das Datum für die Ablauf-Erinnerungen eines Client-Secrets in .env, siehe Umgebungsvariablen). Tragen Sie die, die Sie brauchen, in .env ein und erstellen Sie die Dienste neu; die Liste mit Standardwerten steht unter Archiv-Erfassung aus dem Postfach und Journal-SMTP-Empfänger. Kein Port, kein Volume und kein Dienst hat sich geändert: Graph-Benachrichtigungen kommen auf der 443 des Edge an, und weitergeleitete Kopien auf demselben Journal-Port wie das Exchange-Journaling.

Das Zertifikat des Journal-Empfängers

Exchange Online verlangt TLS (und der Empfänger von jedem anderen Absender ebenso, auch von einem Mailanbieter, der Kopien weiterleitet); der Journal-Empfänger startet daher nicht ohne Zertifikat und Schlüssel und greift nie auf ein eingebautes Zertifikat zurück: Die Archivseite sagt dann „no TLS certificate“. Das Zertifikat muss von einer öffentlich vertrauten Stelle stammen und zu JOURNAL_HOSTNAME passen. Legen Sie die beiden Dateien (fullchain.pem und privkey.pem) in JOURNAL_TLS_DIR ab und setzen Sie JOURNAL_TLS_CERT_PATH und JOURNAL_TLS_KEY_PATH auf die obigen Pfade.

Ein erneuertes Zertifikat wird aus denselben Dateien innerhalb weniger Minuten ohne Neustart übernommen. Die api liest die Dateien beim Start und erwartet, dass sie gültig sind: Starten Sie sie neu, nachdem Sie die Dateien erstmals dort abgelegt haben, oder nach einem Start, der scheiterte, weil sie fehlten oder abgelaufen waren.

Woher das Zertifikat kommt:

Derselbe Host wie RESTOW_APP_DOMAIN: Kopieren Sie das Zertifikat, das Caddy schon hält, zum Beispiel täglich, im Verzeichnis der docker-compose.yml:
Terminal-Fenster
```
docker compose cp "caddy:/data/caddy/certificates/<ACME-Verzeichnis>/<Host>/<Host>.crt" ./journal-tls/fullchain.pem
docker compose cp "caddy:/data/caddy/certificates/<ACME-Verzeichnis>/<Host>/<Host>.key" ./journal-tls/privkey.pem
```
Das <ACME-Verzeichnis> listen Sie mit docker compose exec caddy ls /data/caddy/certificates auf.
Ein anderer Hostname: ein ACME-Client auf dem Host (certbot, acme.sh, lego) mit der DNS-Challenge, weil Caddy Port 80 hält, und ein Deploy-Hook, der die Dateien mit cp -L nach JOURNAL_TLS_DIR kopiert, nicht die Symlinks aus certbots Verzeichnis live.

Die vollständige Einrichtung, mit DNS, Port 25 und der Microsoft-365-Seite, steht unter Exchange-Journaling.

Was sich seit 0.3.6 geändert hat

Gegenüber der Datei von 0.3.6 unterscheidet sich der Release-Stack an diesen Stellen. Eine Installation behält die Datei, mit der sie installiert wurde; führen Sie daher nach dem Update auf 0.4.0 das Installationsskript erneut aus, um sie zu bekommen (Update auf 0.4.0). Von 0.4.0 auf 0.4.7 haben sich nur die Image-Tags in den Beispielen geändert: Die Datei von 0.4.0 bleibt.

Wo	Änderung
Volume von `postgres`	Das Datenverzeichnis ist ein typisierter Mount, gelesen aus `RESTOW_POSTGRES_DATA_TYPE` und `RESTOW_POSTGRES_DATA` (Standard: das Volume `pgdata`), mit `create_host_path: false`.
`api`	Tritt zusätzlich zu `default` dem internen Netz `runners` bei.
`worker`	Neue Einstellungen `RESTOW_MOUNTER_URL`, `RESTOW_MOUNTER_MAX_RUNNERS` (8) und `RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB` (16384); neues schreibgeschütztes Volume `restow-mounter-shared` unter `/mounter-shared`.
`mounter`	Neue Einstellungen `RESTOW_MOUNTER_MAX_RUNNERS` und `RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB`; führt jetzt auch die Runner für Freigaben aus; wird von `install.sh` standardmäßig gestartet.
`networks`	Neues Netz `runners` auf oberster Ebene mit `internal: true`.
`env.example`	Neue leere Zeilen `RESTOW_POSTGRES_DATA_TYPE`, `RESTOW_POSTGRES_DATA` und `PVE_BLOCK_MAP_CACHE_MB`.

Einstellungen, die gefährlich zu ändern sind

Halten Sie eigene Änderungen in docker-compose.override.yml (siehe oben) und lassen Sie diese Zeilen der docker-compose.yml unverändert:

Einstellung	Was davon abhängt
`name: restow`	Das Installationsskript, der Updater, der Mounter und die Volume-Namen (`restow_pgdata`, `restow_restow-data` und die übrigen, siehe Volumes) hängen davon ab.
Die Mounts `restow-updater-shared` und `restow-mounter-shared` der `api` und der Mount `restow-mounter-shared` des `worker`	Ohne sie erreicht die Weboberfläche den Updater oder den Mounter nicht, und der Worker kann keine Läufe für Freigaben starten.
Der Datenbank-Mount von `postgres` (`type`, `source` und `create_host_path: false`)	Nach einem Verschieben der Datenbank liegt der Speicherort in der `.env`; eine Datei ohne diese Zeilen startet PostgreSQL auf dem falschen Verzeichnis. `install.sh` verweigert eine solche Datei (Exit-Code 8).
Das Netz `runners`, `internal: true`, und die `networks` der `api`	Runner für Freigaben müssen die `api` erreichen und sonst nichts. Ohne das Netz meldet der Mounter `runner_network_missing`.
`stop_grace_period: 60s` des `worker`	Eine kürzere Zeit schneidet laufende Jobs ab, bevor sie einen Prüfpunkt speichern (siehe worker).
Die Docker-Socket-Mounts von `updater` und `mounter`	Sie sind root auf dem Host. Binden Sie den Socket in keinen anderen Dienst ein.
`127.0.0.1` im Port der `api`	Der Port der `api` bleibt auf der Loopback-Schnittstelle. `updater` und `mounter` veröffentlichen gar keinen Port.
`:ro` am Import-Ordner und am Journal-TLS-Verzeichnis	Beide sind mit Absicht schreibgeschützt eingehängt (Restow schreibt nie in den Import-Ordner und löscht nie daraus).
`${RESTOW_PROJECT_DIR:-.}:${RESTOW_PROJECT_DIR:-/project}`	Der Updater und der Mounter finden den Host-Pfad des Projekts über diesen Mount (siehe updater).