Ports und Rollen

Ports

Das sind die Ports des Restow-Stacks und wer sie erreichen kann. Alle übrigen Verbindungen (die Ziele, mit denen sich der Restow-Host verbindet, das Docker-Netz, wie Endpoints und Instanz ihre Repositories erreichen, und Firewall-Regeln für eine eigene VM, einen Host hinter einem Reverse Proxy oder eine Installation nur im LAN) stehen unter Netzwerk und Ports.

Port	Dienst	Erreichbarkeit	Wozu
80, 443 (RESTOW_HTTP_PORT, RESTOW_HTTPS_PORT im Release-Stack)	Caddy	Öffentlich im öffentlichen Modus	Liefert die Web-Oberfläche aus, leitet /api/*, /agent/* und /install/* an die api weiter (siehe Agent-Endpunkte) und terminiert TLS (automatisches Let’s Encrypt für RESTOW_APP_DOMAIN). Hinter einem weiteren Reverse Proxy nennen Sie diesen in RESTOW_EDGE_TRUSTED_PROXIES.
25 (JOURNAL_SMTP_PORT)	Archiv-Journal-Empfänger, innerhalb der api	Geschlossen, bis JOURNAL_SMTP_PORT gesetzt ist; dann TCP 25 eingehend aus dem Internet	Empfängt Journal-Reports von Exchange Online und seit 0.4.4 Kopien, die ein Mailanbieter weiterleitet, per SMTP mit verpflichtendem STARTTLS und einem eigenen TLS-Zertifikat; Teil des Archivs, Business und Service Provider. Er muss direkt erreicht werden, nicht über Caddy oder einen HTTP-Proxy; lauscht er auf einem anderen Port, leiten Sie Port 25 darauf weiter. Im Release-Stack legt JOURNAL_SMTP_BIND die Adresse fest, auf der er veröffentlicht wird (Standard Loopback). Siehe Exchange-Journaling.
3000 (RESTOW_API_PORT)	api	Standardmäßig nur Loopback	Health-Checks und die REST-API auf dem Host. Caddy erreicht sie über das Docker-Netz.
5432 (POSTGRES_PORT)	postgres	Im Quell-Stack nur Loopback; im Release-Stack nicht veröffentlicht	PostgreSQL.
8090	updater	Nur internes Docker-Netz, kein veröffentlichter Port	Der Opt-in-Updater (docker compose --profile updater up -d), der den Docker-Socket einbindet, und der ist auf dem Host gleichbedeutend mit root; siehe Updates. Die api erreicht ihn unter RESTOW_UPDATER_URL (Standard http://updater:8090). Caddy leitet nur ein schreibgeschütztes Status-Dokument (/_maintenance/status) an ihn weiter, für die Wartungsseite; es nennt keine Version.
8091	mounter	Nur internes Docker-Netz, kein veröffentlichter Port	Der Mounter (Profil mounts; neue Installationen starten ihn seit 0.4.0 standardmäßig), der ebenfalls den Docker-Socket einbindet. Er startet die Runner der Sicherung von Freigaben und bindet NFS-Freigaben als Repository-Speicher über die Weboberfläche ein; siehe Mounter und NFS-Speicher. Die api und der worker erreichen ihn unter RESTOW_MOUNTER_URL (Standard http://mounter:8091). Jeden Dienst, Port und jedes Volume der Compose-Datei finden Sie in der Release-Stack-Referenz.
445 (SMB), 2049 (NFS)	Ihre Dateiserver	Ausgehend vom Docker-Host zum Dateiserver; nichts eingehend	Sicherung von Freigaben (seit 0.4.0): Der Docker-Host bindet die Freigabe für einen Lauf ein. NFSv3 braucht zusätzlich 111 und den Mount-Daemon. Siehe Netzwerk und Ports.
5173 (RESTOW_WEB_PORT), 1025 / 8025 (MAILPIT_SMTP_PORT / MAILPIT_UI_PORT)	Vite-Dev-Server, Mailpit	Nur Entwicklung	docker compose --profile dev up -d und --profile mail up -d; nicht Teil eines normalen Deployments.

worker und scheduler stellen keine eigenen Ports bereit.

Runner für Freigaben (seit 0.4.0) sprechen mit der api über das interne Docker-Netz runners, auf /internal/file-shares/v1 und /internal/file-shares/restic/<Freigaben-ID>/, mit einer Zugangsberechtigung, die für einen Lauf gilt und nur Daten hinzufügen kann. Diese Pfade leitet der Web-Edge nie weiter (Caddy antwortet auf alles unter /internal/ mit 404), und die api lehnt weitergeleitete Anfragen dorthin ab. Siehe die Release-Stack-Referenz.

Graph-Benachrichtigungs-Hooks (seit 0.4.4) sind zwei öffentliche Pfade derselben Adresse, /api/v1/hooks/graph/notifications und /api/v1/hooks/graph/lifecycle. Microsoft Graph sendet ohne Sitzung dorthin, einmal je archiviertem Microsoft-365-Postfach, das Graph erfasst; jeder Aufruf wird gegen das Geheimnis des Abonnements geprüft, und die Pfade antworten mit 404, solange keine Edition die Erfassung aus dem Postfach enthält. Sie brauchen TCP 443 aus dem Internet und eine öffentliche https://-URL, siehe Microsoft ruft die Instanz auf.

Größengrenzen für Anfragen

Jeder Request-Body ist begrenzt, damit keine Anfrage die api mehr puffern lässt, als sie braucht. Ein Body über einer Grenze wird mit 413 und urn:restow:problem:payload-too-large abgelehnt (die Grenze steht in limitBytes).

Wo	Grenze
api, jede Route, die unten nicht genannt ist	1 MiB
api: Auswahlen für Restore und Export, Import-Aufträge, Verzeichnisregeln, IMAP-Kontolisten und ihr CSV-Import, der Laufbericht eines Agents	16 MiB
api: Download-Auswahlen bei Endpoints	4 MiB
api: Upload-Stücke eines Imports	die Stückgröße, höchstens 32 MiB
api: der restic-Datenpfad (/agent/restic/)	128 MiB je Objekt
Caddy-Edge: Anmeldung, Einrichtung, Links zum Passwort-Setzen und Agent-Anmeldung	1 MiB
Caddy-Edge: der Rest von /api	33 MiB
Caddy-Edge: /agent/v1	16 MiB
Caddy-Edge: /agent/restic	keine Grenze an der Edge (die api setzt ihre eigene)
Caddy-Edge: /agent/pve/v1 (Proxmox-VE-Knoten)	80 MiB (Pakete von bis zu 16 Blöcken zu je 4 MiB)
Caddy-Edge: /agent/pve/restic (Proxmox-VE-Container)	keine Grenze an der Edge

Eine fehlerhafte oder zu große Anmeldeanfrage eines Agents zählt als fehlgeschlagener Anmeldeversuch.

Import-Ordner

Beide Compose-Stacks binden einen Ordner des Hosts schreibgeschützt in die Container api und worker ein: RESTOW_IMPORT_DIR (Standard ./import neben der Compose-Datei) erscheint unter /var/lib/restow/import. Jeder Mandant nutzt seinen eigenen Unterordner. Restow schreibt nie hinein. Siehe Mail-Dateien importieren und exportieren.

Agent-Endpunkte

Rechner, die mit dem Restow-Agent gesichert werden, und Proxmox-VE-Knoten erreichen Ihre Instanz per HTTPS unter ihrer öffentlichen Adresse, über Caddy, und brauchen keinen weiteren Port. Caddy leitet diese Pfade an api weiter:

Pfad	Zweck
/agent/v1/...	Die Agent-API: Enrollment, Konfiguration, Heartbeat, Läufe, Agent-Update.
/agent/restic/<Endpoint-ID>/...	Das restic-Repository eines Endpoints, für den Agent nur anhängend.
/agent/pve/v1/...	Die API des Knoten-Helfers restow-pve für Proxmox VE: Enrollment, Meldungen, Aufgaben, die Gästeliste, Upload und Lesen von VM-Blöcken, Sicherungsstände.
/agent/pve/restic/<Gast-ID>/...	Das restic-Repository eines Proxmox-VE-Containers, für den Knoten nur anhängend.
/install/...	Die Installationsskripte (linux.sh, macos.sh, pve.sh für Proxmox-VE-Knoten) und die Binärdateien von Agent, restow-pve und restic mit ihren SHA256SUMS.

Der Agent verbindet sich nur nach außen; auf dem Rechner lauscht nichts. Siehe Endpoint-Backup. Wie die Backup-Daten vom Agent ins Speicherziel gelangen, steht unter Netzwerk und Ports. Proxmox-VE-Knoten (eine Preview) erreichen Ihre Instanz auf demselben Weg über die beiden Pfade unter /agent/pve/, siehe Proxmox-VE-Backup und Netzwerk und Ports.

Anwendungsrollen

Rolle	Umfang	Kann
Provider-Administration	Gesamte Installation	Verwaltet Mandanten, lädt Mandanten-Administrationen ein, hat Zugriff auf jeden Mandanten. Seit 0.3.1 kann jede Edition, auch Community, mehrere Provider-Administrationen mit Rollen haben (Inhaber, Administrator, Techniker, Nur lesen), im Provider-Team; ein Mitglied auf ausgewählte Mandanten zu beschränken ist Service Provider.
Mandanten-Administration	Ein Mandant	Lässt sich in jeder Edition einladen. Verwaltet dessen Einrichtung (Schutz, Quellen, Zeitpläne), Repositories, Mitglieder und Restores, einschließlich Wiederherstellung im Auftrag einer anderen Nutzerin oder eines anderen Nutzers (Impersonation, immer auditiert).
Restore-Operator (ab 0.3.5)	Ein Mandant	Sieht und stellt jedes Backup des Mandanten wieder her, ohne ihn zu verwalten (Jobs, Speicher, Nutzer). Seit 0.4.0 gehören die Dateien von Servern und Clients, von Proxmox-VE-Gästen und SharePoint-Websites dazu. Siehe Team und Rollen.
Mandanten-Nutzer	Nur eigene Daten	Meldet sich an, stellt nur das eigene Postfach/OneDrive/IMAP-Konto wieder her und lädt es herunter.

Wie Mandanten und Rollen mit Editionen zusammenhängen, steht unter Mandantenfähigkeit.

Datenbankrollen

Rolle	.env-Variable	Rechte
Eigentümer	DATABASE_MIGRATION_URL	Besitzt jede Tabelle; führt nur Migrationen aus.
Anwendung	DATABASE_URL	NOSUPERUSER, NOBYPASSRLS, besitzt keine Tabelle. Die gesamte mandantenbezogene Arbeit zur Laufzeit. Seit 0.3.5 erreicht sie nur Mandantendaten: von den Anmelde-Tabellen nur Namen und E-Mail-Adresse einer Person, keine Installationstabelle, und in der Job-Warteschlange darf sie nur einen Job hinzufügen.
Installation	DATABASE_PROVIDER_URL	BYPASSRLS. Mandantenübergreifende Abfragen, installationsweite Einstellungen, der Scheduler, die Webhook-Zustellung, das Schema von pg-boss.
Auth (seit 0.3.5)	DATABASE_AUTH_URL, optional	Anmeldung: Sitzungen, Passwörter, Passkeys und Zwei-Faktor-Geheimnisse sowie der Code für Anmeldung, Konten und Mitgliedschaften, unter Row Level Security. Die Migration legt sie an, mit einem Login, der von den beiden anderen abgeleitet wird (<Anwendungsrolle>_auth, zum Beispiel restow_app_auth); dafür setzen Sie nichts.

Vollständige Erklärung: Erste Schritte → Die drei Datenbank-Rollen.