Status und Roadmap

Restow befindet sich in der Beta; 0.4.7 (29. Oktober 2026) ist das aktuelle Release, 0.1.0 war das erste öffentliche Release. 0.3.0 wurde getaggt, aber nie veröffentlicht: Seine Release-Prüfungen fanden die ersten beiden Fehler, daher ist 0.3.1 das erste Release der 0.3er-Linie. Diese Seite sagt klar, was heute existiert und was nicht, statt es nur anzudeuten. Geplante Punkte tragen keine Versionsnummern und keine Termine, und eine Funktion gilt erst als ausgeliefert, wenn sie in einem veröffentlichten Release steckt. 0.4.0 hat anderes ausgeliefert, als der frühere Plan dafür vorsah; deshalb steht alles, was noch nicht ausgeliefert ist, unter „Als Nächstes“ oder „Später“.

Ausgeliefert (0.4.0 bis 0.4.7), Dateifreigaben, unveränderbare Backups, Ransomware-Erkennung, SharePoint, Archiv-Erfassung aus dem Postfach, Microsoft-365-Gruppen, Update-Zeitraum für Lizenzschlüssel, nicht mehr gesicherte Objekte, Ablauf-Erinnerungen

0.4.0 und 0.4.1 wurden am 16. Oktober 2026 veröffentlicht, das nächste Release der Linie am 21. Oktober 2026 (0.4.2) und das darauffolgende am 22. Oktober 2026 (0.4.3) und das nächste am selben Tag (0.4.4), am 23. Oktober 2026 das nächste (0.4.5) und am selben Tag das darauffolgende (0.4.6) und am 29. Oktober 2026 das nächste (0.4.7); 0.4.7 ist die aktuelle Version. Das Update auf 0.4.0 führt siebzehn Datenbankmigrationen aus (0035 bis 0051): Lesen Sie zuerst die Release-Notes von 0.4.0. Das Backup von Dateifreigaben und das Verschieben der Datenbank brauchen die docker-compose.yml von 0.4.0; führen Sie deshalb nach dem Update den Installer von 0.4.0 erneut aus (siehe Erneut ausführen). SharePoint braucht eine zusätzliche Anwendungsberechtigung und eine neue Admin-Zustimmung je Mandant. Das Update auf 0.4.1 führt eine weitere Migration aus, 0052_pve_guest_repository_bytes, die nur zwei Spalten hinzufügt und in Sekunden läuft; das Update auf 0.4.2 führt sechs weitere aus (0053 bis 0058), die eine Tabelle, Spalten und Indizes hinzufügen und in Sekunden laufen; das Update auf 0.4.3 führt keine aus; das Update auf 0.4.4 führt vier weitere aus (0059 bis 0062), die die Tabellen der Archiv-Erfassung, neue Spalten und Indizes auf archive_items und backup_jobs, zwei Indizes auf manifest_versions für den Restore-Explorer und die Erfassungswege der Mail-Jobs hinzufügen, die schon archivieren. Die Indizes werden innerhalb der Migration gebaut, wo Schreibzugriffe auf die Tabelle warten (etwa eine Minute je zehn Millionen Zeilen auf SSD-Speicher); planen Sie das Update einer großen Installation deshalb außerhalb des Sicherungsfensters, siehe Updates. Mail-Jobs, die schon vor 0.4.4 archiviert haben, arbeiten genau wie vorher weiter: Nichts Neues startet von selbst, bis ein Administrator Graph oder die IMAP-Archivierung im Job einschaltet. Das Update auf 0.4.5 führt drei weitere Migrationen aus (0063 bis 0065: drei Spalten, die leer sein dürfen, an der Tabelle license, der Entfernungszustand eines Rechners an endpoints mit einem Teilindex über die fälligen Entfernungen und die geschützte Objektart group); keine schreibt eine Tabelle um. 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 eingeschlossen werden, und der erste Verzeichnisabgleich liest die Gruppen jeder Microsoft-365-Quelle einmal vollständig. Jeder bisher ausgestellte Lizenzschlüssel ist eine Beta-Lizenz und deckt weiter jedes 0.x- und 1.x-Release ab; seit 0.4.5 hält ein Release, das von Hand gestartet wird und das ein Business- oder Service-Provider-Schlüssel nicht abdeckt, vor seinen Migrationen an (siehe Lizenz und Editionen). Das Update auf 0.4.6 führt keine Migration aus; aktualisieren Sie restow-pve auf jedem Proxmox-VE-Knoten (der Server bietet es nach seinem eigenen Update an, und Knoten aktualisieren sich selbst, wenn sie frei sind), bevor Sie sich auf Container-Restores oder Startprüfungen verlassen. Das Update auf 0.4.7 führt vier weitere Migrationen aus (0066 bis 0069: zwei Spalten, die leer sein dürfen, an pve_guests, die Spalte settings.pricing, die Spalte settings.app_secret_alerts und fünf Spalten, die leer sein dürfen, an protected_objects mit zwei Check-Constraints und einem Trigger, der sie mit dem Status des Objekts abgleicht); keine schreibt eine Tabelle um, und restow-pve braucht kein Update. Das Update schließt keinen Proxmox-VE-Gast aus und setzt keinen Preis, und Objekte, die schon verwaist waren, gelten als bestätigt. Deaktivierte und unlizenzierte Postfächer sowie gesperrte OneDrives und Websites, die jede Nacht scheiterten, erkennt der erste Verzeichnisabgleich oder die erste Sicherung nach dem Update (eine gesperrte Website an ihrer ersten Sicherung): Erwarten Sie je Objekt einen Hinweis (ein Benutzer ohne Lizenz hat oft zwei, Postfach und OneDrive) oder eine Warnung für einen Mandanten mit vielen, und bestätigen Sie sie unter den geschützten Objekten, sobald sie beabsichtigt sind. Quellen, die vor 0.4.7 über eine eigene App verbunden wurden, haben kein Ablaufdatum und damit keine Erinnerung, bis es auf der Seite der Quelle („Läuft ab“) eingetragen ist; eine zentrale App, deren Secret aus der Umgebung kommt, braucht ENTRA_CLIENT_SECRET_EXPIRES_AT in der .env und einen Neustart der API. Webhooks und Benachrichtigungsempfänger bekommen die neuen Ereignisse erst, wenn sie in der Benachrichtigungsmatrix angehakt sind. Die docker-compose.yml von 0.4.0 bleibt. Seit 0.4.2 warten nach einem Server-Update neue Läufe, während Proxmox-VE-Knoten und Agenten es installieren (höchstens 15 Minuten); nach einem Update von Hand startet „Knoten und Agenten jetzt aktualisieren“ diesen Schritt (seit 0.4.3). Ein Rollback braucht den Datenbank-Dump, der vor dem Update gezogen wurde. Sofern nichts anderes dabeisteht, gehört alles Folgende zu jeder Edition (dem Community-Kern).

• Backup von Dateifreigaben (SMB und NFS) (0.4.0): Restow sichert eine SMB-Freigabe (Windows Server, Samba, ein NAS) oder einen NFS-Export vom Server aus, ohne Agent auf dem Dateiserver. Es bindet die Freigabe für die Dauer eines Laufs schreibgeschützt in einem kurzlebigen Runner-Container ein, den der Mounter startet, und sichert sie mit restic in ein eigenes Repository. NTFS-Berechtigungen (bei NFSv4 und POSIX ACLs nach bestem Bemühen) bleiben in jedem Sicherungsstand erhalten; geöffnete, nicht lesbare und Offline-Dateien werden übersprungen und aufgelistet, und der Lauf endet mit Warnungen. Wiederherstellen aus einem Sicherungsstand als ZIP, in einen neuen Ordner, an den ursprünglichen Ort (überschreiben, beide behalten, überspringen) oder in eine andere Freigabe, mit Berechtigungen, wo das Ziel sie erlaubt. SMB 2.1 bis 3.1.1; SMB1 und NTLMv1 werden abgelehnt. Neue Installationen starten den Mounter standardmäßig; eine bestehende Installation bekommt ihn über Netzlaufwerke einschalten (optionaler Updater). Siehe Freigaben und Netzlaufwerke.
• Restore-Prüfungen, Kopierjobs und Budgets für Freigaben (0.4.0): Jeder neue Sicherungsstand wird geprüft, indem bis zu 20 Stichproben-Dateien zurückgelesen werden, das Repository bekommt wöchentlich einen restic check von 5 Prozent seiner Daten, und die Wiederherstellbarkeit bewertet eine Freigabe nach ihrem neuesten Sicherungsstand. Kopierjobs schreiben den neuesten geprüften Sicherungsstand einer Freigabe in einen Ordner einer anderen (Modus Überschreiben oder Spiegeln) und sind als Nicht-Backup gekennzeichnet. Budgets je Freigabe, je Mandant und als Standard (standardmäßig aus, von Provider-Admins gesetzt) warnen bei 80 Prozent und lehnen bei 100 Prozent neue Sicherungen ab. Freigaben zählen im Status, auf der Startseite, bei der Wiederherstellbarkeit, in Warnungen, im Verlauf, in der Statistik und in der Provider-Ansicht. Siehe Restore von Freigaben, Kopierjobs und Budgets und Runner.
• Unveränderbare Backups (0.4.0): Unveränderbarkeit je Repository, aus, bis ein Administrator sie einschaltet. Auf S3 sperrt Object Lock (Compliance oder Governance, 1 bis 3650 Tage) die Packs, Manifeste und umhüllten Schlüssel des Chunk-Stores (Microsoft 365, IMAP, Proxmox-VE-Festplatten) und die Objekte jedes restic-Repositorys (Rechner, Freigaben, Proxmox-VE-Container); Restow prüft zuerst den Bucket, erneuert die Sperre von Daten, die noch gebraucht werden, und sendet nie den Governance-Bypass-Header. Bei Verzeichnissen (das Docker-Volume, eine NFS-Freigabe) sorgt eine Löschverzögerung dafür, dass der Code von Restow selbst eine Datei erst nach Ablauf der Frist löscht oder überschreibt; sie schützt vor Missbrauch von Restow, nicht vor jemandem mit Zugriff auf den Server, und die Oberfläche sagt, dass es keine Unveränderbarkeit ist. Sicherungsstände zeigen „Unveränderbar bis <Datum>“, grün nur bei einer Compliance-Aufbewahrung, die der Speicher selbst gemeldet hat. Den Schutz zu senken braucht den Provider-Inhaber mit einer frischen Anmeldung. Siehe Unveränderbare Backups.
• Ransomware-Erkennung mit angehaltener Aufbewahrung (0.4.0): Jeder neue Sicherungsstand eines Rechners, einer Freigabe, eines Proxmox-VE-Gasts, eines Postfachs, eines OneDrives, einer SharePoint-Website oder eines IMAP-Kontos wird anhand von Daten, die das Backup ohnehin hat, auf Anzeichen von Ransomware beurteilt (die Menge der Änderungen gegenüber dem Verlauf des Objekts selbst, Massenlöschungen, umbenannte Endungen, bekannte Ransomware-Endungen und Lösegeldforderungen, die Entropie von Stichproben neuer Dateien, das Komprimierungs- und Deduplizierungsverhältnis der neuen Daten). Ein verdächtiger Sicherungsstand bekommt ein Kennzeichen „Verdächtig“, und die Restore-Ansichten bieten den neuesten ohne Befund an. Solange er ungelöst ist, hält eine angehaltene Aufbewahrung Aufbewahrung und Bereinigung dieses Objekts an; nur ein Administrator beendet das („Als Fehlalarm markieren“ oder „Aufbewahrung freigeben“, protokolliert). Es liest die Daten nie ein zweites Mal, blockiert nie ein Backup und ist kein Virenscanner. Einige Signale brauchen Agent 0.4.0 auf Rechnern oder restow-pve 0.4.0 auf dem Knoten, und ein Signal ohne Daten sagt „nicht verfügbar“, nie „unauffällig“. Es ist nach dem Update eingeschaltet; Schwellen und Schalter stehen unter Installation → Ransomware-Erkennung. Siehe Ransomware-Erkennung.
• S3-Endpunkte brauchen HTTPS (0.4.0): Ein neuer oder geänderter S3-Endpunkt über unverschlüsseltes http:// wird abgelehnt, außer zu localhost, 127.0.0.1 und [::1]. Früher gespeicherte Endpunkte laufen weiter und sagen in Rot, dass sie auf HTTPS umziehen sollten; S3_ALLOW_INSECURE=true erlaubt unverschlüsseltes HTTP nur für Test- und Entwicklungsumgebungen.
• Benachrichtigungsmatrix (0.4.0): Unter Integrationen → Benachrichtigungen sind die Ereignisse die Zeilen und die Glocke, jeder Webhook und jeder Benachrichtigungsempfänger die Spalten, jeweils mit den Schnellauswahlen „Nur Fehler“, „Fehler und Warnungen“ und „Alle“. Das Update füllt jede Spalte mit genau dem, was der Kanal vorher bekam; ein danach angelegter Webhook startet mit den Voreinstellungen seines Formats. Neue Ereignisse: backup.succeeded und verify.completed, backup.suspicious und backup.suspicious_hold, boot_test.failed und boot_test.unproven sowie installation.disk_low für Provider-Admins. Siehe Alarme und Berichte.
• Proxmox VE (Preview): Fortschritt, Startprüfungen, Datei-Restore, Jobs (0.4.0, jede Edition, restow-pve 0.4.0 auf dem Knoten): Laufende Sicherungen zeigen einen Fortschrittsbalken, und die eigenen Zeilen des Helfers gelangen in das Log des Laufs; ein Proxmox-VE-Job kann den neuesten Sicherungsstand jedes Gasts wöchentlich oder nach jeder Sicherung isoliert booten (standardmäßig aus; grün, wenn der Gast-Agent geantwortet hat, gelb, wenn die VM nur gestartet ist, rot bei einem Fehler), und Jetzt Start prüfen fordert eine Prüfung von Hand an; Server & Clients → Datei-Restore listet jeden Container mit einem Sicherungsstand und, mit Vorschau markiert, jede VM auf, zum Durchsuchen und Herunterladen von Dateien und Ordnern als eine ZIP-Datei (btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker und LUKS sind nicht lesbar; vergleichen Sie eine wichtige Datei mit dem Original, bevor Sie sich darauf verlassen); Proxmox-VE-Jobs erscheinen unter Server & Clients → Jobs neben den Rechner-Jobs. Proxmox VE bleibt in jeder Edition eine Preview, gegen den simulierten Knoten der Testsuiten getestet, nicht gegen einen echten Proxmox-VE-Cluster. Siehe Startprüfungen und Datei-Restore.
• Richtlinien für Agents (0.4.0): Regeln für die Agents auf Servern und Clients auf drei Ebenen, der Installation, dem Mandanten und dem Backup-Job, wobei jede Ebene die darüber überschreiben darf, sofern die Installation sie nicht sperrt: ein Sicherungsfenster, das Nachholen verpasster Sicherungen, ein Upload-Limit, „Nur am Netzteil“ und die Zahl der automatischen Wiederholungen (0 bis 10). Die Seite eines Rechners zeigt die Richtlinie, die für ihn gilt, und warum eine fällige Sicherung wartet. Fenster, Nachholen, Wiederholungen und der Wartegrund brauchen Agent 0.4.0. Siehe Richtlinien für Agents.
• Datei-Restore für die Restore-Rolle (0.4.0): Restore-Operatoren öffnen Server & Clients → Datei-Restore, lesen die Sicherungsstände von Rechnern und Proxmox-VE-Gästen und deren Unveränderbarkeit, durchsuchen sie, laden Dateien als ZIP herunter und stellen Dateien auf einem Rechner wieder her; Einstellungen, Tokens, Jobs, Sichern, Prüfen und Startprüfungen, das Wiederherstellen eines ganzen Gasts sowie Sperren oder Löschen bleiben bei den Administratoren. Jedes Lesen, Herunterladen und Wiederherstellen wird protokolliert.
• Datenordner, die ein Job auslässt (0.4.0): Der Agent 0.4.0 meldet, welche Ordner aus einer festen Liste von Linux-Datenordnern vorhanden sind und Dateien enthalten (nur die Namen); der Job-Editor nennt die Ordner, die die Rechner des Jobs wirklich haben und der Job auslässt, und die Seite eines Rechners bietet Diesen Ordner hinzufügen an. Die Seite eines Rechners sagt, als was er läuft (Container, virtuelle Maschine, physisch, mit oder ohne Desktop).
• Empfohlenen Job anlegen (0.4.0): Neben jedem Hinweis „kein Job“ und als „Alles ohne Job schützen“ auf der Bereitschaftskarte des Dashboards eine Vorschau, was der Klick anlegt oder erweitert, dann ein Job je Art (Mail, Rechner, Proxmox VE). Nur für Administratoren, protokolliert.
• Live-Ansicht und Dashboard (0.4.0): laufende Sicherungen in der Seitenleiste mit Spinner und Zahl, eine lebendigere Lauf-Schublade, „Erste Sicherung: X von Y Elementen“ für ein großes Postfach und Speicherwachstum im Dashboard über 1 Woche bis 1 Jahr, mit der Angabe, wann das Repository bei diesem Wachstum voll ist, wo der freie Platz bekannt ist. Service Provider ergänzt Alle Mandanten in Jobs: jeder Mandant mit seinen Jobs je Art, was läuft und wartet und dem nächsten Lauf.
• SharePoint Online (0.4.0): Jeder Verzeichnisabgleich findet die Websites des Mandanten (einschließlich der Websites von Microsoft-365-Gruppen und Teams; persönliche Websites bleiben dem OneDrive ihres Besitzers überlassen), und jede Website ist ein eigenes geschütztes Objekt, in den Mail-Jobs. Ein Backup enthält jede Dokumentbibliothek, jede Liste mit ihren Spalten und den Feldwerten jedes Elements als JSON sowie die Beschreibung der Website; Restore im Explorer als ZIP, in die ursprüngliche oder eine andere Bibliothek (beide behalten, überschreiben, wobei SharePoint die alte Datei als Version behält, oder vorhandene überspringen) und Listenelemente als neue Elemente in ihre ursprüngliche Liste. Nicht gesichert: Teams-Chats, Anhänge von Listenelementen, Website-Design, Navigation und Workflows; Berechtigungen werden als Information festgehalten und nie wiederhergestellt. Braucht Sites.ReadWrite.All (Sites.Read.All genügt zum Sichern) und eine neue Admin-Zustimmung je Mandant. Siehe SharePoint Online.
• Laufende Sicherungen während eines Updates (0.4.0): Der Installationsdialog zählt, was in jedem Mandanten läuft und wartet, und fragt: Sauber anhalten (die Voreinstellung), Warten, bis sie fertig sind (höchstens zwei Stunden) oder Nicht warten. Von der Bestätigung bis zum Ende des Updates startet kein neuer Lauf; Agents 0.4.0 halten ihre eigenen Zeitpläne an, ältere Agents nicht. Eine Proxmox-VE-Sicherung, die während eines Restow-Updates läuft, scheitert nicht mehr. Siehe Updates.
• Datenbank verschieben, Warnung bei wenig Speicherplatz, aufbewahrte Dumps (0.4.0): Installation → Datenbank zeigt, wo die Datenbank ihre Daten hält, und lässt den Provider-Inhaber sie mit dem optionalen Updater in ein Verzeichnis auf einem anderen Datenträger verschieben (geprüft, kopiert, verglichen, probeweise gestartet und umgeschaltet, mit automatischem Rollback); alle 15 Minuten prüft die API den Datenträger unter der Datenbank und unter dem lokalen Standard-Repository und warnt Provider-Admins bei weniger als einem Zehntel frei, und immer unter 5 GiB; der Reiter Updates listet die Dumps vor dem Update. Der Preflight des Updates addiert jetzt, was ein Update schreibt, und lehnt eines ab, das nicht passt. Siehe Datenbank.
• Integrations-API, Vertrag 1.4.0 (0.4.0, additiv): GET /api/v1/status hat fileShares und die Zusammenfassung sharesWithoutJob, und events ist beim Anlegen eines Webhooks optional.
• Leistung auf großen Installationen (0.4.0): Der Speicherbedarf bleibt begrenzt bei Freigaben-Katalogen mit Millionen Dateien, bei der Wiederverwendung der SMB-Berechtigungen, bei SharePoint-Websites mit Tausenden Listen, bei großen VM-Blockkarten und bei der Erneuerung von Object Lock.
• Gespeicherte Daten zählen die restic-Repositories (0.4.1): „Gespeichert“ unter Repositories → Nutzung, im Dashboard, in der Statistik und in der API addiert jetzt die restic-Repositories von Rechnern, Freigaben und Proxmox-VE-Containern zum Chunk-Store; vorher sah ein Mandant mit 10 GB Container-Backups „Gespeichert 10,9 kB“. Die Deduplizierungs-Ersparnis, das Wachstum und das Diagramm bleiben Zahlen des Chunk-Stores und sagen das.
• Proxmox VE (Preview): ein alter Knoten-Helfer wird benannt (0.4.1): Eine laufende Container-Sicherung auf einem Knoten mit restow-pve vor 0.4.0 sagt, dass der Fortschritt 0.4.0 braucht, welche Version der Knoten hat und dass der Knoten zu aktualisieren ist; restow-pve fragt jetzt zwei Minuten nach dem Start nach einem Update, danach alle sechs Stunden.
• Eine Sicherung in der Oberfläche stoppen (0.4.2): Proxmox VE: „Sicherung stoppen“ in der Tabelle VMs & Container, auf der Seite des Gastes und in der Lauf-Schublade stoppt eine laufende Sicherung (der Knoten beendet die vzdump-Aufgabe über die Proxmox-VE-API, auch bei einer in Proxmox VE selbst gestarteten Sicherung), „Zurückziehen“ nimmt eine wartende sofort aus der Warteschlange. Je Knoten „Warteschlange anhalten“ und „Alle wartenden zurückziehen“, auch für den ganzen Mandanten. Server und Clients: „Sicherung stoppen“ auf der Seite des Rechners und in der Lauf-Schublade; der Agent beendet restic bei seiner nächsten Meldung sauber, innerhalb etwa einer Minute. Auch Läufe von Dateifreigaben lassen sich in der Lauf-Schublade abbrechen (Läufe von Microsoft 365 und IMAP ließen sich schon vorher abbrechen). Ein gestoppter Lauf endet als „Abgebrochen“, nicht als fehlgeschlagen: kein Fehleralarm, und er zählt nicht als letzte Sicherung. Jedes Stoppen fragt vorher nach und wird im Audit-Log festgehalten. Es braucht restow-pve ab 0.4.2 auf dem Knoten und Agent ab 0.4.2 auf dem Rechner; ein älterer Knoten beendet eine abgebrochene Sicherung bei seinem nächsten Upload, ein älterer Agent führt sie zu Ende.
• Knoten und Agenten ziehen bei einem Server-Update nach (0.4.2): Läuft der Server mit dem neuen Release, bleiben neue Läufe angehalten, während Proxmox-VE-Knoten und Agenten es installieren (sie sind dann frei), bis jeder erreichbare es meldet oder 15 Minuten vergangen sind. Installation → Updates zeigt ihren Fortschritt und nennt für die nicht erreichten den Befehl für ein Update von Hand. „Auf X.Y.Z aktualisieren“ auf der Seite eines Knotens und eines Rechners fordert das Update jederzeit an. restow-agent update auf einem Rechner installiert das angebotene Release sofort, wie restow-pve update auf einem Knoten, über denselben signierten Download wie die automatische Selbstaktualisierung; läuft gerade eine Sicherung, lehnt er ab, und der Agent aktualisiert sich selbst, sobald er frei ist.
• Geplante Updates und eine Zeitzone der Installation (0.4.2): Ein Update lässt sich zu einem gewählten Datum und einer Uhrzeit planen, bis zu 30 Tage im Voraus, neben den Vorlaufzeiten ab jetzt: Vorher wird nichts angehalten, und alle angemeldeten Personen sehen ab einem Tag vorher einen Hinweis. Die Uhrzeit gilt in der Zeitzone der Installation, die im Einrichtungsassistenten gewählt wird (die Zeitzone des Browsers ist vorausgewählt) und die ein Inhaber unter Installation → Server & Betrieb → Server ändert; ein neuer Mandant beginnt mit ihr. Eine Installation, die vor 0.4.2 eingerichtet wurde, nutzt weiter RESTOW_TIME_ZONE, dann TZ, dann Europe/Berlin, bis ein Inhaber eine Zeitzone wählt. Ist ein Update verfügbar, wird die Version in der Seitenleiste zu einem hervorgehobenen „Update auf X.Y.Z verfügbar“, das zu Installation → Updates führt, für alle, die Updates einspielen dürfen.
• Proxmox VE: Jeder neue Sicherungsstand wird binnen Minuten geprüft (0.4.2): Proxmox VE Preview, in jeder Edition. Ein neuer Sicherungsstand einer VM oder eines Containers wird binnen Minuten nach seiner Sicherung zurückgelesen (eine Stichprobe seiner Blöcke, bei einem Container eine restic-Prüfung eines Teils), eine begrenzte Anzahl je Durchlauf, neben der wöchentlichen Prüfung jedes Gastes. Die Einstellung „Jeden neuen Sicherungsstand direkt nach der Sicherung prüfen“ (Installation → Proxmox VE, Inhaber) ist standardmäßig eingeschaltet; ausgeschaltet wartet ein neuer Sicherungsstand auf die wöchentliche Prüfung. In der Wiederherstellbarkeit gibt es „Jetzt prüfen“ je Gast und „Alle ungeprüften prüfen“. Eine rote Prüfung zeigt den Fehler, den sie gefunden hat, zum Beispiel den von restic, statt nur „Blöcke stimmten nicht überein oder ließen sich nicht lesen“. Das ist die stichprobenartige Rücklesung, kein Startversuch; Startprüfungen bleiben wie in 0.4.0.
• Proxmox VE: Neue Sicherungskette für einen Container, dessen Repository fehlt (0.4.2): Proxmox VE Preview, in jeder Edition. Nachdem das primäre Repository mit „Vorhandene Backups dort belassen, wo sie sind“ gewechselt hatte, scheiterte jeder Container mit vorhandenem Repository mit „repository does not exist“. Bevor eine Sicherung ihren Zugang bekommt, prüft der Server jetzt einmal je Lauf, dass das Repository auf dem primären liegt. Fehlt es überall, beginnen ein neues Repository und eine neue Sicherungskette, sichtbar auf der Seite des Gastes („Neue Sicherungskette am“ mit dem Datum) und im Audit-Log; die früheren Sicherungsstände werden „Nicht verfügbar“ (kein Restore, keine Prüfung, in der Wiederherstellbarkeit nicht mitgezählt, von der Aufbewahrung übergangen). Liegt es noch auf einem ausgemusterten Ziel, wird die Sicherung stattdessen mit einer klaren Meldung abgelehnt. „Repository zurücksetzen“ (Gefahrenbereich der Gast-Seite, nur Container) tut dasselbe auf Wunsch: der Name des Gastes wird eingetippt, es braucht eine frische Anmeldung, und es wird im Audit-Log festgehalten. Eine Dateifreigabe, deren Repository fehlt, wird auf diesem Weg noch nicht geheilt; das ist geplant.
• Proxmox VE: Job-Rhythmen, die VM des Restow-Servers und Sicherungen mit Warnungen (0.4.2): Proxmox VE Preview, in jeder Edition. Proxmox-VE-Jobs nehmen die Rhythmen eines Mail-Jobs: alle paar Stunden, täglich, an gewählten Wochentagen, monatlich oder als Cron-Ausdruck, nicht öfter als stündlich. Die VM, auf der Restow selbst läuft, wird an ihrer SMBIOS-UUID erkannt (restow-pve ab 0.4.2 meldet sie) oder von einem Administrator markiert; kein Job sichert sie, und „Jetzt sichern“ oder das Aufnehmen in einen Job braucht eine Bestätigung, die das Risiko nennt, sie mit Restow selbst zu sichern. Eine Sicherung, die vzdump mit „TASK WARNINGS“ beendet, nachdem ihr Sicherungsstand festgeschrieben war, zählt als „Erfolgreich mit Warnungen“ statt als fehlgeschlagen.
• Wo Sicherungen landen, wird angezeigt (0.4.2): Das wirksame primäre Repository des Mandanten steht auf der Seite eines Gastes und in dessen neuem Dialog „Jetzt sichern“, in den Dialogen für Proxmox-VE-Jobs und -Anbindung, auf der Seite eines Rechners und einer Dateifreigabe und in den Job-Editoren; der Installationsstandard auf der lokalen Platte des Servers ist hervorgehoben. Der Bereich Repositories und die Dialoge, die Proxmox-VE-Knoten, Rechner und Dateifreigaben hinzufügen, warnen „Sicherungen landen auf der eigenen Platte des Servers“, wenn das primäre Repository ein Verzeichnis auf einer Platte des Servers selbst ist (keine Netzwerkfreigabe).
• Ein Speicher-Umzug nimmt die restic-Repositories mit (0.4.2): Ein Verschieben des primären Repositorys („Vorhandene Backups verschieben“) kopiert jetzt auch die restic-Repositories von Containern, Rechnern und Dateifreigaben, geprüft nach Größe und per SHA-256 wie Packs. Es wartet vor dem Umschalten auf laufende Container-Sicherungen und Läufe von Dateifreigaben und kopiert die Manifeste der Sicherungsstände von VMs und Containern. „Vorhandene Backups dort belassen, wo sie sind“ und das Befördern einer Kopie werden abgelehnt, solange Container oder Dateifreigaben restic-Repositories haben, die nur das Verschieben mitnimmt. Ein Wechsel des primären Repositorys wird weiterhin abgelehnt, solange ein Rechner des Mandanten aktiv ist.
• Speicherprüfung: Vorübergehend nicht lesbar ist nicht beschädigt (0.4.2): Die Speicherprüfung wertet ein Pack, das sie im Moment nicht lesen konnte (ein mitten in der Übertragung abgebrochener Download, eine zurückgesetzte Verbindung, ein Timeout, S3 mit der Bitte um langsameres Tempo, verweigerter Zugriff), nicht mehr als beschädigt. Sie liest ein solches Pack erneut, bis zu dreimal, und führt, was nicht lesbar bleibt, in Wiederherstellbarkeit → Speicherintegrität als „vorübergehend nicht lesbar“ auf, mit dem Fehler, in wie vielen Prüfungen in Folge es nicht lesbar war und wann; jede weitere Prüfung liest es zuerst, und „Diese Packs erneut prüfen“ liest nur die markierten Packs noch einmal. Objekte, die es verwenden, bekommen „Achtung“; „Nicht wiederherstellbar“ werden sie erst, wenn ein Pack nachweislich beschädigt ist (fehlt, falsche Größe oder Prüfsumme) oder in 3 Prüfungen in Folge über mindestens 24 Stunden nicht gelesen werden konnte. Lesezugriffe auf S3, auch Restores und Restore-Prüfungen, setzen einen abgebrochenen Download fort. Der Wert storageIntegrity.state der Integrations-API hat den neuen Wert unreadable (Vertrag 1.5.0, additiv).
• Restore-Explorer: ein Eintrag je Person und ein Kalender nach Monaten (0.4.2): Der Restore-Explorer listet einen Eintrag je Person: Postfach, OneDrive und ein zugeordnetes IMAP-Konto stehen zusammen, und die zweite Spalte zeigt E-Mail, Kalender, Kontakte und OneDrive, jeweils mit eigenen Sicherungsständen. SharePoint- und Teams-Websites haben einen eigenen Abschnitt, und ein verwaistes OneDrive steht unter dem Namen seines Besitzers als „Konto gelöscht“. Die Liste kommt seitenweise, mit Suche über Namen, Adressen und Konto-IDs und einem Typfilter in der Datenbank; bis etwa 10.000 Personen je Mandant ist das unproblematisch, darüber langsamer. Der Kalender eines Postfachs hat eine Monatsansicht, Tag für Tag über alle seine Kalender oder einen, und eine Serie öffnet sich auf ihre Termine, berechnet aus dem gespeicherten Muster mit den geänderten Terminen an ihrer Stelle; Termine sind nach Beginn sortiert.
• Mail-Job-Editor: sichern, archivieren oder beides (0.4.2): Die erste Frage im Editor eines Mail-Jobs ist, was der Job tun soll: sichern, archivieren oder beides (beides ist die Vorgabe für einen neuen Job). Archiviert er, nennt der Editor den Weg, auf dem Mails ins Archiv gelangen (Exchange-Journaling, einmal je Mandant einzurichten), mit dem Verweis auf die Einrichtung und schlägt vor, alle 8 Stunden zu sichern; nur Sichern nennt die Lücke zwischen zwei Läufen, in der eine eingehende und wieder gelöschte Mail in keiner Sicherung ist. Ein Job, der nur archiviert, sichert nicht nach Zeitplan.
• Proxmox VE: VMs & Container in Reitern, mit Suche, Filtern und Detailbereich (0.4.3): Proxmox VE Preview, in jeder Edition. VMs & Container hat drei Reiter mit Zahlen: Gäste, Backup-Jobs und Knoten. Die Tabelle der Gäste hat eine Suche über ID und Namen, Filter nach Knoten, Art (VM oder Container), Backup-Job (auch „Kein Backup-Job“) und Zustand, eine Schaltfläche „Nur Probleme“, sortierbare Spalten, Seiten zu 25 bis 250 und den Zustand in der Adresse, sodass ein Link dieselbe Ansicht öffnet. Jede Zeile zeigt ein Zustandsabzeichen, nach Dringlichkeit gewählt, mit einem kleinen Fortschrittsbalken, solange die Sicherung läuft, oder „+N“ für weitere Probleme. Ein Klick öffnet einen Detailbereich mit allen Zuständen, dem vollständigen Fehler und den Warnungen des letzten Laufs in einem kopierbaren Block, der Restore-Prüfung, den Größen, dem Job, den neuesten Läufen und den Aktionen (Jetzt sichern, Stoppen, Zurückziehen, Jetzt prüfen, Seite des Gasts öffnen). Die Spalte „Sicherung“ lautet „Erste: 32 GB am 3. Okt. · Letzte: +210 MB“, und der Bereich zeigt die neuen Daten der letzten 30 Sicherungen als kleine Balken. Der Reiter Knoten zeigt je Knoten den Herzschlag, die Version von restow-pve mit „Auf … aktualisieren“, wenn sie veraltet ist, die Version von Proxmox VE, die Zahl der Gäste, die Warteschlange und die Probleme. Die Tabellen behalten feste Spaltenbreiten und eine Zeilenhöhe und springen deshalb nicht mehr, während Sicherungen laufen. Mit DOM-Tests getestet, nicht visuell in einem Browser mit Tausenden Gästen.
• Proxmox VE: Ein gesperrtes Repository lässt keine Restore-Prüfung mehr fehlschlagen (0.4.3): Proxmox VE Preview, in jeder Edition. Direkt nach einer Container-Sicherung scheiterte die neue Restore-Prüfung oft rot mit einer restic-Meldung über veraltete Sperren, obwohl die Prüfung nie lief: Ein anderer Vorgang, meist die eigene Sicherung des Gasts, hielt die Sperre des Repositorys. Eine Prüfung, die eine Sperre aussperrt, wird jetzt verschoben und nach zehn Minuten erneut versucht, das bisherige Ergebnis bleibt stehen. Nach zwei Stunden steht dort „Nicht prüfbar: Repository gesperrt“ in Gelb (Achtung in der Wiederherstellbarkeit), nie rot und nie grün, mit der Angabe, wer die Sperre hält. Veraltete restic-Sperren werden vor der Prüfung und vor der Aufbewahrung entfernt, ein Gast wird nicht geprüft, solange ein Lauf von ihm läuft, und ein neuer Sicherungsstand wird frühestens zwei Minuten nach seinem Festschreiben geprüft. restow-pve wartet bei einer Container-Sicherung bis zu 15 Minuten auf die Sperre. Restore-Prüfungen, die vor dem Update wegen einer Sperre rot ausfielen, bleiben rot bis „Jetzt prüfen“. Gegen eine simulierte Proxmox-VE-API und einen simulierten S3-Speicher getestet, nicht gegen einen echten Cluster.
• Knoten und Agenten jetzt aktualisieren (0.4.3): Auf der Karte der Knoten und Agenten unter Installation › Updates startet „Knoten und Agenten jetzt aktualisieren“ den Schritt, in dem sie dem Server folgen, wenn kein Update in ihn geführt hat: Der Server wurde von Hand aktualisiert, oder die Antwort auf ein angekündigtes Update ging verloren. Ein Administrator mit allen Mandanten startet ihn; neue Läufe pausieren höchstens 15 Minuten, während erreichbare Knoten und Agenten, die zurückliegen, das Release installieren, sobald sie frei sind, und die Pause endet, sobald sie fertig sind (im Audit-Log als update.fleet_started mit manual: true). Außerhalb eines Updates erscheinen Knoten und Agenten, die zurückliegen, als „Update verfügbar“. Knoten mit restow-pve 0.4.1 reagieren darauf nicht und brauchen ein Update von Hand.
• Proxmox VE: restow-pve startet die Proxmox-VE-Dienste nach einer Selbstaktualisierung neu (0.4.3): Proxmox VE Preview, in jeder Edition. Nach einer Selbstaktualisierung behielten die Proxmox-VE-Dienste das alte Speicher-Plugin geladen, bis sie neu starteten. restow-pve startet pvedaemon, pveproxy, pvestatd und pvescheduler jetzt wie der Installer neu, und restow-pve update startet auch den laufenden Dienst restow-pve neu, sodass der Knoten das neue Release mit seiner nächsten Meldung angibt. Ein Knoten, den ein älteres restow-pve aktualisiert hat, startet die Dienste einmal von selbst neu. Knoten mit restow-pve 0.4.1 brauchen ein Update von Hand: /opt/restow-pve/bin/restow-pve update, danach systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler.
• Updates: Kein falsches „Der Updater läuft nicht“ mehr (0.4.3): Das Ankündigen eines Updates konnte „Der Updater läuft nicht“ melden, obwohl der Updater es wenige Sekunden später annahm. Die API wartete 5 Sekunden auf eine Antwort, während der Updater zuerst Docker, die Compose-Konfiguration, den Speicherplatz und die laufende Version prüft (5 bis 12 Sekunden auf echten Installationen); das Update lief dann ohne die Pause neuer Läufe, ohne den Audit-Eintrag update.scheduled und ohne den Schritt, in dem Proxmox-VE-Knoten und Agenten dem Server folgen. Die API wartet jetzt bis zu einer Minute und liest, wenn die Antwort weiter fehlt, den Stand des Updaters erneut und wertet das Update als angenommen, wenn der Updater es zeigt; der Reiter Updates sagt, dass er prüft, ob das Update angenommen wurde. Der Reiter sagt auch nicht mehr hin und wieder für einige Sekunden „läuft nicht“: Der Updater antwortet sofort mit seiner letzten Prüfung und prüft im Hintergrund erneut.
• Archiv-Erfassung: Microsoft 365 per Graph-Änderungsbenachrichtigungen (0.4.4): Business und Service Provider. Restow archiviert Microsoft-365-Postfächer ohne Journaling. Für jedes archivierte Postfach abonniert es Änderungsbenachrichtigungen von Microsoft Graph und holt jede neue Mail binnen Minuten nach der Zustellung (Entwürfe werden übersprungen, und unveränderliche Nachrichten-IDs verhindern, dass eine verschobene Mail doppelt archiviert wird). Ein Abgleich über alle Ordner und die wiederherstellbaren Löschungen läuft standardmäßig alle sechs Stunden und sofort nach einer verpassten Benachrichtigung; der Altbestand des Postfachs wird einmalig in fortsetzbaren Seiten übernommen und als nachträglich erfasst markiert. Es braucht keine neue Microsoft-Berechtigung. Benachrichtigungen kommen nur an, wenn die öffentliche URL der Installation https auf Port 443 ist und von Microsoft erreichbar; sonst wird jedes Postfach abgefragt, standardmäßig alle 15 Minuten, und der Erfassungsstatus nennt den Grund. Das ist zeitnahe Erfassung und nicht vollständig: Eine Mail, die endgültig gelöscht wird, bevor Restow sie geholt hat, kann fehlen, und von den wiederherstellbaren Elementen wird nur der Ordner der Löschungen gelesen. Graph kann Mail über etwa 150 MB nicht exportieren; solche Mail wird protokolliert, nicht archiviert. Restow kann nicht sehen, ob der Mandant gelöschte Mail aufbewahrt (Aufbewahrungsrichtlinie oder Litigation Hold), weil Graph v1.0 dafür keinen Lesezugriff bietet: Ein Administrator bestätigt es je Quelle auf der Archiv-Seite, die die Befehle für Exchange Online PowerShell zeigt, mit denen sich das prüfen lässt. Gegen eine simulierte Graph-API getestet, nicht gegen einen echten Microsoft-365-Mandanten.
• Archiv-Erfassung: IMAP und Google Workspace per IMAP-Abgleich mit IDLE (0.4.4): Business und Service Provider. IMAP- und Google-Workspace-Konten werden durch einen laufenden Abgleich archiviert. Die Aktivierung hält fest, wo jeder Ordner steht, der Altbestand wird einmalig übernommen (fortsetzbar, als nachträglich erfasst markiert), und jeder spätere Durchlauf liest nur neue Mail: eine Statusabfrage je Ordner, zuerst die Metadaten, und die Quelle nur von Mail, die das Archiv für das Konto noch nicht hält. Gelesen werden alle Ordner außer Entwürfen; bei Gmail und Google Workspace nur Alle Nachrichten, Spam und Papierkorb, die jede Mail genau einmal enthalten. Wo der Server IMAP IDLE anbietet, hält Restow je Konto eine Verbindung offen (standardmäßig bis zu 300 Konten je Worker) und archiviert neue Mail nach Augenblicken, mit einer Prüfung der übrigen Ordner standardmäßig alle fünf Minuten; andere Konten werden standardmäßig alle zehn Minuten abgefragt. Eine Quelle lässt sich auf „nur in Abständen prüfen“ stellen, für Anbieter mit knappem Verbindungslimit. Ändert sich UIDVALIDITY, wird der Ordner von vorn gelesen, ohne etwas doppelt zu archivieren. Das ist eine Näherung und als solche gekennzeichnet: Eine Mail, die gleich nach der Zustellung verschoben oder gelöscht wird, kann fehlen, und IMAP kennt nichts wie einen Aufbewahrungs-Hold. Gegen einen simulierten IMAP-Server und den Dovecot des Release-Smoke-Laufs getestet, nicht gegen einen echten Google-Workspace-Mandanten oder Hoster. IMAP-Quellen mit OAuth2 lassen sich weiterhin nicht anlegen; ein Google-Workspace-Konto wird deshalb an seinem Host oder seiner Ordnerliste erkannt.
• Weitergeleitete Kopien ins Archiv (0.4.4): Business und Service Provider. Für Mailsysteme ohne Exchange-Journaling schickt der Anbieter eine Kopie jeder ein- und ausgehenden Mail an Restow, während die Mail in seinem Transport ist: eine BCC-Regel in Postfix oder mailcow, ein Sieve-redirect :copy oder die Routing-Regel „Weitere Empfänger hinzufügen“ in Google Workspace. Der Journal-Empfänger nimmt solche einfachen Kopien ebenso an wie Exchange-Journalberichte. Jedes IMAP-Konto kann eine eigene Archivadresse haben (auf Anforderung ausgestellt, erneuerbar, protokolliert): Eine Kopie an sie gehört genau diesem Konto, während eine Kopie an die Journal-Adresse des Mandanten nach ihren Kopfzeilen und dem SMTP-Absender zugeordnet wird. Eine weitergeleitete Kopie hat keinen Umschlag wie ein Journalbericht; ein BCC-Empfänger ist deshalb nur sichtbar, wenn der Anbieter ihn in eine Kopfzeile schreibt. Die Kopie entsteht im Transport des Anbieters, bevor Nutzer die Mail anfassen können. Die Archiv-Seite zeigt je Konto, wie die Regel einzurichten ist (Postfix, mailcow, Sieve, Google Workspace), und ob Kopien ankommen. Gegen den Empfänger selbst getestet, nie gegen ein echtes Postfix, mailcow, einen Hoster oder Google Workspace. Der Empfänger prüft den Absender nicht (SPF).
• Ein archiviertes Element je Mail, egal über wie viele Wege sie erfasst wurde (0.4.4): Business und Service Provider. Mail, die über mehr als einen Weg ins Archiv gelangt, wird an Message-ID und Inhalt erkannt (die exakten Bytes oder ein Hash des Bodys) und einmal aufbewahrt. Eine Erfassung, die nicht stärker ist als das, was das Archiv hält, wird ein Erfassungseintrag an diesem Element; eine stärkere (etwa eine weitergeleitete Kopie nach einem IMAP-Abgleich) wird das Element und nennt das frühere, das sie ersetzt und das in der Kette unverändert bleibt. Dieselbe Message-ID mit anderem Body bleibt zweimal erhalten und wird markiert. Journalberichte und importierte Nachrichten bleiben eigene Elemente. Suche und Detail des Elements nennen weitergeleitete Kopien, nachträglich erfasste Mail und die anderen Wege, die dieselbe Mail erneut erfasst haben; ersetzte Erfassungen sind ausgeblendet, solange man sie nicht anzeigen lässt, und der Export einer Suche folgt dem. Jeder Schreiber des Archivs hängt jetzt über einen gemeinsamen Weg an und lädt das Original hoch, bevor die Sperre der Kette des Mandanten genommen wird; ein großer Report hält deshalb die übrigen Zustellungen des Mandanten nicht mehr auf.
• Mail-Job-Editor: nur die Erfassungswege, die zum Postfach passen (0.4.4): Der Editor eines Mail-Jobs erkennt die Art des Postfachs (Microsoft 365, IMAP, Google Workspace über IMAP, IMAP bei einem Microsoft-Host) und bietet nur die Erfassungswege an, die dazu passen: Microsoft Graph und Exchange-Journaling für Microsoft 365, IMAP-Archivierung und Weiterleitung für IMAP und Google Workspace. Jeder Weg ist als echt (beim Transport) oder zeitnah gekennzeichnet, mit der Edition gesperrt, die ihn enthält, und je Art ist mindestens einer nötig. Vorgabe für einen neuen Job und für einen Job, der das Archivieren einschaltet, sind Graph und IMAP-Abgleich, jeweils mit einer einmaligen Übernahme der Mail, die schon im Postfach liegt. Bei IMAP-Konten auf einem Microsoft-Host erscheint der Hinweis, stattdessen eine Microsoft-365-Quelle zu verbinden. Archivieren oder einen Weg auszuschalten fragt vorher nach: Neue Mail wird ab dann nicht mehr archiviert, das bisherige Archiv bleibt. Eine Journal-Adresse wird nur angefordert, solange Exchange-Journaling gewählt ist. Jobs, die schon vor dem Update archiviert haben, behalten für Microsoft 365 nur das Journaling und haben für IMAP- und Google-Workspace-Konten noch keinen Weg, sodass nichts Neues von selbst startet: Ein Administrator schaltet Graph oder die IMAP-Archivierung im Job ein. Das Anhalten eines Jobs hält nur seine Sicherungen nach Zeitplan an; die Archivierung läuft weiter.
• Archiv-Seite: Erfassungsstatus, Hold-Bestätigung, PowerShell-Befehle und Weiterleitungsadressen (0.4.4): Business und Service Provider. Die Archiv-Seite zeigt die Erfassung aus den Postfächern (Streams, wie neue Mail bemerkt wird und warum ein Postfach in Abständen geprüft wird, Zahlen der letzten 24 Stunden und 7 Tage, die Übernahme des Altbestands), die Erfassung je Postfach mit einem Nachholen auf Wunsch und je Microsoft-365-Quelle die Hold-Bestätigung mit den lesenden Befehlen für Exchange Online PowerShell, die ihn prüfen. Exchange-Journaling gibt es als fertige PowerShell-Befehle (Connector, Postfach für nicht zustellbare Journalberichte, Journalregel) und mit einem Warten auf den ersten Report, das alle 5 Sekunden nachsieht. Die Weiterleitung hat eine Adresse je IMAP-Konto (erzeugt, kopiert, nach einer Rückfrage erneuert), ihren Status und Anleitungen für Postfix, mailcow, Sieve und Google Workspace. Ein Hinweis, den man ausblenden kann, nennt die Mail-Jobs, in denen sich Graph oder die IMAP-Archivierung einschalten ließe, und der Erfassungsstatus listet die Jobs, die auf einen Weg warten.
• Warnungen, wenn die Archiv-Erfassung stockt (0.4.4): Business und Service Provider. Die Warnung archive.failed (Glocke, Regeln, E-Mail) meldet jetzt auch ein Postfach, dessen Erfassung seit mehr als einer Stunde im Fehler steht, ein IMAP-Konto, dessen weitergeleitete Kopien seit 24 Stunden ausbleiben, obwohl sein Job sie will, und eine Journal-Adresse ohne Reports seit 24 Stunden, jeweils nur, nachdem sie vorher empfangen hatte, und einmal je Ausfallzeitraum. Glocke und Mail sagen, um welchen Fall es geht, und führen zu seinem Abschnitt der Archiv-Seite.
• Grenzen des Journal-Empfängers und eine Archiv-Kette, die sich nicht mehr gabelt (0.4.4): Business und Service Provider. Eine SMTP-Transaktion liefert in das Archiv genau eines Mandanten; ein Empfänger eines zweiten Mandanten wird mit 452 beantwortet und vom Absender getrennt zugestellt. Die Grenze je sendender IP steigt von 60 auf 600 Verbindungen pro Minute, und eine neue Grenze je Archivadresse (300 pro Minute) antwortet mit 451. Mail an die Journal-Adresse, die kein Journalbericht ist, wird als weitergeleitete Kopie archiviert statt als unvollständiger Report. Behoben: Die Archiv-Kette konnte sich gabeln, wenn zwei Schreiber eines Mandanten ihre Elemente mit derselben Zeit stempelten. Schreiber nehmen jetzt das letzte Element in der Reihenfolge, die die Kettenprüfung abgeht (Zeit, dann ID), und stempeln ihres strikt später.
• Restore-Explorer: Große Postfächer und OneDrives öffnen sich in Millisekunden (0.4.4): Ein großes Postfach oder OneDrive im Restore-Explorer zu öffnen dauert nicht mehr Sekunden bis Minuten. Jede Ordnerliste las früher bei jeder Anfrage zweimal alle Einträge des Sicherungsstands und glich die Ordner darunter ohne Index damit ab; jetzt liest sie die Kinder des Ordners und die Ordner darunter aus zwei neuen Indizes. In einem Test mit 120.000 Nachrichten und 200.000 Dateien sank die Liste der Mail-Ordner von 2,5 s auf 15 ms, die Wurzel des Postfachs und des OneDrives von über einer Minute auf 15 ms und jeder OneDrive-Ordner von 1,5 bis 2,5 s auf etwa 10 ms; ein Ordner mit 50.000 Nachrichten listet seine erste Seite in etwa 0,5 s (vorher 1,9 s). Die Versionen, die OneDrive von einer Datei behielt, und die Monatsansicht des Kalenders lesen dieselben Indizes, und Mail-Vorschau und Anhang-Download lesen genau die Bytes eines Chunks per Range-Anfrage, statt dessen ganzes Pack von bis zu 64 MiB herunterzuladen. Sicherungsstände von 0.3.4 und früher, die der Worker noch nicht umgewandelt hat, werden wie bisher aufgelistet. Die Indizes werden während des Updates gebaut, das auf einer großen Installation länger dauert (siehe die Hinweise zum Update).
• Proxmox VE: Der Job-Dialog passt auf einen Desktop-Bildschirm (0.4.4): Proxmox-VE-Preview, in jeder Edition. Der Job-Dialog für Proxmox VE ist doppelt so breit und ordnet seine Einstellungen ab Tablet-Breite in zwei Spalten an (Name und Zeitplan mit den nächsten Läufen links; Umfang, Sicherungsstände, Restore-Prüfung, Startprüfung und Gäste rechts), sodass die Einstellungen eines Jobs ohne Scrollen auf einen Desktop-Bildschirm passen. Auf einem Telefon bleibt es eine Spalte in voller Breite.
• Lizenzschlüssel mit Update-Zeitraum (0.4.5): Business und Service Provider. Ein Lizenzschlüssel kann die Bedingungen seiner Updates tragen: einen Update-Zeitraum (updates_until) und eine Serie. Ein Schlüssel mit Update-Zeitraum deckt jedes Release ab, das bis zum Ende dieses Tages (UTC) erstellt wurde, gleich welche Version es hat. Ein Schlüssel ohne Zeitraum deckt eine ganze Serie ab: Das Schlüsselformat restow-license-v1 nennt sie, und ein Schlüssel ohne Serie zählt als Serie 1, die auch jedes 0.x-Release abdeckt. Jeder bisher ausgestellte Schlüssel ist eine Beta-Lizenz: Er trägt keines der beiden Felder und deckt dauerhaft jedes 0.x- und 1.x-Release ab. Das Schlüsselformat nimmt die neuen Felder als optional und ignoriert Felder, die es nicht kennt, sodass Schlüssel, die der Lizenzserver später ausstellt, weiter verifiziert werden; die sechs Felder von heute bleiben Pflicht und behalten ihre Regeln. Ein Schlüssel kann außerdem den Signaturschlüssel des Herstellers nennen, mit dem er signiert wurde (kid), damit sich ein Signaturschlüssel wechseln lässt, ohne ausgestellte Schlüssel zu brechen. Schlüssel mit den neuen Feldern werden erst ab 0.4.5 verifiziert. Schlüssel werden weiterhin offline geprüft: Restow kontaktiert keinen Lizenzserver, und nichts hält an, solange es läuft, denn ein Schlüssel hat kein Ablaufdatum, nur Releases, die er abdeckt, und Releases, die er nicht abdeckt.
• Das Image trägt sein Release-Datum (0.4.5): Jedes Image trägt das Datum seines Releases (RESTOW_RELEASED_AT, das Commit-Datum des Release-Tags), und GET /api/v1/status meldet es als releasedAt. Die Release-Notes veröffentlichen dasselbe Datum in einer Zeile released: neben den Digests der Images; so kennt die Update-Prüfung das Datum eines Releases, bevor sie etwas installiert. Lizenzschlüssel mit Update-Zeitraum werden an diesem Datum gemessen.
• Update-Prüfung und Start beachten den Update-Zeitraum (0.4.5): Business und Service Provider. Die Update-Prüfung markiert die Releases, die der installierte Business- oder Service-Provider-Schlüssel nicht abdeckt, und sagt das ruhig auf der Seite Updates: Die installierte Version arbeitet weiter, und die neueste abgedeckte Version lässt sich wie gewohnt installieren. Restow lehnt es ab, ein nicht abgedecktes Release zu installieren oder zu planen (409 update-not-covered), und die Glocke und die Alarmregeln update.available kündigen nur das neueste abgedeckte Release an. Ein Release, das von Hand an der Update-Prüfung vorbei gestartet wird und das der installierte Schlüssel nicht abdeckt, hält vor seinen Datenbankmigrationen an, mit einer Logzeile, die die Version, das Ende des Update-Zeitraums und das Datum des letzten abgedeckten Releases nennt; zum Zurückgehen muss nichts wiederhergestellt werden, und der optionale Updater setzt die vorherige Version von selbst zurück. Mit RESTOW_RUN_AS_COMMUNITY=1 startet es stattdessen als Community: Die Module bleiben aus, und es werden keine Daten verändert. Nie bei Beta-Lizenzen, Entwicklungs-Builds, Installationen ohne Schlüssel oder der öffentlichen Demo.
• Lizenzseite: Update-Bedingungen, Hinweis vor dem Ende und Verlängerung (0.4.5): Business und Service Provider. Die Lizenzseite zeigt, welche Updates der installierte Schlüssel enthält („Updates: alle 1.x (Beta-Lizenz)“ oder „Updates: bis“ mit dem Datum), und ab 30 Tage vor dem Ende des Zeitraums und danach einen kurzen Hinweis auf derselben Seite; es wird keine E-Mail verschickt. Ein neuer Schlüssel ersetzt den aktiven, auch solange dieser gilt, und so wird eine Verlängerung eingespielt: Frühere Schlüssel bleiben im Verlauf, und jede Installation oder jeder Austausch steht im Audit-Log mit den Update-Bedingungen des Schlüssels und der Angabe, ob sie die laufende Version abdecken. Ein Schlüssel, der die laufende Version nicht abdeckt, wird abgelehnt (outside_update_period), ebenso ein Schlüssel, der mit einem Signaturschlüssel des Herstellers signiert ist, den diese Version noch nicht kennt (unknown_signing_key): erst aktualisieren, dann installieren.
• Öffentliche Demo: schneller nächtlicher Reset (0.4.5): Die öffentliche Demo setzt sich aus einer gespeicherten Vorlage zurück, statt neu zu befüllen. Nach einer vollständigen Befüllung speichert deploy/demo/reset.sh eine Vorlage (einen Dump der Demo-Datenbank, ihre Rollen und eine Kopie jedes Volumes, das die Befüllung schreibt), die an das Release, die Image-IDs und die .env gebunden ist, und spielt sie in den folgenden Nächten ein, sodass die Demo etwa 15 bis 25 Sekunden statt vieler Minuten offline ist. Beim Einspielen rückt jede Systemzeit um das Alter der Vorlage vor, sodass die Historie weiter heute endet und „letzte Sicherung vor 12 Minuten“ stimmt; das Audit-Log, das Mail-Archiv und die eigenen Snapshot-Zeiten von restic behalten ihre echten Zeiten, und Anmeldungen werden entfernt. Eine Vorlage, die älter als 7 Tage ist (einstellbar), ein neues Release, neue Images, eine geänderte .env oder ein fehlgeschlagenes Einspielen führen zu einer vollständigen Befüllung. Die Gesundheitsprüfungen der Dienste der Demo laufen alle 2 bis 5 statt alle 10 bis 15 Sekunden, sodass ein Reset weniger auf Dienste wartet, die schon bereit sind. Das betrifft nur die öffentliche Demo, keine Installation.
• Einen gesperrten Rechner aus Restow entfernen, mit oder ohne seine Sicherungen (0.4.5): Ein gesperrter Rechner lässt sich aus Restow entfernen. „Aus Restow entfernen“ in seinem Gefahrenbereich bietet „Aus der Liste entfernen, Sicherungen bis zum Ablauf behalten“ (die neueste Sicherung plus die längste Regel der Aufbewahrung des Rechners, als Zeit gelesen) oder „Rechner und seine Sicherungen löschen“, mit eingetipptem Hostnamen und einer jungen Anmeldung. Der Rechner verschwindet aus jeder Liste, Auswahl, Übersicht und Zählung und aus seinem Backup-Job; seine Läufe, Berichte und Audit-Einträge bleiben. Der Worker löscht das restic-Repository des Rechners auf jedem Ziel, das Dateien von ihm hält: dem primären, seinen Kopien und ausgemusterten primären. Sofortiges Löschen wird abgelehnt, solange eine Legal Hold über dem Mandanten oder ein ungeklärter verdächtiger Sicherungsstand die Sicherungen hält, und der Worker wartet auf eine solche Hold, wenn die Sicherungen ablaufen. Objekte, die der Speicher noch sperrt (S3 Object Lock, die Löschverzögerung eines Verzeichnisses), werden zurückgestellt, bis ihre Sperre abläuft, und wie eine abgelehnte Bereinigung festgehalten. Die Rechnerseite listet die noch offenen Entfernungen mit dem Datum, der Hold oder der Sperre. Jeder Schritt wird protokolliert. Die Migration 0064 fügt den Entfernungszustand zu den Rechnern hinzu.
• Einen verschwundenen Rechner sperren, und ein Vorschlag dazu (0.4.5): Eine Deinstallation, die auf einen ausgeschalteten Rechner wartet, bietet jetzt „Jetzt sperren“ an, und ein Rechner, der sich länger als eine einstellbare Zahl von Tagen nicht gemeldet hat (standardmäßig 30, unter Alarme des Rechners), schlägt vor, ihn zu sperren, auf seiner Seite und unter dem, was Aufmerksamkeit braucht. Der Detailbereich des Rechners im Inventar zeigt den Vorschlag als Zustand und bietet „Jetzt sperren“ an und, sobald der Rechner gesperrt ist, auch „Aus Restow entfernen“.
• Warnung, wenn ein Verzeichnis-Repository auf der Systemplatte liegt (0.4.5): Restow warnt, wenn ein Verzeichnis-Repository auf der Systemplatte des Restow-Servers liegt, der Platte unter Betriebssystem, Docker und Datenbank: Eine volle Systemplatte hält alles an, nicht nur die Sicherungen. Die API erkennt das aus ihrem Container heraus am Gerät und am Blockgerät des Pfads, einschließlich des Installationsstandards und der Freigaben des Mounters. Die Warnung steht auf der Seite Repositories, in der Zeile „Sicherungen landen in:“ der Job-Editoren und auf der Speicherkachel des Dashboards, wo Provider-Admins außerdem den freien Platz, seinen Verlauf über die letzte Woche und den Zeitpunkt sehen, an dem die Platte voll wäre. Die API beobachtet jetzt außerdem die Systemplatte auf wenig Speicherplatz. Nichts wird blockiert.
• Microsoft-365-Gruppen als geschützte Objekte: Kalender und Unterhaltungen (0.4.5): Kalender und Unterhaltungen von Microsoft-365-Gruppen und der Gruppen hinter Teams sind geschützte Objekte einer eigenen Art, group. Der Verzeichnisabgleich liest groups/delta als zweiten Delta-Strom neben den Benutzern (eine vollständige Aufzählung beim ersten und bei jedem vollständigen Abgleich, dazwischen nur Änderungen), behält nur Microsoft-365-Gruppen (Sicherheits- und Verteilergruppen haben kein Gruppenpostfach) und verwaist entfernte, deren Sicherungsstände bleiben. Gruppen sind Opt-in: Die Schutzregeln bekommen einen Schalter „Alle Microsoft-365-Gruppen schützen“ (standardmäßig nur ausgewählte Gruppen, also keine, solange Sie sie nicht in die Liste der geschützten Objekte aufnehmen), und einzelne Gruppen lassen sich dort einschließen. Ein Mail-Job mit Umfang „alle“ deckt jede geschützte Gruppe ab, wie Websites. Gruppenpostfächer zählen nie als geschützte Postfächer. Die Migration 0065 fügt die Objektart hinzu. Nach dem Update wird keine Gruppe gesichert, bis die Schutzregeln es einschalten oder Gruppen eingeschlossen werden; der erste Verzeichnisabgleich liest die Gruppen jeder Microsoft-365-Quelle einmal vollständig.
• Gruppenkalender und Unterhaltungen: was ein Backup enthält (0.4.5): Das Backup einer Gruppe enthält ihren Kalender, gelesen vom selben Kalender-Code wie der eines Benutzers (Serienmaster mit ihren Ausnahmen), und jeden Beitrag jeder Unterhaltung, gespeichert als RFC-5322-Nachricht unter mail/Conversations, mit ihren Dateianhängen, wenn Graph sie herausgibt (sonst wird ihr Fehlen festgehalten). Verweigert Graph der App die Ereignisliste eines Gruppenkalenders, fällt Restow auf die calendarView der Gruppe und einen Lesevorgang je Serienmaster zurück; ein Kalender, den Graph ganz verweigert, ist eine Warnung am Lauf, kein Fehler. Nur Threads mit neuen Beiträgen werden erneut gelesen. Eine Gruppe, die es nicht mehr gibt, scheitert mit der neuen Ursache graph.group_unavailable. Es braucht keine neue Microsoft-Berechtigung: Group.Read.All und Calendars.ReadWrite waren immer erforderlich. Gegen eine simulierte Graph-API getestet, nie gegen einen echten Microsoft-365-Mandanten: Welche Kalenderzugriffe Graph einer App auf eine Gruppe erlaubt, kann je Mandant abweichen, und das Backup meldet, was es nicht lesen konnte.
• Gruppenkalender und Unterhaltungen: Restore, Download und Export (0.4.5): Der Restore-Explorer listet Gruppen im Abschnitt „SharePoint und Teams“ mit den Bereichen „Gruppenkalender“ und „Unterhaltungen“; Download (EML, JSON) und Export (EML, MBOX, PST) funktionieren wie bei Postfächern. Ein Restore in das Postfach eines Benutzers bringt Ereignisse und Unterhaltungen zurück, die Unterhaltungen als Mail in einen Ordner Conversations. Ein Restore in die Gruppe selbst bringt nur Kalenderereignisse zurück, weil Microsoft Graph keiner App erlaubt, in eine Gruppenunterhaltung zu schreiben: Jeder Beitrag wird als nicht wiederherstellbar gemeldet, mit den Wegen, die funktionieren. Die Wiederherstellung einer Gruppe ist keine Stellvertretung, weil eine Gruppe keiner Person gehört. Die Integrations-API meldet lastSuccess.groups, und ObjectKind enthält group (Vertrag 1.6.0, additiv: Clients, die Objektarten erschöpfend behandeln, sollten den neuen Wert akzeptieren), und das Dashboard führt Gruppenkalender und Unterhaltungen unter den letzten Sicherungen auf.
• Jetzt starten und Stoppen an jedem Job (0.4.5): Beide Joblisten, Server & Clients und Mail & SaaS, haben „Jetzt starten“ und „Stoppen“ in jeder Zeile und im „…“-Menü der Zeile: eine Schaltfläche fester Größe, die „Jetzt starten“ sagt, „Stoppen“, solange die Sicherungen des Jobs laufen oder warten, und „Wird gestoppt…“, sobald gestoppt wurde. Das Stoppen fragt vorher nach und sagt, was es für die Art des Jobs bedeutet. „Jetzt ausführen“ heißt jetzt „Jetzt starten“. Neue API-Routen: POST /api/v1/backup-jobs/:id/cancel (jede wartende oder laufende Sicherung eines Mail-, Rechner-, Freigaben- oder Kopierjobs in einer Anfrage), POST /api/v1/pve/jobs/:id/run (eine Sicherung jedes Gastes, den ein Proxmox-VE-Job (Preview) abdeckt, wie sein Zeitplan es täte, ohne den Zeitplan zu verschieben) und POST /api/v1/pve/jobs/:id/cancel. Alle werden protokolliert, sind für Mandanten-Administratoren und Provider-Rollen, die bedienen dürfen, und sind in der öffentlichen Demo gesperrt.
• Detailbereiche im Inventar und in den Joblisten (0.4.5): Das Inventar und die Joblisten öffnen einen Detailbereich wie den von VMs & Container: Ein Klick auf eine Zeile, ihren Namen oder ihren Zustand öffnet ihn (?machine=<id> im Inventar, ?job=<id> in den Joblisten, sodass ein Link ihn öffnet). Er listet jeden Zustand, die vollständigen Fehler- und Warntexte der neuesten Sicherung oder des fehlgeschlagenen Laufs in einem kopierbaren Block mit fester Schriftbreite (bei einem Rechner auch das Ende des Protokolls), was Aufmerksamkeit braucht, die Restore-Prüfungen, die wichtigsten Angaben, die neuesten Läufe und die Aktionen. Die Tabellen behalten ihr Layout wie VMs & Container: feste Spaltenbreiten, eine Zeilenhöhe (auch bei ladenden Zeilen), ein kompaktes Zustandsabzeichen je Zeile (das dringendste von dem, was zutrifft; grün nur bei bestandener Restore-Prüfung) mit dem Fortschritt einer laufenden Sicherung daneben, einzeilige Zellen ohne Tooltips und Aktionsschaltflächen einer Größe. Spalten, die nicht auf einen Bildschirm passen, weichen von rechts; der Bereich hat alles.
• Abhängigkeiten: Übersetzungsbibliotheken und der Microsoft-Token-Code (0.4.5): Größeres Update der Übersetzungsbibliotheken, i18next 26 und react-i18next 17, gemeinsam aktualisiert; Texte, Plurale sowie Zahlen- und Datumsformate lesen sich in Englisch und Deutsch genau wie vorher. @azure/msal-node ist keine Abhängigkeit mehr, weil es nichts verwendete: Die App-Token für Microsoft 365, die Admin-Zustimmung und die IMAP-OAuth2-Anmeldung nutzen den eigenen Token-Client von Restow, unverändert.
• Korrekturen: Anhänge-Ordner im Restore-Explorer, Job-Dialog von Proxmox VE auf dem Telefon, Demo-Reset (0.4.5): Im Restore-Explorer zeigt eine Mail, die als JSON gespeichert ist (zu groß für eine einfache Nachricht), neben sich keinen leeren Ordner <Betreff>.attachments mehr: Ihre Anhänge werden mit der Nachricht wiederhergestellt und wurden nie aufgelistet, und die Ordnerzeile, die das Backup dafür festhält, ist jetzt aus der Liste, dem Ordnerbaum und der Suche ausgeblendet. Der Job-Dialog von Proxmox VE (Preview) stapelt seine drei Felder für Sicherungsstände auf dem Telefon (390 px), sodass „Monatliche Sicherungsstände“ nicht mehr über den Rand des Dialogs läuft. Das Reset-Skript der öffentlichen Demo liest RESTOW_DEMO_COMPOSE_FILES jetzt aus deploy/demo/.env, wie es die README immer sagte, und lehnt Einträge, die keine Compose-Dateien sind, ab, bevor etwas angehalten wird.
• Prüfung von Entra-Tenant und IMAP-OAuth2-Geheimnis (0.4.5): Der Einrichtungsassistent akzeptiert den Entra-Tenant für Graph-Mail nur als Tenant-ID (GUID) oder verifizierte Domain, wie es die Einstellungen schon taten; alles andere wird abgelehnt (422), bevor es die Token-URL erreichen kann. Die URL war nie für einen anderen Host offen (der Wert ist URL-kodiert, der Anmeldehost fest), aber ein Wert wie .. änderte ihren Pfad. Ein IMAP-OAuth2-Geheimnis wird abgelehnt, wenn seine tenantId nicht eine Tenant-ID, eine verifizierte Domain, common, organizations oder consumers ist und sein tokenEndpoint keine https-URL. Weder die API noch die Oberfläche legt solche Geheimnisse bisher an; die Token-Anfrage braucht außerdem die Adressrichtlinie der IMAP-Verbindungen, bevor XOAUTH2 angeboten wird.
• Proxmox VE: Der Restore eines Containers funktioniert auf aktuellem Proxmox VE (0.4.6): Proxmox VE Preview, in jeder Edition. Der Restore eines Containers aus Restow scheiterte auf aktuellem Proxmox VE mit Can’t use string (“restow”) as a HASH ref, das die Storage-ID vor dem Info-Hash an den Container-Restore des Backup-Providers übergibt. Startprüfungen von Containern („Nicht gestartet“) und „Als neuen Gast wiederherstellen“ von Containern waren betroffen; VMs nicht. Das Plugin von restow-pve akzeptiert jetzt beide Formen; es wird mit dem Update von restow-pve installiert, das die PVE-Dienste neu lädt. Aktualisieren Sie restow-pve auf jedem Proxmox-VE-Knoten, bevor Sie sich auf Container-Restores oder Startprüfungen verlassen (der Server bietet es nach seinem eigenen Update an, und Knoten aktualisieren sich selbst, wenn sie frei sind); bis dahin scheitern sie weiter wie zuvor. Für Sicherungsstände von Containern, die „Nicht gestartet“ zeigen oder eine fehlgeschlagene Restore-Prüfung aus der Zeit vor 0.4.3 haben, führen Sie „Jetzt Start prüfen“ oder „Jetzt prüfen“ aus, sobald der Knoten aktualisiert ist. Mit Perl-Tests des Plugins getestet (der Container-Restore mit und ohne Storage-ID); vor dem Release nicht gegen einen echten Proxmox-VE-Knoten ausgeführt.
• Ransomware-Erkennung: Eine neue Sicherungskette wird nicht mehr markiert (0.4.6): Proxmox VE Preview, in jeder Edition. Die erste Sicherung der neuen Sicherungskette 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 Vergleichsbasis beginnt jetzt mit der neuesten Kette. Ein Sicherungsstand, der vor dem Update so markiert wurde, bleibt markiert: Markieren Sie ihn als Fehlalarm. Die erste Sicherung einer neuen Kette heißt außerdem „Erste Sicherung“, nicht „Inkrementell“.
• Entfernte Rechner behalten ihre Sicherungen durchsuchbar (0.4.6): Bis ihre Sicherungen gelöscht sind, bietet die Seite eines entfernten Rechners deren Wiederherstellung an und sonst nichts: Die Sicherungsstände, das Durchsuchen, der ZIP-Download und der Repository-Schlüssel funktionieren für sie weiter, protokolliert wie bisher. Die Liste der entfernten Rechner verlinkt „Dateien wiederherstellen“. Das Wiederherstellen auf den Rechner und jede andere Aktion bleiben abgelehnt (404); sobald die Sicherungen gelöscht sind, ist der Rechner für jeden Leser weg. Vor 0.4.6 bot die Oberfläche die Sicherungen, die ein entfernter Rechner bis zum Ablauf behält, nicht an; seit 0.4.6 tut sie es.
• „Prüfung eingereiht“, solange eine Restore-Prüfung wartet (0.4.6): Proxmox VE Preview, in jeder Edition. Nach „Jetzt prüfen“ bei einer VM oder einem Container steht in der Zeile „Prüfung eingereiht“ unter der letzten Prüfung und auf der Seite des Gastes über dem früheren Ergebnis, bis das Ergebnis da ist; beide aktualisieren sich währenddessen alle paar Sekunden.
• Fehlertexte öffnen sich in einer Karte, die sich kopieren lässt (0.4.6): Proxmox VE Preview, in jeder Edition. Fehlertexte hinter einem Abzeichen 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) öffnen sich bei Hover oder Tastaturfokus in einer Karte mit dem ganzen Text, markierbar und mit einer Schaltfläche Kopieren, statt in einem Browser-Tooltip. Eine Startprüfung, die nicht gestartet ist, zeigt die Meldung des Knotens unter ihrem Abzeichen, auf der Seite des Gastes und in der Tabelle der Wiederherstellbarkeit.
• Microsoft 365: Deaktivierte, unlizenzierte und gesperrte Objekte stehen als „Nicht gesichert“, mit Grund (0.4.7): Ein Postfach, dessen Konto deaktiviert ist oder keine Exchange-Online-Lizenz hat, lässt seine Sicherung nicht mehr jede Nacht mit „Microsoft hat die Anfrage abgelehnt“ scheitern. Die Sicherung fragt Microsoft einmal, ob der Benutzer existiert, aber kein Postfach hat, markiert das Postfach „Nicht gesichert: Konto deaktiviert“ oder „Nicht gesichert: keine Lizenz“ und endet neutral: keine Fehlerzählung, kein Rot wegen des Alters, nicht überfällig, keine Warnung backup.failed und kein Webhook job.failed, vorhandene Sicherungen bleiben erhalten. Der Verzeichnisabgleich setzt denselben Zustand aus seiner Postfach-Probe. Nur die Antwort von Exchange zählt: Ein deaktiviertes Konto, dessen Postfach Microsoft noch bereitstellt (ein geteiltes Postfach, eine ausgeschiedene Person), wird wie bisher gesichert, und ein 401 oder 403 wird nie so gelesen. Dasselbe gilt für ein OneDrive oder eine SharePoint-Website, die Microsoft gesperrt hat (HTTP 423, was Microsoft mit dem OneDrive eines Kontos ohne Lizenz tut): Sobald eine einzige billige Leseanfrage die Sperre bestätigt, steht dort „Nicht gesichert: gesperrt“, der Lauf endet ohne Wiederholungen, und das Objekt wird nicht mehr eingeplant; der Verzeichnisabgleich nimmt es erst wieder auf, wenn eine Leseanfrage auf das Laufwerk oder die Website wieder gelingt. Die Sicherung läuft von selbst weiter, sobald der Verzeichnisabgleich das Konto wieder aktiviert oder lizenziert findet. Ein Restore in das ursprüngliche Postfach wird mit dem Grund abgelehnt. Gegen eine simulierte Microsoft-Graph-API getestet, nicht gegen einen echten Microsoft-365-Mandanten.
• Nicht mehr gesichert, bitte bestätigen (0.4.7): Objekte, die Restow nicht mehr sichert, weil die Quelle sie als entfernt, deaktiviert, ohne Lizenz oder gesperrt meldet, stehen zuerst gelb als „Nicht mehr gesichert, bitte bestätigen“, mit Grund und Datum. Das ist kein Fehler, kein Rot und nicht überfällig, aber die Warnungen, das Dashboard und die Bereitschaft des Mandanten bleiben mindestens gelb (nie grün), die Integrations-API zählt sie in readiness.toConfirm, und Provider sehen inactive_to_confirm unter den Warnungen eines Mandanten, bis ein Administrator mit „Ja, beabsichtigt“ bestätigt: je Objekt oder für mehrere in der Liste, per Auswahl oder über den Filter der Liste (höchstens 1000). Mandanten-Administratoren und Provider-Teams mit Konfigurationsrecht dürfen bestätigen, und jede Bestätigung wird im Audit-Log festgehalten; über die API kann sie eine Notiz für das Audit-Log tragen. Bestätigte Objekte stehen grau als „Absichtlich nicht mehr gesichert“, mit dem Namen dessen, der bestätigt hat, und dem Zeitpunkt. Wird das Objekt wieder aktiv, entfällt die Bestätigung, und die Sicherung läuft weiter; hört es später wieder auf, fragt Restow erneut. Ein ausgeschlossenes Objekt, das aus der Quelle verschwindet, wurde nie gesichert und gilt als bestätigt. Die Liste der geschützten Objekte filtert nach to_confirm und confirmed. Die neuen Ereignisse object.inactive (ein Hinweis je Objekt und Übergang, standardmäßig in der Glocke) und object.inactive_many (eine Warnung je Mandant und Tag, wenn mehr als 10 Objekte oder mehr als 20 Prozent der zuvor gesicherten Objekte innerhalb eines Tages ausfallen) gehören zur Benachrichtigungsmatrix; ein Webhook bekommt sie als report.alert, sobald sie dort angehakt sind. Objekte, die schon vor dem Update verwaist waren, gelten als bestätigt, damit keine lange gelbe Liste entsteht. Migration 0069 speichert den Zustand.
• Integrations-API 1.7.0: orphaned heißt jetzt auch „nicht mehr gesichert“ (0.4.7): Die einzige inkompatible Änderung des Releases: Der Status „orphaned“ in GET /api/v1/objects, GET /api/v1/users, im object von GET /api/v1/jobs und in objects.orphaned von GET /api/v1/status umfasst jetzt auch Objekte, die noch in der Quelle stehen, aber nicht mehr gesichert werden (Konto deaktiviert, keine Lizenz oder von Microsoft gesperrt); vorher hieß er „aus der Quelle entfernt“. Das neue statusReason (account_disabled, no_license, locked, null für ein aus der Quelle entferntes Objekt) unterscheidet sie, eine Integration, die orphaned als gelöschtes Konto behandelt, sollte es also prüfen, bevor sie handelt. Alles andere im Vertrag wächst additiv: inactiveSince und statusConfirmedAt an Objekten, toConfirm in der Bereitschaftszusammenfassung von status und verify/latest, eine recoveryReadiness eines Benutzers, die mindestens gelb zeigt, solange eines seiner Objekte auf eine Bestätigung wartet, ausgeschlossene Proxmox-VE-Gäste als guests.excluded (außerhalb von guests.total und guests.withoutJob), der Überspringgrund inactive für POST /api/v1/jobs/backup, data.job.result an den Webhooks job.completed und job.failed eines Restores und die neuen Alarm-Ereignisse. Clients, die Überspringgründe oder Ereignisnamen abschließend behandeln, sollten die neuen Werte akzeptieren.
• Sicherungen, die Microsoft Graph oder der Speicher gebremst haben, zählen nicht mehr als fehlgeschlagen (0.4.7): Eine Mail-&-SaaS-Sicherung, die nach allen Wiederholungen mit graph.throttled, graph.service_unavailable oder storage.rate_limited endet, steht in jeder Ansicht gelb als „Vom Dienst gedrosselt, wird wiederholt“ statt rot als „Fehlgeschlagen“: im Verlauf, in der Job-Übersicht aller Mandanten, in der Objektliste, in den Läufen eines Jobs, auf der Job-Seite, im Dashboard und in den Lauf-Details. Sie fällt aus den Fehlerzahlen der Statistik und des Dashboards heraus, lässt den Job nicht als fehlerhaft gelten (der Lauf davor zählt), macht keine Warnung rot und beendet keine Bestätigung, und sie löst keine Warnung backup.failed und keinen Webhook job.failed aus. Der nächste geplante Lauf versucht es erneut, und ein Objekt, das länger gebremst wird, fangen die Regeln für überfällige Sicherungen und die Bereitschaft auf, die das Alter der neuesten Sicherung ansehen. Ein Restore, Export, Import oder eine Prüfung, die ein Dienst gebremst hat, hat keinen nächsten Lauf und bleibt ein Fehler. Frühere Läufe, die mit diesen Ursachen endeten, zeigen nach dem Update dasselbe und fallen aus den Fehlerzahlen vergangener Zeiträume. Ein Hintergrund-Job beachtet außerdem ein Retry-After von bis zu 5 Minuten (vorher waren Wartezeiten auf etwa eine Minute begrenzt, und Exchange lehnt einen Wiederholungsversuch ab, bevor seine Strafe für gleichzeitige Postfachzugriffe vorbei ist); Anfragen aus der Oberfläche behalten die Grenze von einer Minute.
• Eine der Microsoft-365-App erteilte Berechtigung wirkt ohne neues Client-Secret (0.4.7): Ein Token trägt die Berechtigungen der App so, wie sie bei seiner Ausstellung waren, und Restow behielt es bis kurz vor seinem Ablauf (bis zu etwa einer Stunde); eine Berechtigung, die ein Administrator zwischendurch erteilte, wurde deshalb bis dahin oder bis zur Eingabe eines neuen Secrets abgelehnt. Antwortet Graph mit 401 oder 403, holt Restow jetzt einmal ein neues Token und sendet die Anfrage erneut, höchstens einmal je Minute und Mandant oder Quelle, sodass eine Reihe von Ablehnungen (ein Element, das die App nicht lesen darf) nicht jedes Mal ein Token holt; abgelehnte Teilanfragen eines $batch werden ebenfalls einmal erneut gesendet. Eine Anfrage, die mit dem neuen Token wieder abgelehnt wird, scheitert wie bisher. Das gilt für Sicherungen, Restores, den Verzeichnisabgleich, die Archiv-Erfassung, die Gruppensuche, den Verbindungstest und die Prüfung der Zustimmung. Ein Token-Endpunkt, der nicht erreichbar ist, wird noch zweimal gefragt (nach 1 und 4 Sekunden) und lässt dann den Lauf scheitern, der von seinem Prüfpunkt aus weiterläuft, statt jedes Element als fehlgeschlagen zu verbuchen. Benachrichtigungs-Mail über eine App-Registrierung holt nach einer Ablehnung noch kein neues Token: Eine später erteilte Berechtigung Mail.Send wirkt, sobald das zwischengespeicherte Token abläuft.
• Eine wartende Sicherung blockiert nicht mehr die Sicherungswarteschlange aller Mandanten (0.4.7): Eine wartende Sicherung eines Objekts, dessen Sicherung noch lief (der nächste geplante Lauf, „Jetzt sichern“), blockierte die Sicherungswarteschlange aller Mandanten, bis diese Sicherung endete, weil die Job-Warteschlange sie immer zuerst anbot und nichts herausgab. Ein solcher Job wartet jetzt auf die laufende Sicherung seines Objekts und lässt jede andere Sicherung vorbei. Restow liefert dafür pg-boss 10.4.2 mit einem eigenen Patch aus; die Images tragen ihn, und wer aus dem Quellcode baut, behält den Ordner patches.
• Erinnerungen, bevor das Client-Secret oder das Zertifikat einer App-Registrierung abläuft (0.4.7): Restow erinnert Provider-Administratoren 30 Tage, bevor das Client-Secret oder das Zertifikat der zentralen Microsoft-365-App-Registrierung abläuft, erneut 7 Tage vorher und nach dem Ablauf, jede Stufe einmal je Ablaufdatum; das Ereignis installation.app_secret_expiring ist eine Warnung, nach dem Ablauf ein Fehler. Eine Quelle, die über eine eigene App-Registrierung verbunden ist, bekommt dieselben Erinnerungen als source.app_secret_expiring, das auch Mandanten-Administratoren wählen können. Das Datum ist das unter Installation › Microsoft-Multi-Tenant-App eingetragene (ENTRA_CLIENT_SECRET_EXPIRES_AT bei einem Secret aus der Umgebung), das „Secret läuft ab am“ der eigenen App einer Quelle oder das Ende des Zertifikats selbst; Restow liest es nicht aus Microsoft Graph, das bräuchte Application.Read.All. Bei einer Quelle zeigt die Verbindungskarte „Läuft ab“, und das Datum lässt sich dort eintragen, ändern oder entfernen, ohne das Secret erneut einzugeben. Ein neues Datum, ein neues Secret oder ein neues Zertifikat beginnt die Erinnerungen von vorn. Die Glocke nennt die Stufe („läuft in 5 Tagen ab“, „Bitte jetzt erneuern“, „sind abgelaufen“), und die Mail nennt das Datum, die verbleibenden Tage und die Anwendungs-ID und sagt, wie sich ohne Lücke erneuern lässt: das neue Secret anlegen, mit seinem neuen Datum eintragen, erst dann das alte in Entra löschen. Das Ablauf-Abzeichen wird 30 Tage vor dem Ende gelb statt bei 60 und ab 7 rot. Quellen, die vor 0.4.7 über eine eigene App verbunden wurden, haben noch kein Datum: Tragen Sie es auf der Seite der Quelle ein.
• Postfach, OneDrive, SharePoint und IMAP: Ein Fehler kostet einen Bereich oder ein Element, nicht den ganzen Lauf (0.4.7): Postfach-Sicherung: Ein 403 für Kalender oder Kontakte (fehlende Berechtigung, eine Zugriffsrichtlinie, die nur Mail abdeckt) lässt diesen Bereich scheitern und behält die Mail des Laufs, statt den Sicherungsstand zu verwerfen; ein 401 mitten im Lauf setzt einen Prüfpunkt und läuft weiter; ein bekannter Ordner, den Graph nicht auflösen will, gilt als nicht vorhanden; ein Delta-Link, den Graph als ungültigen Sync-Zustand ablehnt, führt zu einem vollständigen Neuabgleich; eine Nachricht, die Exchange nicht in MIME umwandeln kann, wird wie eine übergroße als JSON mit ihren Anhängen gespeichert; ein Unterordner, der gelöscht wurde, während sein Elternordner aufgelistet wurde, lässt den Lauf nicht mehr scheitern. SharePoint: Eine Bibliothek oder Liste, die Graph nicht herausgibt, ist ein Elementfehler, der ihre letzte Kopie behält, und der Rest der Website bekommt seinen Sicherungsstand. OneDrive und SharePoint: Ein Element, das scheiterte und später im selben Lauf durchkam, bleibt nicht mehr unter den Fehlern, und ein OneDrive, dessen Laufwerk Graph nicht mehr findet, scheitert als „OneDrive nicht verfügbar“, dauerhaft und ohne Wiederholung. IMAP-Sicherung: Eine Anmeldung, die der Server vorerst ablehnt (zu viele Verbindungen, ein ausgefallenes Anmelde-Backend), und eine Download-Grenze sind die neue vorübergehende Ursache imap.server_limit, die von selbst wiederholt wird, statt eines falschen Passworts oder eines vollen Postfachs; während der Sicherung gelöschte oder verschobene Nachrichten zählen nicht als Fehler. IMAP-Archiv-Erfassung: Eine Nachricht, die der Server ablehnt, hält ihren Ordner oder den ganzen Durchgang nicht mehr auf (nach drei Durchgängen gibt die Erfassung sie auf), und Ordner, die ein Durchgang nicht erreichte, behalten ihren Stand. Jeder $batch von Graph sendet außerdem eine identische Leseanfrage nur einmal, sodass eine doppelte Request-ID keinen Batch mehr scheitern lässt, und eine Verbindung, die vor der Antwort von Graph abbrach, wird bei Leseanfragen wiederholt.
• Restores, die nichts wiederhergestellt haben, werden nicht mehr als abgeschlossen gemeldet (0.4.7): Ein abgeschlossener Restore mit fehlgeschlagenen Elementen und keinem wiederhergestellten steht als „Nichts wiederhergestellt“ (rot) da und löst restore.failed und den Webhook job.failed aus, mit „Nothing was restored: N items failed.“ als Fehlertext. Einer, der jedes Element übersprungen hat, steht als „Alles übersprungen“ (gelb) da und bleibt restore.completed, sagt das aber, statt zu behaupten, er habe etwas wiederhergestellt (in Chat-Kanälen Info, nicht Erfolg). Die Webhooks job.completed und job.failed eines abgeschlossenen Restores tragen seine Zähler in data.job.result (restored, skipped, failures, unverified).
• Wiederherstellbarkeit und überfällige Sicherungen: entfernte Objekte, Mitglieder mit eigenem Zeitplan, laufende Sicherungen (0.4.7): Ein Objekt, das aus seiner Quelle entfernt wurde (etwa ein in Microsoft 365 gelöschtes Postfach), wird nicht mehr rot, weil seine letzte Sicherung altert: Nichts sichert es mehr, und die Aufbewahrung behält immer seinen neuesten Sicherungsstand; es wird also danach bewertet, ob sich diese Sicherung wiederherstellen lässt, ohne die Gründe zum Alter, und ist nie überfällig; eine aufbewahrte Sicherung, die sich nicht wiederherstellen lässt, bleibt rot. Dieselbe Bewertung gilt in der Statistik, in der Objektliste, in der Gesamtbereitschaft des Mandanten, in der Integrations-API und in der Benachrichtigung verify.completed; die Tabelle sagt „In der Quelle entfernt, Sicherungen bleiben“, und die Berichtsseite beginnt mit dem Hinweis „Aus der Quelle entfernt“. Ein Objekt, dessen neueste Sicherung nie geprüft wurde, bekommt vom wöchentlichen Planer noch eine Prüfung. Bei backup.overdue wird ein Postfach-Mitglied mit eigenem Zeitplan nach diesem Zeitplan oder nach den Mail-Jobs des Mandanten beurteilt (dem entspanntesten), je nachdem, was länger erlaubt; ein wöchentliches Mitglied eines täglichen Jobs ist also zwei Tage nach seiner Sicherung nicht mehr überfällig, und ein Objekt, dessen Sicherung begonnen hat und noch läuft (bis zu 21 Tage, eine große erste Sicherung), ist ebenfalls nicht überfällig.
• Proxmox VE: Einen Gast bewusst von der Sicherung ausschließen (0.4.7): Proxmox VE Preview, in jeder Edition. Ein Administrator kann eine VM oder einen Container von der Sicherung ausschließen, für Test-VMs oder Gäste, die anderswo gesichert werden: „Von der Sicherung ausschließen“ auf der Seite des Gastes oder, für eine Auswahl der Gäste eines Knotens, im Inventar; „Wieder einschließen“ nimmt es zurück. Mandanten-Administratoren und die Administratoren des Provider-Teams dürfen das. Kein Job sichert einen ausgeschlossenen Gast, auch nicht der Job für alle Gäste, und der empfohlene Job lässt ihn aus; sein eigener Job bleibt gespeichert, sodass das Wiedereinschließen wiederherstellt, was er hatte. Das Ausschließen zieht seine wartenden Sicherungen zurück (eine im selben Moment eingereihte Sicherung wird beim nächsten Heartbeat des Knotens zurückgezogen, bevor der Knoten sie bekommt), und „Jetzt sichern“ und das Aufnehmen des Gastes in einen Job werden abgelehnt, bis er wieder eingeschlossen ist. Ein ausgeschlossener Gast zählt nirgends als ungeschützt: nicht in den Übersichten, der Wiederherstellbarkeit, den Warnungen, backup.overdue, der Statistik oder der Provider-Ansicht, und er hält nie einen Mandanten vom Grün ab; die Gästezahlen führen ihn als ausgeschlossen. In VMs & Container steht er als „Ausgeschlossen“ (grau, nie ein Problem) und hat einen eigenen Zustandsfilter, und das Inventar zeigt „Ausgeschlossen: N“ je Knoten. Seine Sicherungsstände bleiben wiederherstellbar, und die Aufbewahrung behandelt sie wie bisher. Neue Route PUT /api/v1/pve/guests/:id/excluded, im Audit-Log als pve.guest.excluded. Das Update schließt keinen Gast aus; Gäste in keinem Job zählen weiter als „in keinem Backup-Job“, bis ein Administrator sie ausschließt. restow-pve braucht dafür kein Update.
• Proxmox VE: Größe der ersten Sicherung und einer Folgesicherung als Text im Inventar (0.4.7): Proxmox VE Preview, in jeder Edition. Das Inventar zeigt die Größe der ersten Sicherung eines Gastes („Erste Sicherung am“ mit Datum und gespeicherter Größe) und was eine Folgesicherung im Durchschnitt hinzufügt („Durchschnitt je Folgesicherung“ mit der Größe und der Zahl der zugrunde liegenden Sicherungen) als Text in der Zeile des Gastes, nicht nur im Tooltip, sodass beides gelesen und kopiert werden kann.
• Empfohlener Job mit dem Mail-Archiv (0.4.7): Solange die Installation die Archiv-Erfassung aus dem Postfach anbietet (Business und Service Provider) und der Mandant Postfächer oder Konten hat, die ein Archiv erfassen kann, lassen „Empfohlenen Job anlegen“ und „Alles ohne Job schützen“ den neuen Mail-Job über alle Objekte sichern und archivieren. Ein bestehender Mail-Job über alle Objekte, der noch nicht archiviert, wird stattdessen auf Archivierung umgeschaltet („Archivierung einschalten in …“); seine Zeitpläne bleiben, und die Änderung wird wie eine Bearbeitung im Job-Editor im Audit-Log festgehalten. Der Klick nimmt die Erfassungswege, die im Mandanten nichts weiter brauchen: Microsoft Graph für Microsoft-365-Postfächer, IMAP-Abgleich für die übrigen Konten; Journaling und Weiterleitung bleiben eine Wahl im Editor. Der empfohlene Job ändert nie einen Mail-Job über ausgewählte Objekte (die Vorschau nennt sie), und ein Mail-Job über alle Objekte, dessen Erfassungswege von Hand gewählt wurden, bleibt, wie er ist, was die Vorschau sagt. Die Liste der Mail-Jobs zeigt „Archivierung einschalten“, wo die Empfehlung sie einschalten würde. Ohne die Erfassung entsteht der empfohlene Job wie bisher, und bestehende Mail-Jobs ändern sich nur, wenn ein Administrator ihn anwendet.
• Monatspreise und eine Preisschätzung je Mandant für Provider (0.4.7): Unter Installation › Preise trägt der Eigentümer der Installation einen Monatspreis je Postfach und je GB oder TB gespeicherter Sicherungen ein, in EUR, CHF, USD oder GBP (höchstens vier Nachkommastellen; ein leer gelassener Preis wird nicht angezeigt). Postfächer werden wie in der Postfach-Nutzung gezählt (ein OneDrive zählt nicht doppelt); der Speicher sind die gespeicherten Sicherungen des Mandanten, dedupliziert und komprimiert, in dezimalen Einheiten (1 GB = 10^9 Byte). Provider-Administratoren mit allen Mandanten können die Preise lesen, nur der Eigentümer ändert sie, und jede Änderung wird mit den Werten vorher und nachher im Audit-Log festgehalten. Die Übersicht jedes Mandanten zeigt Provider-Administratoren dann eine Kachel „Preis je Monat“ mit dem, was der Mandant zu diesen Preisen ausmacht, eine Zeile für die Postfächer und eine für den Speicher, und einen Link zu den Preisen. Mandanten-Benutzer sehen nie Preise. Restow rechnet nichts ab und begrenzt nichts, und nach dem Update sind die Preise leer.
• Korrekturen: Restores von IMAP und Listen, Zeitlimits von Jobs, Demo-Seed, Formulierungen (0.4.7): Ein IMAP-Restore, dessen Verbindung abbricht, scheitert jetzt und wird auf einer neuen Verbindung wiederholt, wo die Prüfung der Message-ID überspringt, was schon angehängt wurde, statt als „abgeschlossen“ mit allen übrigen Elementen als fehlgeschlagen zu enden. Ein wiederholter Restore einer SharePoint-Liste im Modus „Beide behalten“ fügt die Elemente, die der unterbrochene Versuch angelegt hat, nicht mehr hinzu, und ein wiederholter Restore von Kontakten in diesem Modus legt Kontakte nicht mehr doppelt an. Ein Restore in ein Postfach, das per Adresse angegeben ist, löst das Postfach auf, das die API angenommen hat, sodass eine doppelte Adresse nicht mehr ein anderes wählt. Das Zeitlimit eines Jobs zählt ab dem Moment, in dem ihn die Warteschlange herausgab, auch während er auf einen freien Platz seines Mandanten wartet; ein Abbruch, der eintrifft, während ein Versuch startet oder scheitert, bleibt erhalten; ein Job, den der Reconciler endgültig beendet, löst wie jeder andere den Webhook job.failed, die Glocke und die Benachrichtigungsregeln aus. Der Seed der öffentlichen Demo scheitert nicht mehr, wenn Restow die erste Sicherung eines Objekts selbst eingereiht hat, was die Demo auf ihrer Seite „wird zurückgesetzt“ hängen ließ. Die Job-Seite nennt die Phasen einer SharePoint-Website-Sicherung („Website wird gelesen“, „Listen“) und der Suche nach Websites und Gruppenpostfächern, und die Hinweise zur Aufbewahrung sagen, dass der neueste Sicherungsstand jedes Objekts immer erhalten bleibt. „Aus Restow entfernen“ sagt nicht mehr, der Datei-Restore biete die Sicherungen eines entfernten Rechners nicht mehr an (er bietet sie seit 0.4.6 an), und die Lizenzseite führt die Anmeldung mit Microsoft nicht mehr unter dem auf, was Business freischaltet, weil sie noch nicht verfügbar ist.
• Abhängigkeiten: better-auth, Mail-Bibliotheken, Vite, React und die Build-Werkzeuge (0.4.7): better-auth 1.7.14, mailparser 3.14.1, nodemailer 10.3.1, smtp-server 3.21.3, msgreader 1.29.0, Biome 2.6.4, Vitest 5.0.5, Vite 8.3.5, React 19.3.1 und, in den Release-Pipelines, docker/login-action 4.7.0. zod 4 gehört nicht zu diesem Release.
• Hinweise zu Abhängigkeiten: ip-address, seroval und zod (0.4.7): ip-address 10.7.5 (von 10.7.2), eine transitive Abhängigkeit über socks, behebt einen Hinweis mittlerer Schwere; socks kommt mit der IMAP-Bibliothek und wird nur für Verbindungen über einen SOCKS-Proxy genutzt, den Restow nicht konfiguriert. seroval 1.7.5 (von 1.6.7, über den TanStack-Router) behebt GHSA-7rv5-mrxv-xcr9, GHSA-wp97-x4hv-qvhp und weitere Hinweise zu seinem Deserialisierer, und zod 4.6.7 (ein Override für die Kopie, die better-auth nutzt) behebt dort GHSA-mrhx-c7xc-m3w5. Dieser Hinweis (Speicherverbrauch beim Prüfen eines großen Arrays) nennt auch zod 3, das die eigene Anfrageprüfung von Restow nutzt und für das es kein korrigiertes 3.x gibt; das Audit der CI ignoriert diesen einen Hinweis, bis Restow auf zod 4 umgestellt ist. Die Grenze für den Anfragekörper der API (1 MB auf den meisten Routen) begrenzt ihn: Ein 1-MB-Array, das Element für Element scheitert, kostet für diese Anfrage etwa 150 MB und eine Sekunde der API.

Bekannte Probleme: Vor dem Tag von 0.4.0 nicht gegen echte Systeme getestet: ein Proxmox-VE-Knoten, das Verschieben der Datenbank und die Schaltfläche Netzlaufwerke einschalten über einen echten Updater und seinen Docker-Helfer-Container sowie die neuen Seiten von Hand im Browser. Freigaben wurden im Release-Smoke-Lauf gegen Samba getestet, nicht gegen Windows Server (NTFS-Berechtigungen, Backup-Operatoren, eine in Excel geöffnete Datei), eine Synology- oder TrueNAS-Freigabe, echte NFS-Exporte oder einen Host mit SELinux im Enforcing-Modus; es gibt kein VSS über SMB, keine alternativen Datenströme, DFS-Namespaces, Kerberos oder SMB1, die Repositories von Freigaben liegen nur im primären Repository, Mandantenbenutzer haben keinen Self-Service-Restore von Freigaben, und zeitgesteuerte Berichte haben noch keinen Freigaben-Block. Agents vor 0.4.0 halten ihre eigenen Zeitpläne nicht an, während ein Update wartet oder läuft. Dateien von Proxmox-VE-Containern und -VMs werden als ZIP heruntergeladen; einzelne Dateien in den laufenden Gast zurückzuspielen ist nicht gebaut, und der Datei-Restore von VMs ist eine Vorschau. Unveränderbare Backups, SharePoint Online, Startprüfungen, der Datei-Restore von VMs und Richtlinien für Agents wurden nur gegen simulierte Dienste getestet (ein falsches S3 mit Object Lock, ein simuliertes Microsoft Graph, ein simulierter Proxmox-VE-Knoten), die Ransomware-Signale mit simulierten Angriffen, nicht mit echter Ransomware. Unveränderbare Backups: Das Standard-Repository der Installation lässt sich nicht unveränderbar machen, restic-Indexdateien sind nicht gesperrt, und der Platz gelöschter Daten kommt erst zurück, wenn ihre Sperre abgelaufen ist. SharePoint: Anhänge von Listenelementen, Website-Design, Navigation, Workflows und Berechtigungen werden nicht wiederhergestellt, und eine gelöschte Website oder Bibliothek wird nicht neu angelegt. Unter „Dieser Sicherungsstand enthält“ werden Windows-Pfade aufgelistet, lassen sich aber nicht öffnen. Bekanntes Problem in 0.4.1: Die Größe eines Repositorys hat keinen Verlauf, das Wachstum von „Gespeichert“ stammt also nur aus dem Chunk-Store; Uploads, die abgeschlossen werden, während die erste Messung eines Repositorys es auflistet, können bis zur nächsten Bereinigung oder Aufbewahrungsprüfung fehlen, und „Geschützte Daten“ zählt weiter nur die Quellen des Chunk-Stores. Bekannte Probleme bis 0.4.3: Eine Dateifreigabe, deren Repository nach einem Speicherwechsel fehlt, wird noch nicht so geheilt wie ein Container (neue Sicherungskette); das ist für ein späteres Release 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 ist bis etwa 10.000 Personen je Mandant unproblematisch und darüber langsamer. Die neu gestaltete Seite VMs & Container (0.4.3) wurde mit DOM-Tests getestet, nicht visuell in einem Browser mit Tausenden Gästen. Weitere bekannte Probleme, bis 0.4.4: Die Archiv-Erfassung wurde gegen eine simulierte Microsoft-Graph-API, einen simulierten IMAP-Server, den Dovecot des Release-Smoke-Laufs und den Empfänger selbst getestet, nie 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 keinen Lesezugriff darauf bietet; ein Administrator bestätigt sie deshalb je Quelle. Von den wiederherstellbaren Elementen wird nur der Ordner der Löschungen gelesen, Mail, die endgültig gelöscht wurde, bevor Restow sie holte, kann fehlen, und Graph kann Mail über etwa 150 MB nicht exportieren (solche Mail 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 der API und der Oberfläche weiterhin nicht anlegen; ein Google-Workspace-Konto wird deshalb an seinem Host oder seiner Ordnerliste erkannt. Der Archivstatus und der Bericht der Integrations-API zählen weitergeleitete Kopien in ihren Summen, führen sie aber nicht als eigenen Weg auf. Ein Rollback auf 0.4.3 nach den Migrationen wurde nicht getestet: Ziehen Sie vor dem Update ein Datenbank-Backup und spielen Sie es zurück, um zurückzugehen. Weitere bekannte Probleme, bis 0.4.6: Gruppenkalender und Unterhaltungen wurden gegen eine simulierte Microsoft-Graph-API getestet, nie gegen einen echten Microsoft-365-Mandanten, und welche Kalenderzugriffe Graph einer App auf eine Gruppe erlaubt, kann je Mandant abweichen (das Backup fällt auf calendarView zurück und meldet, was es nicht lesen konnte; ein Restore in eine Gruppe bringt nur Kalenderereignisse zurück, weil Microsoft Graph keiner App erlaubt, in eine Gruppenunterhaltung zu schreiben). Vor 0.4.6 bot die Oberfläche die Sicherungen, die ein entfernter Rechner bis zum Ablauf behält, nicht an; seit 0.4.6 tut sie es, zum Durchsuchen und für den ZIP-Download, nie zum Wiederherstellen auf den Rechner. Die Korrektur, mit der sich ein Container auf aktuellem Proxmox VE wiederherstellen lässt (seit 0.4.6), wurde vor dem Release nicht gegen einen echten Proxmox-VE-Knoten ausgeführt. Ein Rollback auf 0.4.4 nach den Migrationen 0063 bis 0065 wurde nicht getestet: Ziehen Sie vor dem Update ein Datenbank-Backup und spielen Sie es zurück, um zurückzugehen. Weitere bekannte Probleme, bis 0.4.7: Die Erkennung deaktivierter, unlizenzierter und gesperrter Objekte wurde gegen eine simulierte Microsoft-Graph-API getestet, nie gegen einen echten Microsoft-365-Mandanten, und eine Antwort von Microsoft, die Restow nicht als „kein Postfach“ oder als Sperre erkennt, bleibt wie bisher ein gezählter Fehler. Der Ausschluss von Proxmox-VE-Gästen wurde nicht gegen einen echten Knoten ausgeführt, und das Ausschließen einer Auswahl im Inventar sendet eine Anfrage je Gast (scheitert eine, bleiben die Gäste davor ausgeschlossen, und die Liste lädt neu). GET /api/v1/jobs hat kein Feld, das eine gebremste oder neutrale Sicherung von einer fehlgeschlagenen unterscheidet; lesen Sie failure.code und den statusReason des Objekts. Benachrichtigungs-Mail über eine Microsoft-365-App-Registrierung holt nach einer Ablehnung kein neues Token, eine später erteilte Berechtigung Mail.Send wirkt also, sobald das zwischengespeicherte Token abläuft. Das Ablaufdatum eines Client-Secrets liest Restow nicht von Microsoft: Ohne ein eingetragenes Datum (unter Installation, in ENTRA_CLIENT_SECRET_EXPIRES_AT oder an der Quelle) gibt es keine Erinnerung, und Quellen mit einem älteren eigenen Secret ohne eigene App (gemeinsame Client-ID) haben kein Datum in Restow; stellen Sie sie auf eine eigene App oder die zentrale App um. Ein Filter auf die Bewertung in der Liste der Wiederherstellbarkeits-Berichte nimmt die gespeicherte Bewertung: Ein Bericht, der vor dem Update oder noch an der Quelle gespeichert wurde, kann ein aus der Quelle entferntes Objekt unter Rot führen, obwohl er grün zeigt; Prüfungen seit 0.4.7 speichern die Bewertung ohne das Alter. Der Bereitschaftsverlauf früherer Tage zeigt das Gelb unbestätigter Objekte nicht. Eine Nachricht, die die IMAP-Archiv-Erfassung aufgibt, Nachrichten, die das Auffüllen nicht lesen konnte, und ein bekannter Mail-Ordner, den Graph nicht auflösen wollte, stehen nur im Worker-Log. IMAP-Quellen mit OAuth2 lassen sich weiterhin nicht in der API oder der Oberfläche anlegen. Ein Rollback auf 0.4.6 nach den Migrationen 0066 bis 0069 wurde nicht getestet: Ziehen Sie vor dem Update ein Datenbank-Backup und spielen Sie es zurück, um zurückzugehen.

Ausgeliefert (0.3.1 bis 0.3.6), Proxmox-VE-Preview, Mitglieder, Benachrichtigungen

Veröffentlicht vom 8. bis 15. Oktober 2026; 0.3.6 war das letzte Release der Linie. Das Update von 0.2.x führt sechs Datenbankmigrationen aus und bittet jede Installation, die Einrichtungsmitteilung noch einmal zu bestätigen: Lesen Sie zuerst die Release-Notes von 0.3.1. Das Update auf 0.3.5 führt eine weitere Migration aus und wandelt den Backup-Index im Hintergrund um: siehe Update auf 0.3.5. Das Update auf 0.3.6 führt eine weitere kleine Migration (0034) aus: siehe Update auf 0.3.6. Ein Rollback braucht den Datenbank-Dump, der vor dem Update gezogen wurde.

• Proxmox VE (Preview, ab 0.3.1, jede Edition): Backup von VMs und Containern auf Proxmox VE ab 8.4 über die Backup-Provider-API. VM-Festplatten gehen über NBD mit Dirty Bitmaps, sodass nur geänderte 4-MiB-Blöcke hochgeladen werden; Container gehen über restic; ein Restore legt eine neue VMID im Pool restow-restore an. Die Knotenseite ist ein Storage-Plugin-Shim (ein eigenes Werk unter AGPL-3.0-or-later) und der Helfer restow-pve (Apache-2.0), installiert mit /install/pve.sh. Gäste zählen bei Wiederherstellbarkeit, Warnungen und Alarmen für überfällige Sicherungen mit. Ab 0.3.2 bindet ein Befehl je Knoten ihn an, alternativ mit einem vorhandenen Proxmox-VE-API-Token; ab 0.3.3 erscheint jeder Knoten im Inventar mit seinen VMs und Containern; 0.3.4 behebt die Sicherung nicht privilegierter Container (führen Sie nach dem Server-Update auf jedem Knoten restow-pve update aus).
• Mehrere Administratoren in jeder Edition (ab 0.3.1): Mitglieder mit Rollen, auch in Community; ein Mitglied auf ausgewählte Mandanten zu beschränken bleibt Teil von Service Provider. Inhaber können den Zugang eines Mitglieds zurücksetzen. Bevor eine Änderung der öffentlichen URL oder des Betriebsmodus Passkeys unbrauchbar macht, nennen die Einstellungen die betroffenen Konten und verweigern eine Selbstaussperrung. Die Anmeldeseite bietet bei verlorenem Zugang einen Weg zurück. Siehe Team und Rollen.
• NFS-Netzlaufwerke aus der Weboberfläche (ab 0.3.1) über den optionalen Mounter und, ab 0.3.3, eine NFS-Adresse direkt im Pfadfeld eines Repositorys. Siehe NFS-Freigaben.
• Alarme in Discord, Slack und Microsoft Teams (ab 0.3.1): Ein Webhook bekommt ein Format, gewählt anhand seiner URL. Siehe Alarme und Berichte.
• Überfällige Sicherungen und Warnungen (ab 0.3.1): das Ereignis backup.overdue für Postfächer, OneDrives, IMAP-Konten, Rechner und Proxmox-Gäste, das die Zeitpläne der Backup-Jobs berücksichtigt, mit eigener Frist je Alarmregel (24 bis 720 Stunden). Warnungen nennen, warum einzelne Elemente nicht gesichert wurden, und lassen sich mit einer Notiz bestätigen.
• Benachrichtigungs-Mail über Microsoft 365 oder Google Workspace (ab 0.3.1), mit Anleitungen und klaren Fehlermeldungen.
• Archiv (ab 0.3.1): ein Archiv je Mail-Job; Journalberichte werden den Postfächern zugeordnet, die sie nennen; eine Kettenprüfung über jedes Glied, die täglichen Anker (jetzt jede Nacht geschrieben) und auf Wunsch eine Stichprobe der Nachrichteninhalte; archivierte Nachrichten lassen sich lesen und als .eml herunterladen; Suche mit Blättern und Filtern nach Absender, Datum und Postfach. Ein Legal Hold wird mit einer verpflichtenden, protokollierten Begründung aufgehoben. Siehe Archivierung.
• Audit-Log-Export (ab Business, ab 0.3.1): CSV und JSON mit Hashes. Die Zustellprotokolle lassen sich als CSV exportieren. Siehe Audit-Log.
• Klar sagen, was geschützt ist (ab 0.3.1): Rechner, die in keinem Backup-Job sind, zählen nirgends mehr als geschützt; das Verzeichnis, die Backup-Jobs und die Rechner sagen, welcher Job ein Objekt sichert. Übersicht, Statistik zeigt nur den aktiven Mandanten; die Statistik aller Mandanten hat eine eigene Seite.
• „Repository“ überall (ab 0.3.3): Die Oberfläche sagt Repository statt Speicherort.
• Microsoft-365-Postfach-Sicherungen bleiben im Ordnerschritt nicht mehr stehen (0.3.2): Ein Ordner, den Microsoft doppelt aufführte, ließ Microsoft einen ganzen Batch ablehnen (HTTP 400).
• Rolle Restore-Operator (0.3.5): eine Rolle je Mandant, die jedes Backup des Mandanten sieht und wiederherstellt, ohne ihn zu verwalten (Jobs, Speicher, Nutzer). Wer einen Nutzer oder eine Einladung anlegt, muss jetzt immer eine Rolle wählen. Siehe Team und Rollen.
• Lange erste Sicherungen werden fertig (0.3.5): Eine Sicherung, die nach einem gespeicherten Prüfpunkt durch ihr Zeitlimit (23 Stunden) oder durch einen Neustart des Workers unterbrochen wird, setzt sich fort, ohne einen Wiederholungsversuch zu verbrauchen, bis zu 21 Tage nach ihrem ersten Start. Eine Microsoft-Graph-Anfrage, die innerhalb von 5 Minuten keine Antwort bekommt, wird wiederholt. Der Worker bekommt beim Stoppen 60 Sekunden, um Prüfpunkte zu speichern (stop_grace_period). Vorher endete die erste Sicherung eines großen Postfachs, die mehrere Tage brauchte, nach fünf Unterbrechungen als fehlgeschlagen.
• Proxmox VE (Preview) sagt, was ein Backup enthält (0.3.5): eine Spalte Sicherung mit dem, was der neueste Wiederherstellungspunkt enthält und was sein Lauf hinzugefügt hat, Wiederherstellungspunkte mit ihrem Typ (erste Sicherung, inkrementell, vollständig gelesen) und eine Container-Sicherung, die restic nicht vollständig lesen konnte, angezeigt als „Letzte Sicherung unvollständig“ / „Mit Lücken erfolgreich“ mit der Zahl der nicht lesbaren Elemente und im Inventar als „Unvollständig“ gezählt. Proxmox VE bleibt in jeder Edition eine Preview.
• Datenordner-Hinweis für Linux-Maschinen-Jobs (0.3.5): Bei Maschinen-Jobs und in der Dateiwiederherstellung nennt ein Hinweis die üblichen Datenordner (/opt, /srv, /var/lib, /home, …), die die Pfade des Jobs auslassen, mit einer Schaltfläche, sie hinzuzufügen.
• Backup-Index als Elementversionen (0.3.5): Ein Backup kopiert nicht mehr jedes Element eines Postfachs oder OneDrives in die Datenbank. Eine Zeile je Version eines Elements heißt, dass ein unverändertes Element bei späteren Backups nichts kostet; bei einer Installation mit 14 Millionen Index-Zeilen (25 GB) braucht der Index danach etwa 0,5 bis 1,5 GB. Der Worker wandelt vorhandene Backups nach dem Upgrade nacheinander um.
• Anmeldung auf einer eigenen Datenbankrolle (0.3.5): Härtung, keine bekannte Ausnutzung. Bis 0.3.4 konnte die Datenbankrolle der Anwendung auch die Tabellen außerhalb von Row Level Security lesen und schreiben, darunter die Anmelde-Tabellen, die Installationseinstellungen, die Lizenz und die Job-Warteschlange. Nichts zu tun außer dem Update; DATABASE_AUTH_URL ist optional. Siehe Datenbank.
• Proxmox VE (Preview): Gäste im Inventar schützen (0.3.6): Im Abschnitt Proxmox VE unter Server & Clients → Inventar hat jede VM und jeder Container (Knoten aufklappen) seinen Backup-Job als Auswahl (ein vorhandener Job, „Kein Backup-Job“ oder „Neuer Job …“) und Jetzt sichern. Gäste lassen sich einzeln, alle eines Knotens oder alle ohne Job mit einem Klick auswählen („Auswählen“ neben dem Hinweis, wie viele keinen Backup-Job haben) und dann einem Job hinzufügen („Zu Job hinzufügen …“) oder gemeinsam sichern; „Neuer Job …“ öffnet den Job-Dialog und legt die Auswahl in den neuen Job. Die Inventarspalte heißt jetzt Schutz (vorher hieß sie „Sicherung“, genau wie die Spalte, die zeigt, was der neueste Wiederherstellungspunkt enthält). Proxmox VE bleibt in jeder Edition eine Preview.
• Hinweis „Neustart erforderlich“ (0.3.6): Unter Installation → Updates sagt Restow, wenn ein Dienst neu gestartet werden muss, mit dem Grund, der Schaltfläche Jetzt neu starten und dem Befehl zum Kopieren, im Verzeichnis der Installation. Die Schaltfläche läuft über den Updater, gilt nur für api, worker oder scheduler, ist während eines Updates nie verfügbar und wirkt erst nach einer Bestätigung; sie ist für den Inhaber des Provider-Teams und braucht den Updater von 0.3.6 (ein älterer Updater zeigt den Befehl). Provider-Administratoren sehen einen Hinweis auf jeder Seite. Nichts startet ohne Klick neu. Ein verfügbares Update steht jetzt auch neben der laufenden Version. Bekanntes Problem: Noch hält nichts eine Neustart-Anforderung fest. Siehe Neustart erforderlich.
• Der alte Backup-Index gibt seinen Platz von selbst zurück (0.3.6): Ist die Umwandlung des Backup-Index aus 0.3.5 fertig, leert die api die alte Tabelle innerhalb von etwa 15 Minuten; der Neustart der api, den 0.3.5 verlangte, entfällt. Siehe Update auf 0.3.5.
• Das Installationsskript aktualisiert docker-compose.yml (0.3.6): Wer install.sh auf einer vorhandenen Installation erneut ausführt, bringt docker-compose.yml auf das in .env genannte Release (geprüft gegen die signierte SHA256SUMS); die bisherige Datei bleibt als docker-compose.yml.bak-<timestamp> erhalten, und die .env bleibt unverändert. Installationen, deren Datei keinen Mounter hat, kommen so auf den Stand. Siehe Erneut ausführen.
• Klarere NFS-Meldungen (0.3.6): Läuft der Mounter nicht, beginnt der Befehl mit dem Verzeichnis der Installation; eine Compose-Datei aus der Zeit vor dem Mounter wird als solche benannt, mit dem Befehl des Installationsskripts, der sie aktualisiert; ein fehlender NFS-Export nennt den Exportpfad und wie Sie den richtigen finden (showmount -e, Synology-Pfade beginnen mit /volume1/, NFSv3). Das Fenster Serverpfad hinzufügen ist breiter und scrollt nicht mehr zur Seite. Siehe NFS-Freigaben.
• Kleinere Änderungen (0.3.6): docker-compose.yml und .env.example behalten nur die Kommentare, die man nicht übersehen darf; die Referenz ist die Release-Stack-Referenz. Abhängigkeiten: Patch- und Minor-Updates.

Bekannte Probleme: Proxmox VE wurde gegen echte qemu-nbd, qemu-img und restic und, für die Knotenanbindung, gegen Attrappen für pveum und pvesm getestet. Proxmox VE ist eine Preview und wird als einzige Sicherung noch nicht empfohlen. NFS-Einbindungen, die Benachrichtigungs-Mail über Microsoft 365 und Google sowie die Chat-Webhooks wurden nur gegen Attrappen getestet. Solange ein Einbinden aus dem Pfadfeld auf laufende Jobs wartet, starten neue Jobs weiter. Die Unveränderbarkeit des Archivs auf lokalem und NFS-Speicher erzwingt nur die Anwendung. Die Umwandlung des Backup-Index im Hintergrund (0.3.5) wurde an erzeugten Verläufen getestet, noch nicht an einer Produktionsdatenbank mit 25 GB; wie lange sie dort dauert, ist eine Schätzung. Noch hält nichts in Restow eine Neustart-Anforderung fest (0.3.6): Der Hinweis und die Schaltfläche sind für Updates da, die sie brauchen. Der Docker-Fehlertext für einen fehlenden NFS-Export (0.3.6) stammt aus der Dokumentation von Docker, nicht aus einer echten fehlgeschlagenen Einbindung. Die bekannten Probleme von 0.3.4 gelten weiter.

Ausgeliefert (0.2.2), Microsoft-365-Anbindung

Veröffentlicht am 6. Oktober 2026. Das Update braucht keine Migration und keinen manuellen Schritt.

• Eine eigene Graph-App je Quelle (jede Edition): Neben der Zustimmungseinladung der gemeinsamen Backup-App lässt sich eine Quelle über eine App verbinden, die der Kunde von Hand im eigenen Tenant angelegt hat (Tenant-ID, Anwendungs-ID und ein Client-Geheimnis oder Zertifikat). Die Zugangsdaten werden im Geheimnisspeicher der Organisation versiegelt und nie wieder angezeigt. Nur mit Unit-Tests und den CI-Suiten getestet, nicht gegen einen echten Microsoft-365-Mandanten.
• Der Tenant der Backup-App lässt sich ohne Zustimmungslink verbinden: „Eigenen Tenant direkt verbinden“ auf der Quellenseite (nur Provider-Inhaber) nimmt ein funktionierendes App-Token als Nachweis. Dafür braucht es die Verzeichnis-ID (Tenant-ID) der App unter Einstellungen, Microsoft 365.
• Hetzner-Object-Storage-Preset mit Standortauswahl (Falkenstein, Nürnberg, Helsinki); Buckets mit einem Punkt im Namen werden über den Pfad angesprochen, und die Object-Lock-Erkennung akzeptiert die Antworten S3-kompatibler Dienste. Nicht gegen einen echten Hetzner-Bucket getestet.
• Alpha-Kanal für Testbuilds: Unter Installation, Updates wählt „Alpha-Kanal verwenden“ eine Quelle unsignierter Testbuilds. Nur für Testinstallationen, nie für eine mit Produktivdaten.

Ausgeliefert (0.2.1), der Rest aus 0.2.0

Veröffentlicht am 3. Oktober 2026. Das Update von 0.2.0 führt eine additive Migration aus; lesen Sie zuerst die Release-Notes, wenn Sie den Updater unter 0.2.0 eingeschaltet haben oder Agents vor 0.2.1 betreiben.

• Ein Rechner sichert, sobald er in einem Backup-Job ist: Jeder Rechner ohne Job ist mit „Ohne Backup“ markiert, wird in einem Banner gezählt und bekommt „Job anlegen“ oder „Zu Job hinzufügen…“ angeboten. Ein neu angemeldeter Rechner wartet auf einen Job. Siehe Backup-Jobs.
• Einen Rechner einer Person zuordnen, aus dem Verzeichnis, mit der Spalte „Zugeordnet zu“ in der Rechnertabelle.
• Kontextmenüs auf Tabellenzeilen: Rechtsklick, die Kontextmenütaste, Shift+F10, langes Drücken oder die ⋯-Schaltfläche öffnen die Aktionen einer Zeile; auswählbare Tabellen bekommen eine Auswahlleiste und „Neuer Job aus der Auswahl“.
• Datei-Restore mit Rechnern und Postfächern auf einer Zeitleiste, neueste zuerst, nach Tagen gruppiert, mit Sprung zu einem Datum.
• Speicher-Standard in der Weboberfläche (Installation → Speicher-Standard), vor dem Speichern durch einen Test geprüft. Siehe Backups und Zeitpläne.
• Der Updater startet mit einem Befehl, aktualisiert sich nach einem signierten Update selbst und wechselt eine Community-Installation zum vollständigen Build. Siehe Updates.
• Server sichern standardmäßig ihre Anwendungsdaten (/opt, /usr/local, /var/lib, /var/backups).
• Öffentliche Demo mit simulierten laufenden Jobs.
• SMB wird nicht mehr als unterstützter Speicher-Mount genannt; Netzwerkspeicher für lokale Ziele ist NFS. Bestehende eingebundene Pfade funktionieren weiter.

Ausgeliefert (0.2.0), Ordnung und Einstieg

Veröffentlicht. Restow 0.2.0 ordnet die Oberfläche in drei Ebenen und bringt Backup-Jobs mit Live-Läufen. Das Update von 0.1.0 führt additive Migrationen aus und macht aus Ihren Zeitplänen und Rechner-Einstellungen Jobs; nichts wird gelöscht. Die Hinweise zum Update und zum Rückweg stehen im Changelog des Releases.

• Installation, eigene Organisation und Mandanten-Einstellungen: Jede Einstellung hat einen Ort und eine Ebene, die Installation (Server, Benachrichtigungs-Mail, Updates, Lizenz) und je Mandant eine Einstellungsseite (Verbindungen, Schutz, Jobs und Zeitpläne, Aufbewahrung der Sicherungen, Speicher, Agents, Archiv, Benachrichtigungen, Integrationen, Mitglieder, Audit-Log, Stammdaten), anstelle der Reiterleiste Einrichtung aus 0.1.0. Die Einrichtung legt Ihre eigene Organisation als internen Mandanten an.
• Mandanten-Umschalter mit Suche im Menü (Service Provider): Zwischen Mandanten wechseln Sie oben im Menü, und per Suche finden Sie einen nach Name oder Kundennummer.
• Farbschema Restow oder Neutral neben Hell und Dunkel.
• Tabellen in voller Breite mit fixierten Spalten.
• Geführter Installer mit Reverse-Proxy-Modus, standardmäßig verschlüsselt zu Restow.
• Einrichtungsassistent beginnt mit der Sprachwahl. Siehe Einrichtungsassistent.
• Erste Schritte als Checkliste im Menü: Ein Raketen-Eintrag unten links öffnet eine Checkliste für eine neue Installation aus sieben Schritten (funktionierendes Repository, verbundene Quelle, geschützte Objekte, aktive Zeitpläne, erste Sicherung, erste bestandene Restore-Prüfung und Benachrichtigungs-Mail, der einzige optionale Schritt). Sobald die Einrichtung abgeschlossen ist, verschwindet der Eintrag.
• Wiederherstellbarkeit verknüpft mit gefilterten Tabellen: Jeder Zustand (bestanden, fällig, nicht abgeschlossen und wiederholt, fehlgeschlagen, Sicherung zu alt, nie geprüft) filtert die Tabelle darunter.
• Übersicht über alle Mandanten oder einen Mandanten (Service Provider).
• Jobs als Vorlagen: Ein Job legt fest, was gesichert wird, wann, in welches Repository, wie lange und wie oft eine Restore-Prüfung es nachweist, für viele Postfächer, OneDrives, IMAP-Konten oder Rechner zugleich, mit Abweichungen je Objekt oder Rechner. Es gibt Jobs für Mail und für Server und Clients; für Server und Clients wählen Sie die zu sichernden Ordner aus und schließen Dateitypen aus. Beim Update werden die heutigen Zeitpläne und Rechner-Einstellungen zu Jobs; nichts wird gelöscht.
• Live-Aktualisierung ohne Neuladen und ein Detailpanel zum Lauf mit Durchsatz-Diagrammen.
• Bandbreitenlimit mit Zeitfenster.
• Verlauf einschließlich Agent-Läufen: Jeder Lauf, mit Filtern nach Art (Backup, Restore, Restore-Prüfung, Export, Import, Wartung) und nach Job. Die Wiederholungen einer Restore-Prüfung erscheinen als eine Zeile.

Ausgeliefert (0.1.0)

• Setup-Assistent für die Ersteinrichtung: ein einmaliges Setup-Token aus dem Log des Servers (oder RESTOW_SETUP_TOKEN), der Hinweis für Betreiber, Betriebsmodus, öffentliche URL, erste Administration (Passkey-first, Notfall-Passwort mit TOTP-Pflicht als Rückfallebene), Benachrichtigungs-Mail-Transport (SMTP oder Microsoft Graph sendMail) mit Testversand. Ein verlorenes Inhaber-Konto wird über die Kommandozeile des Servers wiederhergestellt (restow admin recover). Siehe Einrichtungsassistent.
• Anmeldung mit Passkeys, sobald die Installation nachweislich über HTTPS erreichbar ist, eine Notfall-Anmeldung mit E-Mail und Passwort mit Authenticator-Pflicht, plus persönliche Kontoverwaltung (Passkeys, Authenticator, Sitzungen). Die Anmeldung mit einem Microsoft-Konto gab es in 0.1.0 nicht und gibt es in 0.4.7 weiterhin nicht; sie ist geplant (siehe „Als Nächstes“ unten). Siehe Erste Schritte als Endnutzer → Anmelden.
• Mandantenfähigkeit mit PostgreSQL Row Level Security, die die Daten jedes Mandanten trennt.
• Microsoft-365-Quellen über den Entra-Admin-Consent-Flow, mit expliziter Berechtigungsprüfung; die App-Registrierung selbst wird unter Installation → Microsoft-Multi-Tenant-App eingetragen und getestet, ohne .env zu bearbeiten.
• Schutzumfang je Quelle: alle im Verzeichnis, eine Gruppe, oder einzeln ausgewählte Objekte, mit Sammelaktionen zum Einschließen/Ausschließen/„Regeln wieder anwenden”. Das Verbinden einer Quelle reiht ihren ersten Verzeichnisabgleich sofort ein, und ein neu geschütztes Objekt erhält automatisch eine erste Sicherung, statt auf einen Zeitplan zu warten.
• IMAP-Quellen (Passwort-Authentifizierung). Jede Quelle nutzt eines von drei Anmeldeverfahren: einen gemeinsamen Zugang für alle Postfächer darunter, ein eigenes Passwort je Postfach oder ein Master-Konto, das sich als jedes Postfach anmeldet. OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant.
• Backup für Exchange Online (Mail, Kalender, Kontakte), OneDrive und IMAP-Postfächer, dedupliziert und verschlüsselt.
• Restore, standardmäßig nicht-destruktiv (wiederhergestellte Elemente kommen neben das, was bereits da ist); einen Modus, der überschreibt, hatte 0.1.0 nicht. Automatisierte wöchentliche Restore-Prüfung: eine Stichproben-Rücklesung über den Restore-Pfad, verglichen mit den festgehaltenen Hashes. Sie stellt nicht in ein Microsoft-365-Postfach, OneDrive oder IMAP-Konto wieder her; der optionale Test-Restore in ein Ziel ist in 0.1.0 nicht angeschlossen und ist es auch in 0.4.7 noch nicht.
• Konfigurierbare Speicherziele.
• Archiv, in jeder Edition: ein nur anhängbarer Speicher mit SHA-256-Hash-Kette und Kettenprüfung (manipulationserkennbar), eine Archivseite für Administrationen mit Suche über Betreff, Adressen und Nachrichtentext (Nachrichtentext importierter Mail; kein Anhangsinhalt) und dem Lesen eines Elements, Aufbewahrungseinstellungen, Export als EML in einer ZIP-Datei oder als MBOX sowie ein Nachweisbericht als JSON über die Integrations-API (ohne PDF). Das Archiv wird durch Mail-Import mit der Option, gleichzeitig zu archivieren (jede Edition), und durch den Empfang von Exchange-Online-Journalberichten (ab Business) gefüllt. Business und Service Provider ergänzen die für den GoBD-konformen Einsatz ausgelegte Schicht: Journal-Empfang per SMTP (braucht ein eigenes TLS-Zertifikat), durchgesetzten Löschlauf der Aufbewahrung und Legal Hold je Mandant oder je Postfach. Archivabgleich aus IMAP und Microsoft 365 ist geplant, siehe „Als Nächstes“ unten. Siehe Archivierung.
• Die Integrations-REST-API.
• Backup-Aufbewahrung: ein Standard je Mandant plus Ausnahmen je Objekt auf dem Reiter Aufbewahrung der Mandanten-Einrichtung. Der tägliche Aufbewahrungslauf räumt Sicherungsstände ab, behält immer den neuesten abgeschlossenen Sicherungsstand jedes Objekts und räumt nichts ab, was unter Legal Hold steht.
• Audit-Log-Ansicht (ab Business): Liste, Filter nach Mandant, Aktion, Akteur, Ziel und Zeitraum, Details eines Eintrags und Kettenprüfung. Die Aufzeichnung läuft in jeder Edition (jedes Lesen und jeder Restore wird in ein nur anhängbares, hashverkettetes Log geschrieben); der Audit-Log-Export kam mit 0.3.1. Siehe Audit-Log.
• Team mit Rollen (in 0.1.0 ab Business; seit 0.3.1 in jeder Edition): mehrere Provider-Administrationen als Inhaber, Administrator, Techniker oder Nur lesen, mit allen oder ausgewählten Mandanten. Siehe Team und Rollen.
• Service Provider: mehrere Mandanten in einer Installation, delegierte Mandanten-Administrationen, die nur ihren eigenen Mandanten sehen und verwalten, die mandantenübergreifende REST-API mit Provider-Keys, die Beschränkung von Provider-Teammitgliedern auf ausgewählte Mandanten und die Provider-Übersicht über alle Mandanten (Status, Kennzahlen, veraltete Sicherungen, Fehler, Speicherprobleme und Alarme je Mandant). Siehe Mandantenfähigkeit.
• Alarme und Berichte: Alarme per E-Mail, in der Glocke und per Webhook, wenn eine Sicherung fehlschlägt, eine Restore-Prüfung nicht besteht oder Speicher beschädigt ist, mit Zustellprotokoll. Siehe Alarme und Berichte.
• Zeitgesteuerte Berichte (ab Business): tägliche, wöchentliche, monatliche oder per Cron geplante Zusammenfassungen per E-Mail. Siehe Alarme und Berichte.
• Endpoint-Backup für Server und Clients (jede Edition): Ein Agent für Linux und macOS sichert Dateien mit restic in den Speicher des Mandanten. Er schreibt nur anhängend (er kann Sicherungen hinzufügen, aber nie eine löschen); Aufbewahrung, Repository-Prüfungen und Restore-Tests (Stichproben-Rücklesungen) laufen auf dem Server und fließen in die Wiederherstellbarkeit ein. Siehe Endpoint-Backup.
• Mail-Datei-Import und -Export (jede Edition): EML, MSG, MBOX, ZIP und MailStore-Exporte werden zu einem importierten Postfach, das Sie durchsuchen, wiederherstellen, herunterladen und optional archivieren können. Mail lässt sich als EML in einer ZIP-Datei oder als MBOX exportieren. Siehe Mail-Dateien importieren und exportieren.
• Updates: eine Update-Prüfung, die aus ist, bis eine Administration sie einschaltet, und ein optionaler Updater (Opt-in, bindet den Docker-Socket ein), der Wartung ankündigt, zuerst die Datenbank sichert und nur dann von selbst zurückrollt, solange die Datenbank-Migrationen der neuen Version noch nicht gelaufen sind. Nach einer Migration, die sich nicht rückgängig machen lässt, hält er an, behält den Dump und sagt, wie Sie ihn einspielen. Er läuft aus seinem eigenen, festgelegten Image, installiert nur Release-Images, deren cosign-Signatur er geprüft hat, und baut aus einem Repository nur, wenn der Betreiber es auf dem Server erlaubt. Siehe Updates.
• Fehlererklärungen: Jeder fehlgeschlagene Job, jedes Element, jeder Abgleich und jede Prüfung sagt, was passiert ist, warum und was zu tun ist. Siehe Fehlererklärungen.
• Betreiberhinweis: ein Schritt des Einrichtungsassistenten, zusammen mit der Einrichtung akzeptiert. Siehe Hinweis für Betreiber.
• Zeitleiste im Restore-Explorer: eine schlanke Zeitleiste der Sicherungsstände am unteren Rand des Explorers, der neueste in der Mitte. Ein Ordner ohne Unterordner sagt das.
• Signierte Release-Images für amd64 und arm64 in zwei Builds (vollständig und Community) mit SBOMs, eine signierte Prüfsummenliste, signierte Agent-Releases und ein Release-Smoke-Lauf beider Builds vor jeder Veröffentlichung. Siehe Ein Release verifizieren.
• Editionen-Aufbau: Die Funktionen von Business und Service Provider liegen unter ee/ im selben Repository und Release. Die vollständigen Images enthalten sie, gesperrt, bis unter Installation → Lizenz ein Lizenzschlüssel installiert ist; die Community-Images enthalten nur den Apache-2.0-Kern. Siehe Lizenz und Editionen.

Die automatisierte Microsoft-365-Prüfung der Release-Pipeline gegen einen echten Mandanten ist noch nicht aktiv: Prüfung 4, ausgeführt gegen einen Dev-Tenant, wurde in jedem Release bis 0.4.7 übersprungen. Der Smoke-Lauf des aktuellen Releases, 0.4.7, bestand für den vollständigen Build 12 von 13 Prüfungen vollständig und für den Community-Build 9 von 13; diese Zahlen werden aus den Smoke-Berichten gelesen, die diesem Release beiliegen. Microsoft-365-Backup und -Restore sind durch Tests gegen eine simulierte Microsoft-Graph-API und IMAP-Server abgedeckt. Jedes Release durchläuft vor der Veröffentlichung einen Smoke-Test: Neuinstallation, Health-Checks, Passkey-Anmeldung, IMAP-Backup und -Restore mit Hash-Vergleich, Journal-Empfang mit Kettenprüfung, ein Restore ohne Server, mehrere Speicherziele, ein Schwachstellen-Scan, Endpoint-Backup und -Restore sowie Mail-Import und -Export. Der Microsoft-365-Check darin ist der, der übersprungen wird. Der abschließende Smoke-Lauf von 0.1.0 (01.10.2026) bestand für den vollständigen Build 9 von 11 Checks vollständig, 1 teilweise (den Update-Pfad gibt es noch nicht, weil es kein früheres Release gibt) und übersprang 1 (Microsoft 365, kein Mandant); für den Community-Build bestand er 7 vollständig, 1 teilweise (derselbe Update-Pfad) und übersprang 3 (Microsoft 365 sowie planmäßig die Journal- und die Speicherziel-Prüfung, die im vollständigen Build laufen). Der Endpoint-Agent wird für Linux und macOS ausgeliefert, der Smoke-Lauf installierte ihn aber nur in einem Linux-Container; der macOS-Installer und der Agent gehörten nicht zu den Release-Prüfungen (die eigenen Tests des Agents liefen nativ auf macOS). Siehe Ein Release verifizieren.

Als Nächstes

Entschieden und vor den Punkten unter Später erwartet. Keine Versionsnummern und keine Termine: Ein Punkt rückt nach Ausgeliefert, wenn ihn ein veröffentlichtes Release enthält, nicht vorher. Die Reihenfolge in dieser Liste ist kein Versprechen.

Bedienung

• Inventar und Schutzgruppen: Aufbauend auf der Rechnertabelle aus 0.2.1 ordnen Schutzgruppen neue Rechner nach Profil, Betriebssystem, Hostname oder Tag einem Job zu, und der Installationsbefehl kann den Job mitbringen. Dass der Agent die üblichen Linux-Datenordner meldet, damit der Job-Editor Pfade vorschlagen kann, ist seit 0.4.0 ausgeliefert (Datenordner, die ein Job auslässt); die Schutzgruppen nicht.
• Vollständige Assistenten: Assistenten Schritt für Schritt für eine neue Quelle oder einen neuen Agent, das Einschalten des Archivs und einen neuen Mandanten, mit Schrittleiste und Entwürfen, die Sie später fortsetzen. Entwürfe enthalten nie Geheimnisse.
• Touch und Suche: Die Zeilenaktionen der Kontextmenüs als Bottom-Sheet auf Touchscreens und eine Befehlspalette, die auch Postfächer, Rechner und Läufe per ID findet.
• Pins und Befehlspalette: Seiten, Mandanten und Mandantenreiter oben im Menü anpinnen, ein Kontextmenü auf Menüeinträgen und Reitern und eine Befehlspalette, die jede Seite und jeden Mandantenreiter erreicht.

Microsoft, Archiv, Marke

• Microsoft-365-App je Mandant: Über die eigene Graph-App hinaus, die eine Quelle seit 0.2.2 nutzen kann (ein Client-Geheimnis oder Zertifikat, das Sie eingeben), verbindet jeder Mandant Microsoft 365 mit einer eigenen App, registriert im Microsoft-Verzeichnis dieses Mandanten. Restow erzeugt je Mandant ein Zertifikat, dessen privater Schlüssel Restow nie verlässt, führt mit den Werten dieses Mandanten durch die Registrierung, prüft jede Berechtigung und warnt vor Ablauf des Zertifikats. Die installationsweite Multi-Tenant-App mit Zustimmungslink bleibt als Option; bestehende Verbindungen laufen unverändert weiter. Seit 0.4.7 erinnert Restow schon 30 Tage vorher, 7 Tage vorher und nach dem Ablauf des Client-Secrets oder Zertifikats der zentralen App-Registrierung oder der eigenen App einer Quelle; das Datum wird eingetragen (ein Zertifikat bringt sein eigenes mit) und nie aus Microsoft Graph gelesen.
• Ersetzen-Modus für OneDrive-Dateien: ein optionaler Restore-Modus, bei dem die aktuelle Datei zu einer früheren Version im eigenen Versionsverlauf von OneDrive wird, statt gelöscht zu werden. Mail, Kalender und Kontakte werden nie überschrieben.
• Archiv als Mail-Browser mit sichtbarem Nachweis je Mail: Das Archiv bekommt einen eigenen Bereich und liest sich wie ein Postfach, das Sie durchblättern. Jede Mail zeigt ihren Nachweis: die Kettenwerte, die letzte Kettenprüfung mit Ergebnis (gespeichert und im Audit-Log vermerkt) und den tatsächlichen Object-Lock-Zustand des Speichers. Das Journaling hält eine Mail fest, bevor Nutzer sie sehen. Repositories bekommen einen Zweck, Backup oder Archiv; ein Archiv-Repository verlangt Object Lock oder die ausdrückliche Bestätigung, dass es keins hat.
• Archiv-Nachweise und Endnutzer-Suche: ein Prüfer-Export mit Kettenwerten (CHAIN.txt), ein signierter PDF-Nachweisbericht, eine Wahl je Postfach zwischen „nur sichern“ und „sichern und archivieren“ sowie eine Selbstbedienungssuche, mit der Endnutzer die eigene Langzeit-Mail-Historie durchsuchen (zum Beispiel alles, was älter als 365 Tage, 2 Jahre oder 10 Jahre ist) und Treffer wiederherstellen oder herunterladen. Teilweise seit 0.4.2 da: Der Mail-Job-Editor fragt je Job, ob er sichert, archiviert oder beides; je Postfach ist nicht gebaut. Siehe Archivierung und Nutzung.
• Externe tägliche Anker für die Archiv-Kette: Die täglichen Anker der Hash-Kette des Archivs, per E-Mail versandt oder als RFC-3161-Zeitstempel. Seit 0.3.1 versiegelt der Worker jede Nacht einen Anker, und die Archivprüfung gleicht damit ab, aber die Anker bleiben in Restow: Noch versendet oder stempelt sie nichts extern. Geplant.
• Generator für die Verfahrensdokumentation: Ein Dokument je Mandant (Verfahrensdokumentation), erzeugt aus der tatsächlichen Konfiguration und einer Vorlage, als Markdown und PDF, versioniert und datiert. Die vollständige Verfahrensdokumentation bleibt Aufgabe Ihrer Organisation. Geplant.
• Anmeldung mit Microsoft und Single Sign-on (SSO) (ab Business): Anmeldung mit einem Microsoft-Konto für Personen, die bereits ein Restow-Konto haben, und Single Sign-on. Der Code für die Anmeldung existiert, aber noch nichts verknüpft ein Restow-Konto mit einer Microsoft-Identität, und Restow legt nie Konten an; heute kann sich also niemand mit Microsoft anmelden, und die Anmeldeseite bietet es nicht an. Die Kontoverknüpfung ist das fehlende Stück.
• White Label (Service Provider): Ihre Marke statt Restow, mit Produktname, Logos für hell und dunkel, Akzentfarbe, Anmeldeseite, Support-Kontakt und Absendername, festgelegt für die Installation und je Mandant überschreibbar. Gilt für die Oberfläche, das Endnutzer-Portal, E-Mails und PDF-Berichte. Grün bleibt für bestandene Restore-Prüfungen reserviert.

Später

Entschieden, weiter entfernt oder noch nicht begonnen, und keinem Release zugeordnet. Keine Versionsnummern und keine Termine.

Nachweis und Betrieb

• Dashboard der Wiederherstellbarkeit mit Trend: der Anteil nachweislich wiederherstellbarer Sicherungen, aufgeteilt nach Zustand, mit einem Trend über zwölf Wochen.

• Repository-Alarme: eine Warnung bei 80 Prozent und ein kritischer Alarm bei 90 Prozent der Kapazität eines Repositorys auf lokalen und NFS-Zielen, optional auch oberhalb einer selbst gesetzten Größe auf jedem Ziel, S3 eingeschlossen. Neue und bestehende Installationen bekommen diese Regeln vorbelegt. Seit 0.4.0 bekommen Provider-Admins bereits einen Hinweis „Wenig Speicherplatz“ für den Datenträger unter der Datenbank und unter dem lokalen Standard-Repository (bei weniger als einem Zehntel frei, und immer unter 5 GiB). Seit 0.4.5 deckt der Hinweis auch die Systemplatte des Servers ab, und die Seite Repositories, die Zeile „Sicherungen landen in:“ der Job-Editoren und die Speicherkachel des Dashboards warnen, wenn ein Verzeichnis-Repository auf ihr liegt.

• Kapazitätsplanung: Auslastung und Wachstum je Mandant und je Repository, mit einer klaren Prognose wie „voll in etwa N Tagen“. Über das hinaus, was das Dashboard seit 0.4.0 zeigt: das Speicherwachstum des Mandanten, den Sie ansehen, und, wo der freie Platz bekannt ist, wann sein Repository bei diesem Wachstum voll ist. Seit 0.4.5 sehen Provider-Admins auf der Speicherkachel des Dashboards außerdem, für ein Repository auf der Systemplatte, den freien Platz, seinen Verlauf über die letzte Woche und den Tag, an dem diese Platte voll wäre.

• PDF-Berichte: Wiederherstellbarkeit, ein Zeitraum (Backups, Restores, Prüfungen), das Audit-Log und die Mandanten als PDF, jeder Bericht im Audit-Log mit dem Hash der Datei vermerkt. Der Audit-Bericht kommt mit Business und Service Provider, die Mandantenberichte mit Service Provider.

• Signierter Wiederherstellungsnachweis (ab Business): ein Restore-Bericht mit Prüfsumme und Signatur, den jede und jeder ohne Restow prüfen kann.

• Vollständiger Test-Restore in ein separates Ziel, über die wöchentliche Stichproben-Rücklesung hinaus. Der optionale Test-Restore in ein Ziel ist heute nicht angeschlossen. Für Proxmox-VE-Gäste sind Startprüfungen von Sicherungsständen ausgeliefert (0.4.0); für Mail, OneDrive und Dateien gibt es nur die Stichproben-Rücklesung.

• Vier-Augen-Freigabe (ab Business): Eine zweite Person gibt Restores und Löschungen frei, bevor sie laufen.

• Rollenbezogene Archivsuche mit Vier-Augen-Freigabe: Ein Provider-Administrator durchsucht das Archiv eines Kunden erst nach Freigabe durch den Mandanten (Vier-Augen-Freigabe), aufbauend auf der Vier-Augen-Freigabe. Geplant.

• Aufbewahrungsrichtlinie je Mandant: Heute gilt für jeden Mandanten dieselbe feste Richtlinie: 8 Jahre, Fristende am 31. Dezember des Jahres des Eingangs. Geplant: eine Richtlinie je Mandant, wählbar als 6, 8 oder 10 Jahre oder unbegrenzt, optional je Postfach-Gruppe, mit Fristbeginn am Erfassungsdatum oder am Ende des Kalenderjahres.

• Archivsuche in Anhängen und nach Größe: Die Archivsuche deckt Betreff, Adressen und Nachrichtentext ab. Geplant: Suche in Anhängen (PDF, DOCX, XLSX, TXT) und nach Postfach und Größe.

• Löschprotokoll als Eintrag der Archiv-Kette: Jede Löschung nach Fristablauf steht heute im Audit-Log. Geplant: ein Löschprotokoll als eigener Eintrag der Hash-Kette, mit der Anzahl der Objekte, dem Zeitraum und den Hashes der gelöschten Objekte.

• Archivprüfung im Hintergrund, mit Fortschritt: Die Archivprüfung (Kette, Anker und eine Stichprobe der Inhalte) läuft heute in einer einzigen Anfrage. Geplant: ein Lauf im Hintergrund, der seinen Fortschritt zeigt.

• Legal Hold je Suchergebnis: Ein Legal Hold gilt heute für einen ganzen Mandanten oder ein Postfach, mit verpflichtender Begründung. Geplant: ein Hold auf ein Suchergebnis.

• Signiertes release.json: Jedes Release veröffentlicht zusätzlich ein maschinenlesbares release.json mit den Image-Digests, mit cosign signiert wie die Images, damit Update-Werkzeuge ein Release prüfen können, bevor sie es installieren.

• Selbstheilung, erste Stufe: Restow erkennt Probleme und ergreift von selbst sichere Maßnahmen: Es wiederholt, gibt veraltete Sperren frei, prüft erneut, liefert fehlende Daten mit einem neuen Backup nach und benachrichtigt Sie mit der genauen Abhilfe. Es löscht nie Daten und kürzt nie die Aufbewahrung, und jede Maßnahme ist im Audit-Log sichtbar. Drei enge Fälle gibt es: Seit 0.4.2 beginnt ein Container, dessen Repository fehlt, von selbst eine neue Sicherungskette (im Audit-Log festgehalten, auf der Seite des Gastes sichtbar; eine Dateifreigabe ist noch nicht abgedeckt), und die Speicherprüfung liest ein Pack, das sie nicht lesen konnte, erneut, bevor sie etwas als beschädigt wertet; seit 0.4.3 entfernt Restow veraltete restic-Sperren vor einer Restore-Prüfung von Proxmox VE und vor der Aufbewahrung und versucht eine Prüfung, die eine Sperre aussperrt, erneut, statt sie scheitern zu lassen. Der allgemeine Mechanismus mit Erkennung, sicheren Maßnahmen und Hinweisen zur Abhilfe im ganzen Produkt ist nicht gebaut.

• Dateisystem-Snapshots im Agent (LVM, ZFS und btrfs unter Linux, APFS unter macOS), damit Dateien, die sich während eines Backups ändern, konsistent bleiben. Heute entsteht Konsistenz über optionale Befehle vor und nach der Sicherung.

• Linux-Abbild-Backup auf Blockebene mit Bare-Metal-Restore. Heute sichert der Agent nur Dateien.

• Windows-Agent mit VSS und Abbild-Backup. Die Web-Oberfläche zeigt Windows heute als „Geplant“. Seit 0.4.0 sichert eine SMB-Freigabe einen Windows-Dateiserver vom Server aus, ohne Agent und ohne VSS.

• Remote-Knoten als Data Mover: Ein zweiter Rechner, etwa an einem anderen Standort, erledigt die Backup-Arbeit nah an den Daten und schreibt ins Repository. Knoten werden mit einem Assistenten hinzugefügt, signieren jede Anfrage mit ihrem eigenen Schlüssel und erhalten das Schlüsselmaterial nur je Aufgabe.

• Automatische Skalierung (Opt-in): Worker werden nach Schwellen hinzugefügt und entfernt, mit Abklingzeit und Höchstzahl.

Anbindungen und Formate

• Google-Workspace-Backup: Gmail und Google Drive, neben Microsoft 365 und IMAP. Noch nicht verfügbar.
• OAuth2 für IMAP-Quellen. Noch nicht umgesetzt; geplant. Die Anmeldung mit Passwort funktioniert heute.
• Agent-mTLS: ein Client-Zertifikat je Agent statt eines Geheimnisses je Agent. Heute meldet sich jeder Agent mit einem eigenen Secret über HTTPS an.
• PST- und OST-Import. Die Dateien werden erkannt und mit einer Erklärung abgelehnt. Bis dahin exportieren Sie aus Outlook als MSG oder EML oder wandeln nach MBOX um.
• PST-Export und MSG-Export von Mail. Der Export als EML in einer ZIP-Datei und als MBOX ist verfügbar.
• SFTP als Speicherziel.

Vorerst nicht geplant

Das sind bewusste Entscheidungen zum Umfang, keine Versehen: Microsoft-Teams-Chats, öffentliche Ordner, eDiscovery-Fallverwaltung und eine mobile App. SharePoint-Online-Websites standen früher auf dieser Liste; sie sind seit 0.4.0 ausgeliefert (siehe Ausgeliefert), auch die SharePoint-Websites hinter Teams. Seit 0.4.5 werden außerdem Kalender und Unterhaltungen der Microsoft-365-Gruppe hinter einem Team als Gruppenpostfach gesichert (Opt-in); Teams-Chats und Kanalnachrichten nicht. Disk-Images und Bare-Metal-Restore standen ebenfalls früher auf dieser Liste; seit dem 2. Oktober 2026 sind sie geplant, siehe Später. Die Sicherung von Servern und Clients unter Linux und macOS steht nicht auf dieser Liste: Sie ist in 0.1.0 enthalten (siehe Ausgeliefert). Der PST-Import steht ebenfalls nicht darauf: Er ist geplant (siehe Später). Nichts davon ist stillschweigend „kommt bald“ ohne genannten Plan.

Editionen

Community ist der Open-Source-Kern unter der Apache License 2.0, kostenlos und ohne Lizenzschlüssel: Backup, Restore und das Archiv (Hash-Kette mit Kettenprüfung, Suche über Betreff, Adressen und Nachrichtentext importierter Mail, gespeist durch Mail-Import mit Archivierung), dazu Endpoint-Backup für Server und Clients, Mail-Datei-Import und -Export, Fehlererklärungen und die Opt-in-Update-Prüfung sowie ein einfaches Betriebsprotokoll (Jobverlauf, Fehler). Jedes Lesen und jeder Restore wird in jeder Edition in das Audit-Log geschrieben. Restore ist nie durch Edition oder Postfachzahl eingeschränkt: Es gibt nirgends eine Postfach-Obergrenze. Business ist für eine Organisation lizenziert, Service Provider für beliebig viele Mandanten (Ihre eigenen Kunden); die Zahl der Postfächer und die Zahl der Mandanten begrenzt die Software technisch nicht. Seit 0.3.1 hat jede Edition mehrere Administratoren mit Rollen; ein Mitglied auf ausgewählte Mandanten zu beschränken gehört zu Service Provider. Proxmox-VE-Backup von VMs und Containern (seit 0.3.1) ist in jeder Edition eine Preview. Seit 0.4.0 hat jede Edition auch das Backup von Dateifreigaben, unveränderbare Backups, Ransomware-Erkennung, die Benachrichtigungsmatrix, Richtlinien für Agents und das Backup von SharePoint Online: Die Funktionen, die ein installierter Lizenzschlüssel freischaltet, haben sich mit 0.4.0 nicht geändert. Seit 0.4.4 gibt es eine Fähigkeit mehr, archive.mailboxCapture (Business und höher), die die Erfassung aus den Postfächern einschaltet; jede Lizenz von Business und Service Provider enthält sie ohne neuen Schlüssel, und der Community-Build lässt den Erfassungsdienst ruhen. Seit 0.4.5 kann ein Lizenzschlüssel einen Update-Zeitraum und eine Serie tragen: Jeder bisher ausgestellte Schlüssel ist eine Beta-Lizenz, die jedes 0.x- und 1.x-Release abdeckt, die Update-Prüfung und der Start eines Releases beachten die Bedingungen eines Schlüssels mit Update-Zeitraum, und Installation → Lizenz zeigt sie; die Fähigkeiten, die ein Schlüssel freischaltet, haben sich seit 0.4.4 nicht geändert (siehe Lizenz und Editionen). Business ergänzt die für den GoBD-konformen Einsatz ausgelegte Schicht des Archivs (Journal-Empfang, durchgesetzte Aufbewahrung, Legal Hold), die Audit-Log-Ansicht und zeitgesteuerte Berichte (alles verfügbar seit 0.1.0), den Audit-Log-Export (seit 0.3.1) und, seit 0.4.4, die Erfassung aus den Postfächern (Microsoft 365 per Graph, IMAP und Google Workspace per IMAP-Abgleich; zeitnah) und weitergeleitete Kopien, dazu die Anmeldung mit Microsoft und Single Sign-on (SSO) (geplant, Als Nächstes) und Vier-Augen-Freigabe und einen signierten Wiederherstellungsnachweis (geplant, Später). Service Provider ergänzt mehrere Mandanten, die mandantenübergreifende API, delegierte Mandanten-Administrationen, die Provider-Übersicht über alle Mandanten und die Beschränkung eines Mitglieds auf ausgewählte Mandanten (alles verfügbar); White Label ist geplant (Als Nächstes), und seit 0.4.0 listen die Jobs-Seiten unter „Alle Mandanten“ die Jobs jedes Mandanten auf. Die Funktionen von Business und Service Provider liegen unter ee/ im selben Repository und gehören zu den vollständigen Images; sie sind quelloffen einsehbar (source-available), und der Produktivbetrieb setzt einen Lizenzschlüssel unter den Restow-Lizenzbedingungen voraus, installiert unter Installation → Lizenz. Business und Service Provider werden bis zum allgemeinen Release zum Vorverkaufspreis verkauft; siehe Preise auf restowbackup.com und Lizenz und Editionen. Eine Live-Demo mit synthetischen Daten läuft unter demo.restowbackup.com.