Fehlerbehebung

Zuerst die Erklärung in der Web-Oberfläche lesen

Jeder fehlgeschlagene Job, jedes Element, jeder Abgleich und jede Prüfung in Restow sagt, was passiert ist, warum und was zu tun ist, mit einem Link auf die passende Einstellungsseite, wo es eine gibt. Unter Technische Details steht, was ein Supportfall braucht: der HTTP-Status, der Fehlercode von Microsoft Graph und die Request-IDs, ohne Geheimnisse. Schauen Sie zuerst dort nach. Fehlererklärungen listet die Ursachen und was Sie jeweils tun. Für Server und Clients, die mit dem Agent gesichert werden, siehe Fehlerbehebung beim Endpoint-Backup.

Die Links in diesen Erklärungen führen standardmäßig auf diese Seite. RESTOW_DOCS_TROUBLESHOOTING_URL richtet sie stattdessen auf Ihr eigenes Runbook.

Installation

• docker compose up -d schlägt fehl, oder ein Container startet immer wieder neu. Prüfen Sie docker compose ps und docker compose logs <dienst>. Die häufigste Ursache ist ein fehlender erforderlicher Wert in .env. Siehe Erste Schritte → Erforderliche Werte ausfüllen; Compose weigert sich, postgres überhaupt zu starten, wenn POSTGRES_PASSWORD nicht gesetzt ist, und caddy, wenn RESTOW_APP_DOMAIN nicht gesetzt ist.
• Compose bricht mit set RESTOW_IMAGE in .env oder set RESTOW_WEB_IMAGE in .env ab. Der Release-Stack braucht beide Image-Zeilen eines Builds in .env, zum Beispiel ghcr.io/restow-backup/restow:0.4.7 und ghcr.io/restow-backup/restow-web:0.4.7 (oder restow-community und restow-web-community). Siehe Erste Schritte → Erforderliche Werte ausfüllen.
• Die api startet nicht und meldet RESTOW_SETUP_TOKEN must have at least 16 characters. Ein selbst gesetztes Setup-Token braucht mindestens 16 Zeichen, Leerzeichen und Bindestriche nicht mitgezählt. Erzeugen Sie eines mit openssl rand -hex 16, oder entfernen Sie die Zeile, damit die api ein Token in ihr Log schreibt. Siehe Einrichtungsassistent → Setup-Token.
• docker compose --profile updater up -d startet den Updater nicht. Die Release-Compose-Datei nimmt das Image des Updaters aus RESTOW_UPDATER_IMAGE und, solange das leer ist, aus RESTOW_IMAGE; der Befehl scheitert also nur, wenn auch RESTOW_IMAGE leer ist. Tragen Sie RESTOW_IMAGE ein (und nutzen Sie, falls Sie RESTOW_UPDATER_IMAGE selbst setzen, ein Image desselben Builds). Siehe Release-Stack-Referenz → updater und Updates → Aktivieren.
• Caddy kann kein Zertifikat beziehen. RESTOW_APP_DOMAIN muss (per A/AAAA) auf den Host auflösen, und die Ports 80/443 müssen für die Let’s-Encrypt-Challenge aus dem Internet erreichbar sein. Das gilt nur im öffentlichen Modus.
• api, worker oder scheduler startet mit einem Row-Level-Security-Fehler nicht. Die Anwendungsrolle (DATABASE_URL) darf kein Superuser sein und RLS nicht umgehen können; diese Prüfung läuft absichtlich beim Start. Prüfen Sie die drei Datenbankrollen erneut in Erste Schritte.
• install.sh bricht mit Exit-Code 8 ab und sagt, die Datenbank dieser Installation liege in einem Verzeichnis. Die Datenbank wurde auf einen anderen Datenträger verschoben (Installation → Datenbank), und die docker-compose.yml, die der Installer einsetzen oder starten würde, liest RESTOW_POSTGRES_DATA nicht aus der .env; so gestartet würde der Stack seine Datenbank nicht finden. Es wurde nichts geändert. Verwenden Sie die docker-compose.yml von Release 0.4.0 oder neuer. Siehe Datenbank.
• Der Updater lehnt ein Update mit dem Blocker disk_space ab. Seit 0.4.0 addiert er den Datenbank-Dump, die Images und die Migrationen und lehnt ein Update ab, das nicht hineinpasst. Geben Sie Platz frei oder verschieben Sie die Datenbank auf einen anderen Datenträger. Siehe Updates.
• Ein Hinweis sagt, der Datenträger ist knapp. Auf dem Datenträger unter der Datenbank oder unter dem lokalen Standard-Repository ist weniger als ein Zehntel oder weniger als 5 GiB frei. Siehe Datenbank.
• Nach einem Server-Update bleiben neue Läufe eine Weile angehalten. Seit 0.4.2 endet die Pause nicht, wenn der neue Server startet: Proxmox-VE-Knoten und Agenten installieren zuerst das Release, bis alle, die sich melden, fertig sind, höchstens 15 Minuten lang. Installation → Updates zeigt den Fortschritt und den Befehl für die, die nicht erreicht wurden. Siehe Knoten und Agenten ziehen das Update nach.
• Nach einem Update von Hand bleiben Proxmox-VE-Knoten und Agenten auf dem alten Release. Ein Update von Hand startet keinen Schritt, in dem sie dem Server nachziehen. Unter Installation → Updates erscheinen sie als Update verfügbar, und Knoten und Agenten jetzt aktualisieren (seit 0.4.3, für einen Administrator mit allen Mandanten) startet diesen Schritt: Neue Läufe werden höchstens 15 Minuten angehalten, während erreichbare Knoten und Agenten das Release installieren. Ein Knoten mit restow-pve 0.4.1 ignoriert es und braucht ein Update von Hand. Siehe Update auf 0.4.3.
• Der Reiter Updates sagt „Es wird geprüft, ob das Update angenommen wurde …“ oder sagte kurz „Der Updater läuft nicht“. Der Updater prüft Docker, die Compose-Konfiguration und den Speicherplatz, bevor er ein Update annimmt, was bis zu etwa 12 Sekunden dauern kann. Seit 0.4.3 wartet die API bis zu einer Minute und fragt den Updater dann nach seinem Zustand, das falsche „läuft nicht“ ist also weg; der Reiter zeigt den Countdown, sobald der Updater antwortet. Vor 0.4.3 konnte ein solches Update ohne die Pause neuer Läufe und ohne den Schritt für Knoten und Agenten laufen: Nutzen Sie Knoten und Agenten jetzt aktualisieren. Siehe Wenn etwas schiefgeht.
• Ein geplantes Update liegt zu einer anderen Zeit, als Sie erwartet haben, oder hat nicht begonnen. Geplante Updates gelten in der Zeitzone der Installation, die der Dialog nennt: Prüfen Sie sie unter Installation → Server & Betrieb → Server (die Reihenfolge ist die dort gewählte Zeitzone, RESTOW_TIME_ZONE, TZ, dann Europe/Berlin). Ein Plan wird mit dem Audit-Eintrag update.plan_failed verworfen, wenn der Server zur geplanten Zeit ausgefallen war und mehr als eine Stunde später zurückkam. Siehe Zu einer gewählten Zeit.
• Läufe für Freigaben warten, oder der Mounter meldet runner_network_missing. Der Mounter ist aus, oder die docker-compose.yml ist älter als 0.4.0 und hat das interne Netz runners nicht. Führen Sie das Installationsskript erneut aus und starten Sie den Mounter. Siehe Update auf 0.4.0 und Freigaben: Fehlerbehebung.

Sicherungen

• Ein Job hängt oder ist sehr langsam. Prüfen Sie den Fortschritt des Jobs auf einen Drosselungshinweis: Die Drosselung durch Microsoft Graph wird angezeigt, nicht verborgen, und die erste Sicherung eines großen Mandanten kann legitim Tage dauern. Ab 0.3.5 wird eine Microsoft-Graph-Anfrage, die innerhalb von 5 Minuten keine Antwort bekommt, wiederholt, statt bis zum Zeitlimit des Jobs zu hängen. Gibt es weder Drosselungshinweis noch Fortschritt, prüfen Sie /healthz und /readyz und ob die Container worker und scheduler laufen.
• Eine lange erste Sicherung wurde unterbrochen. Ab 0.3.5 setzt sich eine Sicherung, die nach einem gespeicherten Prüfpunkt durch ihr Zeitlimit (23 Stunden) oder durch einen Neustart des Workers unterbrochen wurde, fort, ohne einen Wiederholungsversuch zu verbrauchen, bis zu 21 Tage nach ihrem ersten Start. Die Laufansicht zeigt eine solche Unterbrechung als Information, nicht als Fehler. Damit der Worker den Prüfpunkt beim Stoppen speichern kann, braucht der Dienst worker stop_grace_period: 60s (Updates).
• Ein Postfach, OneDrive oder eine Website sagt „Nicht gesichert: Konto deaktiviert“, „Nicht gesichert: keine Lizenz“ oder „Nicht gesichert: gesperrt“ (seit 0.4.7). Microsoft meldet, dass es nichts zu sichern gibt: Das Konto ist deaktiviert, es hat keine Exchange-Online-Lizenz, oder das OneDrive oder die Website ist gesperrt (HTTP 423, was Microsoft mit dem OneDrive eines Kontos ohne Lizenz tut). Das ist kein Fehler und löst keine Fehler-Warnung aus; die vorhandenen Sicherungen bleiben erhalten. Aktivieren Sie das Konto, weisen Sie eine Lizenz zu oder heben Sie die Sperre auf, dann setzt die Sicherung nach dem nächsten Verzeichnisabgleich wieder ein. Bis eine Administration Ja, beabsichtigt wählt, steht das Objekt gelb da, und die Bereitschaft bleibt gelb. Siehe Objekte, die nicht mehr gesichert werden.
• Eine Sicherung sagt „Vom Dienst gedrosselt, wird wiederholt“ (seit 0.4.7). Microsoft Graph oder der Speicher hat Restow gebeten, langsamer zu machen, oder war länger nicht verfügbar, als die Wiederholungen des Laufs reichen. Das ist gelb, kein Fehler, und der nächste geplante Lauf versucht es erneut; Jetzt sichern versucht es früher. Bleibt das Objekt gebremst, meldet sich Sicherung überfällig. Siehe Sicherungen, die ein Dienst gebremst hat.
• Eine Berechtigung, die Sie der App erteilt haben, wird weiter abgelehnt. Seit 0.4.7 holt Restow nach einem 401 oder 403 ein neues Token, und die Berechtigung greift innerhalb etwa einer Minute, ohne neues Client-Secret. Vor 0.4.7 behielt ein Token die alten Berechtigungen bis zu etwa eine Stunde lang. Die Ausnahme ist die Benachrichtigungs-Mail über eine Microsoft-365-App-Registrierung: Eine später erteilte Berechtigung Mail.Send greift, sobald das zwischengespeicherte Token abläuft. Siehe Eine Berechtigung später hinzufügen.
• Die Sicherungen aller Mandanten warteten hinter einer Sicherung (vor 0.4.7). Eine eingereihte Sicherung eines Objekts, dessen Sicherung noch lief (der nächste geplante Lauf, Jetzt sichern), hielt früher die Backup-Warteschlange aller Mandanten auf, bis die laufende endete. Seit 0.4.7 wartet sie auf ihr Objekt, und jede andere Sicherung kommt durch.
• Die Glocke sagt, dass die Zugangsdaten der Microsoft-365-App oder der eigenen App einer Quelle ablaufen oder abgelaufen sind (seit 0.4.7). Legen Sie in Entra ein neues Client-Secret (oder Zertifikat) an, tragen Sie es mit seinem neuen Ablaufdatum ein und löschen Sie erst dann das alte. Ohne Datum gibt es keine Erinnerung. Siehe Ablauf des Geheimnisses oder Zertifikats.
• Eine Sicherung wird als fehlgeschlagen angezeigt. Restow markiert eine Sicherung als fehlgeschlagen, wenn ihre geplante Restore-Prüfung nicht erfolgreich war, selbst wenn der Sicherungslauf selbst Erfolg gemeldet hat. Behandeln Sie das als zutreffenden Status, nicht als Fehlalarm. Siehe Backups und Zeitpläne.
• Eine Sicherung einer Freigabe endet mit Warnungen oder schlägt fehl. Der Lauf nennt die Ursache (share.*) und was zu tun ist; die häufigen stehen unter Freigaben: Fehlerbehebung und Grenzen, die vollständige Liste unter Fehlererklärungen.
• Der Verzeichnisabgleich warnt, dass SharePoint-Websites weder gefunden noch gesichert werden (sites_unavailable). Der App-Registrierung der Sicherung fehlt Sites.Read.All oder Sites.ReadWrite.All, oder die Administration des Kunden hat noch nicht erneut zugestimmt. Siehe SharePoint Online.
• Ein Sicherungsstand ist als Verdächtig markiert, und die Aufbewahrung ist angehalten. Die Ransomware-Erkennung hat Anzeichen in dem gefunden, was die Sicherung gesehen hat. Bis eine Administration den Befund als Fehlalarm markiert oder die Aufbewahrung freigibt, wird kein Sicherungsstand dieses Objekts gelöscht. Siehe Ransomware-Erkennung.
• Das Speichern eines S3-Repositorys schlägt mit endpoint_insecure fehl. Seit 0.4.0 muss ein neuer oder geänderter S3-Endpunkt https:// verwenden (außer zu localhost, 127.0.0.1 und [::1]). Verwenden Sie einen HTTPS-Endpunkt oder setzen Sie für einen Testaufbau S3_ALLOW_INSECURE=true. Siehe Unveränderbare Backups.
• Nach einem Aufbewahrungslauf auf einem unveränderbaren Repository kommt kein Platz zurück. Objekte, die noch gesperrt sind, lassen sich nicht löschen; der Sicherungsstand bleibt sichtbar, und der Platz kommt zurück, sobald die Sperre abgelaufen ist, bis zu der Dauer plus 7 Tage später. Siehe Unveränderbare Backups.
• Die Speicherprüfung führt Packs als vorübergehend nicht lesbar auf, und Objekte sagen Achtung. Seit 0.4.2 gilt ein Pack, das ein Repository im Moment nicht liefern konnte (ein abgebrochener Download, eine zurückgesetzte Verbindung, ein Timeout, S3 mit der Bitte um langsameres Tempo oder verweigerter Zugriff), nicht als beschädigt. Prüfen Sie die Erreichbarkeit und die Zugriffsrechte des Speichers; die nächste Prüfung liest diese Packs zuerst, und Diese Packs erneut prüfen unter Wiederherstellbarkeit → Speicherintegrität liest nur sie noch einmal. Nicht wiederherstellbar werden sie erst, wenn ein Pack nachweislich beschädigt ist oder in 3 Prüfungen in Folge über mindestens 24 Stunden nicht lesbar blieb. Siehe Beschädigt oder vorübergehend nicht lesbar und die Ursachen verify.storage_unreadable und verify.storage_unreadable_persistent in den Fehlererklärungen.
• „Vorhandene Backups dort belassen, wo sie sind“ ist ausgegraut oder wird mit storage-switch-blocked-by-repositories abgelehnt. Container oder Freigaben des Mandanten haben restic-Repositories auf dem aktuellen primären, die nur ein Verschieben mitnimmt; das Befördern einer Kopie ebenso. Wählen Sie Vorhandene Backups verschieben (empfohlen). Siehe Das primäre Repository ersetzen.
• Eine Sicherung wird als abgebrochen angezeigt. Jemand hat sie mit Sicherung stoppen beendet (Proxmox-VE-Gäste, Server und Clients, Freigaben). Das ist kein Fehler und löst keinen Alarm aus. Siehe Eine Sicherung stoppen und eine Warteschlange anhalten.
• Ein Proxmox-VE-Gast sagt „Nicht prüfbar: Repository gesperrt“. Ein anderer Vorgang hielt zwei Stunden lang die Sperre des Repositorys des Containers, sodass die Restore-Prüfung den Sicherungsstand nicht lesen konnte. Das ist gelb und kein Fehler: Über den Sicherungsstand ist noch nichts bekannt. Restow versucht es nach zehn Minuten erneut, entfernt veraltete Sperren selbst und versucht es nach einem Tag wieder; Jetzt prüfen liest früher. Vor 0.4.3 zeigte dieselbe Ursache eine rote „Restore-Prüfung fehlgeschlagen“ mit dem Exit-Code 11 von restic, die bis zur nächsten Prüfung rot bleibt. Siehe Restore-Prüfungen, die nicht laufen konnten und die Fehlerbehebung für Proxmox VE.

Restores

• Ein Restore ist nicht dort gelandet, wo Sie es erwartet haben. Per Design ist ein Restore darauf ausgelegt, ein vorhandenes Original nicht zu überschreiben; lag am Zielort bereits etwas mit demselben Namen, hat Restow das wiederhergestellte Element stattdessen daneben geschrieben (ein neuer Ordner für Mail, eine umbenannte Datei). Prüfen Sie den Protokolleintrag des Restores oder seine Job-Detailseite für den verwendeten Modus und den genauen Ablageort. Siehe Backup und Restore.
• Sie finden einen Restore nicht im Audit-Log. Jeder Restore wird in jeder Edition aufgezeichnet, die Audit-Log-Ansicht ist aber eine Funktion von Business und Service Provider. Haben Sie die Ansicht und finden keinen, prüfen Sie, ob Sie im richtigen Mandanten (Service-Provider-Edition) und Zeitraum suchen.

Archiv und Journaling

• Die Archiv-Seite zeigt „Empfänger läuft nicht“, „Noch keine Reports“ oder „Seit mehr als 24 Stunden kein Report“. Grund und Prüfschritte stehen unter Exchange-Journaling: das TLS-Zertifikat, das der Empfänger braucht, DNS, TCP-Port 25 aus dem Internet, der Microsoft-365-Connector und die Journalregel sowie das Postfach für nicht zustellbare Journalberichte.
• Die Graph-Erfassung prüft die Postfächer alle 15 Minuten, statt benachrichtigt zu werden (seit 0.4.4). Die Archiv-Seite nennt den Grund. graph.notification_url_unavailable: Die öffentliche URL ist nicht https:// auf Port 443, oder sie nennt localhost, eine private Adresse oder einen Host auf .local, .internal oder .lan. graph.subscription_failed: Microsoft hat das Abonnement abgelehnt, meist weil es /api/v1/hooks/graph/notifications aus dem Internet nicht erreichen kann. Siehe Netzwerk und Ports.
• Ein Postfach zeigt unter „Erfassung aus den Postfächern“ den Status Fehler, oder die Warnung Archiv-Erfassung seit über einer Stunde fehlerhaft kam. Suchen Sie das Postfach in der Tabelle Je Postfach und prüfen Sie, was Sie bei einer fehlgeschlagenen Sicherung davon prüfen würden: den Consent, das Passwort, ob der Server erreichbar ist. Funktioniert es wieder, kehrt der Status von selbst zurück; Neu abgleichen liest das Postfach von vorn. Siehe Archivierung.
• Die IMAP-Archivierung führt dazu, dass ein Anbieter Verbindungen ablehnt. Viele Anbieter erlauben je Konto nur wenige Verbindungen, und IDLE hält eine offen. Stellen Sie Archivierung der Quelle auf Nur in Abständen prüfen (Quellen verbinden).
• Es kommen keine weitergeleiteten Kopien an. Prüfen Sie den Status des Kontos unter Weiterleitung an das Archiv, die Regel beim Anbieter mit der Adresse von der Archiv-Seite und den Empfänger (Port 25, Zertifikat, JOURNAL_HOSTNAME). Siehe Weitergeleitete Kopien vom Mailanbieter.
• Der Empfänger startet nicht, nachdem Sie JOURNAL_SMTP_PORT gesetzt haben. Er startet nur mit einem eigenen Zertifikat und Schlüssel (JOURNAL_TLS_CERT_PATH, JOURNAL_TLS_KEY_PATH); das Log der api nennt die Datei, die fehlt, nicht verwendbar oder abgelaufen ist. Siehe Exchange-Journaling → TLS-Zertifikat.

Einrichtung und Anmeldung

• Der Einrichtungsassistent meldet „Das ist nicht das Setup-Token dieses Servers“. Das Token ist bei jedem Start der api neu, bis die Einrichtung abgeschlossen ist; vermutlich haben Sie ein älteres kopiert. Zeigen Sie das zuletzt ausgegebene mit docker compose logs api | grep 'SETUP TOKEN' an und geben Sie es ein (Groß- und Kleinschreibung und Bindestriche spielen keine Rolle). Ist RESTOW_SETUP_TOKEN in .env gesetzt, geben Sie stattdessen diesen Wert ein; dann wird nichts ausgegeben. Die API beantwortet ein falsches Token mit 403 urn:restow:problem:setup-token-invalid. Siehe Einrichtungsassistent → Setup-Token.
• Der Assistent meldet, dass sich das Setup-Token geändert hat. Die api wurde neu gestartet, während Sie im Assistenten waren. Geben Sie das zuletzt ausgegebene Token ein; Ihre Eingaben bleiben erhalten.
• Ein Inhaber hat seinen Passkey, seine Authenticator-App oder sein Passwort verloren. Stellen Sie den Zugang auf dem Server wieder her: docker compose exec api restow admin recover --email <inhaber>. Der Befehl setzt ein neues Passwort, entfernt Authenticator-App und Passkeys des Inhabers, beendet seine Sitzungen und schreibt einen Audit-Eintrag; er funktioniert nur für Inhaber. Andere Administrationen setzt ein Inhaber in der Web-Oberfläche zurück. Siehe Einrichtungsassistent → Admin-Zugang wiederherstellen.
• Passkeys werden noch nicht angeboten. Passkeys erscheinen erst, sobald Ihre Domain nachweislich sauber verbunden ist: gültiges HTTPS-Zertifikat, passende Origin. Bis dahin läuft die Anmeldung über den Notfall-Passwort-Weg mit TOTP-Pflicht. Prüfen Sie die Domain erneut, nachdem Sie DNS oder Zertifikate korrigiert haben (siehe Einrichtungsassistent → Passkey-Bereitschaft).
• Eine Microsoft-365-Admin-Consent-Freigabe sieht unvollständig aus. Restow meldet genau, welche Berechtigungen erteilt wurden und welche nicht; wiederholen Sie den Consent-Flow mit einer Administration, die im Mandanten ausreichende Rechte hat (siehe Erste Schritte).
• Personen können sich nicht mit ihrem Microsoft-Konto anmelden. Die Anmeldung mit Microsoft (Entra ID) ist geplant und in 0.4.7 nicht verfügbar (sie kam nicht mit 0.4.0): Der Code für die Anmeldung existiert, aber noch nichts verknüpft ein Restow-Konto mit einer Microsoft-Identität, und die Anmeldeseite bietet sie nicht an. Melden Sie sich mit einem Passkey oder mit dem Notfall-Passwort und einer Authenticator-App an.

Integrationen und Lizenzierung

• Ein Webhook zeigt „Fehlerhaft“ an. Öffnen Sie sein Zustellprotokoll für den genauen HTTP-Status oder Verbindungsfehler jedes Versuchs. Ein Ziel in einem Loopback- oder privaten Netz wird abgelehnt, sofern der Betreiber es nicht ausdrücklich erlaubt hat. Siehe Integrations-API → Webhooks.
• Ein Lizenzschlüssel wird abgelehnt. Prüfen Sie, ob der Schlüssel für die Installations-ID dieser Installation ausgestellt wurde (zu finden unter Installation → Lizenz, bei Schlüssel installieren). Ein für eine andere Installation ausgestellter Schlüssel oder einer, dessen Ed25519-Signaturprüfung fehlschlägt, wird abgelehnt statt teilweise angewendet. Siehe Lizenz und Editionen.
• Ein Menüeintrag ist ausgegraut mit Schloss, oder es gibt keinen Ort für einen Lizenzschlüssel. In den vollständigen Images bleiben Einträge von Business und Service Provider gesperrt, bis ein Schlüssel installiert ist; das Schloss führt zu Installation → Über, dem Bereich, den Installation → Lizenz öffnet. Die Community-Images haben keine Lizenzeinstellungen und überhaupt keine Einträge von Business oder Service Provider: Wechseln Sie zu den vollständigen Images, um sie zu nutzen. Siehe Lizenz und Editionen.

Fehlerantworten der Web-Oberfläche und der API

Die Web-Oberfläche macht aus diesen Antworten eine Meldung mit dem, was zu tun ist; die API liefert sie als Problem Details (type ist urn:restow:problem:<name>).

Problemtyp	Was Sie sehen, und warum	Was zu tun ist
recent-sign-in-required (403)	„Bestätigen Sie, dass Sie es sind“. Das Ändern der Update-Quelle oder des Tokens, das Ankündigen eines Updates, das Setzen oder Ändern eines Endpoint-Hooks und das Anzeigen des Repository-Passworts eines Endpoints erfordern eine Anmeldung aus den letzten 10 Minuten.	Bestätigen Sie mit Ihrem Passkey, oder melden Sie sich erneut an und wiederholen Sie die Änderung. Siehe Updates → Bestätigen, dass Sie es sind.
update-source-not-allowed (409)	Ein Update soll aus einem Repository gebaut werden, das RESTOW_UPDATER_SOURCE_HOSTS nicht nennt. Der Quellcode-Modus ist standardmäßig aus.	Tragen Sie das Repository in RESTOW_UPDATER_SOURCE_HOSTS in der .env ein und erstellen Sie den Updater neu, nutzen Sie die Standardquelle, oder aktualisieren Sie von Hand. Siehe Updates → Zwei Modi.
update-not-verifiable (409)	Das Release veröffentlicht keinen Digest des Anwendungs-Images, der Updater kann also nicht prüfen, was er installieren würde.	Prüfen Sie das Release mit cosign und aktualisieren Sie von Hand. Siehe Ein Release verifizieren.
invalid-update-source (422)	Die gespeicherte Update-Quelle ist keine verwendbare https-Adresse eines Repositorys, oder sie zeigt auf eine private Adresse oder einen nur lokal gültigen Hostnamen, den RESTOW_UPDATER_SOURCE_HOSTS nicht nennt.	Geben Sie die öffentliche Adresse des Repositorys ein, oder nennen Sie einen internen Host in RESTOW_UPDATER_SOURCE_HOSTS. Siehe Updates → Quelle, Kanal und Token.
pve-guest-excluded (409)	Jetzt sichern oder das Zuordnen eines Proxmox-VE-Gasts zu einem Job, für einen Gast, den eine Administration von der Sicherung ausgeschlossen hat (seit 0.4.7).	Wählen Sie Wieder einschließen auf der Seite des Gasts oder in seiner Inventarzeile, dann sichern Sie ihn oder ordnen ihn einem Job zu. Ihn aus seinem Job zu nehmen bleibt möglich. Siehe Einen Gast von der Sicherung ausschließen.
endpoint-quota-exceeded (403, an den Agent)	Der Upload eines Rechners würde sein Speicherbudget oder das des Mandanten überschreiten. Die Sicherung stoppt; Restores funktionieren weiter.	Erhöhen Sie das Speicherbudget des Rechners oder RESTOW_ENDPOINT_QUOTA_GIB / RESTOW_ENDPOINT_TENANT_QUOTA_GIB, oder sichern Sie weniger. Siehe Fehlerbehebung beim Endpoint-Backup.
endpoint-hooks-not-allowed (409)	Für einen Rechner, dessen Hook-Richtlinie aus ist (oder der keine meldet), wurde ein Hook gesetzt. Nur root auf dem Rechner kann Hooks erlauben.	Führen Sie auf dem Rechner sudo restow-agent hooks scripts (oder any) aus, oder entfernen Sie den Hook. Siehe Fehlerbehebung beim Endpoint-Backup.
endpoint-repository-locked (503)	„Das Repository ist mit einer Sicherung oder Wartung beschäftigt“: Der Server arbeitet gerade am Repository dieses Rechners (zum Beispiel Aufbewahrung oder eine Prüfung), während Sie durchsuchen oder herunterladen.	Versuchen Sie es in einer Minute erneut. Siehe Fehlerbehebung beim Endpoint-Backup.
preview-busy (503)	Alle Parser-Prozesse für die Mail-Vorschau sind belegt, und die Warteschlange ist voll.	Versuchen Sie es erneut. Passiert das häufig, erhöhen Sie PREVIEW_PARSE_WORKERS (sofern der Speicher reicht). Siehe Umgebungsvariablen.
preview-unreadable (422)	Ein Anhang einer Nachricht, die sich innerhalb der Grenzen des Parsers nicht lesen lässt. Die Nachricht selbst wird mit ihren Kopfdaten angezeigt.	Laden Sie die ganze Nachricht als EML herunter, oder stellen Sie sie wieder her.
payload-too-large (413)	Der Request-Body ist größer, als die Route erlaubt (1 MiB für die meisten Anfragen, 16 MiB für Auswahlen bei Restore und Export, Import-Aufträge und Listen; die Grenze steht in limitBytes).	Senden Sie kleinere Anfragen, teilen Sie zum Beispiel eine große Auswahl auf.
feature-unavailable (403)	Community-Images: eine Funktion, die nur Business oder Service Provider bietet (ein zweiter Mandant, Provider-API-Schlüssel, die Ansichten über alle Mandanten, zeitgesteuerte Berichte).	Nutzen Sie die vollständigen Images mit einem Lizenzschlüssel. Siehe Lizenz und Editionen.
edition-required (403)	Vollständige Images: eine Funktion von Business oder Service Provider ohne passenden Lizenzschlüssel.	Installieren Sie einen Schlüssel unter Installation → Lizenz.
export-quota-exceeded (422)	Die nicht abgelaufenen Exporte des Mandanten belegen bereits EXPORT_MAX_TENANT_BYTES (Standard 50 GiB).	Warten Sie, bis ältere Exporte ablaufen (EXPORT_TTL_HOURS), exportieren Sie weniger, oder erhöhen Sie die Grenze. Siehe Mail-Dateien importieren und exportieren.
import-staging-full (422)	Die auf den Import wartenden Uploads des Mandanten würden IMPORT_MAX_STAGING_BYTES (Standard 100 GiB) überschreiten.	Warten Sie, bis ein Import fertig ist, entfernen Sie einen Upload, nutzen Sie den Import-Ordner des Servers (er braucht kein Staging), oder erhöhen Sie die Grenze. Siehe Mail-Dateien importieren und exportieren.
setup-token-invalid (403)	Ein falsches oder veraltetes Setup-Token.	Kopieren Sie das zuletzt ausgegebene Token aus dem Log der api. Siehe Einrichtungsassistent.
cross-site-request (403), unsupported-media-type (415)	Eine Anfrage für Einrichtung, Passwort-Setzen oder Agent-Anmeldung kam von einer anderen Website oder ohne JSON-Body.	Senden Sie JSON von der Restow-Adresse selbst.

Wo Sie als Nächstes nachsehen

• Das Audit-Log, für wer was wann getan hat.
• Das Ergebnis des Testversands Ihres Benachrichtigungs-Mail-Transports (SMTP oder Microsoft Graph sendMail), eingerichtet während der Ersteinrichtung: ein fehlerhafter Transport bedeutet, dass Betriebsmeldungen Sie nicht erreichen, selbst wenn alles andere gesund ist.
• Die Seite Status und Roadmap, wenn Sie unsicher sind, ob etwas überhaupt schon existieren soll.