Kopieren Sie .env.example nach .env und füllen Sie aus, was Sie brauchen. Die wenigen tatsächlich erforderlichen stehen unter Erste Schritte → Installation. Der Release-Stack hat eine eigene, kürzere env.example (an jedem GitHub-Release angehängt und unter deploy/release); jede Variable darin ist hier beschrieben, gruppiert wie in der Datei in der Release-Stack-Referenz, und die .env.example des Repositorys ist die vollständige Liste. Ein leerer Wert in .env fällt auf den hier genannten Standard zurück; NODE_ENV fehlt absichtlich in der Datei, da das Release-Image immer mit NODE_ENV=production läuft und jeder Eintrag hier, selbst ein leerer, das überschreiben würde.
Öffentliche Origin, die der Browser nutzt (nur Origin), z. B. https://app.example.com oder http://localhost:5173.
RESTOW_APP_DOMAIN
keiner
Öffentliche App-Domain für die Caddy-Edge (automatisches Let’s-Encrypt-TLS), z. B. app.example.com.
RESTOW_API_URL
keiner
Interne API-Basis-URL. Eine normale Installation braucht sie nicht; lassen Sie sie leer (der Seed-Prozess der öffentlichen Demo nutzt sie).
RESTOW_MODE
keiner
Betriebsmodus: local | public. Wird vom Einrichtungsassistenten gesetzt; lässt sich hier festlegen.
RESTOW_EDITION
keiner
Nur öffentliche Demo: die Edition, die die Demo ohne Lizenzschlüssel zeigt, community | business | service_provider. Sie wirkt nur zusammen mit RESTOW_DEMO=true; überall sonst wird sie ignoriert. Lassen Sie sie leer: Eine Produktivinstallation bekommt ihre Edition aus einem Lizenzschlüssel unter Installation → Lizenz (vollständige Images). Siehe Lizenz und Editionen.
RESTOW_LICENSE_PUBLIC_KEY
in den Release-Images eingebaut
Optionale Überschreibung des Ed25519-Lizenzprüfschlüssels (roh, base64url), für Entwicklung und Tests des vollständigen Builds. Release-Images tragen den Schlüssel des Herstellers.
RESTOW_UPDATE_CHECK_URL
leer: der Tab Updates entscheidet
Umgebungs-Override für die Update-Prüfung: ein Releases-Endpunkt über https (eine GitHub-URL .../releases oder .../releases/latest oder eine Releases-API von Forgejo oder Gitea). Ist er gesetzt, hat er Vorrang vor dem Tab unter Einstellungen, Updates: Die Prüfung ist an, die Quelle ist diese URL und dort schreibgeschützt, und ein gespeichertes Token wird nicht an sie gesendet. Leer heißt: Der Tab entscheidet, und die Prüfung ist aus, bis eine Administration sie einschaltet. Gelesen wird nur die Release-Liste; es werden keine Installationsdaten gesendet. Siehe Updates.
RESTOW_RUN_AS_COMMUNITY
leer (aus)
Nur vollständiger Build, seit 0.4.5. 1 startet ein Release, das der installierte Business- oder Service-Provider-Schlüssel nicht abdeckt (es erschien nach dem Ende des Update-Zeitraums des Schlüssels), als Community, statt den Start zu verweigern: Die Module bleiben aus, und nichts wird verändert oder gelöscht. Installieren Sie einen Schlüssel, der das Release abdeckt, sind sie sofort wieder an. Die Variable wirkt nicht, solange der Schlüssel das laufende Release abdeckt, und die Prüfung gilt nie für Beta-Lizenzen, Entwicklungs-Builds, Installationen ohne Schlüssel oder die öffentliche Demo. Siehe Lizenz und Editionen.
LOG_LEVEL
info
Log-Level des Workers: debug | info | warn | error.
Die Seite, auf die die Fehlererklärungen in der Web-Oberfläche für weitere Hilfe verweisen. Richten Sie sie auf Ihr eigenes Runbook, falls Sie eines pflegen.
RESTOW_PRODUCT_NAME
Restow
Der Produktname, den die Web-App, Mails, Berichte, die API-Dokumentation und die Namen von Passkeys und Authenticator-Einträgen anzeigen. Nur ein Anzeigename: Die RESTOW_*-Variablen, restow-agent, restow-restore, die X-Restow-*-Header und die Image-Namen behalten ihre Namen. Die statische Wartungsseite wird beim Bauen des Web-Images geschrieben und trägt den Namen, der als Build-Argument RESTOW_PRODUCT_NAME angegeben wurde, nicht diesen Laufzeitwert.
RESTOW_VERSION (die laufende Version) und, seit 0.4.5, RESTOW_RELEASED_AT (ihr Release-Datum, das Commit-Datum des Release-Tags) werden zur Build-Zeit ins Image geschrieben; setzen Sie sie nicht in .env: ein leerer Wert dort würde sie verbergen. GET /api/v1/status meldet das Datum als releasedAt, und die Update-Prüfung vergleicht es mit dem Update-Zeitraum eines Lizenzschlüssels (Lizenz und Editionen).
Das einmalige Setup-Token, nach dem der Einrichtungsassistent in seinem ersten Schritt 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 sie für eine unbeaufsichtigte Installation oder wenn Container-Logs anderswohin weitergeleitet werden: mindestens 16 Zeichen, Leerzeichen und Bindestriche nicht mitgezählt (zum Beispiel openssl rand -hex 16); das Token wird dann nie ins Log geschrieben, und mit einem kürzeren Wert startet die api nicht. Nach Abschluss der Einrichtung ohne Wirkung.
Release-Stack: Host-Ports der Caddy-Edge. Let’s Encrypt braucht beide erreichbar auf den Standardports; ändern Sie sie daher nur hinter einem weiteren Reverse-Proxy oder für eine lokale Evaluierung. Ab 0.2.0 nehmen sie auch eine Adresse: 192.168.1.50:443 veröffentlicht nur auf einer Schnittstelle, 127.0.0.1: nur auf Loopback an einem Port, den Docker wählt (das Installationsskript nutzt das hinter einem Proxy für den Port, den es nicht braucht).
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.
POSTGRES_PORT
5432
Nur Quell-Stack: Port, auf dem der Dienst postgres auf 127.0.0.1 veröffentlicht wird. Der Release-Stack veröffentlicht keinen PostgreSQL-Port.
Das Anwendungs-Image mit Version, genutzt von api, worker und scheduler: ghcr.io/restow-backup/restow:0.4.7 (vollständiger Build) oder ghcr.io/restow-backup/restow-community:0.4.7 (Community-Build). Nutzen Sie beide Images eines Builds in derselben Version. Im Quell-Stack lassen Sie es leer: Compose startet dann das selbst gebaute Image restow:local. Der optionale Updater schreibt diese Zeile.
RESTOW_WEB_IMAGE
keiner (im Release-Stack erforderlich)
Das Web-Image desselben Builds, mit der Caddy-Edge: ghcr.io/restow-backup/restow-web:0.4.7 oder ghcr.io/restow-backup/restow-web-community:0.4.7. Im Quell-Stack leer: restow-web:local. Auch diese Zeile schreibt der Updater.
RESTOW_UPDATER_IMAGE
leer: Der Updater startet aus RESTOW_IMAGE (ab 0.2.1); restow:local im Quell-Stack
Das eigene Image des Updaters. Seit 0.2.1 optional: Beim ersten Start schreibt der Updater es selbst, per Digest fixiert auf das Image, mit dem er läuft, damit das nächste Umschreiben von RESTOW_IMAGE ihn nicht erreicht. Nach einem signierten Update im Image-Modus zieht er sich auf das geprüfte Release nach (siehe RESTOW_UPDATER_SELF_UPDATE); auf ein aus dem Quellcode gebautes Image wechselt er nie. Setzen Sie es selbst, nehmen Sie ein Image desselben Builds wie RESTOW_IMAGE (restow-community beim Community-Build). Siehe Wie Updater und Mounter ihr Image fixieren.
RESTOW_PROJECT_DIR
leer: Das Projektverzeichnis wird unter /project eingehängt (ab 0.2.1)
Absoluter Pfad auf dem Host des Verzeichnisses, das docker-compose.yml und .env enthält, zum Beispiel /opt/restow. Seit 0.2.1 optional; nur setzen, wenn die Compose-Datei einen anderen Pfad braucht (leer wird das Verzeichnis unter /project eingehängt und der Updater liest seinen Host-Pfad aus dem Mount; gesetzt wird es unter demselben Pfad eingehängt). Das Installationsskript setzt sie. Genutzt vom Updater und ab 0.3.1 vom Mounter; ab 0.3.6 liest auch die api sie, um Befehle anzuzeigen, die mit cd <Verzeichnis> beginnen.
RESTOW_UPDATER_URL
http://updater:8090
Wo die api den optionalen Updater sucht. Dort antwortet nichts, solange das Profil updater nicht läuft. Ändern Sie sie nur für einen Updater, der anderswo läuft.
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: Der Quellcode-Modus ist aus, und über die Weboberfläche lassen sich nur die signierten Release-Images der Standardquelle installieren. Tragen Sie nie github.com allein ein. 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. Auch die api liest die Variable, damit die Update-Prüfung einen eingetragenen Host in einem privaten Netz erreichen kann. Erstellen Sie den Updater nach einer Änderung neu: docker compose --profile updater up -d updater.
leer: die Release-Images des eigenen Builds des Updaters
Woher der Updater das Anwendungs- und das Web-Image zieht. Setzen Sie beide nur für einen Registry-Spiegel der Release-Images, und kopieren Sie die Signaturen mit (cosign copy).
Der Updater (docker compose --profile updater up -d, Opt-in) bindet den Docker-Socket ein, und der ist auf dem Host gleichbedeutend mit root; lesen Sie zuerst Updates. Der Dienst updater bekommt die .env nicht als Umgebung: Aus der .env übergibt ihm die Compose-Datei nur RESTOW_PROJECT_DIR (als RESTOW_UPDATER_PROJECT_DIR), RESTOW_UPDATER_SOURCE_HOSTS und die beiden Image-Repositorys. Die folgenden Variablen liest nur der Updater-Container (ROLE=updater); es gelten die Standardwerte, solange Sie keine in einem Compose-Override des Dienstes updater setzen.
Variable
Standard
Zweck
RESTOW_UPDATER_PROJECT_DIR
aus RESTOW_PROJECT_DIR gesetzt
Absoluter Host-Pfad des Compose-Projekts, unter demselben Pfad eingebunden.
RESTOW_UPDATER_HEALTH_TIMEOUT_SECONDS
600
Wie lange auf die neue api gewartet wird (Migrationen können dauern).
RESTOW_UPDATER_MIN_FREE_MB
1024
Reserve zusätzlich zu dem, was ein Update braucht (seit 0.4.0). Der Updater addiert den Datenbank-Dump, die Images und den Platz für die Migrationen und lehnt ein Update ab, das nicht hineinpasst, mit dem Blocker disk_space; diese Reserve kommt obendrauf. Siehe Updates → Speicherplatz.
RESTOW_UPDATER_CLI_IMAGE
docker:27-cli, per Digest festgelegt
Image, mit dem docker und docker compose ausgeführt werden. Muss einen Digest tragen (name:tag@sha256:...).
RESTOW_UPDATER_COSIGN_IMAGE
ghcr.io/sigstore/cosign/cosign:v3.1.3, per Digest festgelegt
Das cosign-Image, das die Release-Signaturen prüft, bevor ein Image gezogen wird. Muss einen Digest tragen.
RESTOW_UPDATER_VERIFY_SIGNATURES
true
false überspringt die Signaturprüfung, nur für Testinstallationen oder unsignierte Spiegel; der Digest bleibt Pflicht, und jeder Lauf vermerkt, dass die Signatur nicht geprüft wurde.
RESTOW_UPDATER_SELF_UPDATE
true
Ab 0.2.1. Nach einem Update im Image-Modus, dessen Images die Signaturprüfung bestanden haben, fixiert der Updater RESTOW_UPDATER_IMAGE per Digest auf das geprüfte Anwendungs-Image und erstellt sich neu. false lässt das Image des Updaters unverändert, bis Sie es von Hand nachziehen. In der .env setzen und den Updater danach neu erstellen.
Der Mounter bindet NFS-Freigaben als Repository-Speicher über die Weboberfläche ein und führt seit 0.4.0 die Container aus, die Freigaben sichern und wiederherstellen. Neue Installationen starten ihn standardmäßig (install.sh --no-mounter lässt ihn aus); auf einer bestehenden Installation starten Sie ihn mit Netzlaufwerke einschalten oder mit docker compose --profile mounts up -d mounter.
Variable
Standard
Zweck
RESTOW_MOUNTER_IMAGE
leer: startet aus RESTOW_IMAGE
Das Image des Mounters, das Anwendungs-Image, gestartet mit ROLE=mounter. Beim ersten Start schreibt der Mounter diese Zeile selbst, per Digest fixiert auf das Image, mit dem er läuft (ein lokal gebautes Image hat keinen Digest und wird nicht fixiert). Der optionale Updater setzt sie bei jedem signierten Update, das er installiert, auf das geprüfte Image. Ohne den Updater setzen Sie sie zum Nachziehen (oder leeren sie) und führen docker compose --profile mounts up -d mounter aus.
RESTOW_MOUNTER_URL
http://mounter:8091
Wo die api den Mounter erreicht. Ändern Sie sie nur für einen Mounter, der anderswo läuft.
RESTOW_MOUNTER_SECRET_FILE
/mounter-shared/secret
Das gemeinsame Secret, das die api aus dem Volume restow-mounter-shared liest.
RESTOW_MOUNTER_HEALTH_TIMEOUT_SECONDS
300
Wie lange der Mounter nach einer Änderung auf api und worker wartet.
RESTOW_MOUNTER_PROBE_TIMEOUT_SECONDS
60
Wie lange der Test einer Freigabe dauern darf.
RESTOW_MOUNTER_MAX_RUNNERS
8 (seit 0.4.0)
Harte Obergrenze der Runner (Container) für Freigaben zugleich. Die Einstellung Runner für Freigaben → Gleichzeitige Läufe in der Weboberfläche ist die normale Grenze und kann sie nicht überschreiten. Der Release-Stack gibt die Variable an Mounter und Worker weiter.
RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB
16384 (seit 0.4.0)
Obergrenze des Arbeitsspeichers je Runner für Freigaben in MiB; Arbeitsspeicher je Runner (MiB) in der Weboberfläche kann sie nicht überschreiten. Wird wie die Zeile darüber an Mounter und Worker weitergegeben.
RESTOW_MOUNTER_SELINUX_CONTEXT
false (seit 0.4.0)
true fügt für Einbindungen von Freigaben die Mount-Option context= hinzu, für einen Docker-Host mit aktivem SELinux. Nötig, wenn ein Test einbindet, aber „Permission denied“ liest. Die docker-compose.yml des Releases gibt sie nicht aus der .env weiter (siehe den Hinweis unter der Tabelle).
RESTOW_MOUNTER_RUNNER_API_URL
http://api:3000 (seit 0.4.0)
Die Adresse, die ein Runner für Freigaben im internen Netzwerk runners aufruft. Der Standard passt zum Release-Stack.
RESTOW_MOUNTER_RUNNER_NETWORK
runners (seit 0.4.0)
Der Compose-Netzwerkschlüssel des Netzwerks der Runner (der Docker-Name ist <Projekt>_runners).
RESTOW_MOUNTER_RUNNER_EXEC_TIMEOUT_SECONDS
60 (seit 0.4.0)
Wie lange ein Test einer Freigabe oder das Auflisten von Ordnern in einem Runner dauern darf.
Der Mounter hat kein env_file: Die docker-compose.yml des Releases gibt nur RESTOW_MOUNTER_PROJECT_DIR, RESTOW_MOUNTER_MAX_RUNNERS und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB an ihn weiter (und die letzten beiden an den Worker). RESTOW_MOUNTER_SELINUX_CONTEXT, RESTOW_MOUNTER_RUNNER_API_URL, RESTOW_MOUNTER_RUNNER_NETWORK und RESTOW_MOUNTER_RUNNER_EXEC_TIMEOUT_SECONDS wirken daher nur, wenn Sie sie in docker-compose.override.yml in das environment des Dienstes mounter eintragen und ihn neu erstellen, zum Beispiel services: mounter: environment: RESTOW_MOUNTER_SELINUX_CONTEXT: "true". Siehe Freigaben: der Docker-Host.
Die Release-Notes von 0.4.0 nennen RESTOW_SHARE_REUSE_MAX_ENTRIES als Überschreibung der Grenze, ab der ein Lauf für eine Freigabe alle Berechtigungen neu liest, statt die vorherigen wiederzuverwenden. Der Runner (restow-share) liest sie, aber der Mounter gibt keine .env-Variable an den Runner-Container weiter; sie in der .env zu setzen, hat daher in 0.4.7 keine Wirkung.
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 vor Caddy steht. Tragen Sie nur die Adresse des Proxys selbst ein (zum Beispiel 192.168.1.20/32): Jede eingetragene Gegenstelle darf eine beliebige Client-Adresse angeben. Die api liest denselben Wert: Sie erfasst als Client-Adresse die am weitesten rechts stehende X-Forwarded-For-Adresse, die keiner dieser Proxys ist (Audit-Log, die Zustimmung zum Hinweis für Betreiber, das Anmelde-Ratenlimit und die Agent-Sperre), nie die am weitesten links stehende, die der Client selbst schreiben kann. Setzen Sie sie in der .env; die mitgelieferten Compose-Dateien geben sie an die api und an Caddy weiter.
RESTOW_EDGE_TLS
acme
Ab 0.2.0. Woher die Edge ihr Zertifikat bekommt. acme (oder leer): automatisches HTTPS, Let’s Encrypt für eine öffentliche RESTOW_APP_DOMAIN. internal: ein Zertifikat für RESTOW_APP_DOMAIN von Caddys eigener Zertifizierungsstelle, für die verschlüsselte Strecke hinter einem weiteren Reverse-Proxy; Verbindungen ohne SNI beantwortet die Edge dann ebenfalls mit diesem Zertifikat. internal braucht, egal bei welchem Namen, keinen öffentlichen DNS-Eintrag und keinen eingehenden Port 80. Jeder andere Wert hält die Edge beim Start an. Die Option --behind-proxy des Installationsskripts setzt internal; siehe Hinter einem Reverse-Proxy. 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 .).
RESTOW_EDGE_HSTS
false
true sendet Strict-Transport-Security (mit includeSubDomains). Setzen Sie es erst, wenn RESTOW_APP_DOMAIN eine echte, öffentlich auflösbare Domain ist, für die die Edge ihr eigenes gültiges TLS-Zertifikat terminiert (öffentlicher Modus). Der Wert wird wörtlich verglichen, muss also 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 bestünden dann auf HTTPS für einen Host, der es womöglich nie anbietet, und es gibt keinen Weg zurück, bis das max-age abläuft. Es gilt auch für jede Subdomain von RESTOW_APP_DOMAIN, nicht nur für diesen Host.
Passwort für den Postgres-Superuser, den Docker Compose anlegt. Compose startet postgres ohne es nicht.
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.
DATABASE_MIGRATION_URL
keiner (erforderlich)
Der Datenbankeigentümer (POSTGRES_USER); führt nur Migrationen aus, zum Beispiel postgres://restow:<POSTGRES_PASSWORD>@postgres:5432/restow.
DATABASE_URL
keiner (erforderlich)
Die Anwendungsrolle, der Row Level Security unterliegt, zum Beispiel postgres://restow_app:<Passwort>@postgres:5432/restow. Der Migrationsschritt legt sie mit dem hier angegebenen Namen/Passwort an.
DATABASE_PROVIDER_URL
keiner (erforderlich)
Die Installationsrolle (BYPASSRLS), zum Beispiel postgres://restow_provider:<Passwort>@postgres:5432/restow, genauso angelegt.
DATABASE_AUTH_URL
keiner (optional, seit 0.3.5): der Login wird von den beiden anderen abgeleitet
Die Auth-Rolle, auf der die Anmeldung läuft. Lassen Sie sie leer, leitet die Migration ihren Login aus DATABASE_URL und DATABASE_PROVIDER_URL ab. Setzen Sie sie nur für einen eigenen Login; siehe unten.
volume oder bind: ob das Datenverzeichnis des Dienstes postgres ein Docker-Volume oder ein Verzeichnis auf dem Host ist. Der Updater schreibt bind, wenn er die Datenbank verschiebt.
RESTOW_POSTGRES_DATA
leer: das Volume pgdata
Der Volume-Name, oder mit bind das absolute Verzeichnis auf dem Host, in dem die Daten liegen, zum Beispiel /mnt/volume-1/restow-db/restow-postgres-<Zeit>. Der Updater schreibt sie, wenn er die Datenbank unter Installation → Datenbank verschiebt.
Beide Zeilen sind optional und werden nur von der docker-compose.yml von 0.4.0 oder neuer gelesen. Sind sie gesetzt, starten Sie den Stack nie aus einer Compose-Datei, die sie nicht liest (die Datei von 0.3.6 tut das nicht): PostgreSQL würde seine Daten nicht finden. install.sh verweigert eine solche Datei mit Exit-Code 8. Siehe Datenbank.
Drei Rollen, drei Verbindungszeichenfolgen, drei verschiedene Passwörter (erzeugen Sie jedes mit openssl rand -hex 16). In Compose ist der Datenbank-Host der Dienstname postgres. Siehe Erste Schritte → Die drei Datenbank-Rollen. Die Prozesse starten nicht, wenn sich herausstellt, dass DATABASE_URL ein Superuser ist oder RLS umgehen kann.
Die Auth-Rolle (seit 0.3.5). Die Anmeldung (Sitzungen, Passwörter, Passkeys, Zwei-Faktor-Geheimnisse) läuft auf einer eigenen Datenbankrolle, die die Migration anlegt und aktuell hält. Ihr Login wird von den beiden anderen Logins abgeleitet (<Anwendungsrolle>_auth, zum Beispiel restow_app_auth); Sie setzen dafür nichts und brauchen beim Update keine Änderung in .env. Setzen Sie DATABASE_AUTH_URL, zum Beispiel postgres://restow_auth:<Passwort>@postgres:5432/restow, nur für einen eigenen Login oder wenn Sie die Datenbankrollen selbst verwalten; der Migrationsschritt legt sie wie die anderen an. Die Anwendungsrolle bleibt bei den Mandantendaten unter Row Level Security und darf der Warteschlange nur Jobs hinzufügen. Zusammen mit der Installationsrolle ist die Auth-Rolle die einzige, die die Anmelde-Tabellen erreicht.
Erforderlich. 32-Byte-Schlüsselverschlüsselungsschlüssel (KEK), base64. Umschließt jeden Mandantenschlüssel; bewahren Sie eine Kopie offline auf, denn ohne ihn lässt sich kein Backup je wieder lesen. Siehe Restow selbst sichern.
BETTER_AUTH_SECRET
Erforderlich. Secret für die eigenen Tokens und Sitzungen des Auth-Systems.
Microsoft Entra (mandantenübergreifende App für Backup, Client Credentials)
Client-Secret-Zugangsdaten (füllen Sie genau dieses oder den Zertifikatspfad aus).
ENTRA_CLIENT_SECRET_EXPIRES_AT
Optional, seit 0.4.7: wann ENTRA_CLIENT_SECRET abläuft, wie Entra es zeigt (JJJJ-MM-TT, zum Beispiel 2027-03-01). Restow erinnert 30 Tage vorher, erneut 7 Tage vorher und nach dem Ablauf des Secrets, aber nur mit diesem Datum, weil es es nicht von Microsoft liest. Tragen Sie es in .env ein und erzeugen Sie die api neu. Ein Zertifikat braucht keines (sein eigenes Ende zählt), und ein nicht lesbarer Wert gilt als unbekannt: keine Erinnerung. Das env.example des Release-Stacks führt sie nicht auf; env_file reicht sie trotzdem an die api weiter.
ENTRA_CLIENT_CERT_PATH
Optional: Zertifikatspfad (PEM, privater Schlüssel + Zertifikat) statt eines Secrets. Wird bevorzugt genutzt, wenn beide gesetzt sind.
ENTRA_AUTHORITY_HOST
Optional: Authority-Host für souveräne Clouds. Standard https://login.microsoftonline.com.
DIRECTORY_FULL_SYNC_HOURS
Standard 24. Stunden zwischen vollständigen Verzeichnis-Enumerationen; dazwischen laufen inkrementelle Abgleiche.
Alle diese Werte sind optional: Die App-Registrierung lässt sich stattdessen in der Weboberfläche eintragen (verschlüsselt gespeichert, ohne Neustart wirksam). Sind ENTRA_CLIENT_ID und ENTRA_CLIENT_SECRET oder ENTRA_CLIENT_CERT_PATH hier gesetzt, haben sie Vorrang, und die Weboberfläche zeigt sie schreibgeschützt.
Reserviert für die Anmeldung mit Microsoft (Entra ID), die geplant und nicht Teil von 0.4.7 ist. Sie hat keine Wirkung: Lassen Sie sie leer.
ENTRA_SSO_CLIENT_SECRET
Reserviert für dieselbe Funktion. Es hat in 0.4.7 keine Wirkung: Lassen Sie es leer.
RESTOW_EXPERIMENTAL_MICROSOFT_SIGN_IN
Nur für Entwickler: true schaltet den Code der Microsoft-Anmeldung ein. Das wird nicht unterstützt, und niemand könnte sich so anmelden, weil kein Konto mit einer Microsoft-Identität verknüpft ist. Lassen Sie es leer; die Anmelde-Endpunkte antworten dann mit 404.
Gilt, wenn unter Installation → Benachrichtigungs-Mail nichts gespeichert ist; die Weboberfläche hat Vorrang. Microsoft 365 mit einer eigenen App-Registrierung für Benachrichtigungen und Google Workspace (ein Dienstkonto mit domänenweiter Delegierung) haben hier keine Variablen: Richten Sie sie in der Weboberfläche unter Installation → Benachrichtigungs-Mail ein, die ihre Schlüssel in der Datenbank versiegelt.
Variable
Zweck
MAIL_TRANSPORT
smtp | graph.
SMTP_HOST, SMTP_PORT
SMTP-Server und -Port.
SMTP_SECURE
true für implizites TLS (wird auch bei Port 465 angenommen); sonst STARTTLS.
SMTP_USER, SMTP_PASSWORD
Optionale SMTP-Zugangsdaten.
SMTP_FROM
Absenderadresse.
GRAPH_MAIL_SENDER
Absenderpostfach für den Microsoft-Graph-sendMail-Transport.
GRAPH_MAIL_TENANT_ID
Entra-Mandant des Absenderpostfachs, falls der Einrichtungsassistent keinen nennt.
Erlaubt IMAP-Quellen ohne TLS. Nur Entwicklung; niemals in Produktion.
IMAP_ALLOW_PRIVATE_NETWORKS
nur vom Provider gespeicherte
true lässt jede IMAP-Quelle Loopback und private Netze erreichen; standardmäßig können das nur von einer Provider-Administration gespeicherte Server, und Mandanten-Administrationen sind auf öffentliche Server beschränkt.
Wie die IMAP-Archivierung ein Konto beobachtet (IDLE oder im Intervall), stellen Sie mit den Variablen ARCHIVE_IMAP_* unter Archiv-Erfassung aus dem Postfach und je Quelle mit ihrer Einstellung Nur in Abständen prüfen ein.
Der Standardspeicher der Installation. Der Provider-Inhaber kann ihn auch in der Weboberfläche setzen (Installation → Standard-Repository & Netzlaufwerke); eine dort gespeicherte Einstellung hat Vorrang vor diesen Werten, die als Rückfall bleiben.
Variable
Standard
Zweck
STORAGE_TARGET
local
Zieltyp: local | s3.
STORAGE_LOCAL_PATH
/data/chunks
Pfad im Container für das lokale Standardziel.
STORAGE_COPY_LOCAL_PATH
keiner
Optionales zweites Ziel, in das jeder Standard-Schreibvorgang zusätzlich kopiert wird (eine eingebundene NFS-Freigabe).
S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_PREFIX
keiner
S3-kompatibles Ziel (Hetzner Object Storage, Garage, Wasabi, B2, AWS, …).
S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY
keiner
S3-Zugangsdaten.
S3_FORCE_PATH_STYLE
true
false für virtuell gehostete Bucket-Adressierung.
S3_ALLOW_INSECURE
false (seit 0.4.0)
true akzeptiert einen S3-Endpunkt über einfaches http:// zu einem anderen Host als localhost, 127.0.0.1 oder [::1]. Nur für Test- und Entwicklungsaufbauten, zum Beispiel einen Objektspeicher im Compose-Netzwerk; setzen Sie sie für api und worker. Ohne sie muss ein gespeicherter oder geänderter S3-Endpunkt https:// verwenden (endpoint_insecure), auch für Provider-Administratoren und den Installations-Standard. Ein vor 0.4.0 gespeicherter S3_ENDPOINT arbeitet weiter, und seine Karte und jeder Test sagen in Rot, dass er auf HTTPS umziehen sollte.
Host-Verzeichnis, das in api und worker schreibgeschützt unter /var/lib/restow/import 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 (oder einen MailStore-Exportordner) ab und wählen Sie sie unter Mandanten-Einstellungen → Verbindungen → Quelle hinzufügen → Mail-Dateien importieren.
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 im Browser 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 (erlaubt: 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 vor dem ersten Byte abgelehnt (import-staging-full). Der Import-Ordner des Servers nutzt kein Staging.
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 Nachricht ü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 (export-quota-exceeded), und ein Export, der darüber hinauswächst, schlägt fehl („Der Export ist größer als der Platz für Exporte“, Fehlercode export.quota_exceeded), bis ältere Exporte abgelaufen sind.
PREVIEW_PARSE_WORKERS
2 (1 bis 8)
Parser-Prozesse, die die api gleichzeitig für die Mail-Vorschau, Anhang-Downloads und Journalberichte ausführt. Dieselben Speichergrenzen wie oben.
PREVIEW_TIMEOUT_MS
10000
Wie lange eine Nachricht für ihre formatierte Vorschau brauchen darf. Eine Nachricht, die mehr braucht, wird als Text („Vereinfachte Ansicht“) oder als nicht lesbar angezeigt.
Alles optional. Die Standardwerte passen zum Release-Stack; nur ein eigenes Image braucht Änderungen. Siehe Endpoint-Backup.
Variable
Standard
Zweck
RESTIC_BINARY
restic aus dem PATH
Die restic-Binärdatei, die api und worker für Aufbewahrung, Prüfungen, Restore-Tests, Durchsuchen und Downloads ausführen. Das Image liefert sie unter /usr/local/bin/restic mit.
RESTOW_RESTIC_CACHE_DIR
der Temp-Ordner
Wo restic seine Caches je Endpoint ablegt. Ein Ordner auf einem Volume, zum Beispiel /data/restic-cache, erhält sie über Neustarts hinweg und beschleunigt das Durchsuchen.
RESTOW_AGENT_DIR
/srv/agent
Wo das Image die Agent-Binärdateien ablegt, in /srv/agent/<Version>/<OS>-<Architektur>/. Ein Entwicklungs-Checkout liest stattdessen agent/install aus dem Repository.
RESTOW_AGENT_INSTALL_DIR
/srv/agent/install
Wo das Image die Installationsskripte ablegt. Richten Sie RESTIC_BINARY, RESTOW_AGENT_DIR oder RESTOW_AGENT_INSTALL_DIR nur für ein eigenes Image anderswohin.
RESTOW_ENDPOINT_QUOTA_GIB
2048 (2 TiB)
Speicherbudget eines Endpoint-Repositorys in GiB (ganze oder Dezimalzahlen; 0 schaltet es ab). Eine Administration kann je Rechner einen anderen Wert setzen („Speicherbudget“ in seinen Einstellungen). Von api und worker gelesen.
RESTOW_ENDPOINT_TENANT_QUOTA_GIB
20480 (20 TiB)
Speicherbudget aller Endpoint-Repositorys eines Mandanten zusammen, in GiB (0 schaltet es ab). Ein Upload über ein Budget hinaus wird abgelehnt (endpoint-quota-exceeded), Restores funktionieren weiter, und die Alarme warnen ab 90 Prozent. Von api und worker gelesen.
Parallele Jobs je Warteschlange in einem Worker-Prozess.
WORKER_TENANT_CONCURRENCY
2
Parallele Jobs je Mandant in einem Worker-Prozess.
WORKER_POLL_SECONDS
2
Polling-Intervall von pg-boss.
WORKER_SHUTDOWN_TIMEOUT_MS
50000 (seit 0.3.5)
Wie lange das Herunterfahren auf einen Prüfpunkt laufender Jobs wartet. Halten Sie ihn unter dem stop_grace_period von 60 Sekunden des Dienstes worker im Release-Stack; Dockers Standard von 10 Sekunden würde das Leeren abschneiden.
WORKER_CANCEL_POLL_MS
15000
Wie oft ein laufender Job prüft, ob er abgebrochen wurde.
WORKER_PROGRESS_FLUSH_ITEMS
50
Fortschritt wird alle N Elemente geschrieben …
WORKER_PROGRESS_FLUSH_MS
2000
… oder mindestens alle M Millisekunden.
IMMUTABILITY_RENEWAL_CONCURRENCY
32 (seit 0.4.0; zuvor 8, höchstens 256)
Wie viele Object-Lock-Anfragen die tägliche Erneuerung eines unveränderbaren Repositorys gleichzeitig sendet. Eine unterbrochene Erneuerung macht dort weiter, wo sie stehen blieb.
Seit 0.4.4, alle optional, vom worker gelesen (Business und Service Provider; die Community-Version lässt den Erfassungsdienst ruhen). Die env.example des Release-Stacks führt sie nicht auf: Tragen Sie die, die Sie brauchen, in .env ein, die api und worker lesen. Was sie steuern: Archivierung, Quellen verbinden.
Variable
Standard
Zweck
ARCHIVE_CAPTURE_CONCURRENCY
16
Postfächer, an denen ein Worker-Prozess gleichzeitig arbeitet (ein Strom je archiviertem Postfach und Weg).
ARCHIVE_CAPTURE_TENANT_CONCURRENCY
4
Davon höchstens so viele für einen Mandanten, damit die Postfächer eines Mandanten nicht alle Plätze belegen.
ARCHIVE_BACKFILL_CONCURRENCY
4
Einmalige Übernahmen vorhandener Mail, die in einem Worker-Prozess gleichzeitig laufen.
ARCHIVE_GRAPH_CATCHUP_MINUTES
360
Microsoft 365: wie oft der Delta-Abgleich über jeden Ordner je Postfach läuft, solange Änderungsbenachrichtigungen ankommen. Er läuft sofort nach einer verpassten Benachrichtigung.
ARCHIVE_GRAPH_POLL_MINUTES
15
Microsoft 365 ohne Benachrichtigungen (keine öffentliche https://-URL auf Port 443, siehe Netzwerk und Ports): wie oft jedes Postfach geprüft wird. Das ist dann die Erfassung.
ARCHIVE_IMAP_IDLE_MAX
300
IMAP-Archivierung: Konten, die ein Worker-Prozess mit IMAP IDLE beobachtet, je eine Verbindung. 0 schaltet IDLE ab; weitere Konten werden im Intervall per Anmeldung geprüft. Beachten Sie das Verbindungslimit je Konto Ihrer Anbieter.
ARCHIVE_IMAP_POLL_MINUTES
5
Wie oft eine beobachtete Verbindung die übrigen Ordner des Kontos per STATUS prüft.
ARCHIVE_IMAP_LOGIN_POLL_MINUTES
10
Wie oft ein Konto, das niemand mit IDLE beobachtet, per Anmeldung geprüft wird.
Die öffentliche URL, die Graph-Benachrichtigungen brauchen, ist RESTOW_PUBLIC_URL, es sei denn, Installation → Server & Betrieb → Server setzt eine.
Arbeitsspeicher in MiB, den die entschlüsselten Blockkarten der VM-Disks, die gerade durchsucht oder wiederhergestellt werden, in der api belegen dürfen, nach Größe statt nach Anzahl zwischengespeichert. Erhöhen Sie ihn für sehr große VM-Disks. Siehe Dateien eines Gasts.
RESTOW_HOST_SMBIOS_UUID
keiner (seit 0.4.2)
Die SMBIOS-UUID des Rechners, auf dem Restow läuft, um die VM des Restow-Servers selbst unter den Gästen zu finden. Sie überschreibt /sys/class/dmi/id/product_uuid, das die api sonst liest. Setzen Sie sie nur für einen Host, der /sys verbirgt.
Die Zeitzone der Installation, für eine Installation, in der kein Inhaber in der Weboberfläche eine gewählt hat: ein IANA-Name wie Europe/Vienna. Geplante Updates gelten in ihr, und ein neuer Mandant beginnt mit ihr. Es gilt die erste dieser Angaben: die im Einrichtungsassistenten oder unter Installation → Server & Betrieb → Server gewählte Zeitzone, dann RESTOW_TIME_ZONE, dann die Prozess-Zeitzone TZ der Server-Container, dann Europe/Berlin. Ein Wert, der keine IANA-Zeitzone ist, wird übersprungen, ein Tippfehler hält also nichts an. Nicht in der .env.example: Fügen Sie die Zeile selbst in die .env ein und erzeugen Sie die Container neu (docker compose up -d), wenn Sie sie möchten. Siehe Die Zeitzone der Installation.
SCHEDULER_DEFAULT_TIMEZONE
Europe/Berlin
IANA-Zeitzone, in der die Zeiten der empfohlenen Standard-Zeitpläne ausgelegt werden, zum Beispiel Europe/Vienna. Eine unbekannte Zone stoppt den Scheduler.
SCHEDULER_TICK_MS
30000
Tick-Intervall.
SCHEDULER_LEADER_RETRY_MS
15000
Leader-Wiederholung.
SCHEDULER_BATCH_SIZE
200
Fällige Zeitpläne je Tick.
SCHEDULER_DEFER_MS
3600000
Verzögerung, bevor ein nicht planbarer Zeitplan (ungültiger Cron-Ausdruck) erneut betrachtet wird.
SCHEDULER_LOCK_KEY
keiner
Postgres-Advisory-Lock-Key für die Leader-Wahl; nur ändern, wenn zwei Installationen eine Datenbank teilen.
Alles optional; der Empfänger ist aus, bis JOURNAL_SMTP_PORT gesetzt ist. Einrichtung, DNS, Port 25 und Zertifikat: Exchange-Journaling. Seit 0.4.4 nimmt derselbe Empfänger die Kopien an, die ein Mailanbieter weiterleitet (Weitergeleitete Kopien vom Mailanbieter).
Variable
Standard
Zweck
JOURNAL_SMTP_PORT
keiner (Empfänger aus)
Port, auf dem der SMTP-Journal-Empfänger des Archivs lauscht. Der Empfänger startet nur, wenn dieser Wert gesetzt ist. Exchange Online liefert an Port 25. Die .env.example des Repositorys setzt 25; die env.example des Release-Stacks lässt ihn leer. Leer bleibt er aus: Nichts lauscht, und die Release-Compose-Datei bildet nur einen geschlossenen Port (2525) auf der Loopback-Schnittstelle ab, sodass eine Standardinstallation keinen Mail-Port zum Netz öffnet.
JOURNAL_SMTP_BIND
127.0.0.1
Nur im Release-Stack: die Host-Adresse, auf der der Port veröffentlicht wird. Setzen Sie sie zusammen mit JOURNAL_SMTP_PORT=25 auf 0.0.0.0, um Journal-Reports von Exchange Online zu empfangen; sie müssen den Empfänger direkt erreichen, nicht über Caddy (der Empfänger muss aus dem Internet erreichbar sein).
JOURNAL_HOSTNAME
keiner
Der Hostname, an den Exchange Online zustellt, zum Beispiel archive.example.com: nur der Hostname, ohne Schema, Pfad, Port und Mailadresse. Er bildet die Journal-Adressen der Mandanten, journal+<token>@<Host>; veröffentlichen Sie ihn im DNS. Ohne gültigen Wert zeigt Restow keine vollständige Adresse.
JOURNAL_TLS_CERT_PATH
keiner
Pfad zur Zertifikatskette (PEM, Blatt zuerst) einer öffentlich vertrauten Stelle, passend zu JOURNAL_HOSTNAME. Exchange Online verlangt TLS, daher startet der Empfänger ohne Zertifikat nicht (die Archivseite sagt dann „no TLS certificate“) und greift nie auf ein eingebautes zurück. Mit Zertifikat wird Mail bis STARTTLS abgewiesen. Im Release-Stack: /etc/restow/journal-tls/fullchain.pem.
JOURNAL_TLS_KEY_PATH
keiner
Pfad zum privaten Schlüssel (PEM, nicht mit Passphrase verschlüsselt), der zum Zertifikat gehört. Beide Pfade müssen gesetzt sein. Im Release-Stack: /etc/restow/journal-tls/privkey.pem.
JOURNAL_TLS_DIR
./journal-tls
Compose-Datei beider Stacks: das Host-Verzeichnis, das schreibgeschützt in die api unter /etc/restow/journal-tls eingehängt wird. Legen Sie fullchain.pem und privkey.pem dorthin. Erneuerte Dateien werden innerhalb von fünf Minuten ohne Neustart übernommen. Die api liest sie 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, mit den docker compose cp-Befehlen: Das Zertifikat des Journal-Empfängers.
JOURNAL_ALLOW_INSECURE
leer (aus)
true startet den Empfänger ohne Zertifikat und ohne STARTTLS anzubieten. Nur lokale Entwicklung, nie in Produktion: Exchange Online stellt an so einen Empfänger nicht zu, und Mail liefe unverschlüsselt durchs Netz. Wird ignoriert, solange ein Zertifikat konfiguriert ist: Ein konfiguriertes, aber defektes Zertifikat fällt nie auf Klartext zurück.
JOURNAL_MAX_SIZE_MB
150
Größter angenommener Journal-Report, in MB. Größere Reports werden abgewiesen.
JOURNAL_RATE_PER_IP
600 (seit 0.4.4; davor fest 60)
Verbindungen je Absender-IP-Adresse und Minute, je api-Prozess. Darüber antwortet der Empfänger mit 421. Erhöhen Sie ihn für einen Hoster, der die Mail vieler Konten weiterleitet.
JOURNAL_RATE_PER_ADDRESS
300 (seit 0.4.4)
Zustellungen je Archivadresse (Journal-Adresse oder Archivadresse eines IMAP-Kontos) und Minute, je api-Prozess. Darüber antwortet der Empfänger bei RCPT TO mit 451.
Nur für die öffentliche Demo unter deploy/demo/; lassen Sie alle in einer normalen Installation leer. deploy/demo/README.md und deploy/demo/.env.example im Repository beschreiben die übrigen Variablen der Demo.
Variable
Zweck
RESTOW_DEMO
true schaltet den Demo-Modus ein: Das Demo-Konto meldet sich ohne Code einer Authenticator-App an, eine einzige Sperre lehnt jede Änderung ab, die die Installation verändern oder nach außen wirken könnte, und Webhooks und Benachrichtigungen tun nichts. Im Demo-Modus gibt es kein Setup-Token.
RESTOW_DEMO_EMAIL, RESTOW_DEMO_PASSWORD
Zugangsdaten des Demo-Kontos, im Klartext auf der Anmeldeseite angezeigt.
RESTOW_DEMO_SEED_TOKEN
Gemeinsames Secret zwischen dem Seed-Prozess der Demo und der api.
RESTOW_EDITION
Die Edition, die die Demo ohne Lizenzschlüssel zeigt (siehe Kern).
Seit 0.4.5 liest deploy/demo/reset.sh die durch Doppelpunkt getrennte Liste der Compose-Dateien auch aus deploy/demo/.env (vorher nur aus seiner Umgebung) und protokolliert, welche Dateien ein Lauf nutzt. Eine Liste aus der .env, die web auf jeder Schnittstelle veröffentlichen würde (die Überschreibung für eine Demo auf einer eigenen VM, mit den Ports 80 und 443), wird nur zusammen mit RESTOW_DEMO_PUBLISH_PUBLIC=true genutzt; Einträge, die keine Compose-Dateien in deploy/demo/ sind, werden abgelehnt, bevor etwas angehalten wird.
Der schnelle nächtliche Reset (seit 0.4.5). Nach einem vollständigen Seed speichert der Reset eine Vorlage (einen Datenbank-Dump und die gefüllten Volumes) und stellt sie in den folgenden Nächten statt eines erneuten Seeds wieder her, sodass die Demo etwa 15 bis 25 Sekunden offline ist statt vieler Minuten. RESTOW_DEMO_TEMPLATES=false schaltet ihn aus. Eine Vorlage, die älter ist als RESTOW_DEMO_TEMPLATE_MAX_AGE_DAYS (Standard 7; 0 seedet immer), ein neues Release, neue Images, eine geänderte .env oder eine fehlgeschlagene Wiederherstellung führen zu einem vollständigen Seed. Die übrigen Einstellungen: wo Vorlagen liegen (Standard templates, die neuesten zwei bleiben), der freie Platz in MB, der nach dem Speichern einer Vorlage bleiben muss (Standard 1024), und wie lange das Speichern auf laufende Jobs wartet (Standard 300 Sekunden).
