-
Dateifreigaben (SMB und NFS)
-
Backup und Restore von Dateifreigaben
Sichert eine SMB-Freigabe (Windows Server, Samba, ein NAS) oder einen NFS-Export vom Server aus, ohne Agent auf dem Dateiserver. Restow bindet sie für die Dauer eines Laufs schreibgeschützt in einem kurzlebigen Runner-Container ein, den der Mounter startet, und hält NTFS-Berechtigungen (bei NFSv4 und POSIX ACLs nach bestem Bemühen) in jedem Sicherungsstand fest. Geöffnete, nicht lesbare und Offline-Dateien werden übersprungen und aufgelistet; der Lauf endet dann mit Warnungen. Wiederherstellen 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 bekommt ihn über „Netzlaufwerke einschalten“. Im Release-Smoke-Lauf gegen Samba getestet, nicht gegen Windows Server, eine Synology- oder TrueNAS-Freigabe, echte NFS-Exporte oder einen Host mit SELinux im Enforcing-Modus. Kein VSS über SMB: Dateien, die mit exklusiver Sperre geöffnet sind, werden übersprungen.
0.4.0
Jede Edition
-
Dateifreigaben: Restore-Prüfungen, Kopierjobs und Budgets
Jeder neue Sicherungsstand wird geprüft, indem bis zu 20 Stichproben-Dateien zurückgelesen und verglichen 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, im Modus Überschreiben oder Spiegeln; ein Kopierjob führt keine Versionen und ist 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. Noch nicht: andere Repositories als das primäre, Self-Service-Restore für Mandantenbenutzer und ein Freigaben-Block in zeitgesteuerten Berichten.
0.4.0
Jede Edition
-
Schutz vor Ransomware und Missbrauch
-
Unveränderbare Backups
Unveränderbarkeit je Repository, aus, bis ein Administrator sie einschaltet (Repositories, „Unveränderbarkeit ändern“). 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, behandelt eine vom Speicher verweigerte Löschung als „noch nicht“ 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; Prüfergebnisse und Warnungen erscheinen auf der Repository-Karte, im Dashboard und in der Provider-Ansicht. Den Schutz zu senken braucht den Provider-Inhaber mit einer frischen Anmeldung. Gegen ein simuliertes S3 mit Object Lock getestet, noch nicht gegen einen echten Dienst; das Standard-Repository der Installation lässt sich nicht unveränderbar machen.
0.4.0
Jede Edition
-
Ransomware-Erkennung mit angehaltener Aufbewahrung
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 sowie 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, damit saubere ältere Sicherungsstände nicht gelöscht werden, während verschlüsselte sich anhäufen; nur ein Administrator beendet das (Fehlalarm 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“. Nach dem Update eingeschaltet, mit Schwellen und Schaltern unter Installation, Ransomware-Erkennung. Mit simulierten Angriffen getestet, nicht mit echter Ransomware.
0.4.0
Jede Edition
-
S3-Endpunkte brauchen HTTPS
Ein neuer oder geänderter S3-Endpunkt über unverschlüsseltes http:// wird abgelehnt, auch für Provider-Admins und den Standard der Installation, 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.
0.4.0
Jede Edition
-
Benachrichtigungen
-
Benachrichtigungsmatrix
Unter Integrationen, Benachrichtigungen sind die Ereignisse die Zeilen, nach Schweregrad gruppiert und markiert, und die Glocke, jeder Webhook und jeder Benachrichtigungsempfänger die Spalten, jeweils mit den Schnellauswahlen „Nur Fehler“, „Fehler und Warnungen“ und „Alle“. Das Speichern wird protokolliert. Das Update füllt jede Spalte mit genau dem, was der Kanal vorher bekam, sodass sich zunächst nichts ändert; ein danach angelegter Webhook startet mit den Voreinstellungen seines Formats, und eine Alarmregel sendet ein Ereignis nicht mehr an einen Kanal, dessen Spalte es ausgeschaltet hat. Neue Ereignisse: backup.succeeded und verify.completed für Mail und die Glocke, backup.suspicious und backup.suspicious_hold, boot_test.failed und boot_test.unproven sowie installation.disk_low für Provider-Admins.
0.4.0
Jede Edition
-
Proxmox VE (Preview)
-
Proxmox VE: Fortschritt einer laufenden Sicherung
VMs & Container, das Inventar und die Seite eines Gasts zeigen einen Fortschrittsbalken („34% · 3,2 GB von 9,4 GB · 85 MB/s“), und die eigenen Zeilen des Helfers (die Lauf-ID, was restic hinzugefügt hat, was es nicht lesen konnte) gelangen in das Log des Laufs; eine Sicherung, die mit Lücken erfolgreich war, nennt die ersten 20 nicht lesbaren Elemente. Container-Sicherungen lassen restic jetzt zuerst scannen, sodass es eine Gesamtmenge gibt, gegen die sich der Fortschritt zeigen lässt. Braucht restow-pve 0.4.0 auf dem Knoten. Gegen den simulierten Knoten der Testsuiten getestet, nicht gegen einen echten Proxmox-VE-Knoten.
0.4.0
Jede Edition
-
Proxmox VE: Startprüfungen von Sicherungsständen
Ein Proxmox-VE-Job kann den neuesten Sicherungsstand jedes Gasts wöchentlich oder nach jeder Sicherung booten (standardmäßig aus; standardmäßig ein Speicherlimit von 8 GiB und fünf Minuten Wartezeit auf den Gast-Agent), und „Jetzt Start prüfen“ fordert eine Prüfung von Hand an. Der Knoten stellt ihn als neuen Gast im Pool restow-restore wieder her, isoliert ihn vor dem Start (Netzwerkverbindungen getrennt, Passthrough-Geräte, serielle Ports, Bind-Mounts und das Hook-Skript entfernt), wartet auf den QEMU-Gast-Agent und zerstört ihn in jedem Fall. Grün, wenn der Gast-Agent geantwortet hat, gelb, wenn die VM nur gestartet ist, rot, wenn Wiederherstellung, Start oder Boot fehlschlugen; die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand nach seiner Startprüfung. Eine Prüfung je Knoten zur Zeit, nie neben einer Sicherung. Braucht restow-pve 0.4.0; gegen den simulierten Knoten getestet, nicht gegen einen echten Proxmox-VE-Cluster.
0.4.0
Jede Edition
-
Proxmox VE: Datei-Restore von Containern und VMs (Vorschau)
Unter Server & Clients, Datei-Restore ist jeder Container mit einem Sicherungsstand in der Gruppe „Proxmox-VE-Container“ aufgeführt und jede VM in „Proxmox-VE-VMs“, mit „Vorschau“ markiert: einen Sicherungsstand durchsuchen und Dateien und Ordner als eine ZIP-Datei herunterladen, vom Server aus dem Repository des Gasts gelesen; Lesen und Herunterladen werden protokolliert. Bei VMs ist jedes lesbare Dateisystem der Festplatten ein Ordner (GPT- und MBR-Partitionen und lineare LVM-Volumes mit ext2, ext3, ext4, XFS, NTFS oder FAT), gelesen in einem eingeschränkten Kindprozess, ohne dass auf dem Server oder dem Knoten etwas eingebunden wird. Nicht lesbar: btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker und LUKS, NTFS-komprimierte und EFS-Dateien; die Logs von XFS und NTFS werden nicht abgespielt, vergleichen Sie also eine wichtige Datei mit dem Original, bevor Sie sich darauf verlassen. Einzelne Dateien in einen laufenden Gast zurückzuspielen ist nicht gebaut.
0.4.0
Jede Edition
-
Proxmox-VE-Jobs unter Server & Clients
Proxmox-VE-Jobs erscheinen unter Server & Clients, Jobs neben den Rechner-Jobs, mit einer Spalte Typ, den Gästen je Job, Zeitplan, letztem und nächstem Lauf und „2 von 5 Gästen fertig“, während eine Runde läuft; eine von Hand gestartete Sicherung erscheint als Zeile, bis sie endet. „Neuer Job“ ist ein Menü mit einem Eintrag je Typ, und das Formular des Proxmox-VE-Jobs listet die VMs und Container auf, die in den Job kommen. Auf der Seite eines Gasts steht, was eine Folgesicherung im Schnitt hinzufügt.
0.4.0
Jede Edition
-
Server und Clients
-
Richtlinien für Agents
Regeln für die Agents auf Servern und Clients auf drei Ebenen: die Installation (Installation, Richtlinie der Agenten), der Mandant und der Backup-Job. Jede Ebene darf eine Einstellung überschreiben, sofern die Installation sie nicht sperrt, und jede Ansicht sagt, woher ein Wert kommt. Die Einstellungen: ein Sicherungsfenster (Wochentage und ein Zeitraum), in dem geplante Sicherungen, Nachholläufe und Wiederholungen starten dürfen; „Verpasste Sicherungen nachholen“, sobald der Rechner wieder an ist oder im nächsten Fenster, auf Wunsch nur bis zu einem Höchstalter; ein Upload-Limit für Jobs ohne eigenes; „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; Upload-Limit und Netzteil erreichen auch ältere Agents. Nur gegen simulierte Dienste getestet.
0.4.0
Jede Edition
-
Datei-Restore für die Restore-Rolle
Restore-Operatoren (die Restore-Rolle eines Mandanten) öffnen Server & Clients, Datei-Restore: Sie listen die Rechner auf, lesen deren Sicherungsstände und Unveränderbarkeit, durchsuchen sie, laden Dateien als ZIP herunter und stellen Dateien auf dem Rechner wieder her. Bei Proxmox VE lesen sie die Übersicht und die Sicherungsstände eines Gasts und durchsuchen und laden Dateien von Container- und VM-Sicherungsständen herunter. 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 mit dem Operator als Akteur protokolliert.
0.4.0
Jede Edition
-
Datenordner, die ein Job auslässt, und als was ein Rechner läuft
Der Agent 0.4.0 meldet, welche Ordner aus einer festen Liste von Linux-Datenordnern (/opt, /usr/local, /srv, /var/www, Docker- und Podman-Volumes, die PostgreSQL-, MySQL- und MongoDB-Ordner unter /var/lib) 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), und ein Linux-Rechner in einem Container oder einer virtuellen Maschine ohne Desktop bekommt das Server-Profil; der Datei-Browser eines Sicherungsstands sagt, welche Ordner er enthält.
0.4.0
Jede Edition
-
Jobs, Live-Ansicht und Dashboard
-
Empfohlenen Job anlegen
Neben jedem Hinweis „kein Job“ (Jobs, Inventar, Quellen, Verzeichnis, VMs & Container) 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 alle 8 Stunden; Rechner je System und Profil; ein Proxmox-VE-Job, täglich um 22:00 im Snapshot-Modus). Ein zweiter Klick ergänzt denselben Job, statt einen neuen anzulegen. Nur für Administratoren, im Audit-Log vermerkt.
0.4.0
Jede Edition
-
Laufende Sicherungen in der Seitenleiste und eine lebendigere Lauf-Schublade
Die Einträge Jobs und VMs & Container zeigen einen Spinner mit der Zahl der laufenden und der wartenden Sicherungen; der Tooltip listet sie auf, ein Klick öffnet den Lauf. In der Lauf-Schublade bewegen sich die Diagramme mit der Zeit zwischen den Messungen, die Zahlen zählen hoch, die Restzeit läuft herunter, und eine Zeile sagt, wann der Lauf sich zuletzt gemeldet hat (oder dass Microsoft Graph ihn drosselt). Die erste Sicherung eines großen Postfachs zeigt „Erste Sicherung: X von Y Elementen“ über alle Versuche, mit geschätzter Restzeit; ein OneDrive zeigt „X Elemente bisher“, bis es vollständig aufgelistet ist.
0.4.0
Jede Edition
-
Alle Mandanten in Jobs
Unter „Alle Mandanten“ listen Jobs von Mail & SaaS und von Server & Clients jeden Mandanten mit seinen Jobs je Art, was läuft und wartet, wie die neuesten Sicherungen endeten und dem nächsten Lauf, mit Filtern und Sortierung; eine Zeile öffnet die Jobs des Mandanten schreibgeschützt. Die Ansicht bleibt auf großen Installationen schnell, weil sie über einen Index liest und die Zahlen jedes Mandanten 30 Sekunden vorhält.
0.4.0
Service Provider
-
Speicherwachstum im Dashboard
Das Dashboard zeigt, wie die gespeicherten Daten eines Mandanten über 1 Woche, 1 Monat, 3 Monate oder 1 Jahr gewachsen sind; ab 3 Monaten ist die Schätzung ein Band zwischen dem langsamsten und dem schnellsten Wachstum, und wo der freie Platz bekannt ist, sagt es, wann das Repository bei diesem Wachstum voll ist.
0.4.0
Jede Edition
-
Microsoft 365
-
SharePoint Online: Backup und Restore von Websites
Jeder Verzeichnisabgleich findet die SharePoint-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 wie Postfächer und OneDrives; die Schutzregeln haben einen Websites-Modus, alle Websites oder ausgewählte. Ein Backup enthält jede Dokumentbibliothek (auf Wunsch mit Versionen), jede Liste mit ihren Spalten und den Feldwerten jedes Elements als JSON sowie die Beschreibung der Website. Restore im Explorer: Download als ZIP; Dateien und Ordner in die ursprüngliche oder eine andere Bibliothek einer gesicherten Website (beide behalten, überschreiben, wobei SharePoint die alte Datei als Version behält, oder vorhandene überspringen); Listenelemente als neue Elemente in ihre ursprüngliche Liste, nur beschreibbare Felder. Nicht gesichert oder wiederhergestellt: Teams-Chats, Anhänge von Listenelementen, Website-Design, Navigation und Workflows; Berechtigungen werden als Information festgehalten und nie wiederhergestellt; eine gelöschte Website oder Bibliothek wird nicht neu angelegt. Braucht die Anwendungsberechtigung Sites.ReadWrite.All (Sites.Read.All genügt zum Sichern) und eine neue Admin-Zustimmung je Mandant. Gegen ein simuliertes Microsoft Graph getestet, nicht gegen einen echten Microsoft-365-Mandanten.
0.4.0
Jede Edition
-
Updates, Datenbank und Speicher
-
Laufende Sicherungen während eines Updates
Der Installationsdialog zählt, was in jedem Mandanten läuft und wartet, und fragt, was geschehen soll: „Sauber anhalten“ (die Voreinstellung: Läufe von Microsoft 365 und Mail speichern einen Checkpoint und halten an; auf Läufe von Agents und Freigaben wird gewartet, höchstens 30 Minuten), „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, und Zeitpläne, die in der Zwischenzeit fällig werden, laufen danach; alle angemeldeten Personen sehen ein Banner. Agents 0.4.0 halten ihre eigenen Zeitpläne an und warten; Agents vor 0.4.0 tun das nicht, sodass eine Sicherung, die ein solcher Rechner während eines Updates selbst startet, scheitern kann, wenn die API darunter neu startet. Eine Proxmox-VE-Sicherung, die während eines Restow-Updates läuft, scheitert nicht mehr: Der Knoten versucht es fünf Minuten lang weiter.
0.4.0
Jede Edition
-
Datenbank auf einen anderen Datenträger verschieben
Installation, Datenbank zeigt, wo die Datenbank ihre Daten hält, ihre Größe, den freien Platz darunter und unter dem lokalen Standard-Repository und was das nächste Update braucht. Mit dem optionalen Updater verschiebt der Provider-Inhaber die Datenbank in ein Verzeichnis auf einem anderen Datenträger: zuerst geprüft (ein anderes lokales Dateisystem, ext4, XFS, Btrfs oder ZFS, Platz für die Daten), dann kopiert, Datei für Datei verglichen, probeweise gestartet und umgeschaltet, mit automatischem Rollback bei jedem Fehler; die alte Kopie bleibt erhalten und wird am Start gehindert, bis sie entfernt ist. Der Preflight des Updaters addiert jetzt, was ein Update schreibt, und lehnt eines ab, das nicht passt; der Reiter Updates listet die Dumps vor dem Update (der Inhaber kann einen herunterladen oder löschen). Das Verschieben wurde vor dem Release nicht über einen echten Updater und seinen Docker-Helfer getestet.
0.4.0
Jede Edition
-
Warnung bei wenig Speicherplatz
Alle 15 Minuten prüft die API den Datenträger unter der Datenbank (über den Updater) und unter dem lokalen Standard-Repository. Bei weniger als einem Zehntel frei, und immer unter 5 GiB, bekommen Provider-Admins einen Hinweis in der Glocke, und Alarmregeln, die „Wenig Speicherplatz“ aufführen, senden ihn, einmal je Vorfall.
0.4.0
Jede Edition
-
Leistung auf großen Installationen
Der Speicherbedarf bleibt unabhängig von der Größe begrenzt: Der erste Katalog einer Freigabe wird in Paketen zu 5.000 Dateien in die Datenbank gestreamt, die Wiederverwendung der SMB-Berechtigungen hält einen kompakten Index, sodass Freigaben mit Millionen Dateien nicht mehr am Speicher scheitern, SharePoint-Websites mit Tausenden Listen brauchen keine quadratische Zeit mehr, die Blockkarten durchsuchter VM-Festplatten werden nach Größe zwischengespeichert, und die Erneuerung von Object Lock sendet 32 Anfragen gleichzeitig und setzt einen unterbrochenen Durchlauf dort fort, wo er stehen blieb. Die Ransomware-Beurteilung und die Ansicht „Alle Mandanten“ der Jobs lesen über Indizes.
0.4.0
Jede Edition
-
0.4.1
-
Gespeicherte Daten zählen die restic-Repositories mit
Repositories, Nutzung, die Kachel „Gespeichert“ im Dashboard, die Statistik und die API zählten nur die Packs des Chunk-Stores: Ein Mandant mit 10 GB Container-Backups sah „Gespeichert 10,9 kB“. „Gespeichert“ addiert jetzt die restic-Repositories von Rechnern, Freigaben und Proxmox-VE-Containern, und die Nutzungskarte zeigt, wie viel im Chunk-Store und wie viel in restic-Repositories liegt. Die Größe des Repositorys eines Containers wird beim ersten Upload nach dem Update einmal gemessen, danach je Upload und Löschung mitgezählt und nach einer Bereinigung erneut gemessen. Die Deduplizierungs-Ersparnis, das Wachstum und das Diagramm bleiben Zahlen des Chunk-Stores und sagen das; die Größe eines Repositorys hat keinen Verlauf, und „Geschützte Daten“ zählt weiter nur die Quellen des Chunk-Stores.
0.4.1
Jede Edition
-
Proxmox VE: Ein alter Knoten-Helfer wird benannt
Eine laufende Container-Sicherung auf einem Knoten mit restow-pve vor 0.4.0 zeigte während ihres ganzen Laufs „Noch kein Fortschritt gemeldet“. Jetzt steht dort, dass der Fortschritt restow-pve 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, statt erst nach sechs Stunden; das Update wartet weiterhin, bis keine Sicherung und kein Restore läuft.
0.4.1
Jede Edition
-
0.4.2
-
Eine Sicherung in der Oberfläche stoppen
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.
0.4.2
Jede Edition
-
Knoten und Agenten ziehen bei einem Server-Update nach
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 <Version> 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.
0.4.2
Jede Edition
-
Geplante Updates und eine Zeitzone der Installation
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 <Version> verfügbar“, das zu Installation › Updates führt, für alle, die Updates einspielen dürfen.
0.4.2
Jede Edition
-
Proxmox VE: Jeder neue Sicherungsstand wird binnen Minuten geprüft
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.
0.4.2
Jede Edition
-
Proxmox VE: Neue Sicherungskette für einen Container, dessen Repository fehlt
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 <Datum> begonnen“) 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.
0.4.2
Jede Edition
-
Proxmox VE: Job-Rhythmen, die VM des Restow-Servers und Sicherungen mit Warnungen
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.
0.4.2
Jede Edition
-
Wo Sicherungen landen, wird angezeigt
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).
0.4.2
Jede Edition
-
Ein Speicher-Umzug nimmt die restic-Repositories mit
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.
0.4.2
Jede Edition
-
Speicherprüfung: Vorübergehend nicht lesbar ist nicht beschädigt
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).
0.4.2
Jede Edition
-
Restore-Explorer: ein Eintrag je Person und ein Kalender nach Monaten
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.
0.4.2
Jede Edition
-
Mail-Job-Editor: sichern, archivieren oder beides
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. Seit 0.4.4 bietet der Editor je Art von Postfach auch die dazu passenden Erfassungswege an (siehe 0.4.4).
0.4.2
Jede Edition
-
0.4.3
-
Proxmox VE: VMs & Container in Reitern, mit Suche, Filtern und Detailbereich
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.
0.4.3
Jede Edition
-
Proxmox VE: Ein gesperrtes Repository lässt keine Restore-Prüfung mehr fehlschlagen
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.
0.4.3
Jede Edition
-
Knoten und Agenten jetzt aktualisieren
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.
0.4.3
Jede Edition
-
Proxmox VE: restow-pve startet die Proxmox-VE-Dienste nach einer Selbstaktualisierung neu
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.
0.4.3
Jede Edition
-
Updates: Kein falsches „Der Updater läuft nicht“ mehr
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.
0.4.3
Jede Edition
-
0.4.4
-
Archiv-Erfassung: Microsoft 365 per Graph-Änderungsbenachrichtigungen
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.
0.4.4
BusinessService Provider
-
Archiv-Erfassung: IMAP und Google Workspace per IMAP-Abgleich mit IDLE
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.
0.4.4
BusinessService Provider
-
Weitergeleitete Kopien ins Archiv
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).
0.4.4
BusinessService Provider
-
Ein archiviertes Element je Mail, egal über wie viele Wege sie erfasst wurde
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.
0.4.4
BusinessService Provider
-
Mail-Job-Editor: nur die Erfassungswege, die zum Postfach passen
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.
0.4.4
Jede Edition
-
Archiv-Seite: Erfassungsstatus, Hold-Bestätigung, PowerShell-Befehle und Weiterleitungsadressen
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.
0.4.4
BusinessService Provider
-
Warnungen, wenn die Archiv-Erfassung stockt
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.
0.4.4
BusinessService Provider
-
Grenzen des Journal-Empfängers und eine Archiv-Kette, die sich nicht mehr gabelt
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.
0.4.4
BusinessService Provider
-
Restore-Explorer: Große Postfächer und OneDrives öffnen sich in Millisekunden
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).
0.4.4
Jede Edition
-
Proxmox VE: Der Job-Dialog passt auf einen Desktop-Bildschirm
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.
0.4.4
Jede Edition
-
0.4.5
-
Lizenzschlüssel mit Update-Zeitraum
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.
0.4.5
BusinessService Provider
-
Das Image trägt sein Release-Datum
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.
0.4.5
Jede Edition
-
Update-Prüfung und Start beachten den Update-Zeitraum
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.
0.4.5
BusinessService Provider
-
Lizenzseite: Update-Bedingungen, Hinweis vor dem Ende und Verlängerung
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.
0.4.5
BusinessService Provider
-
Öffentliche Demo: schneller nächtlicher Reset
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.
0.4.5
Jede Edition
-
Einen gesperrten Rechner aus Restow entfernen, mit oder ohne seine Sicherungen
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.
0.4.5
Jede Edition
-
Einen verschwundenen Rechner sperren, und ein Vorschlag dazu
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“.
0.4.5
Jede Edition
-
Warnung, wenn ein Verzeichnis-Repository auf der Systemplatte liegt
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.
0.4.5
Jede Edition
-
Microsoft-365-Gruppen als geschützte Objekte: Kalender und Unterhaltungen
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.
0.4.5
Jede Edition
-
Gruppenkalender und Unterhaltungen: was ein Backup enthält
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.
0.4.5
Jede Edition
-
Gruppenkalender und Unterhaltungen: Restore, Download und Export
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.
0.4.5
Jede Edition
-
Jetzt starten und Stoppen an jedem Job
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.
0.4.5
Jede Edition
-
Detailbereiche im Inventar und in den Joblisten
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.
0.4.5
Jede Edition
-
Abhängigkeiten: Übersetzungsbibliotheken und der Microsoft-Token-Code
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.
0.4.5
Jede Edition
-
Korrekturen: Anhänge-Ordner im Restore-Explorer, Job-Dialog von Proxmox VE auf dem Telefon, Demo-Reset
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.
0.4.5
Jede Edition
-
Prüfung von Entra-Tenant und IMAP-OAuth2-Geheimnis
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.
0.4.5
Jede Edition
-
0.4.6
-
Proxmox VE: Der Restore eines Containers funktioniert auf aktuellem Proxmox VE
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.
0.4.6
Jede Edition
-
Ransomware-Erkennung: Eine neue Sicherungskette wird nicht mehr markiert
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“.
0.4.6
Jede Edition
-
Entfernte Rechner behalten ihre Sicherungen durchsuchbar
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.
0.4.6
Jede Edition
-
„Prüfung eingereiht“, solange eine Restore-Prüfung wartet
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.
0.4.6
Jede Edition
-
Fehlertexte öffnen sich in einer Karte, die sich kopieren lässt
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.
0.4.6
Jede Edition
-
0.4.7
-
Microsoft 365: Deaktivierte, unlizenzierte und gesperrte Objekte stehen als „Nicht gesichert“, mit Grund
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.
0.4.7
Jede Edition
-
Nicht mehr gesichert, bitte bestätigen
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.
0.4.7
Jede Edition
-
Integrations-API 1.7.0: orphaned heißt jetzt auch „nicht mehr gesichert“
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.
0.4.7
Jede Edition
-
Sicherungen, die Microsoft Graph oder der Speicher gebremst haben, zählen nicht mehr als fehlgeschlagen
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.
0.4.7
Jede Edition
-
Eine der Microsoft-365-App erteilte Berechtigung wirkt ohne neues Client-Secret
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.
0.4.7
Jede Edition
-
Eine wartende Sicherung blockiert nicht mehr die Sicherungswarteschlange aller Mandanten
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.
0.4.7
Jede Edition
-
Erinnerungen, bevor das Client-Secret oder das Zertifikat einer App-Registrierung abläuft
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.
0.4.7
Jede Edition
-
Postfach, OneDrive, SharePoint und IMAP: Ein Fehler kostet einen Bereich oder ein Element, nicht den ganzen Lauf
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.
0.4.7
Jede Edition
-
Restores, die nichts wiederhergestellt haben, werden nicht mehr als abgeschlossen gemeldet
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).
0.4.7
Jede Edition
-
Wiederherstellbarkeit und überfällige Sicherungen: entfernte Objekte, Mitglieder mit eigenem Zeitplan, laufende Sicherungen
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.
0.4.7
Jede Edition
-
Proxmox VE: Einen Gast bewusst von der Sicherung ausschließen
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.
0.4.7
Jede Edition
-
Proxmox VE: Größe der ersten Sicherung und einer Folgesicherung als Text im Inventar
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.
0.4.7
Jede Edition
-
Empfohlener Job mit dem Mail-Archiv
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.
0.4.7
Jede Edition
-
Monatspreise und eine Preisschätzung je Mandant für Provider
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.
0.4.7
Jede Edition
-
Korrekturen: Restores von IMAP und Listen, Zeitlimits von Jobs, Demo-Seed, Formulierungen
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.
0.4.7
Jede Edition
-
Abhängigkeiten: better-auth, Mail-Bibliotheken, Vite, React und die Build-Werkzeuge
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.
0.4.7
Jede Edition
-
Hinweise zu Abhängigkeiten: ip-address, seroval und zod
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.
0.4.7
Jede Edition
Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am