Backup und Restore

Was gesichert wird

Exchange Online: Mail, Kalender und Kontakte, inkrementell über Microsoft-Graph-Delta-Abfragen.
OneDrive: Dateien, einschließlich älterer Dateiversionen, die Restow erfasst hat, inkrementell über Microsoft Graph.
SharePoint-Online-Websites (seit 0.4.0): jede Dokumentbibliothek, jede Liste mit ihren Spalten und den Feldwerten jedes Listenelements sowie die Beschreibung der Website, über Microsoft Graph. Websites von Microsoft-365-Gruppen und Teams sind dabei; persönliche Websites sind die OneDrives. Es braucht eine zusätzliche Berechtigung und einen neuen Admin-Consent je Tenant. Siehe SharePoint Online.
Microsoft-365-Gruppen (seit 0.4.5, Opt-in): der Gruppenkalender und jeder Beitrag jeder Unterhaltung einer Microsoft-365-Gruppe und der Gruppe hinter einem Team, als eigenes geschütztes Objekt, über Microsoft Graph. Sie brauchen keine neue Berechtigung. Siehe Microsoft-365-Gruppen.
IMAP-Postfächer: Mail, über IMAP, heute passwortbasiert (OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant).
Server und Clients: Dateien, über den Restow-Agent unter Linux und macOS, in restic-Repositories in Ihrem Speicherziel. Siehe Endpoint-Backup.
Dateifreigaben (SMB und NFS) (seit 0.4.0): vom Server aus gesichert, ohne Agent auf dem Dateiserver, mit ihren Berechtigungen (NTFS, sowie NFSv4- oder POSIX-ACLs nach bestem Bemühen), in restic-Repositories. Siehe Dateifreigaben.
VMs und Container von Proxmox VE (eine Preview, seit 0.3.1, in jeder Edition): VM-Festplatten als geänderte Blöcke, Container über restic, ab Proxmox VE 8.4. Eine Wiederherstellung legt einen neuen Gast neben dem Original an; seit 0.4.0 können Sie außerdem einen Sicherungsstand durchsuchen und einzelne Dateien eines Containers oder einer VM herunterladen (der VM-Teil ist eine Preview) und den neuesten Sicherungsstand eines Gasts isoliert als Test starten. Siehe Proxmox-VE-Backup.

Mail, die Sie aus Dateien importieren, wird nirgends gesichert: Sie liegt als importiertes Postfach im selben Format wie eine IMAP-Sicherung (siehe Mail-Dateien importieren und exportieren).

Jeder Sicherungslauf eines Postfachs, OneDrive, einer SharePoint-Website, einer Microsoft-365-Gruppe oder eines IMAP-Kontos wird inhaltsbasiert zerlegt (Content-Defined Chunking), innerhalb eines Mandanten dedupliziert und verschlüsselt, bevor er den Speicher erreicht (AES-256-GCM, ein Schlüssel je Mandant), und erzeugt einen Snapshot, einen Zeitpunkt, den Sie später durchsuchen und aus dem Sie wiederherstellen können: eine einzelne Mail, einen Ordner, eine Datei, eine ältere Dateiversion oder ein ganzes Postfach/OneDrive/IMAP-Konto. Bei einer SharePoint-Website sind das Bibliotheken, Ordner, Dateien, Listen und Listenelemente. Wie Läufe ausgelöst und geplant werden, steht unter Backups und Zeitpläne.

Teilausfälle kosten einen Bereich oder ein Element (seit 0.4.7)

Eine Ablehnung oder eine kaputte Antwort von Microsoft oder von einem IMAP-Server kostet jetzt den kleinsten Teil, den sie trifft, nicht den ganzen Lauf, und ein Lauf, der nicht weitergehen kann, hält an einem Checkpoint an und setzt dort fort. Die Lauf-Seite und die Fehlererklärungen sagen, was passiert ist.

Postfach. Ein 403 für Kalender oder Kontakte (eine fehlende Berechtigung oder eine Zugriffsrichtlinie, die nur Mail umfasst) lässt diesen Bereich fehlschlagen und behält die Mails des Laufs, statt den Sicherungsstand zu verwerfen. Ein 401 mitten im Lauf setzt einen Checkpoint und macht weiter, statt eine angefangene erste Sicherung aufzugeben. Ein bekannter Ordner, den Graph nicht auflösen will (400, 403), gilt als nicht vorhanden und steht nur im Log des Workers, und ein gespeicherter Delta-Link, den Graph als ungültigen Sync-Zustand ablehnt (400), 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, wird als Fehler des Elternordners erfasst und lässt den Lauf nicht mehr scheitern.
SharePoint. Eine Bibliothek oder Liste, die Graph nicht liefert (400, 501 oder ein andauerndes 500 bei einer Listenvorlage oder den Berechtigungen einer Bibliothek), ist ein Element-Fehler, der ihre letzte Kopie behält, und der Rest der Website bekommt seinen Sicherungsstand. Ein 500 oder 502 für den Inhalt einer Bibliothek lässt den Job weiterhin scheitern, der an seinem Checkpoint fortsetzt, und eine fortgesetzte Website zählt die Element-Fehler der Bibliotheken, die ein früherer Versuch beendet hat. Eine Bibliothek, die weg ist, heißt nicht mehr „dieser Benutzer hat kein OneDrive“.
OneDrive- und SharePoint-Dateien. Ein Element, das fehlschlug und im selben Lauf später durchkam (zweimal in einem Delta-Feed aufgelistet oder wiederholt), bleibt nicht mehr unter den Fehlern, Dateien, die ein Host komprimiert sendet, gelten nicht mehr als abgeschnittene Downloads, und das Abbrechen eines Jobs während einer Drosselungswartezeit erfasst keine Elemente mehr als fehlgeschlagen. Ein OneDrive, dessen Laufwerk Graph nicht mehr findet (der Nutzer wurde gelöscht, oder die Aufbewahrung ist vorbei), scheitert als graph.onedrive_unavailable, dauerhaft und ohne Wiederholung, statt als Element.
IMAP. Eine Anmeldung oder ein Lesebefehl, den der Server wegen eines Limits ablehnt (zu viele Verbindungen für das Konto, ein ausgefallenes Authentifizierungs-Backend, ein Download-Limit), ist imap.server_limit, vorübergehend und von selbst wiederholt, statt eines falschen Passworts oder eines vollen Postfachs; ein solches Limit lässt den Ordner als Ganzes fehlschlagen, und der nächste Lauf setzt fort. Nachrichten, die während der Sicherung gelöscht oder verschoben wurden, zählen nicht als Fehler, und ein Lauf, dessen Verbindung zu oft abbrach, scheitert als imap.connection_lost. In der Archiv-Erfassung hält eine Nachricht, die der Server ablehnt oder nicht liefert, ihren Ordner oder den Durchlauf nicht mehr auf, und die Erfassung gibt sie nach drei Durchläufen auf. Siehe Archivierung.
Microsoft Graph. Eine Verbindung, die abbrach, bevor Graph antwortete (Reset, abgelehnt, ein vorübergehender DNS-Fehler, ein Timeout), wird bei Anfragen, die nur lesen, mit Backoff wiederholt und nicht als Drosselung gemeldet. Ein Token-Endpunkt, der nicht erreichbar ist, wird zweimal nachgefragt (nach 1 und 4 Sekunden) und lässt dann den Lauf scheitern, der an seinem Checkpoint fortsetzt, statt jedes Element als fehlgeschlagen zu erfassen. Jeder $batch sendet eine identische Leseanfrage nur einmal, sodass eine Delta-Seite oder eine Wiederholung nie eine Anfrage-ID wiederholen kann.
Jobs. Das Zeitlimit eines Jobs zählt ab dem Moment, in dem die Warteschlange ihn herausgegeben hat, auch während er auf einen freien Platz seines Mandanten wartet, sodass ein Job, der seine Zeit abgewartet hat, vor dem Start stoppt und kein Neuversuch neben einem späten Versuch läuft. Ein Abbruch, der eintrifft, während ein Versuch startet oder fehlschlägt, bleibt erhalten. Ein Job, den der Reconciler endgültig beendet, löst den Webhook job.failed, die Glocke und die Benachrichtigungsregeln aus wie jeder andere, und sein Checkpoint wird gelöscht.

Wiederherstellen: durchsuchen, auswählen, wiederherstellen

Der Restore-Explorer (Mail & SaaS → Restore-Explorer) durchsucht eine Sicherung so, wie sie zu einem beliebigen Zeitpunkt aussah (Ordner, einzelne Mails, Dateien und deren Versionsverlauf) und stellt das Ausgewählte wieder her oder lädt es herunter, entweder Element für Element oder die gesamte Sicherung auf einmal. Ein Suchfeld deckt Namen, Pfade und Mail-Betreffe zum gewählten Zeitpunkt ab.

Ein Eintrag je Person (seit 0.4.2). Die Liste links zeigt jede Person einmal. Postfach, OneDrive und ein zugeordnetes IMAP-Konto einer Person stehen unter ihrem Verzeichnisbenutzer zusammen, und die zweite Spalte zeigt, was ihre Sicherungen enthalten: E-Mail, Kalender, Kontakte und OneDrive (und E-Mail (IMAP)), jeweils mit den Sicherungsständen des eigenen Objekts und einer Markierung Noch keine Sicherung oder Entfernt, wo das zutrifft. Seit 0.4.7 trägt ein Bereich, dessen Objekt noch an der Quelle steht, aber nicht mehr gesichert wird, stattdessen Nicht gesichert: Konto deaktiviert, Nicht gesichert: keine Lizenz oder Nicht gesichert: gesperrt (siehe Objekte, die nicht mehr gesichert werden). SharePoint-Websites (mit den Dateien der Teams-Kanäle) und, seit 0.4.5, Microsoft-365-Gruppen haben einen eigenen Abschnitt, SharePoint und Teams (vor 0.4.5 SharePoint- und Teams-Websites). Ein OneDrive for Business gehört immer genau einem Benutzer: Nach dem Löschen des Kontos bleibt es unter dem Namen seines Besitzers in der Liste, markiert als Konto gelöscht, mit jedem Sicherungsstand, den es je hatte. Die Liste kommt seitenweise (50 Einträge; Weitere anzeigen), und die Suche (Namen, Adressen und Konto-IDs) und der Typfilter laufen in der Datenbank, sodass ein Mandant mit mehr als 10.000 Personen nie alle auf einmal lädt. Der Eintrag der angemeldeten Person steht zuerst. Die Personenliste gruppiert die geschützten Objekte des Mandanten für jede Seite, die sie ausliefert, was bis etwa 10.000 Personen je Mandant unproblematisch und darüber langsamer ist (ein bekanntes Problem in 0.4.2). Die Daten kommen von GET /api/v1/snapshots/people, siehe API-Referenz.

Gruppen (seit 0.4.5). Eine Microsoft-365-Gruppe hat die Bereiche Gruppenkalender und Unterhaltungen. Als ZIP herunterladen liefert jeden Beitrag als .eml-Datei und jedes Ereignis als .json; der Export liefert die Unterhaltungen als EML, MBOX oder PST, wie die Mails eines Postfachs (der Kalender wird übersprungen und gezählt). Eine Wiederherstellung in das Postfach eines Benutzers (Ziel Anderes Konto, die Adresse eines Postfachs derselben Microsoft-365-Quelle) bringt die Ereignisse in den Kalender dieses Benutzers und die Unterhaltungen als Mail in einen Ordner Conversations zurück; mit Beide behalten kommen sie in einen Wiederherstellungskalender und unter den Wiederherstellungsordner. Eine Wiederherstellung in die Gruppe (Ziel Ursprünglicher Ort) bringt nur Kalenderereignisse zurück, in den einen Kalender der Gruppe: Microsoft Graph lässt keine App eine Gruppenunterhaltung beginnen oder beantworten, der Bericht führt also jeden Beitrag als nicht wiederherstellbar auf, und der Dialog sagt, dass nur der Gruppenkalender zurückgeht. Stellen Sie die Unterhaltungen in das Postfach eines Benutzers wieder her, oder laden Sie sie herunter oder exportieren Sie sie. Eine Gruppe gehört keiner Person, ihre Wiederherstellung ist also keine Admin-Wiederherstellung im Auftrag und braucht keinen Grund, wird aber wie üblich auditiert; nur Restore-Operatoren und Administratoren sehen Gruppen, und es gibt kein Überschreiben.

Kalender (seit 0.4.2). Der Kalender eines Postfachs öffnet sich als Liste oder als Monat. Die Liste sortiert Termine danach, wann sie beginnen (neueste zuerst oder anstehende zuerst, Spalten Wann, Ort und Organisator), nicht mehr nach Betreff. Die Monatsansicht zeigt die Tage des Monats über alle Kalender des Postfachs oder einen, und ein Serientermin steht einmal in der Liste als Serie, die sich auf ihre Termine öffnet. Die API berechnet die Termine aus dem gespeicherten Muster, setzt die gespeicherten Ausnahmen an ihre Stelle und folgt der Zeitzone der Serie über die Sommerzeit. Ein Termin, der einzeln gelöscht wurde, ist in der Sicherung nicht vermerkt (Microsoft Graph v1.0 meldet abgesagte Termine nicht) und kann daher noch erscheinen, so wie er mit der Wiederherstellung der Serie zurückkäme. Das Öffnen eines Kalenders steht im Audit-Log (snapshot.calendar.read), und Sicherungen seit 0.4.2 halten außerdem den Ort eines Termins und das Ende einer Serie fest.

Am unteren Rand des Restore-Explorers zeigt eine schlanke Zeitleiste die Sicherungsstände des gewählten Kontos, links den ältesten und rechts den neuesten. Der Sicherungsstand, den Sie gerade durchsuchen, steht in der Mitte, und die Zeitleiste öffnet sich auf dem neuesten. Jede Markierung zeigt, ob eine Restore-Prüfung bewiesen hat, dass sich genau diese Sicherung zurücklesen lässt. Ein Ordner ohne Unterordner sagt das im Ordnerbaum.

Zwei weitere Zeichen können an einem Sicherungsstand stehen. Ein rotes Zeichen Verdächtig sagt, dass Restow darin Anzeichen von Ransomware gefunden hat; ist der neueste Sicherungsstand verdächtig, bietet der Explorer den neuesten ohne Befund an (siehe Ransomware-Erkennung). Unveränderbar bis mit einem Datum sagt, dass das Repository die Daten des Sicherungsstands bis zu diesem Datum gesperrt hält, grün nur, wenn der Speicher selbst eine Compliance-Sperre gemeldet hat (siehe Unveränderbare Backups).

Geschwindigkeit des Restore-Explorers (seit 0.4.4)

Ein großes Postfach oder OneDrive brauchte früher Sekunden bis Minuten, bevor seine Ordner im Restore-Explorer erschienen. Jede Ordnerliste las alle Einträge des Sicherungsstands (jede Nachricht des Postfachs, jede Datei des OneDrives), zweimal je Anfrage, und glich die darunterliegenden Ordner ohne Index damit ab; ein Ordner, dessen Unterordner keinen eigenen Eintrag haben, etwa die Wurzel eines Postfachs mit mail und calendar oder die Wurzel eines OneDrives, wuchs mit dem Quadrat der Einträge und konnte in ein Zeitlimit laufen. Seit 0.4.4 liest die Liste die Kinder des Ordners und die Ordner darunter aus zwei neuen Indizes (Migration 0061_explorer_parent_index; die Zeit, die das Update dafür auf einer großen Installation braucht, steht unter Update auf 0.4.4).

Die Release-Notes nennen diese Zahlen, gemessen mit 120.000 Nachrichten und 200.000 Dateien in einem Sicherungsstand:

Liste	Vorher	Seit 0.4.4
Die Mail-Ordnerliste	2,5 s	15 ms
Die Wurzel des Postfachs und des OneDrives	über eine Minute	15 ms
Jeder OneDrive-Ordner	1,5 bis 2,5 s	etwa 10 ms
Die erste Seite eines Ordners mit 50.000 Nachrichten	1,9 s	etwa 0,5 s
Die Versionen, die OneDrive von einer Datei aufbewahrt hat, und die Monatsansicht des Kalenders	130 ms und 260 ms	unter 50 ms

Auch andere Teile sind schneller. Die Sicherungsstände eines Kontos laden zusammen mit dem Eintrag seines Inhabers in der Personenliste, eine Rundreise weniger, bevor ein Postfach oder OneDrive seine Ordner zeigt. Die Mail-Vorschau, der Download eines Anhangs und die Kalenderserie lesen jeden Chunk der Nachricht mit einer Byte-Range-Anfrage genau für seine Bytes aus dem Speicher, statt für jede Vorschau das ganze Pack (bis 64 MiB); ein Chunk, der auf jedem Ziel beschädigt ist, wird weiterhin über sein ganzes Pack gelesen, wie bisher. Die Inhaltsprüfung des Archivs liest genauso. Sicherungsstände von 0.3.4 und früher, die der Worker noch nicht umgewandelt hat, werden wie bisher aufgelistet, ohne die Beschleunigung.

Vorschau einer Nachricht

Der Restore-Explorer zeigt eine ausgewählte Mail in einer Vorschau. Eine Mail kann von jedem stammen, deshalb liest Restow sie für die Vorschau in einem eigenen Hilfsprozess mit Zeit- und Speichergrenze, nie im API-Prozess selbst (siehe Mail-Dateien importieren und exportieren).

Vereinfachte Ansicht. Wäre die formatierte Ansicht einer Nachricht zu aufwendig, zeigt die Vorschau stattdessen den Text der Nachricht, gekennzeichnet als Vereinfachte Ansicht: Bilder und Layout fehlen. Das gilt auch für HTML über 12 MiB. Laden Sie die Nachricht herunter, um sie vollständig zu sehen.
Nicht lesbar. Lässt sich die Nachricht innerhalb der Grenzen gar nicht lesen, sagt die Vorschau, dass sie nicht gelesen werden konnte, und zeigt die Kopfdaten aus der Sicherung. Herunterladen und Wiederherstellen funktionieren weiter, weil sie die gespeicherten Bytes verwenden und nichts auswerten.
Anhänge einer solchen Nachricht. Der Download eines einzelnen Anhangs einer Nachricht, die sich innerhalb der Grenzen nicht lesen lässt, wird abgelehnt (preview-unreadable). Laden Sie die ganze Nachricht als EML herunter oder stellen Sie sie wieder her.
Ausgelastet. Sind alle Vorschau-Prozesse beschäftigt und ihre Warteschlange voll, antworten Vorschau und Anhang-Download mit preview-busy. Versuchen Sie es in einigen Sekunden erneut. Passiert das oft, erhöhen Sie PREVIEW_PARSE_WORKERS (siehe Umgebungsvariablen).

Restore ist auf nicht-destruktiv ausgelegt

Das ist die feste Regel des Produkts: Restore soll ein vorhandenes Original in einem Postfach oder OneDrive nicht überschreiben. Wenn Sie an den ursprünglichen Ort wiederherstellen, fragt Restow, was geschehen soll, wenn dort bereits etwas mit demselben Namen liegt:

Beide behalten (Standard): Vorhandenes bleibt unberührt; das wiederhergestellte Element wird daneben geschrieben. Mail-Restores landen in einem neuen, klar benannten Ordner (zum Beispiel „Wiederhergestellt 2026-09-23 1432“); eine Datei, die mit einer bereits vorhandenen kollidieren würde, wird unter einem neuen Namen wiederhergestellt.
Vorhandene überspringen: Elemente, die noch da sind, bleiben unverändert; nur das tatsächlich Fehlende wird wiederhergestellt.

Sie können auch in ein anderes Konto desselben Mandanten wiederherstellen (Postfach, OneDrive oder IMAP-Konto; bei einer SharePoint-Website eine andere Bibliothek einer gesicherten Website derselben Quelle; nur für Restore-Operatoren und Mandanten-Administrationen), oder als ZIP herunterladen: Mails als .eml, andere Dateien unverändert, zusammen mit einer Prüfsummenliste, über einen 24 Stunden gültigen Link. Eine ältere Dateiversion, die OneDrive selbst aufbewahrt hat (getrennt von Restows eigenen Sicherungen), ist nur als Download verfügbar.

Vor der Bestätigung zeigt der Dialog eine Vorschau dessen, was gleich geschieht: die Quelle (Objekt und Zeitpunkt), Ziel und Modus, und, wenn eine Administration die Daten einer anderen Person wiederherstellt, einen Hinweis, dass dies als Admin-Wiederherstellung in deren Auftrag protokolliert wird, plus eine erforderliche Begründung (eine SharePoint-Website gehört niemandem, dafür ist keine nötig). Jeder Restore wird ins Audit-Log geschrieben: wer ihn angefordert hat, wann, was genau und wohin, in wessen Auftrag falls zutreffend, und von welcher IP-Adresse. Über diesen Audit-Log-Eintrag hinaus gibt es derzeit keine druckbare oder exportierbare Restore-Bestätigungsansicht.

Wiederherstellungen, die nichts wiederhergestellt haben (seit 0.4.7)

Eine Wiederherstellung, die endete, aber nichts zurückgespielt hat, zeigt sich nicht mehr als Erfolg.

Nichts wiederhergestellt (rot): eine abgeschlossene Wiederherstellung mit fehlgeschlagenen Elementen und keinem wiederhergestellten. Sie löst restore.failed und den Webhook job.failed aus, mit „Nothing was restored: N items failed.“ als Fehlermeldung (englisch, so wie der Server sie speichert).
Alles übersprungen (gelb): eine Wiederherstellung, die jedes Element übersprungen hat. Sie bleibt restore.completed und sagt es, statt zu behaupten, sie habe etwas wiederhergestellt; in Chat-Kanälen ist sie eine Information, kein Erfolg.
Die Webhooks job.completed und job.failed einer abgeschlossenen Wiederherstellung tragen ihre Zähler in data.job.result: restored, skipped, failures und unverified. Eine Wiederherstellung, die abgeschlossen wurde, ohne etwas wiederherzustellen, während Elemente fehlschlugen, hat data.job.status completed und löst trotzdem job.failed aus.
In ein Konto, das nichts aufnehmen kann. Eine Wiederherstellung in das ursprüngliche Postfach eines Nutzers, dessen Konto deaktiviert ist oder keine Exchange-Online-Lizenz hat, oder in ein OneDrive oder eine Website, die Microsoft gesperrt hat, wird mit dem Grund abgelehnt, zum Beispiel „Das Konto ist in Microsoft 365 deaktiviert, es gibt also kein Postfach, in das wiederhergestellt werden kann. Aktivieren Sie es wieder, um dorthin wiederherzustellen.“ Stellen Sie stattdessen in ein anderes Konto wieder her oder laden Sie als ZIP herunter. Siehe Objekte, die nicht mehr gesichert werden.
Wiederholte Wiederherstellungen verdoppeln nichts. Eine IMAP-Wiederherstellung, deren Verbindung abbricht, scheitert und wird auf einer frischen Verbindung wiederholt, wo die Prüfung der Message-ID überspringt, was schon angehängt wurde, statt als abgeschlossen zu enden, obwohl jedes verbleibende Element fehlschlug. Eine wiederholte Wiederherstellung einer SharePoint-Liste im Modus Beides behalten fügt die Elemente, die der unterbrochene Versuch hinzugefügt hat, nicht mehr hinzu, und eine wiederholte Kontakte-Wiederherstellung in diesem Modus legt Kontakte nicht mehr doppelt an. Eine Wiederherstellung in ein Postfach, das per Adresse angegeben ist, löst dasselbe Postfach auf, das die API akzeptiert hat (über die Adresse des Verzeichnisbenutzers, nie ein verwaistes oder importiertes Postfach), sodass eine doppelte Adresse nicht mehr ein anderes wählt.

Importierte Postfächer

Ein Postfach, das Sie aus Dateien importieren, erscheint im Restore-Explorer wie jedes andere Konto, gekennzeichnet als Importiert: Ordnerbaum, Suche, Vorschau, Druckansicht, Download und Wiederherstellen in ein bestehendes IMAP-Konto oder ein Microsoft-365-Postfach. Es gibt kein Original, in das sich zurückspielen ließe; die Wiederherstellung an den ursprünglichen Ort ist dafür daher nicht verfügbar. Siehe Mail-Dateien importieren und exportieren.

SharePoint-Websites

Eine Website stellen Sie im selben Restore-Explorer wieder her (Kontotyp SharePoint-Websites, Bereiche Bibliotheken und Listen). Dateien und Ordner gehen zurück in ihre ursprüngliche Bibliothek oder in eine andere Bibliothek einer gesicherten Website derselben Quelle; Listenelemente gehen als neue Elemente in ihre ursprüngliche Liste zurück, nur beschreibbare Felder. Berechtigungen werden als Information gesichert und nie wiederhergestellt, und eine gelöschte Website oder Bibliothek wird nicht neu angelegt. Nur Restore-Operatoren und Administrationen sehen Websites. Siehe SharePoint Online.

Server und Clients

Server und Clients stellen Sie auf ihren eigenen Seiten wieder her, nicht im Restore-Explorer für Postfächer: eine Sicherung durchsuchen, Dateien als ZIP herunterladen oder in einen neuen Ordner auf dem Rechner wiederherstellen, nie über vorhandene Dateien. Siehe Restore für Server und Clients. Auch Restore-Operatoren öffnen diese Seiten (seit 0.4.0): Sie lesen die Sicherungsstände, durchsuchen sie, laden Dateien herunter und stellen Dateien auf einem Rechner wieder her.

Dateifreigaben und Proxmox-VE-Gäste

Dateifreigaben stellen Sie auf ihrer eigenen Seite wieder her, Freigaben (seit 0.4.0): einen Sicherungsstand durchsuchen und als ZIP herunterladen, in einen neuen Ordner, an den ursprünglichen Ort (überschreiben, beide behalten oder überspringen) oder in eine andere Freigabe wiederherstellen, mit den Berechtigungen, soweit das Ziel es erlaubt. Siehe Restore von Dateifreigaben. Ein Proxmox-VE-Gast wird als neuer Gast neben dem Original wiederhergestellt; die Dateien eines Container- oder VM-Sicherungsstands lassen sich unter Server & Clients → Datei-Restore durchsuchen und als ZIP herunterladen. Siehe Proxmox-VE-Backup.

Export als Dateien

Sie können ein Postfach oder Ordner aus einer Sicherung, einem importierten Postfach oder dem Archiv als Dateien exportieren: EML-Dateien in einer ZIP-Datei (mit MANIFEST.csv und SHA256SUMS) oder als MBOX. Der Download-Link ist 24 Stunden gültig, und jede Anfrage und jeder Download wird ins Audit-Log geschrieben. Siehe Mail-Dateien importieren und exportieren.

Restore-Prüfung (Wiederherstellbarkeit)

Eine Sicherung, die Restow nicht zurückgelesen hat, gilt nicht als vertrauenswürdig. Eine geplante Restore-Prüfung (standardmäßig wöchentlich) liest eine Zufallsstichprobe von Elementen (bei einer SharePoint-Website Dateien ihrer Bibliotheken) der letzten Sicherung über den Restore-Pfad zurück (denselben Chunk-Index, Pack-Abruf und dieselbe AES-256-GCM-Entschlüsselung wie ein echter Restore) und vergleicht Größe und SHA-256-Hash mit dem Manifest, wobei jedes geschützte Objekt als Bereit, Achtung oder Nicht wiederherstellbar bewertet wird. Eine Sicherung, die noch niemand zurückgelesen hat, ist Nicht geprüft, unabhängig davon, wie eine frühere Sicherung bewertet wurde. Sie stellt nicht in ein Microsoft-365-Postfach, OneDrive oder IMAP-Konto wieder her: Die optionale Test-Wiederherstellung in ein Ziel ist in 0.4.7 nicht angeschlossen. Siehe Wie Restow prüft, ob eine Sicherung wiederherstellbar ist für genau das, was geprüft wird und was noch nicht geprüft wird, Erste Schritte für eine Prüfung von Hand und Backups und Zeitpläne, um sie auf einen Zeitplan zu legen. Server und Clients werden auf dieselbe Weise bewertet, über einen Restore-Test mit Stichprobendateien: siehe Server und Clients.

Genannte Grenzen

Microsoft Teams ist nur zum Teil abgedeckt: Chats und Kanalnachrichten sind in dieser Version weder gesichert noch wiederherstellbar. Die Dateien eines Teams liegen in der Dokumentbibliothek seiner SharePoint-Website und werden mit dieser Website gesichert; seit 0.4.5 lassen sich Kalender und Unterhaltungen der Microsoft-365-Gruppe hinter dem Team als Gruppenpostfach sichern (Opt-in).
Die IMAP-Anmeldung erfolgt per Passwort. Jede IMAP-Quelle nutzt einen gemeinsamen Zugang, ein Passwort je Postfach oder ein Master-Konto (siehe Quellen verbinden). OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant.
Microsoft 365 gegen einen echten Mandanten: Backup und Restore von Microsoft 365, SharePoint-Online-Websites eingeschlossen, wurden in den Release-Prüfungen noch nicht gegen einen echten Microsoft-365-Mandanten ausgeführt. Sie sind durch Tests gegen eine simulierte Microsoft-Graph-API abgedeckt (der Smoke-Check 4 des Releases wurde mangels Zugangsdaten übersprungen). Siehe Ein Release verifizieren. Restow nutzt ausschließlich Microsoft Graph und nie Exchange Web Services, die Microsoft für Exchange Online am 1. Oktober 2026 abgeschaltet hat.
Server und Clients werden Datei für Datei gesichert, nicht als Disk-Images, und es gibt keinen Bare-Metal-Restore. Der Agent wird für Linux und macOS ausgeliefert, die Release-Prüfungen haben ihn aber nur in einem Linux-Container installiert.
SharePoint Online: Anhänge von Listenelementen, Websitedesign, Navigation, Workflows und Berechtigungen werden nicht wiederhergestellt (Berechtigungen werden als Information gesichert); eine gelöschte Website oder Bibliothek wird nicht neu angelegt; Listenelemente gehen nur in ihre ursprüngliche Liste zurück. Siehe SharePoint Online.
PST- und OST-Dateien lassen sich noch nicht importieren.
Erste Sicherung eines großen Mandanten: Microsoft drosselt die Graph-API, daher kann die erste Sicherung Tage statt Stunden dauern. Restow zeigt diese Wartezeit im Fortschritt des Jobs an, statt sie zu verbergen. Ab 0.3.5 setzt sich eine Sicherung, die nach einem gespeicherten Prüfpunkt durch ihr Zeitlimit (23 Stunden) oder durch einen Neustart des Workers unterbrochen wurde, fort, ohne einen Wiederholungsversuch zu verbrauchen, bis zu 21 Tage nach ihrem ersten Start, und die Laufansicht zeigt eine solche Unterbrechung als Information, nicht als Fehler. Seit 0.4.0 verbraucht auch ein Lauf, den ein Neustart oder ein Update vor seinem ersten Prüfpunkt stoppt, keinen Versuch mehr, und der Update-Dialog kann Microsoft-365- und Mail-Läufe sauber mit einem Prüfpunkt anhalten (siehe Updates). Eine Microsoft-Graph-Anfrage, die innerhalb von 5 Minuten keine Antwort bekommt, wird wiederholt, statt bis zum Zeitlimit des Jobs zu hängen; Anfragen und Drosselungswartezeiten enden mit dem Job. Seit 0.4.7 beachtet ein Hintergrund-Job ein Retry-After von bis zu 5 Minuten (vorher waren Wartezeiten auf etwa eine Minute begrenzt, und Exchange lehnt einen Neuversuch ab, bevor seine Strafe für gleichzeitige Postfachzugriffe vorbei ist); Anfragen der Weboberfläche behalten die Grenze von einer Minute. Eine Sicherung, die Microsoft Graph oder der Speicher nach allen Wiederholungen noch gebremst hat, zeigt Vom Dienst gedrosselt, wird wiederholt (gelb), nicht fehlgeschlagen: Der nächste geplante Lauf versucht es erneut (Fehlererklärungen).