Updates

Restow wird als Docker-Images ausgeliefert, in zwei Builds je Release (die vollständigen Images und die Community-Images, siehe Erste Schritte als Administrator), mit automatisch angewendeten Datenbankmigrationen. Es gibt zwei Wege zu aktualisieren:

• Von Hand, mit docker compose. Das ist der Standard und funktioniert immer. Die nächsten Abschnitte beginnen dort.
• Über die Weboberfläche, unter Installation → Updates. Restow sagt Ihnen, wenn es eine neuere Version gibt, und installiert sie, wenn Sie den Updater-Dienst aktivieren, für Sie, sofort oder (seit 0.4.2) zu einem Datum und einer Uhrzeit Ihrer Wahl: mit einem Countdown für alle angemeldeten Personen, zuerst einer Datenbanksicherung und einem automatischen Zurücksetzen, wenn die neue Version nicht startet, solange ihre Datenbankmigrationen noch nicht gelaufen sind. Nach einer Migration, die sich nicht rückgängig machen lässt, hält der Updater an und sagt Ihnen, wie Sie die Sicherung zurückspielen (siehe Wenn etwas schiefgeht).

Auf dieser Seite passiert nichts, solange Sie es nicht einschalten. Eine frische Installation sucht nicht nach Updates, kontaktiert dafür keinen Server und startet den Updater nicht.

Vor jedem Update

1. Lesen Sie die Release-Notes jeder Version zwischen Ihrer und der neuen, besonders Breaking Changes und Update-Aufwand. Jedes Release nennt seinen Update-Aufwand (siehe die drei Arten unten), dazu die erwartete Ausfallzeit und den Weg zurück.

2. Sichern Sie die Datenbank. Sie enthält Metadaten, die Job-Warteschlange und das Audit-Log. Gesicherte Inhalte liegen im Chunk-Store und werden von einem Update nicht angefasst.

   docker compose exec -T postgres pg_dump -U restow -Fc restow > restow-$(date +%F).dump

   Der Updater erledigt das selbst (siehe unten).

3. Prüfen Sie, dass RESTOW_MASTER_KEY offline gesichert ist. Ein Update ändert ihn nie, aber ohne ihn lässt sich keine Sicherung lesen. Siehe Restow selbst sichern.

4. Prüfen Sie den freien Platz (seit 0.4.0): Das Update braucht Platz für einen Datenbank-Dump, die neuen Images und die Migrationen. Installation → Datenbank zeigt die Schätzung; der Updater lehnt ein Update ab, das nicht hineinpasst (Speicherplatz).

5. Denken Sie an laufende Läufe. Eine Sicherung, die beim Update läuft, wird sauber angehalten oder abgewartet, wie Sie es im Installationsdialog wählen (Laufende Läufe während eines Updates). Ein Update von Hand tut keines von beiden. Seit 0.4.2 können Sie vorher auch eine laufende Sicherung eines Gasts, eines Rechners oder einer Freigabe selbst stoppen, siehe Proxmox VE, Server und Clients und Freigaben.

6. Prüfen Sie, ob Ihr Lizenzschlüssel das Release abdeckt (vollständige Images mit einem Business- oder Service-Provider-Schlüssel, seit 0.4.5). Jeder bisher ausgestellte Schlüssel ist eine Beta-Lizenz und deckt jedes 0.x- und 1.x-Release ab. Ein Schlüssel mit Update-Zeitraum deckt die Releases ab, die bis zu seinem Ende erschienen sind: Der Reiter Updates markiert die anderen, und ein Release, das Sie von Hand starten und das der Schlüssel nicht abdeckt, startet nicht (Releases, die Ihr Schlüssel nicht abdeckt).

Die drei Arten von Updates

1. Nur Konfiguration

Nur Werte in der .env ändern sich (eine neue optionale Variable, eine geänderte Einstellung).

docker compose up -d

up -d erstellt die Container neu, deren Konfiguration sich geändert hat. docker compose restart ist kein Update: Es startet die laufenden Container mit ihrem alten Image und ihrer alten Umgebung neu und übernimmt weder ein neues Image noch eine geänderte .env.

2. Neues Image, mit automatischen Migrationen

Der übliche Fall. Restow wendet Datenbankmigrationen selbst an: Der api-Container führt sie als Datenbankbesitzer (DATABASE_MIGRATION_URL) aus, bevor er eine Anfrage bedient, und startet nicht, wenn eine fehlschlägt. Die Release-Notes sagen, ob es Migrationen gibt und wie lange sie ungefähr dauern.

Release-Stack (die veröffentlichten Images, deploy/release/docker-compose.yml). Tragen Sie die Version in die .env ein und ziehen Sie die Images:

.env

RESTOW_IMAGE=ghcr.io/restow-backup/restow:X.Y.Z
RESTOW_WEB_IMAGE=ghcr.io/restow-backup/restow-web:X.Y.Z

Eine Installation mit dem Community-Build aktualisiert genauso, mit ihren eigenen beiden Images ghcr.io/restow-backup/restow-community und ghcr.io/restow-backup/restow-web-community. RESTOW_UPDATER_IMAGE gehört allein Ihnen; ein Update ändert die Zeile nie (siehe Der Updater (opt-in)).

docker compose pull
docker compose up -d

Verfolgen Sie dann die Migrationen und den Start:

docker compose logs -f api

Das Log zeigt restow: applying database migrations, danach restow: starting role 'api'.

3. Manuelle Schritte

Ein Release, das mehr braucht als die Befehle oben (eine neue Pflichtvariable, eine geänderte Compose-Datei, einen einmaligen Befehl), nennt jeden Schritt in der richtigen Reihenfolge unter Update-Aufwand und Breaking Changes. Führen Sie sie in dieser Reihenfolge aus, vor oder nach docker compose up -d, genau wie beschrieben. Der Updater kennt solche Schritte nicht: Er wendet das Image an und startet die Dienste neu. Lesen Sie zuerst die Notes, und aktualisieren Sie von Hand, wenn dort mehr steht.

Nach dem Update

curl -fsS http://127.0.0.1:3000/healthz
curl -fsS http://127.0.0.1:3000/readyz
docker compose ps

Prüfen Sie dann die Version unten in der Seitenleiste der Weboberfläche und starten Sie für einen Mandanten Jetzt prüfen: Eine bestandene Restore-Prüfung belegt, dass die neue Version noch lesen kann, was die alte geschrieben hat.

Sichern Sie Proxmox-VE-Knoten (eine Preview), Server oder Clients, ziehen deren Helfer seit 0.4.2 das Server-Update von selbst nach: Neue Läufe bleiben angehalten, während die Knoten und Agenten das neue Release installieren, höchstens 15 Minuten lang. Siehe Knoten und Agenten ziehen das Update nach. Haben Sie von Hand aktualisiert oder ist dieser Schritt ausgeblieben, startet Knoten und Agenten jetzt aktualisieren ihn im Reiter Updates (seit 0.4.3). Führen Sie bei einem Knoten, den das nicht erreicht hat, als root auf ihm restow-pve update aus, siehe Knoten aktualisieren und entfernen; bei einem Agenten sudo restow-agent update.

Update auf 0.4.7

0.4.7 ist ein neues Image mit vier Datenbankmigrationen (0066 bis 0069). Sie fügen Spalten, zwei Check-Constraints und einen Trigger hinzu und schreiben keine Tabelle um; die einzige Datenänderung ist, dass 0069 die Zeilen aktualisiert, die schon verwaist sind. Es bringt keine neue Pflicht-Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Der Vertrag der Integrations-API wechselt additiv auf 1.7.0, mit einer Änderung der Bedeutung, die Sie zuerst lesen müssen (der erste Punkt). Was Sie wissen sollten:

• Breaking: status: "orphaned" heißt jetzt auch „noch an der Quelle, aber nicht mehr gesichert“. Bisher bedeutete orphaned: aus der Quelle entfernt. Seit 0.4.7 umfasst es auch ein Objekt, dessen Konto deaktiviert ist, das keine Exchange-Online-Lizenz hat oder das Microsoft gesperrt hat, und das neue statusReason (account_disabled, no_license oder locked; null bei einem aus der Quelle entfernten Objekt) unterscheidet sie. Das gilt in GET /api/v1/objects, GET /api/v1/users, im object.status von GET /api/v1/jobs und in objects.orphaned von GET /api/v1/status. Eine Integration, die orphaned als gelöschtes Konto behandelt, muss statusReason prüfen, bevor sie handelt, zum Beispiel bevor sie in einem PSA einen Nutzer abmeldet. Siehe Vertrag 1.7.0.

• Die Migrationen, in dieser Reihenfolge. Sie laufen beim Start der api:

  Migration	Was sie tut
  0066_pve_guest_exclusion	Zwei nullbare Spalten an pve_guests (excluded_at, excluded_by).
  0067_pricing	Die Spalte settings.pricing (jsonb, Vorgabe {}: kein Preis gesetzt).
  0068_app_secret_alerts	Die Spalte settings.app_secret_alerts (jsonb, Vorgabe {}): die letzte Erinnerung vor dem Ablauf von App-Zugangsdaten.
  0069_object_status_reason	Fünf nullbare Spalten an protected_objects (status_reason, inactive_since, inactive_notified_at, status_confirmed_at, status_confirmed_by), zwei Check-Constraints und ein Trigger, der sie mit dem Status des Objekts im Gleichschritt hält. Sie aktualisiert nur die Zeilen, die schon orphaned sind.

• Nicht mehr gesicherte Objekte warten gelb auf eine Bestätigung. Ein Postfach eines deaktivierten oder unlizenzierten Kontos, ein OneDrive oder eine SharePoint-Website, die Microsoft gesperrt hat, und ein aus der Quelle entferntes Objekt zeigen Nicht mehr gesichert, bitte bestätigen, bis eine Administration Ja, beabsichtigt wählt; danach sind sie grau. Das ist kein Fehler, aber die Bereitschaft bleibt bis dahin mindestens gelb. Objekte, die schon vor dem Update verwaist waren, gelten als bestätigt (migration) und lösen keine Meldung aus, es entsteht also keine lange gelbe Liste. Deaktivierte und unlizenzierte Postfächer sowie gesperrte OneDrives und Websites, die jede Nacht fehlschlugen, erkennt der erste Verzeichnisabgleich oder die erste Sicherung nach dem Update (eine gesperrte Website an ihrer ersten Sicherung). Rechnen Sie mit einem Hinweis je Objekt (object.inactive; ein unlizenzierter Nutzer hat oft zwei Objekte, Postfach und OneDrive) oder mit einer Warnung für einen Mandanten mit vielen (object.inactive_many), und bestätigen Sie sie unter den geschützten Objekten, sobald sie beabsichtigt sind. Siehe Objekte, die nicht mehr gesichert werden.

• Sicherungen, die Microsoft Graph oder der Speicher gebremst hat, zählen nicht mehr als fehlgeschlagen. Eine Sicherung, die nach allen Wiederholungen mit graph.throttled, graph.service_unavailable oder storage.rate_limited endet, zeigt gelb Vom Dienst gedrosselt, wird wiederholt. Sie verlässt die Zähler der Fehlschläge, macht keinen Job fehlerhaft und löst keine Meldung backup.failed und keinen Webhook job.failed aus; die Regeln für überfällige Sicherungen melden sich, wenn keine Sicherung durchkommt. Die Zählung liest die zu jedem Lauf gespeicherte Ursache, sodass frühere Läufe mit diesen Ursachen nach dem Update genauso erscheinen und die Fehlerzähler vergangener Zeiträume verlassen (Statistik und Dashboard). Dasselbe gilt für eine Sicherung, die neutral endet, weil ein Objekt nicht mehr gesichert wird (graph.mailbox_inactive, graph.object_locked, config.object_inactive). GET /api/v1/jobs behält für beide den Status failed: Lesen Sie failure.code (und das statusReason des Objekts) und behandeln Sie sie wie den Zustand des Objekts, nicht wie einen Fehler. Siehe Fehlererklärungen.

• Webhooks und Benachrichtigungsempfänger bekommen die neuen Ereignisse erst, wenn sie angehakt sind. Die Ereignisse object.inactive, object.inactive_many, source.app_secret_expiring und installation.app_secret_expiring erreichen einen Webhook oder Empfänger nur, wenn die Benachrichtigungsmatrix sie eingeschaltet hat; eine Glocken-Spalte, die nie geändert wurde, zeigt sie. Eine Wiederherstellung, die abgeschlossen wurde, ohne etwas wiederherzustellen, während Elemente fehlschlugen, löst jetzt restore.failed und den Webhook job.failed aus (data.job.status bleibt completed), und ein Job, den der Reconciler endgültig beendet, löst job.failed wie jeder andere aus. Siehe Benachrichtigungen und Berichte.

• Eine Berechtigung, die Sie der App erteilen, gilt ohne neues Client-Secret. Restow behielt das Token, das es geholt hatte, mit den Berechtigungen der App von damals bis zu etwa eine Stunde lang; eine Berechtigung, die dazwischen erteilt wurde, wurde bis dahin oder bis zur Eingabe eines neuen Secrets abgelehnt. Jetzt lässt ein 401 oder 403 von Graph Restow einmal ein neues Token holen (höchstens einmal pro Minute je Tenant oder Quelle) und die Anfrage erneut senden. Die Benachrichtigungs-Mail über eine Microsoft-365-App ist die Ausnahme, siehe die bekannten Probleme unten. Siehe Erste Schritte.

• Eine eingereihte Sicherung kann die Backup-Warteschlange aller Mandanten nicht mehr blockieren. Eine eingereihte Sicherung eines Objekts, dessen Sicherung noch lief (der nächste geplante Lauf, Jetzt sichern), hielt früher die Sicherungen aller Mandanten auf, bis die laufende endete. Sie wartet jetzt auf ihr Objekt und lässt jede andere Sicherung durch. Die Korrektur ist ein Patch an pg-boss 10.4.2; beim Bauen aus dem Quellcode wird er über pnpm.patchedDependencies angewendet (patches/pg-boss@10.4.2.patch, von pnpm install angewendet), behalten Sie also den Ordner patches. Die Images tragen den Patch. Siehe Aus dem Quellcode bauen.

• Erinnerungen, bevor das Client-Secret oder das Zertifikat einer App-Registrierung abläuft. Restow warnt 30 Tage vorher, erneut 7 Tage vorher und nach dem Ablauf, für die zentrale App und für eine Quelle mit eigener App. Es braucht das Datum, weil es es nicht aus Microsoft Graph liest (dafür wäre Application.Read.All nötig). Für die zentrale App mit ihrem Secret in .env tragen Sie die neue optionale Variable ENTRA_CLIENT_SECRET_EXPIRES_AT ein (JJJJ-MM-TT, wie Entra es zeigt) und erzeugen die api neu. Ein Zertifikat braucht keine, und ein nicht lesbarer Wert gilt als unbekannt. Eine Quelle, die vor 0.4.7 über eine eigene App verbunden wurde, hat kein Datum und damit keine Erinnerung: Tragen Sie bei einem Client-Secret das Datum auf der Seite der Quelle unter Läuft ab ein; ein Zertifikat bekommt sein Datum, wenn es erneut eingegeben wird. Die Ablauf-Badge wird 30 statt 60 Tage vor dem Ende gelb und ab 7 Tagen rot. Das env.example des Release-Stacks nennt die Variable nicht (die .env.example des Repositorys schon); env_file reicht sie trotzdem an die api weiter (Umgebungsvariablen). Siehe Erinnerungen, bevor Zugangsdaten einer App ablaufen.

• Teilausfälle kosten einen Bereich oder ein Element, nicht den ganzen Lauf. Eine Postfach-Sicherung behält die Mails des Laufs, wenn Kalender oder Kontakte abgelehnt werden (403), setzt nach einem 401 mitten im Lauf fort, synchronisiert vollständig neu, wenn Graph einen gespeicherten Delta-Link ablehnt, und speichert eine Nachricht, die Exchange nicht in MIME umwandeln kann, als JSON. Eine SharePoint-Bibliothek oder -Liste, die Graph nicht liefert, ist ein Element-Fehler, und der Rest der Website bekommt seinen Sicherungsstand. Ein OneDrive, dessen Laufwerk Microsoft nicht mehr findet, scheitert als graph.onedrive_unavailable, dauerhaft und ohne Wiederholung. Eine IMAP-Sicherung behandelt eine Anmeldung oder einen Lesebefehl, den der Server wegen eines Limits ablehnt, als imap.server_limit (vorübergehend, wird wiederholt) statt als falsches Passwort oder volles Postfach. In der IMAP-Archiv-Erfassung hält eine Nachricht, die der Server ablehnt, ihren Ordner nicht mehr auf. Eine Wiederherstellung über IMAP, deren Verbindung abbricht, wird auf einer frischen Verbindung wiederholt. Für Sie ist nichts zu tun; die Lauf-Seiten und die Fehlererklärungen sagen, was passiert ist.

• Wiederherstellungen, die nichts wiederhergestellt haben, sagen es. Eine abgeschlossene Wiederherstellung mit fehlgeschlagenen Elementen und keinem wiederhergestellten zeigt rot Nichts wiederhergestellt; eine, die jedes Element übersprungen hat, zeigt gelb Alles übersprungen und bleibt restore.completed. Eine Wiederherstellung in das ursprüngliche Postfach eines deaktivierten oder unlizenzierten Kontos wird mit dem Grund abgelehnt. Siehe Sicherung und Wiederherstellung.

• Die Wiederherstellbarkeit bewertet ein aus seiner Quelle entferntes Objekt ohne das Alter seiner letzten Sicherung. Ein in Microsoft 365 gelöschtes Postfach wird zum Beispiel nicht mehr rot, weil seine letzte Sicherung altert: Nichts sichert es mehr, es wird also danach bewertet, ob sich diese Sicherung wiederherstellen lässt. Die Tabelle sagt In der Quelle entfernt, Sicherungen bleiben. Das gilt ab dem Update, ohne neue Prüfung; ein Objekt, dessen neueste Sicherung nie geprüft wurde, bekommt noch eine Prüfung von der nächsten geplanten Prüfung. Siehe Objekte, die nicht mehr gesichert werden.

• Proxmox-VE-Gäste lassen sich bewusst von der Sicherung ausschließen (eine Vorschau). Das Update schließt keinen aus: Gäste ohne Job zählen weiter als Kein Backup-Job, bis eine Administration sie ausschließt. restow-pve braucht in diesem Release kein Update; der Server zieht die Sicherungen eines ausgeschlossenen Gasts zurück, bevor ein Knoten sie bekommt. Siehe Einen Gast von der Sicherung ausschließen.

• Der empfohlene Job schaltet das Mail-Archiv ein. Wo die Installation die Erfassung aus dem Postfach anbietet (archive.mailboxCapture) und der Mandant Postfächer oder Konten hat, die ein Archiv erfassen kann, legen Empfohlenen Job anlegen und Alles ohne Job schützen den neuen Mail-Job so an, dass er sichert und archiviert, oder schalten das Archivieren in einem bestehenden Mail-Job über alle Objekte ein (seine Zeitpläne bleiben). Bestehende Mail-Jobs ändern sich nur, wenn eine Administration den empfohlenen Job anwendet, nie durch das Update. Siehe Backup-Jobs.

• Die Preise sind nach dem Update leer. Die neue Seite Installation → Preise (Monatspreis je Postfach und je GB oder TB, vom Inhaber gesetzt) zeigt die Kachel Preis je Monat in der Übersicht eines Mandanten erst, wenn der Inhaber einen Preis eingetragen hat. Restow rechnet nichts ab und begrenzt nichts. Siehe Mandantenfähigkeit.

• Kleinere Änderungen. Ein Hintergrund-Job beachtet ein Retry-After von Microsoft Graph bis zu 5 Minuten (die Oberfläche behält eine Minute); ein Postfach-Mitglied mit eigenem Zeitplan wird für den Alarm für überfällige Sicherungen nach diesem Zeitplan beurteilt, und eine Sicherung, die noch läuft (bis zu 21 Tage), ist nicht überfällig; das Zeitlimit eines Jobs zählt ab dem Moment, in dem die Warteschlange ihn herausgegeben hat; das Proxmox-VE-Inventar zeigt die Größe der ersten Sicherung und den Durchschnitt der Folgesicherungen als Text in der Zeile (Inventar); und die Lizenzseite führt die Anmeldung mit Microsoft nicht mehr unter dem auf, was Business freischaltet (sie ist weiterhin experimentell und standardmäßig aus).

• Sicherheit und Abhängigkeiten. ip-address 10.7.5 und seroval 1.7.5 beheben Hinweise in transitiven Abhängigkeiten, zod 4.6.7 in der Kopie, die better-auth nutzt. Ein Hinweis zum Speicherverbrauch beim Prüfen eines großen Arrays (GHSA-mrhx-c7xc-m3w5) nennt auch zod 3, das die eigene Anfrage-Validierung von Restow nutzt und für das es keine behobene 3.x gibt; das Audit der CI übergeht diesen einen Hinweis, bis Restow auf zod 4 umgestellt wird, und das Größenlimit des Anfragekörpers der API (1 MB bei den meisten Routen) begrenzt ihn. Mehrere weitere Abhängigkeiten sind aktualisiert (better-auth, mailparser, nodemailer, smtp-server, msgreader, Vite, React und weitere).

• Der Rollback auf 0.4.6 nach den Migrationen wurde nicht getestet. Sichern Sie die Datenbank vor dem Update und spielen Sie die Sicherung zurück, um zurückzugehen (Von Hand zurücksetzen).

• Bekannte Probleme in 0.4.7:

  • Die Erkennung deaktivierter, unlizenzierter und gesperrter Objekte wurde gegen eine simulierte Graph-API getestet, nicht gegen einen echten Microsoft-365-Tenant, und der Ausschluss von Gästen lief nicht gegen einen echten Proxmox-VE-Knoten. Eine Antwort von Microsoft, die Restow nicht als „kein Postfach“ oder als Sperre erkennt, bleibt ein gezählter Fehler, wie bisher.
  • GET /api/v1/jobs hat kein Feld, das eine gebremste oder neutrale Sicherung von einer fehlgeschlagenen unterscheidet; lesen Sie failure.code.
  • Benachrichtigungs-Mail über eine Microsoft-365-App-Registrierung holt nach einer Ablehnung kein neues Token: Eine später erteilte Berechtigung Mail.Send greift, sobald das zwischengespeicherte Token abläuft.
  • Das Ablaufdatum eines Client-Secrets wird nicht von Microsoft gelesen: Ohne eingetragenes Datum (unter Installation, in ENTRA_CLIENT_SECRET_EXPIRES_AT oder an der Quelle) gibt es keine Erinnerung. Eine Quelle mit einem älteren eigenen Secret ohne eigene App (gemeinsame Client-ID) hat in Restow kein Datum; stellen Sie sie auf eine eigene App oder die zentrale App um.
  • In der Liste der Berichte der Wiederherstellbarkeit trifft ein Filter auf die Bewertung die gespeicherte Bewertung: Ein Bericht, der vor dem Update oder noch an der Quelle gespeichert wurde, zählt das Alter der Sicherung, sodass ein solcher Bericht eines aus seiner Quelle entfernten Objekts unter Rot erscheinen kann, obwohl er grün zeigt. Prüfungen ab 0.4.7 speichern die Bewertung ohne das Alter. Der Verlauf der Bereitschaft früherer Tage zeigt das Gelb unbestätigter Objekte nicht, weil nur die aktuelle Bestätigung gespeichert wird, nicht, wann sie erteilt wurde.
  • Eine Nachricht, auf die die IMAP-Archiv-Erfassung verzichtet (nach drei Durchläufen), Nachrichten, die der Backfill nicht lesen konnte, und ein bekannter Mail-Ordner, den Graph nicht auflösen wollte, stehen nur im Log des Workers, nicht in der Oberfläche.
  • Das Ausschließen einer Auswahl von Proxmox-VE-Gästen im Inventar sendet eine Anfrage je Gast; scheitert eine, bleiben die Gäste davor ausgeschlossen, und die Liste aktualisiert sich.
  • Gruppenkalender und Unterhaltungen wurden gegen eine simulierte Graph-API getestet, nie gegen einen echten Microsoft-365-Tenant (wie in 0.4.5), und IMAP-Quellen mit OAuth2 lassen sich weiterhin nicht in der API oder der Oberfläche anlegen.
  • Die bekannten Probleme von 0.4.4 gelten weiterhin.

Update auf 0.4.6

0.4.6 ist ein neues Image ohne Datenbankmigration. Es bringt keine neue Pflicht-Umgebungsvariable und keine neue Einstellung, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Aus der API wird nichts entfernt: Der Vertrag der Integrations-API bleibt bei 1.6.0 (siehe unten). Was Sie wissen sollten:

• Aktualisieren Sie restow-pve auf jedem Proxmox-VE-Knoten (eine Vorschau), bevor Sie sich auf Container-Wiederherstellungen oder Startprüfungen verlassen. Das aktuelle Proxmox VE übergibt die Storage-ID an die Container-Wiederherstellung des Backup-Providers vor dem Info-Hash, und das Plugin früherer Releases scheiterte daran mit Can't use string ("restow") as a HASH ref. Jede Wiederherstellung und jede Startprüfung eines Containers schlug fehl (Nicht gestartet, Als neuen Gast wiederherstellen eines Containers); VMs waren nicht betroffen. Das Plugin von restow-pve akzeptiert jetzt beide Formen. Der Server bietet restow-pve nach seinem eigenen Update an, Knoten aktualisieren sich im Leerlauf selbst, und das Update lädt die Proxmox-VE-Daemons neu (Knoten und Agenten ziehen das Update nach); auf einem Knoten, der nicht erreicht wurde, führen Sie als root restow-pve update aus. Bis ein Knoten aktualisiert ist, schlagen Container-Wiederherstellungen auf ihm weiter fehl wie bisher. Siehe Wiederherstellen.
• Container-Sicherungsstände, die „Nicht gestartet“ oder eine fehlgeschlagene Restore-Prüfung zeigen, von vor dem Update des Knotens, brauchen einen neuen Lauf: Wählen Sie Jetzt Start prüfen oder Jetzt prüfen, sobald der Knoten das neue restow-pve betreibt (Startprüfungen, Restore-Prüfungen).
• Eine neue Sicherungskette eines Containers wird nicht mehr als Ransomware-Angriff markiert. Die erste Sicherung der neuen Kette eines Containers (sein Repository fehlte oder wurde zurückgesetzt) wurde an der alten Kette gemessen und als verdächtig markiert, weil in einem leeren Repository jede Datei neu ist. Die Baseline beginnt jetzt mit der neuesten Kette, und diese Sicherung heißt Erste Sicherung, nicht Inkrementell. Ein Sicherungsstand, der vor dem Update so markiert wurde, bleibt markiert: Markieren Sie ihn als Fehlalarm (Ransomware-Erkennung).
• Entfernte Rechner behalten ihre Sicherungen durchsuchbar. Bis ihre Sicherungen gelöscht sind, bietet die Seite eines aus Restow entfernten Rechners deren Wiederherstellung an, und die Sicherungsstände, das Durchsuchen, der ZIP-Download und das Repository-Passwort funktionieren für sie weiter. Die Liste der entfernten Rechner im Inventar verlinkt Dateien wiederherstellen. Das Wiederherstellen auf den Rechner und jede andere Aktion bleiben abgelehnt. Siehe Deinstallation und erneute Anmeldung.
• Die Restore-Prüfung sagt, dass sie eingereiht ist. Nach Jetzt prüfen bei einer VM oder einem Container sagt die Zeile Prüfung eingereiht unter der letzten Prüfung und die Seite des Gasts über dem früheren Ergebnis, bis das neue Ergebnis da ist; beide aktualisieren sich in der Zwischenzeit alle paar Sekunden.
• Fehlertexte öffnen sich in einer Karte. Ein Fehlertext hinter einem Badge oder einer abgeschnittenen Zeile (die Startprüfung, die Restore-Prüfung einer VM oder eines Containers auf ihrer Seite und in der Tabelle der Wiederherstellbarkeit) öffnet sich bei Hover oder Tastaturfokus in einer Karte mit dem ganzen Text, den Sie markieren und mit einer Schaltfläche Kopieren kopieren können, statt in einem Browser-Tooltip. Eine Startprüfung, die nicht gestartet ist, zeigt die Meldung des Knotens unter ihrem Badge.
• Keine Migration rückgängig zu machen. An der Datenbank hat sich nichts geändert, der Weg zurück ist also der erste Fall unter Von Hand zurücksetzen; die Release Notes nennen keinen Rollback-Test.
• Bekannte Probleme in 0.4.6:
  • Die Korrektur der Container-Wiederherstellung wurde mit den Perl-Tests des Proxmox-VE-Plugins getestet (die Container-Wiederherstellung mit und ohne Storage-ID), vor dem Tag nicht gegen einen echten Proxmox-VE-Knoten.
  • Die bekannten Probleme bis 0.4.5 gelten weiterhin, außer dem zu entfernten Rechnern (siehe unten): Seit 0.4.6 lassen sich die Sicherungen eines entfernten Rechners durchsuchen und herunterladen.

Update auf 0.4.5

0.4.5 ist ein neues Image mit drei Datenbankmigrationen (0063 bis 0065). Sie fügen Spalten, einen Index und einen Enum-Wert hinzu und schreiben keine Tabelle um, laufen also in Sekunden, egal wie groß die Installation ist. Es bringt keine neue Pflicht-Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Der Vertrag der Integrations-API wechselt additiv auf 1.6.0 (siehe unten). Was Sie wissen sollten:

• Die Migrationen, in dieser Reihenfolge. Sie laufen, wenn die api startet:

  Migration	Was sie tut
  0063_license_update_terms	Drei nullable Spalten an der Tabelle license: series des Schlüssels, sein updates_until und die ID seines Signaturschlüssels.
  0064_endpoint_removal	Der Entfernungszustand eines Rechners an endpoints (drei nullable Spalten und ein partieller Index über die fälligen Entfernungen).
  0065_group_mailboxes	Die Art geschütztes Objekt group (nur ein Enum-Wert).

• Installierte Lizenzschlüssel funktionieren unverändert weiter. Jeder Schlüssel, der vor 0.4.5 ausgestellt wurde, ist eine Beta-Lizenz und deckt jedes 0.x- und 1.x-Release ab. Von jetzt an hält aber ein Release, das Sie von Hand starten und das der installierte Business- oder Service-Provider-Schlüssel nicht abdeckt, vor den Datenbankmigrationen an und sagt das in seinem Log; RESTOW_RUN_AS_COMMUNITY=1 startet es stattdessen als Community. Es muss nichts zurückgespielt werden, um zurückzugehen. Siehe Lizenz und Editionen und Releases, die Ihr Schlüssel nicht abdeckt.

• Schlüssel mit den neuen optionalen Mitgliedern (series, updates_until, kid) lassen sich nur ab 0.4.5 prüfen. Ein Schlüssel mit ihnen, der auf einer Installation von vor 0.4.5 installiert wird, wird als invalid_payload abgelehnt: Aktualisieren Sie zuerst auf 0.4.5, mit dem Schlüssel, den Sie haben.

• Microsoft-365-Gruppen sind Opt-in. Nach dem Update wird keine Gruppe gesichert, bis die Schutzregeln Alle Microsoft-365-Gruppen schützen einschalten oder einzelne Gruppen in die Liste der geschützten Objekte aufgenommen werden. Die erste Verzeichnissynchronisierung nach dem Update liest die Gruppen jeder Microsoft-365-Quelle einmal vollständig. Keine neue Microsoft-Berechtigung und keine neue Administratorzustimmung ist nötig: Group.Read.All und Calendars.ReadWrite waren schon immer Pflicht. Siehe Quellen verbinden.

• Rechner lassen sich aus Restow entfernen. Ein gesperrter Rechner bekommt Aus Restow entfernen im Abschnitt Sicherung dieses Rechners beenden, mit oder ohne seine Sicherungen. Das Update löscht nichts, und Deinstallieren oder Sperren löschen weiterhin nichts. Ein Rechner, der sich länger als eine einstellbare Zahl von Tagen (standardmäßig 30) nicht gemeldet hat, schlägt jetzt vor, ihn zu sperren, und eine Deinstallation, die auf einen ausgeschalteten Rechner wartet, bietet Jetzt sperren an. Siehe Deinstallation und erneute Anmeldung.

• Beide Joblisten sehen anders aus. Jetzt ausführen heißt Jetzt starten, und jede Zeile von Server & Clients → Jobs und Mail & SaaS → Jobs hat Jetzt starten, das zu Stoppen wird, solange die Sicherungen des Jobs laufen oder warten. Ein Klick auf eine Zeile öffnet einen Detailbereich wie den von VMs & Container. Inventar und die Joblisten behalten ein festes Layout, mit einem kompakten Badge Zustand je Zeile. Nichts geht verloren: Dieselben Aktionen sind da. Siehe Backup-Jobs.

• Ein Repository auf der Systemplatte des Servers wird gemeldet. Die Seite Repositories, die Zeile „Backups landen in“ der Job-Editoren und die Speicherkachel des Dashboards warnen, wenn ein Verzeichnis-Repository auf der Platte unter Betriebssystem, Docker und Datenbank liegt, und die API überwacht diese Platte jetzt auch auf knappen Speicherplatz. Nichts wird blockiert (Wo Backups landen).

• Der Einrichtungsassistent ist beim Entra-Tenant strenger. Für Graph-Mail nimmt er nur eine Tenant-ID (eine GUID) oder eine verifizierte Domain an, wie es die Einstellungen schon taten; alles andere wird mit 422 abgelehnt.

• Vertrag der Integrations-API 1.6.0 (additiv): ObjectKind enthält group, der Status meldet lastSuccess.groups und version.releasedAt. Ein Client, der Objektarten vollständig abfragt, sollte den neuen Wert akzeptieren (Integrations-API).

• Neue optionale Einstellungen. Keine für eine normale Installation außer RESTOW_RUN_AS_COMMUNITY (standardmäßig leer; siehe Umgebungsvariablen). RESTOW_RELEASED_AT wird wie RESTOW_VERSION in das Image geschrieben; setzen Sie sie nicht. Die öffentliche Demo hat eigene Einstellungen.

• Zurück auf 0.4.4 wurde nicht getestet. Sichern Sie vor dem Update die Datenbank und spielen Sie sie zurück, um zurückzugehen (Von Hand zurücksetzen).

• Bekannte Probleme in 0.4.5:

  • Gruppenkalender und Unterhaltungen wurden gegen eine simulierte Graph-API getestet, nie gegen einen echten Microsoft-365-Tenant; welche Kalender-Lesezugriffe Graph einer App auf einer Gruppe erlaubt, kann je Tenant verschieden sein (die Sicherung weicht auf calendarView aus und meldet, was sie nicht lesen konnte).
  • Aus Restow entfernte Rechner ließen sich in der Oberfläche nicht wiederherstellen, solange ihre Sicherungen bis zum Ablauf behalten wurden. Ab 0.4.6 behoben.
  • IMAP-Quellen mit OAuth2 lassen sich in API und Oberfläche noch immer nicht anlegen.
  • Die bekannten Probleme bis 0.4.4 gelten weiterhin.

Update auf 0.4.4

0.4.4 ist ein neues Image mit vier Datenbankmigrationen (0059 bis 0062). Es bringt keine neue Pflicht-Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Die Release-Datei hat sich seit 0.4.3 nur in den Beispiel-Image-Tags in den Meldungen von RESTOW_IMAGE und RESTOW_WEB_IMAGE geändert, es gibt also nichts zu ersetzen (siehe die Release-Stack-Referenz). Aus der API wird nichts entfernt: Der Vertrag der Integrations-API bleibt bei 1.5.0 (siehe unten). Was Sie wissen sollten:

• Die Migrationen, in dieser Reihenfolge. Sie laufen, wenn die api startet:

  Migration	Was sie tut
  0059_archive_capture_enum	Fügt dem Archiv den Erfassungsweg smtp_forward (eine Kopie, die ein Mailanbieter weiterleitet) hinzu.
  0060_archive_capture	Die Tabellen der Archiv-Erfassung (ein Strom je archiviertem Postfach und Weg, von Graph angekündigte und noch nicht geholte Mail, Graph-Abonnements, die Archivadressen von IMAP-Konten, weitere Erfassungen einer archivierten Mail), neue Spalten an archive_items und die Erfassungswege eines Mail-Jobs (backup_jobs.archive_capture) und fünf Indizes auf archive_items.
  0061_explorer_parent_index	Zwei Indizes auf manifest_versions für den Restore-Explorer, der die Ordner eines großen Postfachs oder OneDrives jetzt in Millisekunden listet.
  0062_archive_capture_existing	Eine Datenmigration: die Erfassungswege der Mail-Jobs, die schon archivieren (siehe den nächsten Punkt).

• Planen Sie das Update einer großen Installation. Die Indizes werden innerhalb der Migration gebaut, wo Schreibzugriffe auf die Tabelle warten: Rechnen Sie mit etwa einer Minute je zehn Millionen Zeilen auf SSD. 0060 baut fünf Indizes auf archive_items (eine Zeile je archivierter Mail; drei davon lesen jede Zeile, die zwei partiellen beginnen leer). 0061 baut zwei auf manifest_versions, meist der größten Tabelle einer Installation (eine Zeile je Mail, Datei oder Termin, und je Änderung davon); während dieses Baus warten Sicherungen von Microsoft 365 damit, ihren Sicherungsstand festzuhalten. Zählen Sie beide vorher und aktualisieren Sie außerhalb des Backup-Fensters, wenn sie zig Millionen Zeilen enthalten. Eine schnelle Schätzung, die die Tabellen nicht liest (Row Level Security gilt dafür nicht):

  docker compose exec -T postgres psql -U restow -d restow -c "SELECT relname, reltuples::bigint AS approx_rows FROM pg_class WHERE relname IN ('archive_items', 'manifest_versions');"

• Es startet nichts von selbst. Mail-Jobs, die archivieren, tun nach dem Update genau das, was sie vorher taten. Die Migration 0062 gibt jedem von ihnen nur Exchange-Journaling für Microsoft-365-Postfächer und noch keinen Erfassungsweg für IMAP- und Google-Workspace-Konten (markiert als wartet auf eine Wahl), sodass keine Erfassung aus einem Postfach und keine Übernahme vorhandener Mail beginnt. Sie schalten Graph oder IMAP-Archivierung je Job ein, wenn Sie es wollen:

  • Mit einer Lizenz Business oder Service Provider zeigt die Seite Archiv einen Hinweis, den Sie ausblenden können, Neu: Erfassung über Microsoft Graph bzw. IMAP verfügbar, mit den Jobs, in denen Graph aus ist oder noch kein Weg gewählt ist, jeweils mit Job öffnen. Der Erfassungsstatus listet dieselben Jobs unter Wartet auf einen Erfassungsweg.
  • Im Job-Editor sagt die Karte der IMAP-Konten, dass noch kein Erfassungsweg gewählt ist. Wählen Sie einen, startet er mit einer einmaligen Übernahme der Mail, die schon in den Postfächern liegt, markiert als nachträglich erfasst. Änderungen, die die Wege nicht berühren (Name, Zeitplan), lassen sich wie bisher speichern.
  • Jobs, die nach dem Update angelegt werden, und ein Job, der das Archivieren einschaltet, starten mit den Vorgaben: Graph für Microsoft 365, IMAP-Archivierung für IMAP und Google Workspace, jeweils mit dieser Übernahme. Siehe So gelangen E-Mails ins Archiv.
  • Die Community-Version lässt den Erfassungsdienst ruhen; die Wege sind gesperrt und nennen die Edition.

• Die Erfassung aus dem Postfach braucht die Fähigkeit archive.mailboxCapture, die der Edition der Lizenz folgt: Jede Lizenz Business und Service Provider enthält sie ohne neuen Schlüssel.

• Die Graph-Erfassung wird nur dann über neue Mail benachrichtigt, wenn Microsoft die Installation erreichen kann. Die öffentliche URL muss https:// auf Port 443 und von Microsoft erreichbar sein, und ein Reverse-Proxy von Ihnen muss /api/v1/hooks/graph/ durchreichen (höchstens 1 MiB je Anfrage). Sonst wird jedes Postfach alle 15 Minuten geprüft (ARCHIVE_GRAPH_POLL_MINUTES), und die Archiv-Seite nennt den Grund. Keine neue Microsoft-Berechtigung und kein neuer Admin-Consent sind nötig. Siehe Quellen verbinden und Netzwerk und Ports.

• Die IMAP-Archivierung hält je Konto eine Verbindung offen (IDLE), wo der Server es anbietet; ein Anbieter mit knappem Verbindungslimit braucht deshalb womöglich die Quelle auf Nur in Abständen prüfen (archiveIdle: "off"). Siehe IMAP-Archivierung und Google-Workspace-Konten.

• Neue optionale Einstellungen. Keine ist Pflicht; setzen Sie sie in .env, die api und worker lesen. Die env.example des Release-Stacks führt sie nicht auf (die .env.example des Repositorys schon): JOURNAL_RATE_PER_IP (jetzt 600 Verbindungen pro Minute je Absenderadresse, vorher fest 60) und JOURNAL_RATE_PER_ADDRESS (300 Zustellungen pro Minute je Archivadresse), und für die Erfassung ARCHIVE_CAPTURE_CONCURRENCY (16), ARCHIVE_CAPTURE_TENANT_CONCURRENCY (4), ARCHIVE_BACKFILL_CONCURRENCY (4), ARCHIVE_GRAPH_CATCHUP_MINUTES (360), ARCHIVE_GRAPH_POLL_MINUTES (15), ARCHIVE_IMAP_IDLE_MAX (300), ARCHIVE_IMAP_POLL_MINUTES (5) und ARCHIVE_IMAP_LOGIN_POLL_MINUTES (10). Siehe Umgebungsvariablen.

• Was sich anders verhält. Das Anhalten eines Mail-Jobs hält nur seine Sicherungen nach Zeitplan an; die Archivierung läuft weiter, und die Rückfrage beim Anhalten sagt das. Das Ausschalten der Archivierung oder eines Erfassungswegs im Editor fragt vorher nach. Der Journal-Empfänger liefert eine SMTP-Transaktion in das Archiv genau eines Mandanten (ein Empfänger eines zweiten Mandanten erhält 452), und Mail an die Journal-Adresse, die kein Journal-Report ist, wird als weitergeleitete Kopie archiviert statt als unvollständiger Report. Die Archivsuche blendet Erfassungen aus, die ein stärkerer Weg ersetzt hat, es sei denn, Sie verlangen sie, und der Export der aktuellen Suche folgt ihr. Das Öffnen des Job-Editors eines Jobs mit nur IMAP-Konten legt die Journal-Adresse des Mandanten nicht mehr an.

• Der Restore-Explorer öffnet große Postfächer und OneDrives in Millisekunden. Die Ordnerlisten kommen aus den neuen Indizes, und eine Mail-Vorschau oder ein Anhang-Download liest genau seine Bytes aus dem Speicher. Siehe Backup und Restore. Sicherungsstände von 0.3.4 und früher, die der Worker noch nicht umgewandelt hat, werden wie bisher aufgelistet.

• Integrations-API. Der Vertrag 1.5.0 bleibt unverändert: Archivstatus und Nachweisbericht zählen weitergeleitete Kopien in ihren Gesamtzahlen, führen sie aber noch nicht als eigenen Weg auf. Die Session-API bekommt archiveCapture an Mail-Jobs, captureKind an ihren Mitgliedern, mailSourceKinds in den Job-Vorgaben und includeSuperseded an der Archivsuche. Siehe Integrations-API.

• Neue Warnungen. Das Ereignis Archiv-Abgleich fehlgeschlagen (archive.failed) meldet auch ein Postfach, dessen Erfassung seit mehr als einer Stunde fehlschlägt, weitergeleitete Kopien, die seit 24 Stunden ausbleiben, und eine Journal-Adresse ohne Reports seit 24 Stunden (Benachrichtigungen und Berichte).

• Zurück auf 0.4.3 wurde nicht getestet. Sichern Sie vor dem Update die Datenbank und spielen Sie sie zurück, um zurückzugehen (Von Hand zurücksetzen).

• Bekannte Probleme in 0.4.4:

  • Die Erfassungswege wurden gegen Simulationen getestet: die Graph-Erfassung gegen eine simulierte Graph-API, die IMAP-Archivierung gegen einen simulierten IMAP-Server und den Dovecot des Release-Smokes, die Weiterleitung gegen den Empfänger selbst. Keiner lief gegen einen echten Microsoft-365- oder Google-Workspace-Mandanten, Postfix, mailcow oder Hoster.
  • Holds in einem Microsoft-365-Mandanten werden nicht erkannt, weil Graph v1.0 sie nicht lesen kann; eine Administration bestätigt sie je Quelle. Von den Wiederherstellbaren Elementen wird nur der Ordner der Löschungen gelesen, Mail, die endgültig gelöscht wurde, bevor Restow sie geholt hat, kann also fehlen, und Graph kann Mail über etwa 150 MB nicht exportieren (sie wird protokolliert, nicht archiviert).
  • Der Journal-Empfänger prüft den Absender nicht (SPF), und seine Grenzen zählen je api-Prozess.
  • IMAP-Quellen mit OAuth2 lassen sich in API und Oberfläche noch immer nicht anlegen, ein Google-Workspace-Konto wird deshalb nur an seinem Host oder seiner Ordnerliste erkannt.
  • Archivstatus und Nachweisbericht der Integrations-API führen weitergeleitete Kopien nicht als eigenen Weg auf.
  • Die bekannten Probleme bis 0.4.3 gelten weiterhin (siehe unten und die Roadmap).

Update auf 0.4.3

0.4.3 ist ein neues Image ohne Datenbankmigration. Es bringt keine neue Pflicht-Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Aus der API wird nichts entfernt (der Vertrag 1.5.0 bleibt; der lastVerify.state eines Gasts kann jetzt yellow sein, und ein Knoten trägt offeredVersion und outdated, beides additiv). Was Sie wissen sollten:

• Proxmox-VE-Knoten sollten restow-pve 0.4.3 laufen lassen. Es wartet bei einer Container-Sicherung auf die Repository-Sperre des Servers und startet die Proxmox-VE-Dienste (pvedaemon, pveproxy, pvestatd, pvescheduler) neu, nachdem es sich selbst aktualisiert hat. Knoten, die restow-pve ab 0.4.2 laufen lassen, installieren es mit dem Schritt nach dem Server-Update oder mit Knoten und Agenten jetzt aktualisieren (Knoten und Agenten ziehen das Update nach).

• Knoten und Agenten jetzt aktualisieren ist neu im Reiter Updates (seit 0.4.3). Es startet den Schritt, in dem Knoten und Agenten dem Server nachziehen, wenn kein Update in ihn geführt hat: Der Server wurde von Hand aktualisiert, oder die Antwort auf ein angekündigtes Update ging verloren. Knoten und Agenten, die zurückliegen, zeigen auf der Karte Update verfügbar, und ein Administrator mit allen Mandanten startet den Schritt von dort.

• Knoten mit restow-pve 0.4.1 brauchen ein Update von Hand. Sie ignorieren „jetzt aktualisieren“ und den Schritt nach dem Server-Update. Sie aktualisieren sich mit ihrer eigenen Prüfung (zwei Minuten nach dem Start des Dienstes, danach alle sechs Stunden) oder sofort von Hand, als root auf dem Knoten, sobald dort keine Sicherung und keine Wiederherstellung läuft:

  /opt/restow-pve/bin/restow-pve update
  systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler

  Ab 0.4.3 startet restow-pve die Dienste nach jedem Update, das es installiert, selbst neu. Ein Knoten, den ein älteres Release aktualisiert hat, tut das einmal von selbst, nachdem das neue Release gestartet ist.

• Restore-Prüfungen, die eine gesperrte Repository fehlschlagen ließ, bleiben vor dem Update rot bis zur nächsten Prüfung des Gasts. Wählen Sie Jetzt prüfen beim Gast oder bei einem Sicherungsstand auf seiner Seite, um sie erneut zu lesen (Restore-Prüfungen). Ab 0.4.3 wird eine Prüfung, die eine Sperre aussperrt, erneut versucht und steht, wenn die Sperre bleibt, als Nicht prüfbar: Repository gesperrt in Gelb da, nie in Rot.

• VMs & Container sieht anders aus. Die Seite hat jetzt drei Reiter (Gäste, Backup-Jobs, Knoten), eine Suche, Filter und einen Detailbereich für einen Gast. Nichts geht verloren: Dieselben Aktionen sind da, und ein Lesezeichen der Seite öffnet den Reiter Gäste (Inventar, Gäste und Sicherungsstände).

• Das falsche „Der Updater läuft nicht“ ist behoben. Das Ankündigen eines Updates konnte es melden, obwohl der Updater es wenige Sekunden später angenommen hatte; das Update lief dann ohne die Pause neuer Läufe und ohne den Schritt für Knoten und Agenten. Siehe Wenn etwas schiefgeht.

• Zurück auf 0.4.2 funktioniert. Es gibt keine Migration rückgängig zu machen, das ältere Image startet also auf derselben Datenbank. Es zeigt einen Sicherungsstand, der nicht geprüft werden konnte, als ungeprüft.

• Bekannte Probleme in 0.4.3:

  • Die neuen Teile wurden nur gegen eine simulierte Proxmox-VE-API und einen simulierten S3-Speicher getestet, nie gegen einen echten Proxmox-VE-Cluster oder S3-Anbieter.
  • Die neu gestaltete Seite VMs & Container wurde mit DOM-Tests getestet, nicht von Hand im Browser mit Tausenden Gästen.
  • Das Heilen einer Dateifreigabe, deren Repository nach einem Speicherwechsel fehlt, ist weiter für ein späteres Release geplant; das eines Containers wird seit 0.4.2 geheilt.
  • Die bekannten Probleme bis 0.4.2 gelten weiter (siehe unten und die Roadmap).

Update auf 0.4.2

0.4.2 ist ein neues Image mit sechs Datenbankmigrationen (0053 bis 0058). Sie fügen nur eine Tabelle, Spalten, Indizes und Enum-Werte hinzu und erweitern eine Prüfung, und sie laufen in Sekunden, egal wie groß die Installation ist. Es bringt keine neue Pflicht-Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Aus der API wird nichts entfernt (der Vertrag 1.5.0 ist additiv). Was Sie wissen sollten:

• Die Migrationen, in dieser Reihenfolge:

  Migration	Was sie hinzufügt
  0053_pve_repository_chains	Die neuen Sicherungsketten eines Containers (pve_guests.repository_chains) und pve_snapshots.unavailable_at.
  0054_pve_runs_042	Die VM des Restow-Servers selbst (pve_guests.restow_server_detected, restow_server_flagged, self_backup_confirmed_at), pve_snapshots.verify_requested_at und die Proxmox-VE-Einstellungen der Installation (settings.pve_settings).
  0055_pack_read_failures	Eine neue, leere Tabelle für Packs, die die Speicherprüfung nicht lesen konnte.
  0056_cancel_and_fleet_update	Abbruchanforderungen und den Zustand cancelled für Aufgaben und Läufe, die angehaltene Warteschlange eines Knotens, „jetzt aktualisieren“ für Knoten und Rechner, die Phase fleet der Pause neuer Läufe und settings.planned_update.
  0057_explorer_people	Einen Index auf den geschützten Objekten einer Person in einem Mandanten, für die Liste der Personen im Restore-Explorer.
  0058_installation_time_zone	settings.time_zone.

• Proxmox-VE-Knoten sollten restow-pve 0.4.2 laufen lassen. Es meldet die VM des Restow-Servers selbst mit dem Inventar, hält seinen Heartbeat aufrecht, solange eine Sicherung läuft (nötig für Sicherung stoppen und für den Fortschritt), und meldet eine Sicherung, die mit „TASK WARNINGS“ endet, nicht mehr als fehlgeschlagen. Das Flottenupdate nach dem Server-Update installiert es auf jedem Knoten, der sich meldet; der Reiter Updates nennt den Befehl für die anderen (Knoten und Agenten ziehen das Update nach).

• Eine laufende Sicherung zu stoppen braucht restow-pve 0.4.2 auf dem Knoten und Agent 0.4.2 auf dem Rechner. Ein älterer Knoten beendet eine abgebrochene Sicherung bei seinem nächsten Upload (der Server lehnt ihn ab), ein älterer Agent führt die Sicherung zu Ende. Beide aktualisieren sich mit diesem Release selbst.

• „Vorhandene Backups dort belassen, wo sie sind“ wird abgelehnt, solange Container oder Dateifreigaben restic-Repositories haben (storage-switch-blocked-by-repositories), und das Befördern einer Kopie zum primären Repository ebenso. Ändern Sie das primäre Repository mit Vorhandene Backups verschieben (empfohlen), das die restic-Repositories jetzt mitnimmt. Siehe Das primäre Repository ersetzen.

• Berichte der Speicherprüfung von vor 0.4.2 werden neu gelesen. Packs, die ein früherer Bericht als nicht lesbar aufführte, gelten jetzt als vorübergehend nicht lesbar, nicht als beschädigt, und die nächste Speicherprüfung liest sie zuerst; eine Vollprüfung ist nicht nötig. Ein Objekt, das nur wegen eines solchen Packs Nicht wiederherstellbar war, steht bis zu dieser Prüfung auf Achtung (Speicherintegrität).

• Integrations-API, Vertrag 1.5.0 (additiv): storageIntegrity.state kann unreadable sein. Ein Client, der die Werte vollständig abfragt, sollte ihn akzeptieren (Integrations-API).

• Noch keine eigene Zeitzone nach dem Update. Eine vorhandene Installation nutzt RESTOW_TIME_ZONE, sonst TZ, sonst Europe/Berlin, bis ein Inhaber unter Installation → Server & Betrieb → Server eine wählt (Die Zeitzone der Installation).

• Zurück auf 0.4.1 funktioniert. Die Migrationen fügen nur eine Tabelle, Spalten, Indizes und Enum-Werte hinzu und erweitern eine Prüfung, 0.4.1 startet also mit ihnen. Läufe und Aufgaben im Zustand cancelled kennt 0.4.1 nicht.

• Bekannte Probleme in 0.4.2:

  • Eine Dateifreigabe, deren Repository nach einem Speicherwechsel fehlt, wird noch nicht so geheilt wie ein Container (mit einer neuen Sicherungskette). Das ist geplant.
  • Die Korrektur für das Wartungs- und Update-Banner, das den oberen Rand fensterhoher Seiten verdeckte, wurde nicht von Hand im Browser geprüft.
  • Die neuen Teile wurden nur gegen eine simulierte Proxmox-VE-API, einen simulierten S3-Speicher und eine simulierte Microsoft-Graph-API getestet, nie gegen einen echten Proxmox-VE-Cluster, einen echten S3-Anbieter oder einen echten Microsoft-365-Mandanten.
  • Die Personenliste des Restore-Explorers gruppiert die geschützten Objekte des Mandanten für jede Seite, die sie ausliefert, in der Datenbank. Das ist bis etwa 10.000 Personen je Mandant unproblematisch und darüber langsamer.
  • Die bekannten Probleme von 0.4.1 und 0.4.0 gelten weiter (siehe unten und die Roadmap).

Update auf 0.4.1

0.4.1 ist ein neues Image mit einer Datenbankmigration, 0052_pve_guest_repository_bytes (zwei Spalten in pve_guests), die in Sekunden läuft. Es bringt keine Umgebungsvariable, und die docker-compose.yml von 0.4.0 bleibt: Es gibt nichts zu ersetzen. Was Sie wissen sollten:

• Der belegte Speicher ändert sich. Repositories → Nutzung, die Kachel Gespeichert des Dashboards, die Statistik und physicalBytes von GET /api/v1/status und GET /api/v1/storage enthalten jetzt die restic-Repositories von Rechnern, Freigaben und Proxmox-VE-Containern, nicht mehr nur den Chunk-Store (die Felder und ihre Typen bleiben). Das Repository eines Containers zählt ab seiner nächsten Sicherung unter Gespeichert, das eines Rechners oder einer Freigabe wie bisher (ab der nächsten Sicherung oder dem nächsten Aufbewahrungslauf); bis dahin zählt es als null.
• Proxmox-VE-Knoten holen sich restow-pve 0.4.1 selbst: Es fragt jetzt zwei Minuten nach seinem Start nach seinem Update, danach alle sechs Stunden, und installiert es, sobald auf dem Knoten keine Sicherung und keine Wiederherstellung läuft.
• Zurück auf 0.4.0 geht mit der neuen Migration: Sie fügt nur zwei Spalten hinzu.
• Die bekannten Probleme von 0.4.0 gelten weiter (siehe unten).

Update auf 0.4.0

0.4.0 ist ein neues Image, siebzehn Datenbankmigrationen (0035 bis 0051) und eine neue docker-compose.yml für Freigaben und das Verschieben der Datenbank. Beim Update hört nichts auf zu funktionieren: Bestehende Compose-Dateien, Webhooks, Benachrichtigungsempfänger, API-Clients und Agenten arbeiten weiter. Gehen Sie in dieser Reihenfolge vor:

1. Aktualisieren Sie wie gewohnt, mit dem optionalen Updater oder mit docker compose pull && docker compose up -d. Die API wendet die Migrationen beim Start an. Mit dem Updater fragt der Installationsdialog jetzt, was mit laufenden Läufen geschehen soll; Standard ist sauber anhalten (Laufende Läufe während eines Updates).
2. Führen Sie das install.sh von 0.4.0 erneut aus, im Installationsverzeichnis (Erneut ausführen). Es ersetzt docker-compose.yml durch die Datei von 0.4.0 (geprüft gegen die signierte SHA256SUMS), behält die bisherige als docker-compose.yml.bak-<Zeitstempel> und lässt die .env unverändert. Ohne das läuft alles andere, aber Läufe für Freigaben können nicht starten (der Mounter meldet runner_network_missing) und Installation → Datenbank kann die Datenbank nicht verschieben. Eine Compose-Datei, die Sie von Hand pflegen, braucht die Änderungen der Release-Datei: das Datenbank-Volume aus der .env, das interne Netzwerk runners an der API sowie RESTOW_MOUNTER_URL, die Runner-Grenzen und das Volume restow-mounter-shared am Worker (siehe die Release-Stack-Referenz).
3. Mounter als Standard. Neue Installationen starten den Mounter (Compose-Profil mounts) jetzt standardmäßig, weil die Sicherung von Freigaben darüber läuft; skriptgesteuerte Installationen, die ihn nicht wollen, übergeben --no-mounter (oder --without-mounter). Führen Sie den Installer erneut auf einer bestehenden Installation aus, behält er deren Wahl. Für Freigaben auf einer bestehenden Installation starten Sie den Mounter, falls er nicht läuft: Netzlaufwerke einschalten in der Weboberfläche (mit dem optionalen Updater) oder docker compose --profile mounts up -d mounter. Der Mounter bindet den Docker-Socket ein, was Root-Zugriff auf den Host bedeutet: Lesen Sie Mounter und NFS-Speicher. Der Docker-Host braucht das Modul cifs für SMB und den NFS-Client für NFS (Freigaben).
4. Proxmox-VE-Knoten: restow-pve 0.4.0 aktualisiert sich selbst (es prüft alle sechs Stunden und aktualisiert im Leerlauf; seit 0.4.1 auch zwei Minuten nach seinem Start), oder führen Sie restow-pve update auf dem Knoten aus. Ältere Helfer arbeiten weiter, aber ohne Fortschritt, ohne das Fünf-Minuten-Wiederholungsfenster und ohne die Liste der aktiven Läufe.
5. Server und Clients: Der Endpoint-Agent 0.4.0 aktualisiert sich selbst, sofern der Mandant Agent-Updates nicht pausiert hat. Ältere Agenten arbeiten weiter, aber ohne Datenordner, Rechnerangaben, das Sicherungsfenster, die Nachhol-Regeln und die Wiederholungszahl einer Richtlinie der Agenten, und sie halten ihre eigenen Zeitpläne während einer Update-Pause nicht an.
6. S3-Endpunkte über einfaches HTTP. Seit 0.4.0 muss ein gespeicherter oder geänderter S3-Endpunkt https:// verwenden, außer zu localhost, 127.0.0.1 und [::1]. Ein Repository oder Standard-Repository, das http:// zu einem anderen Host nutzt (und S3_ENDPOINT in der .env), arbeitet weiter, sodass keine Sicherung stehen bleibt, aber seine Karte, Installation → Standard-Repository und jeder Verbindungstest sagen in Rot, dass es auf HTTPS umziehen sollte, und seinen Speicherort zu ändern verlangt https://. Ein Testaufbau mit einem Objektspeicher im Compose-Netzwerk setzt S3_ALLOW_INSECURE=true in der .env (API und Worker). Siehe Unveränderbare Backups.
7. SharePoint Online. Die App-Registrierung der Sicherung braucht die Anwendungsberechtigung Sites.ReadWrite.All (Sites.Read.All genügt für die Sicherung, nicht für die Wiederherstellung). Fügen Sie sie der App-Registrierung hinzu, dann öffnet die Administration des Kunden den Zustimmungs-Link der Quelle erneut (SharePoint Online, Erste Schritte). Bis dahin laufen Mail und OneDrive weiter, und der Verzeichnisabgleich warnt, dass Sites weder gefunden noch gesichert werden (sites_unavailable).
8. Unveränderbare Backups mit S3 Object Lock brauchen einen Bucket, der mit Object Lock (und Versionierung) angelegt wurde; sie lassen sich einem bestehenden Bucket nicht nachträglich hinzufügen. Nichts wird gesperrt, bis eine Administration es einschaltet. Der Zugriffsschlüssel braucht eigene Berechtigungen: siehe Unveränderbare Backups.
9. Die Ransomware-Erkennung ist nach dem Update an und beurteilt Sicherungen der letzten 72 Stunden. Ihre Aufbewahrungssperre ist ebenfalls an: Ein verdächtiger Sicherungsstand hält die Aufbewahrung seines Objekts an, bis eine Administration ihn klärt. Schwellenwerte und beide Schalter stehen unter Installation → Ransomware-Erkennung (Ransomware-Erkennung).
10. Der Bau aus dem Quellcode braucht Node.js 22.12 oder neuer (engines in package.json; commander 15 verlangt es). Die Docker-Images laufen wie bisher auf node:22-slim, für Docker-Installationen ändert sich also nichts. Siehe Aus dem Quellcode bauen.

Was sich anders verhält (die Breaking Changes der Release-Notes): Benachrichtigungen folgen der Matrix, in der jeder Kanal die Ereignisse behält, die er erhält, und der Webhook-Dialog keine Ereignisauswahl mehr hat; die vier Schalter der Benachrichtigungsempfänger sind durch eine Ereignisliste ersetzt (die Mandanten-API akzeptiert und liefert weiter categories); neue Installationen starten den Mounter; wurde die Datenbank verschoben, verweigert install.sh (Exit-Code 8, nichts geändert) eine docker-compose.yml, die RESTOW_POSTGRES_DATA nicht liest (Datenbank).

Die Migrationen, in dieser Reihenfolge: 0035_file_shares, 0036_backup_job_kinds_share_copy, 0037_backup_job_file_shares, 0038_notification_matrix (sie übersetzt die Empfänger-Schalter und Webhook-Ereignislisten jedes Mandanten und entfernt die vier Schalter-Spalten), 0039_pve_run_progress, 0040_recommended_jobs, 0041_pve_downloads, 0042_job_start_pause (die Update-Pause), 0043_disk_alerts, 0044_pve_boot_tests, 0045_ransomware_detection, 0046_sharepoint_sites, 0047_immutable_backups, 0048_suspicion_retention_hold, 0049_perf_indexes, 0050_agent_policies (ändert die Konfiguration keines Rechners) und 0051_agent_waiting. Sie ändern das Schema und füllen nur die Benachrichtigungsempfänger und Webhooks nach, einige Zeilen je Mandant, und dauern daher auf jeder Installation Sekunden, mit einer Ausnahme. 0049_perf_indexes legt sechs partielle Indizes an (jobs, endpoint_runs, file_share_runs, pve_runs, pve_tasks); jeder Aufbau liest seine Tabelle einmal, während Schreibzugriffe auf sie warten, was auf den meisten Installationen Sekunden und auf großen etwa eine Minute je zehn Millionen Zeilen dauert. 0035 legt die Erweiterung pg_trgm für die Suche in Freigaben an, wenn die Datenbankrolle es darf; ein externes PostgreSQL ohne sie sucht langsamer, mit denselben Ergebnissen. Sie liefen in den Postgres-Testsuites auf einem Schema von 0.3.6; wie lange sie auf einer sehr großen Datenbank dauern, wurde nicht gemessen.

Neue optionale Umgebungsvariablen: RESTOW_POSTGRES_DATA_TYPE und RESTOW_POSTGRES_DATA (wo die Datenbank liegt; leer bedeutet das Volume pgdata; der Updater schreibt sie, wenn er die Datenbank verschiebt), RESTOW_MOUNTER_MAX_RUNNERS (harte Obergrenze der Runner für Freigaben, Standard 8) und RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB (Standard 16384). Keine neue Pflichtvariable. Siehe Umgebungsvariablen.

Ausfallzeit und Zurücksetzen. Die Container starten neu und die Migrationen laufen, wie bei 0.3.6. Die Migrationen lassen sich nicht rückgängig machen: Gehen Sie nur mit dem vor dem Update gezogenen Datenbank-Dump auf 0.3.6 zurück (Von Hand zurücksetzen). Behalten Sie nach einem Verschieben der Datenbank eine Compose-Datei, die RESTOW_POSTGRES_DATA liest: Die Datei von 0.3.6 tut das nicht, und PostgreSQL weigert sich dann, auf der alten Kopie zu starten.

Update auf 0.3.6

0.3.6 ist ein neues Image mit einer Datenbankmigration (0034, eine kleine Tabelle für Neustart-Hinweise), die bei jeder Datenbankgröße nur Sekunden dauert. Es bringt keine neue Pflichtvariable. Alles Weitere steht in den Release-Notes von 0.3.6. Vier Dinge sollten Sie vor dem Start wissen:

• Die Schaltfläche „Jetzt neu starten“ braucht den Updater von 0.3.6. Ein Updater aus der Zeit vor 0.3.6 zeigt stattdessen den Befehl, den Sie auf dem Server ausführen, bis er das Image 0.3.6 ausführt. Nach einem Update über die Weboberfläche, das die Signaturprüfung bestanden hat, zieht der Updater selbst auf das neue Release um (Der Updater aktualisiert sich selbst); aktualisieren Sie von Hand, oder zieht er nicht um, setzen Sie RESTOW_UPDATER_IMAGE auf das Image aus RESTOW_IMAGE und führen Sie docker compose --profile updater up -d updater aus. Siehe Neustart erforderlich.
• Installationen, deren docker-compose.yml keinen Dienst mounter hat: Führen Sie das Installationsskript erneut aus. Eine Installation behält die Compose-Datei, mit der sie installiert wurde, und ein Update ändert nur die .env; eine Installation aus der Zeit vor der 0.3er-Linie (angelegt vor 0.3.1; 0.3.0 wurde nie veröffentlicht) hat deshalb keinen Mounter. Führen Sie das Installationsskript von 0.3.6 auf ihr erneut aus: Es ersetzt docker-compose.yml durch die geprüfte Datei des in der .env genannten Releases, behält die alte als docker-compose.yml.bak-<Zeit> und lässt die .env unverändert. Siehe Erneut ausführen und no such service: mounter.
• Eine Umwandlung des 0.3.5-Index, die noch läuft, braucht nichts. Die Umwandlung läuft wie bisher weiter, und sobald sie fertig ist, gibt die api den Platz des alten Backup-Index innerhalb von etwa 15 Minuten von selbst zurück. Der Neustart der api, den 0.3.5 verlangte, ist nicht mehr nötig. Wie lange die Umwandlung dauert, hängt von der Datenbank ab; die Zahlen im Abschnitt zu 0.3.5 stammen aus Tests, und die ersten Minuten sind langsamer.
• Zurück auf 0.3.5 geht nur mit dem Datenbank-Dump, der vor dem Update gezogen wurde. Die Migration lässt sich nicht rückgängig machen; die alte Version darf daher nicht auf der migrierten Datenbank gestartet werden. Siehe Von Hand zurücksetzen.

Update auf 0.3.5

0.3.5 ist ein neues Image mit einer Datenbankmigration (0033), die nur eine Tabelle anlegt und zwei Indizes löscht und bei jeder Datenbankgröße Sekunden dauert. Es bringt keine neue Pflichtvariable; DATABASE_AUTH_URL ist optional (siehe Datenbank). Alles Weitere steht in den Release-Notes von 0.3.5. Vier Dinge sollten Sie vor dem Start wissen:

• Schaffen Sie zuerst freien Festplattenplatz. 0.3.5 speichert den Backup-Index (welche Elemente jedes Backup enthält) als Elementversionen statt als vollständige Kopie je Backup. Nach dem Start wandelt der Worker den vorhandenen Index im Hintergrund um und schreibt den neuen Index, bevor der alte freigegeben wird. Der Updater schreibt außerdem vor dem Update einen Datenbank-Dump. Auf einer fast vollen Festplatte schaffen Sie zuerst Platz.

• Compose-Dateien, die Sie von Hand pflegen, brauchen stop_grace_period: 60s beim Dienst worker. Die Zeile gibt laufenden Jobs 60 Sekunden, um einen Kontrollpunkt zu speichern, wenn der Worker stoppt. Ohne sie stoppt Docker den Worker wie bisher nach 10 Sekunden. Übernehmen Sie die Zeile aus der docker-compose.yml des Releases, siehe den worker in der Release-Stack-Referenz. Ab 0.3.6 kann das Installationsskript diese Datei einer Installation für Sie aktualisieren (Erneut ausführen).

• Die Umwandlung des Index läuft im Hintergrund. Der Worker wandelt die Backups nacheinander um (im Test etwa 19.000 Index-Zeilen pro Sekunde, also grob 15 Minuten für 14 Millionen Zeilen; für eine Produktionsdatenbank mit 25 GB ist das eine Schätzung, keine Messung). Backups, Durchsuchen und Restores laufen währenddessen weiter. Verfolgen Sie sie im Log des Workers:

  docker compose logs worker | grep "manifest index conversion"

  Sagt es manifest index conversion finished, ist der alte Index leer, aber das Dateisystem hat seinen Platz noch nicht zurück. Ab 0.3.6 erledigt das die api innerhalb von etwa 15 Minuten von selbst, ein Neustart ist nicht nötig: Sie prüft alle 15 Minuten die Größe der alten Tabelle (das liest keine Zeile), leert sie, sobald nichts mehr darin ist, und hört dann auf zu prüfen. Ihr Log sagt the old manifest table was emptied and its disk space given back. Sie tut das als Datenbankbesitzer (DATABASE_MIGRATION_URL, die Verbindung ihres Migrationsschritts), mit einer kurzen Verbindung je Versuch; keine andere Rolle bekommt ein neues Recht. Auf 0.3.5 selbst starten Sie die api stattdessen einmal neu, mit demselben Ergebnis:

  docker compose restart api

• Zurück auf 0.3.4 geht nur mit dem Datenbank-Dump, der vor dem Update gezogen wurde. Die Migration lässt sich nicht rückgängig machen; die alte Version darf daher nicht auf der migrierten Datenbank gestartet werden. Siehe Von Hand zurücksetzen.

Schritt für Schritt: eine Installation mit install.sh

Das Installationsskript legt den Stack in /opt/restow ab, root gehört er, und es aktualisiert ihn nie (Erneut ausführen). Ab 0.3.6 bringt es beim erneuten Ausführen docker-compose.yml auf den Stand des in der .env genannten Releases, ändert aber weiterhin weder die Images noch die .env. So aktualisieren Sie eine solche Installation von Hand, von Version 0.1.0 auf eine neuere X.Y.Z (ohne das führende v). Bei einer Installation von Hand führen Sie dieselben Befehle im Verzeichnis ihrer docker-compose.yml aus. Alle Befehle für den täglichen Betrieb stehen in der Befehlsübersicht.

1. Lesen Sie die Release-Notes jeder Version zwischen Ihrer und X.Y.Z auf GitHub, besonders Breaking Changes und Update-Aufwand. Nennen sie manuelle Schritte, folgen Sie diesen statt dem kurzen Weg unten.

2. Wechseln Sie zum Stack und sichern Sie die Datenbank (von root geschrieben, nur für root lesbar):

   cd /opt/restow
   sudo sh -c 'umask 077; docker compose exec -T postgres pg_dump -U restow -Fc restow > restow-$(date +%F).dump'

3. Optional: Prüfen Sie beide neuen Images, bevor Sie sie starten. Die Identität ist der Release-Workflow genau am Tag der neuen Version, wie unter Ein Release verifizieren. Für den vollständigen Build:

   NEW=X.Y.Z
   for image in restow restow-web; do
     cosign verify "ghcr.io/restow-backup/$image:$NEW" \
       --certificate-identity "https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v$NEW" \
       --certificate-oidc-issuer https://token.actions.githubusercontent.com
   done

   Für den Community-Build nehmen Sie restow-community restow-web-community in die Schleife.

4. Tragen Sie die neue Version in .env ein. Legen Sie zuerst eine Kopie der aktuellen Datei an (cp -p behält ihren Modus 0600), dann ändern Sie die beiden Image-Zeilen, entweder mit diesem Einzeiler, der nur RESTOW_IMAGE und RESTOW_WEB_IMAGE (beider Builds) ändert und RESTOW_UPDATER_IMAGE in Ruhe lässt:

   NEW=X.Y.Z
   sudo cp -p .env .env.before-update
   sudo sed -i -E 's#^(RESTOW_(WEB_)?IMAGE=ghcr\.io/restow-backup/restow(-web)?(-community)?):.*$#\1:'"$NEW"'#' .env
   sudo grep -E '^RESTOW_(WEB_)?IMAGE=' .env

   oder von Hand in einem Editor (zum Beispiel sudo nano .env), sodass die beiden Zeilen so lauten (vollständiger Build):

   RESTOW_IMAGE=ghcr.io/restow-backup/restow:X.Y.Z
   RESTOW_WEB_IMAGE=ghcr.io/restow-backup/restow-web:X.Y.Z

5. Laden und starten, dann die Migrationen und den Start verfolgen (Strg+C beendet die Log-Anzeige, nicht den Stack):

   sudo docker compose pull
   sudo docker compose up -d
   sudo docker compose logs -f api

   Das Log zeigt restow: applying database migrations, dann restow: starting role 'api'. Prüfen Sie das Ergebnis wie unter Nach dem Update.

Zurück. Kommt die neue Version nicht hoch und hat das Release keine Datenbankmigrationen (das sagen seine Notes), setzen Sie die alten Image-Zeilen zurück und starten erneut:

cd /opt/restow
sudo cp -p .env.before-update .env
sudo docker compose up -d

Sind Migrationen gelaufen, darf die alte Version nicht auf der migrierten Datenbank starten: Spielen Sie zuerst die Sicherung aus Schritt 2 zurück, wie unter Von Hand zurücksetzen beschrieben.

Installation → Updates

Der Reiter ist für alle Provider-Administratoren sichtbar. Er zeigt die laufende Version, den Release-Kanal, die neueste Version mit Tag und Veröffentlichungsdatum, einen Link zu den Release-Notes (und die Notes selbst, sicher dargestellt und eingeklappt), den Stand der letzten Prüfung und ob ein Update verfügbar ist. Ab 0.3.6 steht ein verfügbares Update neben der laufenden Version, in derselben Größe und hervorgehoben, mit der Beschriftung verfügbar; vorher stand es nur in der Statuszeile. Seit 0.4.2 sagt es auch die Seitenleiste (Der Hinweis in der Seitenleiste). Braucht ein Dienst einen Neustart, beginnt der Reiter mit einer Karte Neustart erforderlich.

Wer ändern darf. Einstellungen ändern, Jetzt prüfen, ein Update ankündigen, abbrechen und ausblenden erfordern die Rolle Inhaber im Provider-Team. Der vom Einrichtungsassistenten angelegte Administrator ist Inhaber. Alle anderen sehen nur den Status. Siehe Team und Rollen. Das Ändern der Update-Quelle oder des Zugriffstokens und das Ankündigen eines Updates erfordern zusätzlich eine frische Anmeldung (siehe Bestätigen, dass Sie es sind).

Die Prüfung einschalten

Die Prüfung ist standardmäßig aus. Schaltet ein Inhaber sie ein (Einmal täglich auf Updates prüfen), liest Restow einmal täglich die Release-Liste der Update-Quelle und jedes Mal, wenn Sie Jetzt prüfen drücken. Nach einer fehlgeschlagenen Prüfung versucht es frühestens nach einer Stunde erneut.

Was gelesen wird. Nur die Release-Liste der Quelle. Keine Anfrage trägt Daten über Ihre Installation, und das Ergebnis wird zwischengespeichert. Wie bei jeder Web-Anfrage sieht die Quelle die Adresse, von der Ihr Server sich verbindet. Schlägt eine Prüfung fehl, nennt der Reiter den Grund und zeigt weiter das letzte gute Ergebnis:

Grund	Bedeutung
Rate-Limit	Die Quelle hat weitere Anfragen vorerst abgelehnt. Der Reiter zeigt, wann es endet.
Token abgelehnt	Der Zugriffstoken ist falsch, abgelaufen oder widerrufen.
Nicht gefunden	Das Repository existiert nicht, oder es ist privat und es ist kein Token gespeichert.
Zugriff verweigert	Der Token darf die Releases dieses Repositorys nicht lesen.
Quellenfehler, keine Antwort	Die Quelle hat mit einem Serverfehler geantwortet, nicht rechtzeitig reagiert oder war nicht erreichbar.
Keine Release-Liste	Die Adresse hat geantwortet, aber nicht mit Releases.
Kein Release veröffentlicht	Die Quelle hat für diesen Kanal noch kein Release.
Weiterleitung abgelehnt	Die Quelle hat auf einen anderen Host weitergeleitet. Restow folgt dem nicht, tragen Sie stattdessen die endgültige Adresse des Repositorys ein.

Quelle, Kanal und Token

• Quelle. Standard sind die öffentlichen Releases von https://github.com/restow-backup/restow. Sie können auf ein eigenes Repository verweisen: ein GitHub-Repository oder ein Forgejo- oder Gitea-Repository (deren Releases-API ist kompatibel), zum Beispiel https://git.example.com/acme/restow. Akzeptiert werden nur https-Adressen ohne Zugangsdaten in der URL, weil ein Zugriffstoken mit der Anfrage reist. Die Prüfung verbindet sich nur mit öffentlichen Adressen: Jede aufgelöste Adresse wird beim Verbindungsaufbau geprüft, und eine Adresse in einem Loopback-, privaten oder Link-Local-Netz (zum Beispiel ein Forgejo in Ihrem LAN oder ein Hostname, der dorthin auflöst) wird abgelehnt, es sei denn, der Betreiber nennt ihren Host in RESTOW_UPDATER_SOURCE_HOSTS (siehe Zwei Modi). Das Speichern einer solchen Quelle ohne diesen Eintrag wird mit urn:restow:problem:invalid-update-source abgelehnt. Die Antwort wird als Stream gelesen und ab 8 MiB verworfen.
• Kanal. Stabil bietet nur finale Releases an. Beta bietet zusätzlich Vorabversionen wie 0.3.0-rc.1. Versionen werden als Semantic Versions verglichen, eine Vorabversion steht also vor ihrem Release. Ein Release wie 0.1.0 ist ein gewöhnliches Release, das auch der Kanal Stabil anbietet.
• Zugriffstoken. Für ein privates Repository hinterlegen Sie einen Zugriffstoken mit Leserechten. Er wird verschlüsselt in der Datenbank gespeichert, nur als Authorization-Header an den eigenen Host der Quelle gesendet, nie wieder angezeigt (der Reiter sagt nur, ob einer gespeichert ist, und lässt Sie ihn ersetzen oder entfernen) und nie in ein Log oder das Audit-Log geschrieben. Verweisen Sie die Quelle auf einen anderen Host, wird der gespeicherte Token entfernt, statt Ihnen dorthin zu folgen. Ein privates Repository wird aus dem Quellcode gebaut (siehe unten).

RESTOW_UPDATE_CHECK_URL und ihr Vorrang

RESTOW_UPDATE_CHECK_URL ist ein Umgebungs-Override für die Einstellungen des Reiters. Vom stärksten zum schwächsten:

1. RESTOW_UPDATE_CHECK_URL, wenn sie auf eine https-Adresse gesetzt ist. Die Prüfung ist an, die Quelle ist diese Adresse, und der Reiter zeigt sie schreibgeschützt. Ein gespeicherter Token wird dorthin nie gesendet. Da sie eine Einstellung des Betreibers selbst ist, darf sie auf eine interne Adresse zeigen. Akzeptiert werden: eine GitHub-Adresse https://api.github.com/repos/<owner>/<repo>/releases (oder .../releases/latest), eine Forgejo- oder Gitea-Adresse .../api/v1/repos/<owner>/<repo>/releases oder jede andere https-Adresse, die dasselbe JSON liefert. Der Kanal lässt sich im Reiter weiterhin ändern.
2. Die Einstellungen des Reiters (Schalter, Quelle, Kanal, Token).
3. Die Standardwerte: aus, die öffentlichen Releases des Projekts, stabil.

Bestätigen, dass Sie es sind

Das Ändern der Update-Quelle, das Hinterlegen, Ersetzen oder Entfernen des Zugriffstokens und das Ankündigen eines Updates (auch mit einer Vorlaufzeit von null) erfordern neben der Rolle Inhaber eine Anmeldung aus den letzten 10 Minuten: mit einem Passkey, mit dem Passwort zusammen mit dem Code der Authenticator-App oder mit einer OIDC-Anmeldung. Eine ältere Sitzung bekommt den Dialog Bestätigen Sie, dass Sie es sind. Mit einem Passkey bestätigen Sie direkt dort, und die Änderung wird sofort ausgeführt; sonst melden Sie sich erneut an und wiederholen die Änderung im Reiter (nicht gespeicherte Eingaben bleiben nicht erhalten). Das Ein- und Ausschalten der Prüfung, der Kanal, Jetzt prüfen, das Abbrechen und das Ausblenden brauchen keine frische Anmeldung. Die API beantwortet eine solche Anfrage aus einer älteren Sitzung mit 403 urn:restow:problem:recent-sign-in-required.

Der Alarm „Update verfügbar“

Einmal je neuer Version löst Restow einen Alarm Update verfügbar aus: einen Eintrag in der Benachrichtigungsglocke der Provider-Administratoren und die Alarmregeln unter Täglich → Alarme, die das Ereignis Update verfügbar führen (E-Mail, Webhook), in jedem Mandanten. Nur Provider-Administratoren können eine Regel für dieses Ereignis anlegen, die eigenen Administratoren eines Mandanten erfahren nichts von Ihren Updates. Dieselbe Version löst ihn nie zweimal aus. Mit einem Business- oder Service-Provider-Schlüssel, der Updates einschränkt, nennt der Alarm das neueste Release, das der Schlüssel abdeckt (Releases, die Ihr Schlüssel nicht abdeckt). Siehe Alarme und Berichte.

Releases, die Ihr Schlüssel nicht abdeckt (seit 0.4.5)

Das gilt für die vollständigen Images mit einem Business- oder Service-Provider-Lizenzschlüssel. Ohne Schlüssel, mit einer Beta-Lizenz und im Community-Build wird jedes Release angeboten und wie bisher installiert. Ein Schlüssel mit Update-Zeitraum (siehe Lizenz und Editionen) deckt die Releases ab, die bis zum Ende seines letzten Tages erschienen sind; das Release-Datum ist das, das die Images tragen und das die Release Notes in einer Zeile released: veröffentlichen.

• Die Update-Prüfung markiert ein Release, das der Schlüssel nicht abdeckt. Der Reiter Updates sagt das ruhig: Die Version liegt außerhalb des Update-Zeitraums, die installierte Version arbeitet unverändert mit allen Modulen weiter, und die neueste Version innerhalb des Zeitraums, falls es eine gibt, lässt sich wie gewohnt installieren. Er sagt auch, dass Sie den Update-Zeitraum verlängern können.
• Der Updater installiert nur abgedeckte Releases. Ein anderes anzukündigen oder zu planen wird mit 409 urn:restow:problem:update-not-covered abgelehnt.
• Die Glocke und der Alarm Update verfügbar nennen nur das neueste abgedeckte Release. Ein Release außerhalb des Update-Zeitraums zeigt sich nur im Reiter Updates.
• Ein Release, das von Hand gestartet wird, wird geprüft, bevor es die Datenbank anfasst. docker compose pull und docker compose up -d umgehen die Update-Prüfung, deshalb prüft die api den installierten Schlüssel vor jeder Migration. Deckt der Schlüssel die Version nicht ab, startet die api nicht und schreibt nichts in die Datenbank. Ihre Logzeile nennt die Version, das Ende des Update-Zeitraums und das letzte abgedeckte Release-Datum, und es muss nichts zurückgespielt werden, um zurückzugehen:
  • Gehen Sie auf die Version zurück, die Sie vorher betrieben haben (setzen Sie die vorherigen Tags in RESTOW_IMAGE und RESTOW_WEB_IMAGE zurück, dann docker compose up -d), oder auf eine Version, die der Schlüssel abdeckt, und installieren Sie dort einen verlängerten Schlüssel; oder
  • starten Sie die neue Version als Community mit RESTOW_RUN_AS_COMMUNITY=1 in der .env: Die Business- und Service-Provider-Module bleiben aus, nichts wird verändert oder gelöscht, und die Lizenzseite sagt, warum. Installieren Sie einen Schlüssel, der die Version abdeckt, sind die Module sofort wieder an.
• Der Updater (opt-in) sieht eine solche api nicht starten und stellt die vorherige Version selbst wieder her (Wenn etwas schiefgeht); da keine Migration lief, braucht es keinen Dump.

Die Prüfung hält nie eine Installation ohne Schlüssel an, nie die öffentliche Demo, nie einen Entwicklungs-Build und nie ein Release mit einer Beta-Lizenz (jeder bisher ausgestellte Schlüssel). Releases von vor 0.4.5 veröffentlichen keine Zeile released:; für sie nutzt die Prüfung ihr Veröffentlichungsdatum.

Neustart erforderlich (ab 0.3.6)

Manchmal wirkt eine Änderung erst, nachdem ein Dienst neu gestartet wurde: Etwas, das ein Update im Hintergrund getan hat, ist fertig, oder eine Einstellung wird nur beim Start gelesen. Restow hält dann fest, welcher Dienst neu gestartet werden muss und warum, und zeigt das an zwei Stellen:

• Ein Hinweis auf jeder Seite, nur für Provider-Administratoren: „Neustart erforderlich: Worker.“, mit dem Link Anleitung anzeigen zu diesem Reiter. Alle anderen sehen ihn nicht.

• Eine Karte oben unter Installation → Updates, Neustart erforderlich, die jeden Dienst (API, Worker oder Scheduler) mit seinem Grund und dem Befehl nennt, den Sie auf dem Server ausführen, zum Beispiel:

  cd /opt/restow && docker compose restart worker

  Läuft der optionale Updater, nennt der Befehl das eigene Verzeichnis der Installation. Ohne ihn geht die Karte von /opt/restow aus und sagt, dass Sie stattdessen das Verzeichnis Ihrer Installation verwenden: das mit docker-compose.yml und .env.

Jetzt neu starten. Läuft der Updater, bekommt der Inhaber des Provider-Teams außerdem für jeden Dienst die Schaltfläche Jetzt neu starten. Nach einer Bestätigung führt der Updater docker compose restart <Dienst> genau für diesen Dienst aus, und nur für api, worker oder scheduler: nie die Datenbank, den Edge, den Updater oder den Mounter. Die Schaltfläche ist nicht verfügbar, solange ein Update angekündigt ist oder läuft oder ein anderer Neustart läuft; die Karte sagt das dann. Sie ist auch nicht verfügbar, wenn kein Updater läuft oder der Updater älter als 0.3.6 ist, und die Karte zeigt nur den Befehl. Ein Neustart unterbricht den Dienst kurz; laufende Backup-Jobs speichern einen Kontrollpunkt und laufen danach weiter, seit 0.4.0 ohne einen Versuch zu verbrauchen (beim Stoppen gilt die Frist des Workers von 60 s, stop_grace_period). Das Audit-Log hält fest, wer ihn angefordert hat (update.restart.requested).

Nichts startet ohne Klick neu. Der Hinweis bleibt, bis der Dienst wieder gestartet ist, durch die Schaltfläche, durch den Befehl oder durch das nächste Update, und verschwindet dann von selbst.

Bekanntes Problem in 0.3.6: Noch hält nichts eine Neustart-Anforderung fest. Der Hinweis und die Schaltfläche sind für Updates vorbereitet, die sie brauchen; deshalb gibt es für den Hinweis vorerst nichts zu zeigen.

In der Integrations-API

GET /api/v1/status enthält ein Objekt version, damit ein RMM Installationen markieren kann, die zurückgefallen sind: running, commit (der Quell-Commit des laufenden Builds), latest, updateAvailable (null, wenn unbekannt), releaseUrl, updateCheck (disabled, pending, ok oder failed), checkedAt, channel, latestTag, publishedAt, checkError (der Grundcode einer fehlgeschlagenen Prüfung), maintenance (ein angekündigtes oder laufendes Update: phase, targetVersion, startsAt) und, seit 0.4.5 (Vertrag 1.6.0), releasedAt (wann der laufende Build erschienen ist, das Commit-Datum seines Release-Tags; null für einen Build ohne eines). Felder werden nur hinzugefügt, nie umbenannt oder entfernt. Siehe Integrations-API.

Der Updater (opt-in)

Der Reiter Updates zeigt Update installieren nur, wenn der Updater-Dienst läuft. Ohne ihn zeigt der Reiter stattdessen die manuellen Schritte dieser Seite.

Der Updater bindet den Docker-Socket ein: das ist Root auf dem Host

Zugriff auf den Docker-Socket ist Root-Zugriff auf den Rechner. Wer den Updater zu etwas bewegen kann, kann jeden Container mit jedem Mount starten, jede Datei lesen und alles auf dem Host ändern. Deshalb ist der Updater ein Compose-Profil, das nichts tut, solange Sie es nicht starten, und deshalb ist er so klein gebaut wie möglich:

• Er ist ein eigener Prozess und Container (ROLE=updater, das Anwendungs-Image, aber in einer eigenen, festgelegten Kopie: RESTOW_UPDATER_IMAGE, siehe unten). Er hat keinen Datenbankzugriff und kein Anwendungs-Secret: Er bekommt die .env nicht als Umgebung, also kein Datenbankpasswort und nicht RESTOW_MASTER_KEY. Die .env-Datei im eingehängten Projektverzeichnis liest und überschreibt er aber, weil er die beiden Image-Zeilen ändern muss. Für die Sicherung entnimmt er ihr Datenbankbenutzer und -namen und merkt sich jeden zugangsdatenähnlichen Wert darin, damit keiner in ein Log gelangen kann.
• Er lauscht nur im internen Docker-Netzwerk. Es wird kein Port veröffentlicht.
• Die API authentifiziert sich bei ihm mit einem Secret, das der Updater beim ersten Start in ein Docker-Volume schreibt (restow-updater-shared, in der API schreibgeschützt eingehängt). Das Secret steht nie im Repository, in der .env oder in einem Log.
• Der schreibgeschützte Status, den die öffentliche Wartungsseite zeigt (Phase, Schritt, Fortschritt, ein Fehlercode), ist das Einzige, was der öffentliche Edge an ihn weiterleitet. Er nennt keine Version und nichts über die Installation; angemeldete Nutzer sehen die Versionen in der Weboberfläche.
• Sein eigenes Image folgt nie RESTOW_IMAGE, der Zeile, die jedes Update umschreibt. Er läuft mit RESTOW_UPDATER_IMAGE, per Digest fixiert, und wechselt ab 0.2.1 nur dann auf ein neues Image, wenn ein Update im Image-Modus gelungen ist, dessen Images die Signaturprüfung bestanden haben: Dann fixiert er das geprüfte Anwendungs-Image dieses Releases per Digest und erstellt sich selbst neu (Der Updater aktualisiert sich selbst). Ein aus Quellcode gebautes Image führt er nie aus. Solange RESTOW_UPDATER_IMAGE leer ist und die Compose-Datei das Image des Updaters aus RESTOW_IMAGE nehmen würde, verweigert er jedes Update (die Blockade „Updater-Image nicht fixiert“).
• Im Image-Modus installiert er nur Release-Images, die der Release-Workflow des Projekts signiert hat (siehe Was geprüft wird).
• Der Quellcode-Modus, der ein Image aus einem Repository baut und dessen Dockerfile auf dem Docker Ihres Hosts ausführt, ist aus, solange der Betreiber dieses Repository nicht in RESTOW_UPDATER_SOURCE_HOSTS auf dem Host nennt. Über die Weboberfläche kann ihn niemand einschalten.
• Das Ändern der Update-Quelle oder des Tokens und das Ankündigen eines Updates erfordern eine Anmeldung aus den letzten 10 Minuten, zusätzlich zur Rolle Inhaber (Bestätigen, dass Sie es sind).

Wenn Sie das lieber nicht auf Ihrem Host haben möchten, aktivieren Sie ihn nicht. Das Aktualisieren von Hand wird vollständig unterstützt und braucht nur wenige Befehle.

Aktivieren

Ab 0.2.1 genügt ein Befehl, einmal auf dem Server, im Verzeichnis mit docker-compose.yml und .env (/opt/restow bei einer Installation mit dem Installationsskript):

docker compose --profile updater up -d

In der .env muss dafür nichts stehen, und eine Update-Quelle unter Installation → Updates zu wählen startet ihn nicht: Nur dieser Befehl startet ihn.

• Es gibt kein eigenes Updater-Image. Der Updater ist das Anwendungs-Image (das aus RESTOW_IMAGE), gestartet mit ROLE=updater. RESTOW_UPDATER_IMAGE und RESTOW_PROJECT_DIR sind optional. Solange RESTOW_UPDATER_IMAGE leer ist, startet die Release-Compose-Datei den Updater aus RESTOW_IMAGE, und beim ersten Start schreibt der Updater RESTOW_UPDATER_IMAGE selbst in die .env, per Digest fixiert auf das Image, mit dem er läuft (ghcr.io/restow-backup/restow:0.4.7@sha256:...). Das sorgt nur dafür, dass das nächste Umschreiben von RESTOW_IMAGE den Updater nicht erreicht. Kann er nicht fixieren (ein lokal gebautes Image hat keinen Registry-Digest, die .env ist nicht beschreibbar), zeigt der Reiter die Blockade „Updater-Image nicht fixiert“.
• Das Projektverzeichnis wird unter /project eingehängt; RESTOW_PROJECT_DIR setzen Sie nur, wenn die Compose-Datei einen anderen Pfad braucht.
• Update von 0.2.0 mit eingeschaltetem Updater: Ersetzen Sie /opt/restow/docker-compose.yml durch die Datei aus den Release-Assets von 0.2.1, installieren Sie 0.2.1 unter Installation → Updates, löschen Sie dann die Zeile RESTOW_UPDATER_IMAGE aus der .env (oder setzen Sie sie auf das Anwendungs-Image von 0.2.1) und führen Sie einmal docker compose --profile updater up -d updater aus. Danach folgt der Updater signierten Updates selbst.

Die Signatur des Images prüfen Sie, bevor Sie ihm den Docker-Socket geben (das Installationsskript hat das für die installierten Images schon getan):

cosign verify ghcr.io/restow-backup/restow:0.4.7 \
  --certificate-identity https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v0.4.7 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Öffnen Sie dann Installation → Updates. Die Installationskarte sagt, ob der Updater bereit ist oder was ihn blockiert: Docker nicht erreichbar, das Docker-Kommandozeilen-Image noch nicht geladen, Compose-Datei nicht gefunden, Projektverzeichnis passt nicht, .env nicht beschreibbar, zu wenig freier Platz oder das Image des Updaters nicht fixiert. Der erste Start lädt das Docker-Kommandozeilen-Image, wofür Zugriff auf Docker Hub nötig ist; bis dahin meldet die Karte, dass sie sich vorbereitet.

Zum Entfernen: docker compose --profile updater rm -sf updater. Das Volume des Updaters (restow-updater, mit den Datenbanksicherungen) bleibt, bis Sie es mit docker volume rm entfernen.

Der Updater aktualisiert sich selbst

Ab 0.2.1 zieht sich der Updater nach einem gelungenen Update im Image-Modus selbst auf dasselbe Release nach, und nur, wenn die Images des Releases in diesem Lauf die Prüfung aus Was geprüft wird bestanden haben:

1. Er schreibt das Anwendungs-Image des Releases mit dem geprüften Digest (<repository>:<version>@sha256:<digest>) in RESTOW_UPDATER_IMAGE: einen Digest, nie ein Tag, sodass als Nächstes genau der Inhalt läuft, dessen Signatur geprüft wurde.
2. Ein kurzlebiger Hilfscontainer (das fixierte Docker-Kommandozeilen-Image) führt im Projektverzeichnis docker compose --profile updater up -d --no-deps updater aus, weil ein Prozess seinen eigenen Container nicht von innen neu erstellen kann.
3. Der neue Updater meldet sich mit der neuen Version, und der Reiter zeigt sie.

Nach einem aus Quellcode gebauten Update, bei ausgeschalteter Signaturprüfung (RESTOW_UPDATER_VERIFY_SIGNATURES=false) oder mit RESTOW_UPDATER_SELF_UPDATE=false in der .env (danach den Updater neu erstellen) zieht er sich nie selbst nach. Der Reiter zeigt dann, was von Hand zu tun ist: RESTOW_UPDATER_IMAGE auf das Image aus RESTOW_IMAGE setzen und docker compose --profile updater up -d updater ausführen. Schlägt das Selbst-Update fehl, bleibt das Update der Anwendung erfolgreich, und der Reiter zeigt den Befehl, der es abschließt.

Das Vertrauensmodell. Bis 0.2.0 entschied ein Mensch, wann sich der Container mit dem Docker-Socket ändert. Ab 0.2.1 entscheidet die schlüssellose Signatur des Release-Workflows: Der Updater wechselt nur auf ein Image, das im Transparenzlog von Sigstore als von release.yml genau des installierten Tags signiert verzeichnet ist, und nur per Digest, den diese Signatur abdeckt. Ist Ihnen das zu viel, setzen Sie RESTOW_UPDATER_SELF_UPDATE=false und ziehen den Updater von Hand nach.

Eine Community-Installation zum vollständigen Build wechseln

Ab 0.2.1 hat eine Community-Installation den Bereich Installation → Edition. Er nennt den Build, zählt auf, was Business und Service Provider ergänzen, und wechselt zum vollständigen Build derselben Version:

• Mit dem Updater: Zum vollständigen Build wechseln wird wie ein Update angekündigt und braucht die Inhaberrolle und eine frische Anmeldung. Der Updater prüft beide vollständigen Images gegen die Release-Signatur dieses Tags, sichert die Datenbank, schreibt RESTOW_IMAGE=ghcr.io/restow-backup/restow:<version> und RESTOW_WEB_IMAGE=ghcr.io/restow-backup/restow-web:<version> in die .env, erstellt die Dienste neu und rollt auf die Community-Images zurück, wenn der vollständige Build nicht startet. Beide Builds teilen sich dieselben Migrationen, es wird also nichts migriert. Danach zieht sich auch der Updater auf das vollständige Image nach.
• Ohne Updater zeigt der Bereich die zwei Zeilen für die .env zum Kopieren und docker compose pull && docker compose up -d.

Zurück zu Community gibt es keinen Wechsel. Einen Lizenzschlüssel können Sie im selben Bereich schon vor dem Wechsel eintragen; der Community-Build bewahrt ihn versiegelt und ungelesen auf, und der vollständige Build prüft und installiert ihn beim ersten Start. Ein Schlüssel, der die Prüfung nicht besteht, wird verworfen und die Ablehnung protokolliert.

Zwei Modi

Restow wählt den Modus anhand der Update-Quelle und zeigt ihn im Reiter:

• Image (die Standardquelle, die öffentlichen Releases des Projekts). Prüft und zieht ghcr.io/restow-backup/restow:<Version> für die Anwendung und ghcr.io/restow-backup/restow-web:<Version> für den Web-Edge (restow-community und restow-web-community bei einer Community-Installation; siehe Was geprüft wird), schreibt die beiden Image-Referenzen in die .env (RESTOW_IMAGE, RESTOW_WEB_IMAGE) und erstellt die Dienste neu. Veröffentlicht ein Release keinen Digest für das Web-Image, bleibt der Web-Edge, wie er ist, und der Lauf sagt das.

• Quellcode (jedes andere Repository, zum Beispiel Ihr eigenes Forgejo). Lädt das getaggte Archiv des Repositorys herunter, mit dem gespeicherten Token in einem Authorization-Header (nie in einer URL, einer Kommandozeile oder einem Log), baut die Anwendungs- und Web-Images lokal mit docker build (die Dockerfile-Targets runtime und web, bei einer Community-Installation runtime-community und web-community) und erstellt die Dienste dann auf dieselbe Weise neu. Das dauert länger als ein Download.

  Was dort gebaut wird, läuft als die Anwendung, mit der Datenbank und dem Master-Key. Der Quellcode-Modus ist deshalb aus, solange der Betreiber das Repository nicht in der .env nennt und den Updater neu erstellt:

  # One repository (recommended), several separated by commas, or a whole host
  RESTOW_UPDATER_SOURCE_HOSTS=git.example.com/acme/restow

  docker compose --profile updater up -d updater

  Ein Eintrag ist host/owner/repository (nur dieses Repository) oder host (jedes Repository auf diesem Host). GitHub-Repositorys heißen github.com/owner/repo; ein bloßes github.com würde jedes Repository auf GitHub erlauben, verwenden Sie es also nicht. Solange das Repository nicht eingetragen ist, zeigt der Reiter die genaue .env-Zeile und bietet keine Installationsschaltfläche an, und auch der Updater lehnt die Anfrage ab: Das Installieren aus einer Quelle, die nicht auf der Liste steht, wird mit 409 urn:restow:problem:update-source-not-allowed beantwortet. Die api liest dieselbe Variable, damit die Update-Prüfung einen eingetragenen Host in einem privaten Netz erreichen kann.

Was geprüft wird

Im Image-Modus, bevor irgendetwas angehalten wird:

1. Das Release muss in seinen Notes den Digest des Anwendungs-Images veröffentlichen (restow: sha256:..., beim Community-Build restow-community: sha256:...). Ein Release ohne ihn wird abgelehnt: Der Reiter bietet es nicht an (409 urn:restow:problem:update-not-verifiable), und der Updater beendet einen solchen Lauf als unverändert. Aktualisieren Sie darauf von Hand, nachdem Sie das Release geprüft haben. Der Web-Edge ändert sich nur, wenn das Release auch den Digest des Web-Images veröffentlicht.
2. Jedes Image wird in der Registry anhand dieses Digests mit cosign (keyless) geprüft: Es muss eine Signatur tragen, deren Zertifikat von https://token.actions.githubusercontent.com für genau https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v<Version> ausgestellt wurde, den Lauf des Release-Workflows der zu installierenden Version, und die Signatur muss im Transparenz-Log von Sigstore stehen. Ein von Hand in Release-Notes eingetragener Digest, ein anderswo gebautes Image und das Image eines anderen Releases scheitern daran (fetch.signature_invalid, unverändert, nichts gezogen).
3. Erst dann wird das Tag gezogen, und das lokale Image muss den geprüften Digest tragen (sonst fetch.digest_mismatch).

Jeder Lauf zeigt unter Release-Signatur, ob die Signatur geprüft wurde. cosign v3.1.3 läuft in einem kurzlebigen Container aus einem per Digest festgelegten Image (RESTOW_UPDATER_COSIGN_IMAGE), ohne Capabilities, schreibgeschützt, über denselben Docker-Daemon, im Standard-Bridge-Netz von Docker. Während eines Updates braucht er ausgehendes HTTPS zur Registry (ghcr.io) und zur Vertrauensbasis von Sigstore (tuf-repo-cdn.sigstore.dev). Ohne diesen Zugang schlägt die Prüfung fehl, und es wird nichts installiert; das Aktualisieren von Hand funktioniert weiterhin.

Wenn Sie die Images spiegeln (RESTOW_UPDATER_IMAGE_REPOSITORY, RESTOW_UPDATER_WEB_IMAGE_REPOSITORY), kopieren Sie die Signaturen mit (cosign copy); sonst scheitert jedes Update mit fetch.signature_invalid. Eine Testinstallation oder ein unsignierter Spiegel kann die Prüfung mit RESTOW_UPDATER_VERIFY_SIGNATURES=false in einem Compose-Override des Updater-Dienstes abschalten (sie steht absichtlich nicht in der Compose-Datei); der Digest bleibt Pflicht und wird geprüft, und jeder Lauf vermerkt, dass die Signatur nicht geprüft wurde.

Im Quellcode-Modus ist nichts signiert: Das Archiv wird per https aus einem Repository auf der Positivliste des Betreibers geholt, mit dem gespeicherten Token, falls es einen gibt, und so gebaut, wie es ist. Der Updater prüft Host und Repository gegen die Positivliste, die Größe des Archivs und dass es ein Dockerfile enthält; er prüft nicht, wer den Code geschrieben hat, keine Signatur des Tags und nicht, was das Dockerfile tut. Das Vertrauen in dieses Repository ist der ganze Schutz, deshalb kann nur der Betreiber es erlauben.

Was ein Update tut

Der Inhaber wählt die Version und eine Vorlaufzeit (sofort, 1, 5, 15, 30 Minuten oder 1 Stunde) und bestätigt. Seit 0.4.2 fragt der Installationsdialog Wann: Ab jetzt (mit dieser Vorlaufzeit, wie bisher) oder Zu Datum und Uhrzeit (Zu einer gewählten Zeit). Ab dann sieht jede angemeldete Person, nicht nur Administratoren, ein Banner mit Live-Countdown und beim Ankündigen einen Hinweis. Der Inhaber kann bis zum Start abbrechen. Beim Start sehen alle einen Vollbild-Hinweis mit den Schritten und dem Fortschritt. Die Schritte nennen die Version, an der sie arbeiten („Das Image von Version X.Y.Z wird heruntergeladen“); vor 0.4.2 zeigten einige stattdessen ein wörtliches {image} oder {file}.

1. Vorbereiten. Prüft, dass Docker antwortet, die Compose-Datei da ist, die .env beschreibbar ist, Platz für das Update da ist (Speicherplatz), die Datenbank nicht gerade verschoben wird (Datenbank), das Ziel neuer ist als die laufende Version, dass die Compose-Datei das Image von API, Worker, Scheduler und Web-Edge aus RESTOW_IMAGE und RESTOW_WEB_IMAGE bezieht (damit keine Installation mit gemischten Versionen entstehen kann) und dass sie das eigene Image des Updaters nicht daraus bezieht.
2. Prüfen und herunterladen oder bauen. Der Image-Modus prüft zuerst die Signaturen (Was geprüft wird). Es wird noch nichts angehalten: Ein Fehler hier ändert nichts.
3. Datenbanksicherung. pg_dump -Fc der Datenbank in das Volume des Updaters, auf Lesbarkeit geprüft. Die letzten drei bleiben erhalten, dazu die, auf die sich ein Lauf mit Handlungsbedarf stützt.
4. Worker und Scheduler anhalten. Laufende Jobs bekommen bis zu 60 Sekunden, um einen Kontrollpunkt zu speichern und anzuhalten. Sie machen nach dem Neustart ab ihrem letzten Kontrollpunkt weiter, und das Anhalten verbraucht keinen ihrer Versuche. Sicherungen von Rechnern und Proxmox VE, die auf den Agenten laufen, werden nicht angehalten (siehe Laufende Läufe während eines Updates).
5. Neue Version starten. Die API wird mit dem neuen Image neu erstellt und wendet beim Start ihre Datenbankmigrationen an.
6. Health-Check. Wartet, bis die API bereit meldet und die neue Version nennt (er gibt sofort auf, wenn der API-Container immer wieder neu startet), startet dann Worker und Scheduler und erstellt zuletzt den Web-Edge neu.
7. Fertig.

Solange die API neu startet, antwortet der Edge Browsern mit einer statischen Wartungsseite (in der Sprache des Browsers, hell oder dunkel; sie zeigt den Fortschritt, ohne Versionen zu nennen) und API-Aufrufen mit 503. Die Weboberfläche versteht das als „der Server startet neu“ und lädt sich selbst neu, sobald die neue Version antwortet.

Der Zustand liegt im Volume des Updaters und übersteht daher den Neustart der API. Das Ergebnis jedes Laufs erscheint außerdem in der Benachrichtigungsglocke.

Laufende Läufe während eines Updates

Seit 0.4.0 zählt der Installationsdialog, was gerade in jedem Mandanten läuft und wartet, und fragt, was damit geschehen soll. Er nennt die Läufe nach Gruppen: Microsoft 365 und E-Mail (Sicherungen, Wiederherstellungen, Importe, Exporte, Restore-Prüfungen), Server und Clients, Proxmox VE und Freigaben. Sind Läufe in Arbeit, fragt er:

• Sauber anhalten (Standard). Läufe für Microsoft 365 und E-Mail speichern einen Kontrollpunkt und halten innerhalb einer Minute an; sie gehen zurück in die Warteschlange und machen nach dem Update weiter, ohne einen Versuch zu verbrauchen. Läufe auf den Agenten (Server, Clients, Proxmox VE) und von Freigaben hält das Update nicht an, es wartet daher auf sie, höchstens 30 Minuten. Seit 0.4.2 kann ein Administrator sie vorher einzeln in der Web-App stoppen (Proxmox VE, Server und Clients, Freigaben).
• Warten, bis sie fertig sind. Das Update wird angekündigt, und sein Countdown beginnt, sobald nichts mehr läuft, spätestens nach zwei Stunden.
• Nicht warten. Das Update wird sofort angekündigt, wie vor 0.4.0. Was bei seinem Start noch läuft, wird angehalten, speichert einen Kontrollpunkt, wo das geht, und macht danach weiter.

Die Bestätigungsschaltfläche bleibt gesperrt, bis die Läufe gelesen wurden (oder das Lesen fehlschlug), damit ein schneller Klick das Update nicht ankündigt, bevor Sie sie gesehen haben.

In jedem Fall startet ab der Bestätigung kein neuer Lauf, bis das Update vorbei ist: Der Scheduler plant nichts (Zeitpläne, die in der Zwischenzeit fällig werden, laufen bei seinem ersten Durchgang danach, nichts entfällt), der Worker nimmt aus seinen Warteschlangen keinen neuen Job, Läufe für Freigaben und Sicherungsaufgaben von Proxmox VE warten, und die Agenten von Servern und Clients starten keine Sicherung (siehe unten). Dieser Zustand liegt in der Datenbank und hält daher, während die Dienste neu starten. Alle angemeldeten Personen sehen ein Banner, solange das Update wartet; ist es angekündigt, übernimmt das Countdown-Banner. Die Pause endet von selbst, wenn das Update fertig ist oder abgebrochen wurde, und in jedem Fall einige Stunden später (die längste Wartezeit, die Vorlaufzeit und zwei Stunden für das Update), damit eine Installation nie angehalten bleibt. Das Audit-Log hält update.jobs_paused und update.jobs_resumed fest.

Solange das Update wartet, zeigt der Reiter Updates, was noch läuft und bis wann es höchstens wartet. Jetzt starten kündigt das Update sofort an, Abbrechen verwirft es, und neue Läufe starten wieder. Sollte der Updater das Update ablehnen, wenn die Wartezeit um ist (er wurde zwischenzeitlich unerreichbar oder blockiert), starten neue Läufe wieder, und die Administrationen bekommen einen Hinweis in der Glocke.

Was mit einem Lauf geschieht, den das Update anhält:

• Microsoft 365, IMAP und E-Mail. Er speichert einen Kontrollpunkt, geht zurück in die Warteschlange und macht dort nach dem Update weiter. Ein Anhalten durch ein Update oder einen Neustart verbraucht nie einen seiner Versuche (auch ohne Kontrollpunkt), bis zu 21 Tage nach dem ersten Start des Laufs. Nur wenn ein Lauf keinen Versuch mehr hat, endet er als fehlgeschlagen, und seine Erklärung sagt dann, dass sein Kontrollpunkt verworfen wurde und der nächste Lauf von vorn beginnt. Sicherungsstände früherer Läufe sind nicht betroffen.
• Ein Worker, der beendet statt angehalten wurde (die Frist zum Anhalten lief ab, der Host fiel aus), kann seine Jobs nicht zurückgeben. Der nächste Worker findet sie zwei Minuten nach seinem Start: Ein Job, der noch als laufend markiert ist, aber vor jedem lebenden Worker begann, geht mit seinem Versuch zurück in die Warteschlange, und sein Lauf erscheint als unterbrochen. Vor 0.4.0 wartete ein solcher Job bis zu seinem Ablauf, bei einer Sicherung 23 Stunden.
• Proxmox VE. Der Knoten-Helfer sendet die Blöcke, den Commit und das Ende einer laufenden Sicherung fünf Minuten lang weiter, während der Server nicht erreichbar ist (restow-pve 0.4.0; ältere Helfer etwa 30 Sekunden), was ein Update mit seinen Datenbankmigrationen abdeckt. Ein Sicherungslauf, dessen Ende den Server nie erreichte, wird geschlossen, sobald der Heartbeat des Knotens ihn nicht mehr nennt (restow-pve 0.4.0), sonst nach 48 Stunden.
• Server und Clients. Eine Anfrage des Agenten, die gerade läuft, während die API neu startet, schlägt fehl. Der Lauf gilt nur als unterbrochen (nicht als fehlgeschlagene Sicherung), wenn der Server an seinem Ende noch nicht erreichbar ist; sonst endet er als fehlgeschlagen, und der nächste geplante Lauf sichert erneut. Warten oder sauber anhalten vermeidet das.

Die Agenten von Servern und Clients warten auf die Pause (Agent 0.4.0, siehe die Update-Pause). Die Antworten auf die Konfigurationsanfrage und den Heartbeat eines Agenten sagen, ob neue Läufe pausiert sind (startsPaused), und der Agent fragt jede Minute erneut, solange sie es sind. Solange pausiert ist oder der Server nicht antwortet (die API startet neu), warten eine fällige Sicherung, eine Wiederholung und ein Nachholen und starten, sobald die Pause vorbei ist und der Server wieder antwortet. Ein solches Warten ist weder eine verpasste Sicherung (die Nachhol-Regeln einer Richtlinie der Agenten gelten dafür nicht) noch eine fehlgeschlagene. Ein Lauf, der schon läuft, geht weiter und wird vom Dialog wie bisher mitgezählt und abgewartet. Jetzt sichern aus der Weboberfläche bleibt eine wartende Aufgabe auf dem Server und wird dem Agenten mit seinem ersten Heartbeat nach der Pause übergeben, welche Version er auch hat; restow-agent backup-now auf dem Rechner sagt, dass die Instanz aktualisiert wird, und wartet (Strg-C beendet das Warten, nichts wurde gestartet). Ein Agent älter als 0.4.0 kennt die Pause nicht: Eine Sicherung, die sein eigener Zeitplan während der Pause startet, läuft wie bisher und kann fehlschlagen, wenn die API unter ihr neu startet.

Ein Update von Hand (docker compose pull && docker compose up -d) wartet auf nichts: Der Worker bekommt seine 60 Sekunden, und alles oben über angehaltene Läufe gilt.

Knoten und Agenten ziehen das Update nach

Seit 0.4.2 ziehen die Proxmox-VE-Knoten (restow-pve) und die Agenten von Servern und Clients dem Server nach. Sobald der aktualisierte Server läuft, endet die Pause neuer Läufe nicht sofort: Sie geht in eine zweite Phase über, und jeder Knoten und Agent hinter dem neuen Release bekommt mit seinem nächsten Heartbeat gesagt, dass er jetzt aktualisieren soll. Sie installieren das signierte Release nur, wenn sie frei sind, und während der Pause sind sie es.

• Wann die Pause endet. Sobald jeder erreichbare Knoten und Agent die neue Version meldet, in jedem Fall nach 15 Minuten. Erreichbar heißt: in den letzten sieben Minuten gemeldet. Auf einen Agenten, dessen Mandant (oder der Rechner selbst) Agent-Updates angehalten hat, wird nicht gewartet.

• Was alle sehen. Das Banner sagt „Proxmox-VE-Knoten und Agenten aktualisieren sich jetzt; neue Läufe starten, sobald sie fertig sind, spätestens am …“ statt des Countdowns.

• Der Reiter Updates zeigt den Fortschritt unter Knoten und Agenten: wie viele aktualisiert sind, in Arbeit, nicht erreichbar und mit pausierten Updates, und listet die, die noch ausstehen, mit Mandant, Version und letzter Meldung (bis zu 200 mit Namen; die Zahlen umfassen alle).

• Bei den nicht erreichten steht der Befehl für ein Update von Hand, als root auf dem Rechner:

  /opt/restow-pve/bin/restow-pve update                        # Proxmox-VE-Knoten
  sudo restow-agent update                                     # Agent 0.4.2 oder neuer (Linux, macOS)
  sudo systemctl restart restow-agent                          # Linux-Agent vor 0.4.2: er prüft eine Minute nach dem Start
  sudo launchctl kickstart -k system/com.restowbackup.agent    # macOS-Agent vor 0.4.2

  restow-agent update installiert das angebotene Release sofort, über denselben signierten Download wie die automatische Selbstaktualisierung, startet den Dienst neu und sagt, was es getan hat. Läuft gerade eine Sicherung auf dem Rechner, lehnt es ab („A backup is running; the update waits“, englischer Text), und der Agent aktualisiert sich selbst, sobald er frei ist. Der Reiter nennt den Befehl, der zur Version des jeweiligen Agenten passt. Siehe Befehle.

  restow-pve update installiert das angebotene Release auf einem Knoten. Seit 0.4.3 startet es die Proxmox-VE-Dienste und den Dienst restow-pve selbst neu und endet mit „Updated to X.Y.Z.“ (englischer Text); ein Helfer vor 0.4.3 installiert das Release und sagt Ihnen, dass Sie die Dienste selbst neu starten sollen (systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler), was ein Knoten mit restow-pve 0.4.1 nach seinem Update von Hand braucht.

• Auf X.Y.Z aktualisieren bei einem Knoten und einem Rechner. Sobald ein neueres Release angeboten wird, haben die Seite eines Knotens (Proxmox VE) und die Seite eines Rechners die Schaltfläche Auf X.Y.Z aktualisieren, mit der angebotenen Version, auch außerhalb eines Server-Updates. Der Knoten oder Agent installiert das Release bei seiner nächsten Meldung, sobald dort keine Sicherung und keine Wiederherstellung läuft, und startet dann neu. Beides wird im Audit-Log festgehalten (pve.node.update_requested, endpoint.update_requested). Agent-Updates, die der Mandant oder der Rechner angehalten hat, bleiben angehalten, und die Seite sagt das.

Ein Update von Hand (docker compose pull && docker compose up -d) startet von selbst keine Flottenphase: Die Knoten und Agenten aktualisieren sich innerhalb von Stunden selbst, wie bisher, oder sofort mit den Befehlen oben oder mit Knoten und Agenten jetzt aktualisieren.

Knoten und Agenten jetzt aktualisieren

Seit 0.4.3. Läuft der Server mit einem neueren Release als seine Proxmox-VE-Knoten und Agenten, hat aber kein Update in den Schritt geführt, in dem sie ihm nachziehen (der Server wurde von Hand aktualisiert, oder die Antwort auf ein angekündigtes Update ging verloren), zeigen die Knoten und Agenten, die zurückliegen, auf der Karte Knoten und Agenten im Reiter Updates Update verfügbar. Dieselbe Karte hat die Schaltfläche Knoten und Agenten jetzt aktualisieren.

• Wer. Ein Administrator mit allen Mandanten. Der Dialog fragt vorher nach: „Neue Läufe werden wie nach einem Update höchstens 15 Minuten angehalten. Erreichbare Proxmox-VE-Knoten und Agenten mit einem älteren Release installieren das neue, sobald sie frei sind; die Pause endet, sobald alle fertig sind. Nicht erreichbare und Agenten mit pausierten Updates bleiben unverändert.“
• Was geschieht. Dasselbe wie nach einem Update: Neue Läufe werden höchstens 15 Minuten angehalten, jeder erreichbare Knoten und Agent, der zurückliegt, installiert das Release, sobald er frei ist, und die Pause endet, sobald sie fertig sind oder die 15 Minuten vergangen sind. Der Fortschritt steht wie oben auf der Karte.
• Wann es angeboten wird. Nur, solange ein erreichbarer Knoten oder Agent zurückliegt und kein Update auf Läufe wartet, angekündigt ist oder läuft (keine Pause neuer Läufe gilt). Der Dialog ergänzt den Hinweis „Kein Update hat diesen Schritt ausgelöst (zum Beispiel, weil der Server von Hand aktualisiert wurde).“ Liegt beim Bestätigen kein erreichbarer Knoten oder Agent mehr zurück, sagt die Seite das („Kein erreichbarer Knoten oder Agent läuft mit einem älteren Release. Aktualisieren Sie nicht erreichbare von Hand, sobald sie wieder online sind.“), und es wird nichts angehalten.
• Audit. update.fleet_started, mit manual: true.
• Knoten mit restow-pve 0.4.1 reagieren nicht darauf. Siehe Update auf 0.4.3.

Die Route hinter der Schaltfläche steht unter Routen der Weboberfläche.

Zu einer gewählten Zeit

Seit 0.4.2 fragt der Installationsdialog Wann: Ab jetzt (mit einem Countdown, wie bisher) oder Zu Datum und Uhrzeit. Für Letzteres wählen Sie ein Datum, eine Uhrzeit in der Zeitzone der Installation (der Dialog nennt sie, siehe Die Zeitzone der Installation) und den Countdown davor.

• Restow hält den Plan fest und bestätigt ihn zum Zeitpunkt des Countdowns vor der gewählten Zeit genau so, als hätten Sie ihn dann bestätigt: dieselben Prüfungen, die gewählte Behandlung laufender Läufe, derselbe Countdown für alle. Vorher wird nichts angehalten. Alle angemeldeten Personen sehen ab einem Tag vorher einen Hinweis („… wird am … auf Version X.Y.Z aktualisiert“).
• Grenzen. Bis zu 30 Tage im Voraus und mindestens eine Minute vor dem eigenen Countdown. Eine Zeit, die die Uhr überspringt (die Stunde, die die Sommerzeit auslässt), wird abgelehnt. Das Planen braucht dasselbe wie das Ankündigen eines Updates: die Rolle Inhaber und eine frische Anmeldung.
• Geplantes Update absagen im Reiter Updates verwirft den Plan; Sie können ihn jederzeit erneut planen oder das Update ankündigen.
• War der Server zur geplanten Zeit ausgefallen und kommt mehr als eine Stunde später zurück, wird der Plan verworfen statt gestartet, und das Audit-Log sagt das.
• Eine ungültige Zeit wird abgelehnt mit „Choose another time“ (422, update-invalid-time, englischer Text): Sie liegt schon in der Vergangenheit (oder zu nah, um bis dahin herunterzuzählen), mehr als 30 Tage voraus oder wird von einer Zeitumstellung übersprungen.
• Ein Plan behält die Zeitzone, in der er gemacht wurde. Wird die Zeitzone der Installation danach geändert, verschiebt das ein geplantes Update nicht.

Der Hinweis in der Seitenleiste

Ist ein Update verfügbar, wird die Version unten in der Seitenleiste zu einem hervorgehobenen, sanft pulsierenden Update auf X.Y.Z verfügbar, das zu Installation → Updates führt. Nur wer Updates einspielen darf, sieht es. Ist im Betriebssystem „Bewegung reduzieren“ eingeschaltet, gibt es keine Animation.

Die Zeitzone der Installation

Geplante Updates gelten in der Zeitzone der Installation, der Reiter Updates zeigt ihre Zeiten in ihr, und ein neuer Mandant beginnt mit ihr (jeder Mandant behält für seine Zeitpläne eine eigene Zeitzone, die er in seinen Kundendaten ändert). Sie wird im Einrichtungsassistenten gewählt, mit der Zeitzone Ihres Browsers vorausgewählt, und von einem Inhaber unter Installation → Server & Betrieb → Server in der Karte Zeitzone geändert, die eine durchsuchbare Liste der Zeitzonen hat. Akzeptiert werden nur IANA-Namen wie Europe/Berlin, keine festen Versätze.

Es gilt die erste dieser Angaben, die gesetzt ist:

1. die in der Weboberfläche gewählte Zeitzone,
2. RESTOW_TIME_ZONE in der Server-Umgebung,
3. die Prozess-Zeitzone TZ,
4. Europe/Berlin.

Eine Installation, die vor 0.4.2 eingerichtet wurde, hat keine eigene Zeitzone, die Umgebung gilt also wie bisher, bis ein Inhaber eine speichert; Die des Servers verwenden nimmt eine Wahl zurück. Die Karte sagt, woher die geltende Zeitzone kommt („Hier gewählt“, „Aus RESTOW_TIME_ZONE in der Server-Umgebung“, „Aus der Prozess-Zeitzone (TZ) des Servers“ oder „Die Voreinstellung“). Ein Wert in der Umgebung, der keine IANA-Zeitzone ist, wird übersprungen, ein Tippfehler hält also nichts an. Die Änderung steht im Audit-Log (settings.time_zone.changed). Siehe Umgebungsvariablen.

Speicherplatz

Ein Update schreibt einen vollständigen Datenbank-Dump in das Volume des Updaters, zieht zwei neue Images und lässt die neue API ihre Migrationen ausführen. Auf einem fast vollen Datenträger könnte allein der Dump ihn füllen und PostgreSQL mitten im Update anhalten. Seit 0.4.0 addiert der Updater daher vor dem Start, was das Update braucht, und lehnt es ab, wenn das nicht frei ist (Blocker disk_space, mit den Zahlen), statt ein festes 1 GB zu verlangen:

Teil	Schätzung
Dump	der neueste Dump plus ein Viertel; vor dem ersten die Größe der Tabellen ohne ihre Indizes (eine Obergrenze)
Images	die Größe der Images, die jetzt laufen (2 GiB, wenn sie sich nicht lesen lässt)
Migrationen	ein Zehntel der Datenbank, mindestens 1 GiB
Reserve	RESTOW_UPDATER_MIN_FREE_MB (Standard 1024 MB)

Dump und Images müssen dort hineinpassen, wo Docker seine Daten hält (das Volume des Updaters und der Image-Speicher liegen standardmäßig dort). Der Platz für die Migrationen wird dort mitgezählt, außer die Datenbank liegt auf einem anderen Datenträger, wo er stattdessen frei sein muss. Installation → Datenbank zeigt die Schätzung, die Datenträger und wie Sie die Datenbank auf einen anderen Datenträger verschieben.

Die aufbewahrten Dumps stehen im Reiter Updates unter Datenbanksicherungen, mit ihrer Größe. Die Inhaberin oder der Inhaber der Installation kann dort einen herunterladen oder löschen (aktuelle Anmeldung, im Audit-Log festgehalten). Ein Dump enthält die gesamte Datenbank, auch die verschlüsselten Geheimnisse: Bewahren Sie einen heruntergeladenen so sorgfältig auf wie den Master-Schlüssel. Siehe Datenbank.

Wenn etwas schiefgeht

Der Updater rät nie. Er beendet einen fehlgeschlagenen Lauf in genau einem von drei Zuständen:

• Unverändert. Er ist fehlgeschlagen, bevor etwas angehalten wurde (Docker nicht erreichbar, das Release hat keinen Digest veröffentlicht, die Signatur war nicht gültig, das Image ließ sich nicht ziehen oder passte nicht zu seinem Digest, der Build ist fehlgeschlagen, die Sicherung ist fehlgeschlagen). Die alte Version wurde nie angehalten.
• Zurückgesetzt. Die neue Version kam nicht hoch, und die Datenbankmigrationen waren noch nicht gelaufen (der Updater hält zuerst die neue API an und vergleicht dann die Zahl der angewendeten Migrationen mit der vor dem Update). Die vorherigen Images laufen wieder, die .env ist Byte für Byte wiederhergestellt, und der Reiter nennt, welcher Schritt warum fehlschlug. Das geschieht auch, wenn ein Release des vollständigen Builds, das der Lizenzschlüssel nicht abdeckt, nicht startet, seit 0.4.5 (Releases, die Ihr Schlüssel nicht abdeckt).
• Erfordert Ihr Eingreifen. Die neue API ist nach ihren Migrationen fehlgeschlagen. Migrationen lassen sich nicht rückgängig machen, deshalb startet der Updater die alte Version nicht auf einer migrierten Datenbank. Er hält API, Worker und Scheduler an, behält die Datenbanksicherung und sagt Ihnen, was zu tun ist. Der Web-Edge zeigt weiter die Wartungsseite.

„Es wird geprüft, ob das Update angenommen wurde …“ (seit 0.4.3). Bevor der Updater ein Update annimmt, prüft er Docker, die Compose-Konfiguration, den Speicherplatz und die laufende Version, was auf echten Installationen 5 bis 12 Sekunden dauert. Die API wartet bis zu einer Minute auf die Antwort (30 Sekunden beim Abbrechen, Ausblenden, bei Neustarts und beim Löschen einer Datenbanksicherung). Geht die Antwort trotzdem verloren, fragt sie den Updater erneut nach seinem Zustand: Zeigt er das Update, gilt es als angekündigt (die Pause neuer Läufe, der Audit-Eintrag update.scheduled, der Schritt für Knoten und Agenten), und der Reiter zeigt den Countdown. Antwortet der Updater gar nicht, bleibt die Pause neuer Läufe, bis er wieder antwortet, und endet in jedem Fall von selbst; der Reiter liest erneut und zeigt, was der Updater meldet. Vor 0.4.3 wartete die API 5 Sekunden, und der Reiter konnte „Der Updater läuft nicht“ sagen, obwohl der Updater das Update einen Moment später angenommen hatte; das Update lief dann ohne die Pause und ohne den Schritt, in dem Knoten und Agenten dem Server nachziehen, sodass sie auf dem alten Release blieben. Nutzen Sie für diese Knoten und Agenten jetzt aktualisieren. Der Reiter konnte auch hin und wieder für ein paar Sekunden „Der Updater läuft nicht“ sagen; der Updater antwortet jetzt sofort mit seiner letzten Prüfung und prüft im Hintergrund erneut (ein Update prüft vor dem Start weiterhin neu).

Wird der Updater selbst mitten in einem Lauf neu gestartet oder beendet, wird der Lauf als unterbrochen festgehalten (unverändert, wenn er noch nichts angehalten hatte, sonst erfordert er Ihr Eingreifen), und von selbst wird nichts gestartet.

Bei erfordert Ihr Eingreifen spielen Sie die vor dem Update gemachte Sicherung zurück. Der Reiter zeigt den genauen Dateinamen und die vorherigen Image-Referenzen:

# copy the dump out of the updater's volume
docker compose --profile updater cp updater:/state/dumps/<file> ./<file>
# stop the application and restore
docker compose stop api worker scheduler
docker compose exec -T postgres pg_restore -U restow -d restow --clean --if-exists < <file>
# put the previous images back into .env (RESTOW_IMAGE, RESTOW_WEB_IMAGE), then
docker compose up -d

Sicherungen, die nach dem Update entstanden sind, liegen im Chunk-Store, aber nicht in der zurückgespielten Datenbank, führen Sie daher nach dem Zurücksetzen ein Backup aus. Melden Sie den Fehler dann mit dem Log-Ausschnitt, den der Reiter zeigt. Ausblenden entfernt einen beendeten Lauf von der Seite. Nutzen Sie es erst, nachdem Sie die Installation wiederhergestellt haben, denn die Wiederherstellungsbefehle verschwinden damit. Der Lauf bleibt im Audit-Log.

Audit-Ereignisse

Jeder wichtige Schritt steht im Audit-Log: update.check, update.settings.updated, update.scheduled, update.cancelled, update.started, update.succeeded, update.failed, update.acknowledged (Ausblenden eines beendeten Laufs), ab 0.3.6 update.restart.requested (Jetzt neu starten) und, ab 0.4.0, update.jobs_paused und update.jobs_resumed (die Pause neuer Läufe), update.dump.downloaded und update.dump.deleted (die aufbewahrten Datenbanksicherungen) sowie die Einträge des Verschiebens der Datenbank database.move.requested, database.move.started, database.move.succeeded, database.move.failed, database.old_copy.removal_requested und database.old_copy.removed (Datenbank). Ab 0.4.2 kommen hinzu: update.planned (ein zu einer gewählten Zeit geplantes Update; verwirft man den Plan, steht update.cancelled mit planned: true im Log), update.plan_failed (ein Plan, der nicht beginnen konnte), update.fleet_started (Knoten und Agenten zur Aktualisierung aufgefordert; update.jobs_resumed nennt dann fleet_done oder fleet_deadline als Grund), pve.node.update_requested und endpoint.update_requested (Auf X.Y.Z aktualisieren bei einem Knoten oder einem Rechner) und settings.time_zone.changed (die Zeitzone der Installation). Der Updater hat keinen eigenen Datenbankzugriff, er führt daher ein Journal, und die API schreibt es danach ins Audit-Log, in der richtigen Reihenfolge und genau einmal, auch wenn die API zwischendurch ersetzt wurde. Siehe Audit-Log.

Einstellungen des Updaters

Der Compose-Dienst setzt, was er braucht. Diese Variablen liest der Updater (ROLE=updater); RESTOW_UPDATER_SOURCE_HOSTS liest auch die api:

Variable	Standard	Bedeutung
RESTOW_UPDATER_PROJECT_DIR	erforderlich, aus RESTOW_PROJECT_DIR gesetzt	Absoluter Host-Pfad des Compose-Projekts, unter demselben Pfad eingehängt.
RESTOW_UPDATER_IMAGE_REPOSITORY	die Release-Images des eigenen Builds des Updaters (ghcr.io/restow-backup/restow oder ghcr.io/restow-backup/restow-community)	Repository des Anwendungs-Images für den Image-Modus; nur für einen Spiegel setzen, der auch die Signaturen braucht. Aus der .env übergeben.
RESTOW_UPDATER_WEB_IMAGE_REPOSITORY	ghcr.io/restow-backup/restow-web oder ghcr.io/restow-backup/restow-web-community	Repository des Web-Images für den Image-Modus. Aus der .env übergeben.
RESTOW_UPDATER_SOURCE_HOSTS	leer (Quellcode-Modus aus)	Repositorys (host/owner/repo) oder Hosts, aus denen der Quellcode-Modus bauen darf, kommagetrennt. Aus der .env übergeben.
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 (Speicherplatz).
RESTOW_UPDATER_CLI_IMAGE	docker:27-cli, per Digest festgelegt	Image, mit dem docker und docker compose ausgeführt werden (siehe unten). 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 Signaturen prüft. Muss einen Digest tragen.
RESTOW_UPDATER_VERIFY_SIGNATURES	true	false überspringt die Signaturprüfung (Testinstallationen, unsignierte Spiegel); Digests bleiben Pflicht. Nur in einem Compose-Override setzen.

Die Compose-Datei selbst liest RESTOW_UPDATER_IMAGE aus der .env für das Image des Updater-Dienstes (in der Release-Compose-Datei Pflicht).

Das veröffentlichte Image enthält keine Docker-Kommandozeile. Der Updater führt daher jeden Befehl docker und docker compose in einem kurzlebigen Hilfs-Container aus RESTOW_UPDATER_CLI_IMAGE aus (standardmäßig von Docker Hub, im Hintergrund beim Start des Updaters gezogen; vorher kann der Updater nichts installieren und sagt das), über den eingehängten Socket, ohne Netzwerkzugriff und mit eingehängtem Projektverzeichnis und State-Volume des Updaters. Steckt im Image des Updaters selbst eine docker-Binärdatei, wird stattdessen diese direkt verwendet. Die Hilfs-Container tragen keine Registry-Zugangsdaten: Die Images der öffentlichen Releases des Projekts brauchen keine, und eine private Registry wird in diesem Modus nicht unterstützt. Die API erreicht den Updater unter RESTOW_UPDATER_URL (Standard http://updater:8090). Dort antwortet nichts, solange das Updater-Profil nicht läuft.

Von Hand zurücksetzen

• Keine Migrationen im Release: Tragen Sie die vorherigen RESTOW_IMAGE und RESTOW_WEB_IMAGE wieder in die .env ein und führen Sie erneut docker compose up -d aus. Der Updater tut das selbst, wenn eine neue Version nicht startet.

• Mit Migrationen: Migrationen lassen sich nicht zurückdrehen. Halten Sie den Stack an, spielen Sie die vor dem Update gemachte Datenbanksicherung zurück und starten Sie dann die vorherige Version:

  docker compose stop api worker scheduler
  docker compose exec -T postgres pg_restore -U restow -d restow --clean --if-exists < restow-YYYY-MM-DD.dump
  # die vorherigen RESTOW_IMAGE und RESTOW_WEB_IMAGE wieder in die .env eintragen, dann
  docker compose up -d

  Sicherungen, die nach dem Update entstanden sind, liegen im Chunk-Store, aber nicht in der zurückgespielten Datenbank, führen Sie daher nach dem Zurücksetzen ein Backup aus.

  Nach dem Verschieben der Datenbank (Installation → Datenbank, seit 0.4.0) muss die Compose-Datei, mit der Sie zurückgehen, RESTOW_POSTGRES_DATA weiterhin aus der .env lesen; die Datei von 0.3.6 tut das nicht, und PostgreSQL weigert sich dann, auf der alten Kopie zu starten. install.sh verweigert eine solche Datei mit Exit-Code 8 (Datenbank).

Versionen und Kanäle

Restow verwendet Semantic Versioning. Vor 1.0.0 bringt eine Minor-Version (0.2.0) neue Funktionen und kann Migrationen enthalten. Eine Patch-Version (0.2.1) behebt Probleme und enthält nur dann Migrationen, wenn eine Korrektur sie braucht. Tags heißen vMAJOR.MINOR.PATCH, Vorabversionen tragen -rc.N. Der Kanal Stabil der Update-Prüfung bietet nur Releases an, der Kanal Beta zusätzlich die Vorabversionen. Die Docker-Tags eines Releases sind eine eigene Sache, siehe Ein Release verifizieren.