← Alle Funktionen

Microsoft-365- und IMAP-Backup

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Restow sichert Exchange-Online-Postfächer (Mail, Kalender und Kontakte), OneDrive und, seit 0.4.0, SharePoint-Websites inkrementell über die Microsoft-Graph-API, und jedes IMAP-Postfach über IMAP, heute mit Passwort-Authentifizierung (OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant). Seit 0.4.5 sichert es auf Wunsch auch Kalender und Unterhaltungen von Microsoft-365-Gruppen. Jeder Restore aus diesem Backup wird in jeder Edition im hashverketteten Audit-Log festgehalten: wer, wann, für wen und von wo. Die Audit-Log-Ansicht (Suche, Filter, Details, Prüfung der Kette) gehört zu Business und Service Provider, und seit 0.3.1 auch der Export des Logs, als CSV und als JSON mit Hashes.

Wie die Microsoft-365-Seite funktioniert

Das Backup läuft inkrementell über den Delta-Abfrage-Mechanismus von Microsoft Graph, sodass ein normaler Lauf nur abruft, was sich seit dem letzten geändert hat, statt ein ganzes Postfach oder OneDrive neu zu scannen. Nutzer, Postfächer und OneDrives kommen automatisch per Entra-ID-Verzeichnis-Sync herein (Graph users/delta), der Schutzumfang wird je Mandant gesteuert: alle, eine bestimmte Gruppe, oder eine Ausschlussliste. Microsoft drosselt die Graph-API, besonders beim ersten Backup eines großen Mandanten. Restow zeigt diese Wartezeit, statt sie zu verstecken: dieselbe Ehrlichkeitsregel, die für jeden anderen Fortschritt oder jede andere Grenze im Produkt gilt. Eine Sicherung, die Graph oder der Speicher nach allen Wiederholungen noch bremst, steht gelb als „Vom Dienst gedrosselt, wird wiederholt“ da, nicht rot als „Fehlgeschlagen“, und löst keine Fehlerwarnung und keinen Fehler-Webhook aus; der nächste geplante Lauf versucht es erneut (seit 0.4.7). Ein Hintergrund-Job beachtet jetzt ein Retry-After von bis zu 5 Minuten (vorher etwa eine Minute), weil Exchange einen Wiederholungsversuch ablehnt, bevor seine Strafe für zu viele parallele Anfragen vorbei ist. Microsoft hat am 1. Oktober 2026 begonnen, Exchange Web Services (EWS) für Exchange Online abzuschalten (endgültig am 1. April 2027); Restow hat sie nie genutzt und spricht mit Microsoft ausschließlich über Microsoft Graph.

Seit 0.3.5 kann ein erstes Backup, das Tage dauert, nach einer Unterbrechung weiterlaufen. Wird ein Backup durch sein Zeitlimit von 23 Stunden oder durch einen Neustart des Workers unterbrochen, nachdem es einen Checkpoint gespeichert hat, läuft es weiter, ohne einen seiner Wiederholungsversuche zu verbrauchen, bis zu 21 Tage nach seinem ersten Start, und die Laufansicht zeigt die Unterbrechung als Information, nicht als Fehler. 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.

Das erste Backup eines großen Postfachs zeigt „Erste Sicherung: X von Y Elementen“ über alle Versuche hinweg, mit geschätzter Restzeit, und ein OneDrive zeigt „X Elemente bisher“, bis es vollständig aufgelistet ist.

Mehr dazu: OneDrive-Backup.

Objekte, die nicht mehr gesichert werden

Seit 0.4.7 scheitern ein Postfach, dessen Konto deaktiviert ist oder keine Exchange-Online-Lizenz hat, und ein OneDrive oder eine SharePoint-Website, die Microsoft gesperrt hat (HTTP 423, was Microsoft mit dem OneDrive eines Kontos ohne Lizenz tut), nicht mehr jede Nacht. Die Sicherung fragt zuerst Microsoft, ob der Benutzer existiert, aber kein Postfach hat, oder bestätigt die Sperre mit einer einzigen billigen Leseanfrage. Erst dann steht das Objekt als „Nicht gesichert: Konto deaktiviert“, „Nicht gesichert: keine Lizenz“ oder „Nicht gesichert: gesperrt“ da, der Lauf endet neutral ohne Wiederholungen, vorhandene Sicherungen bleiben erhalten, und nichts zählt als fehlgeschlagen oder überfällig. Nur die Antwort von Exchange zählt: Ein deaktiviertes Konto, dessen Postfach Microsoft noch bereitstellt, etwa ein geteiltes Postfach, wird wie bisher gesichert, und ein 401 oder 403 wird nie so gelesen. Die Sicherung läuft von selbst weiter, nachdem der Verzeichnisabgleich das Konto wieder aktiviert oder lizenziert findet oder die Sperre aufgehoben ist.

Damit nichts still bleibt, steht jedes Objekt, das Restow nicht mehr sichert, auch eines, das aus seiner Quelle entfernt wurde, zuerst gelb als „Nicht mehr gesichert, bitte bestätigen“ da, mit Grund und Datum. Die Bereitschaft des Mandanten bleibt mindestens gelb, nie grün, und Provider sehen das Objekt unter den Warnungen des Mandanten, bis ein Administrator mit „Ja, beabsichtigt“ bestätigt: für ein Objekt oder für eine Auswahl oder eine gefilterte Liste von bis zu 1000. Das Objekt steht dann grau als „Absichtlich nicht mehr gesichert“ da, mit dem Namen dessen, der bestätigt hat, und dem Zeitpunkt; wird es wieder aktiv, entfällt die Bestätigung, und hört es später wieder auf, fragt Restow erneut. Ein Hinweis je Objekt, oder eine Warnung je Mandant und Tag, wenn viele auf einmal ausfallen, läuft über die Benachrichtigungsmatrix. Objekte, die schon vor dem Update verwaist waren, gelten als bestätigt. Ein aus seiner Quelle entferntes Objekt wird danach bewertet, ob sich seine neueste aufbewahrte Sicherung wiederherstellen lässt, nicht danach, wie alt sie ist.

Seit 0.4.7 kostet ein Fehler auch weniger: Ein 403 für Kalender oder Kontakte lässt nur diesen Bereich scheitern und behält die Mail des Laufs, ein Delta-Link, den Graph ablehnt, führt zu einem vollständigen Neuabgleich, eine Nachricht, die Exchange nicht in MIME umwandeln kann, wird als JSON mit ihren Anhängen gespeichert, und eine Berechtigung, die ein Administrator der App später erteilt, wirkt ohne neues Client-Secret.

SharePoint-Websites

Seit 0.4.0 findet jeder Verzeichnis-Sync auch die SharePoint-Websites des Mandanten, die von Microsoft-365-Gruppen und Teams eingeschlossen; persönliche Websites bleiben dem OneDrive ihres Besitzers überlassen. Jede Website ist in den Mail-Jobs ein eigenes geschütztes Objekt, wie ein Postfach oder ein OneDrive, und die Schutzregeln haben einen Websites-Modus: alle Websites (die Voreinstellung) oder nur die ausgewählten. Ein Backup enthält jede Dokumentbibliothek (mit der OneDrive-Engine: Delta je Bibliothek, optionale Versionen, Checkpoints), jede Liste mit ihren Spalten und die Feldwerte jedes Listenelements als JSON sowie die Beschreibung der Website. Eine Bibliothek oder Liste, die Graph verweigert, wird gemeldet und behält ihre letzte Kopie. Eine neue Website bekommt sofort ihr erstes Backup, und eine gelöschte Website schlägt mit einer klaren Ursache fehl.

Im Restore-Explorer zeigt eine Website ihre Bibliotheken, Ordner, Dateien, Listen und Elemente. Sie können sie als ZIP herunterladen; Dateien und Ordner in die ursprüngliche Bibliothek oder eine andere Bibliothek einer gesicherten Website derselben Quelle wiederherstellen („Beide behalten“, „Überschreiben“, wobei SharePoint die alte Datei als Version behält, oder „Vorhandene überspringen“); und Listenelemente als neue Elemente in ihre ursprüngliche Liste wiederherstellen, nur beschreibbare Felder. Die Restore-Prüfungen lesen Stichproben aus den Bibliotheken wie bei einem OneDrive.

Es braucht eine zusätzliche Berechtigung und eine neue Zustimmung. Die Backup-App braucht die Anwendungsberechtigung Sites.ReadWrite.All (Sites.Read.All genügt zum Sichern, nicht zum Wiederherstellen), und der Administrator des Kunden muss den Zustimmungslink der Quelle erneut öffnen. Bis dahin laufen Mail und OneDrive weiter, und der Verzeichnis-Sync warnt, dass Websites weder gefunden noch gesichert werden. Nicht gesichert werden 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, und Listenelemente gehen nur in ihre ursprüngliche Liste zurück.

Mehr dazu: SharePoint-Online-Backup.

Microsoft-365-Gruppen: Kalender und Unterhaltungen

Seit 0.4.5 sind Kalender und Unterhaltungen von Microsoft-365-Gruppen und der Gruppen hinter Teams geschützte Objekte einer eigenen Art. Der Verzeichnis-Sync liest die Gruppen als zweiten Delta-Strom neben den Benutzern und behält nur Microsoft-365-Gruppen (Sicherheits- und Verteilergruppen haben kein Gruppenpostfach); eine gelöschte Gruppe wird verwaist, ihre Sicherungsstände bleiben. Gruppen sind Opt-in: Die Schutzregeln haben einen Schalter „Alle Microsoft-365-Gruppen schützen“, standardmäßig aus, und einzelne Gruppen lassen sich in der Liste der geschützten Objekte einschließen. Ein Mail-Job mit Umfang „alle“ deckt jede geschützte Gruppe ab, und Gruppenpostfächer zählen nie als geschützte Postfächer. Nach dem Update wird keine Gruppe gesichert, bis Sie es einschalten, und der erste Verzeichnis-Sync liest die Gruppen jeder Microsoft-365-Quelle einmal vollständig.

Ein Backup enthält den Kalender der Gruppe (Serien mit ihren Ausnahmen, gelesen vom Code, der auch den Kalender eines Benutzers liest) und jeden Beitrag jeder Unterhaltung als Mail-Nachricht, mit ihren Dateianhängen, wo Graph sie herausgibt; sonst wird das Fehlen der Anhänge festgehalten. Verweigert Graph der App die Ereignisliste eines Gruppenkalenders, fällt Restow auf die Kalenderansicht der Gruppe zurück und liest jede Serie einmal; ein Kalender, den Graph ganz verweigert, ist eine Warnung am Lauf, kein Fehler. Nur Threads mit neuen Beiträgen werden erneut gelesen. Es braucht keine neue Microsoft-Berechtigung: Group.Read.All und Calendars.ReadWrite waren immer erforderlich.

Im Restore-Explorer stehen Gruppen im Abschnitt „SharePoint und Teams“ mit den Bereichen „Gruppenkalender“ und „Unterhaltungen“. Download als ZIP (EML, JSON) und Export (EML, MBOX, PST) funktionieren wie bei Postfächern. Ein Restore in das Postfach eines Benutzers derselben Quelle bringt Ereignisse und Unterhaltungen zurück (die Unterhaltungen als Mails). 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. Nicht gesichert: Teams-Chats und Kanalnachrichten sowie die Anhänge von Kalenderereignissen.

Der Backup-Index

Seit 0.3.5 wird der Index, welche Elemente ein Backup enthält, als eine Zeile je Version eines Elements gespeichert und nicht als Kopie jedes Elements für jedes Backup. Ein Element, das sich nicht geändert hat, kostet bei späteren Backups nichts. Nach dem Update wandelt der Worker den Index bestehender Backups im Hintergrund um, ein Backup nach dem anderen; Backups, Durchsuchen und Restores laufen währenddessen weiter. Seit 0.3.6 gibt die API den Platz der alten Tabelle von selbst zurück, sobald die Umwandlung abgeschlossen ist, innerhalb von etwa 15 Minuten; der API-Neustart, den 0.3.5 verlangte, ist nicht mehr nötig. Unter 0.3.5 selbst starten Sie die API nach der Umwandlung einmal neu.

Eine Microsoft-365-Quelle verbinden

Eine Quelle verbindet sich auf einem von drei Wegen mit Microsoft 365:

• Über die Zustimmungseinladung der gemeinsamen Backup-App, die der Administrator des Kunden annimmt.
• Über eine eigene Graph-App für diese Quelle (seit 0.2.2): eine App, die der Kunde von Hand im eigenen Tenant angelegt hat. Sie geben Tenant-ID, Anwendungs-ID und ein Client-Geheimnis oder ein Zertifikat ein. Die Zugangsdaten werden im Geheimnisspeicher der Organisation versiegelt und nie wieder angezeigt. Die Anleitung listet jede Berechtigung mit einer Kopieren-Schaltfläche auf und sagt, dass keine Redirect-URI nötig ist. Seit 0.4.7 können Sie auch das Ablaufdatum des Secrets eintragen („Secret läuft ab am“, optional): Restow erinnert Sie dann 30 Tage vorher, 7 Tage vorher und nach dem Ablauf, und die Verbindungskarte zeigt „Läuft ab“.
• Für den Tenant, in dem die Backup-App selbst liegt, eine direkte Verbindung ohne Zustimmungslink (nur Provider-Inhaber). Ein funktionierendes App-Token für diesen Tenant dient als Nachweis, sodass der Zustimmungs-Umweg entfällt, den Entra für eine dort nicht installierte App ablehnt. Dafür braucht es die Verzeichnis-ID (Tenant-ID) der App unter Einstellungen, Microsoft 365.

Wie die IMAP-Seite funktioniert

Jedes IMAP-Postfach ist eine gültige Backup-Quelle, heute mit Passwort-Authentifizierung. Je IMAP-Quelle legen Sie fest, wie sich Restow anmeldet: eine gemeinsame Anmeldung mit einem Passwort für alle Postfächer (die Voreinstellung), ein eigenes Passwort je Postfach oder ein Master-Konto, das sich als jedes Postfach anmeldet. OAuth2 für IMAP-Quellen (Microsoft 365 oder Google über IMAP) ist noch nicht umgesetzt; geplant. Reine IMAP-Mandanten (ohne ein Entra-ID-Verzeichnis zum Synchronisieren) werden stattdessen per manueller Postfachliste oder CSV-Import angelegt.

Mehr dazu: IMAP-Postfach sichern.

Backup-Jobs, Live-Läufe und Verlauf

Ein Backup-Job legt fest, was gesichert wird, wann, in welches Repository, wie lange und wie oft eine Restore-Prüfung es nachweist, für viele Postfächer, OneDrives, IMAP-Konten oder Rechner zugleich, mit Abweichungen je Objekt oder Rechner. Es gibt Jobs für Mail und für Server und Clients. Sie können begrenzen, wie viel Bandbreite ein Backup nutzen darf, innerhalb eines Zeitfensters, das Sie festlegen. Laufende Jobs und Tabellen aktualisieren sich von selbst, ohne dass Sie die Seite neu laden, und ein Lauf öffnet ein Detailpanel mit Diagrammen seines Durchsatzes. Der Verlauf listet jeden Lauf, auch die Läufe der Agents auf Servern und Clients, mit Filtern nach Art (Backup, Restore, Restore-Prüfung, Export, Import, Wartung) und nach Job. Das Verzeichnis und die Job-Seiten sagen, welcher Job ein Objekt sichert.

Seit 0.4.2 fragt der Editor eines Mail-Jobs zuerst, was der Job tun soll: Sichern (Ordner, Kalender, Kontakte und ganze Postfächer so wiederherstellen, wie sie zu einem Sicherungsstand waren), Archivieren (jede E-Mail manipulationserkennbar aufbewahren, erfasst, bevor Nutzer sie ändern oder löschen können) oder Sichern und archivieren, die Vorgabe für einen neuen Job. Archivieren erfasst Mail auf den Wegen, die der Editor für jede Art von Postfach im Job anbietet: seit 0.4.4 Microsoft Graph oder Exchange-Journaling für Microsoft 365 sowie IMAP-Abgleich oder Kopien, die der Mailanbieter weiterleitet, für IMAP- und Google-Workspace-Konten, jeweils als „Echt“ (beim Transport) oder „Zeitnah“ gekennzeichnet, mit mindestens einem je Art (Vorgabe eines neuen Jobs sind Graph und IMAP-Abgleich, jeweils mit einer einmaligen Übernahme der Mail, die schon im Postfach liegt). Zeitnahe Erfassung ist nicht vollständig; der Abschnitt zum Archiv sagt, was sie nicht verspricht. Die Wege gehören zu Business und höher; ohne sie bleibt die Wahl gespeichert, aber sie erfassen nichts. Jobs, die schon vor 0.4.4 archiviert haben, behalten nur das Journaling, sodass nichts Neues von selbst startet. Ein Job, der nur archiviert, sichert nicht nach Zeitplan (ein von Hand gestarteter Lauf sichert trotzdem). Archiviert ein Job, schlägt der Editor vor, alle 8 Stunden statt öfter zu sichern, nur als Vorschlag: Der Zeitplan bleibt, wie Sie ihn eingestellt haben. Sichert er nur, nennt der Editor die Lücke zwischen zwei Läufen, in der eine eingehende und wieder gelöschte E-Mail in keiner Sicherung ist, und dass Sicherungen nicht manipulationserkennbar sind. Seit 0.4.7 archivieren „Empfohlenen Job anlegen“ und „Alles ohne Job schützen“ auch, wo die Installation die Erfassung aus dem Postfach anbietet: Der neue Mail-Job über alle Objekte sichert und archiviert, und ein Mail-Job über alle Objekte, der noch nicht archiviert, wird auf Archivierung umgeschaltet, mit seinen Zeitplänen; ein Job über ausgewählte Objekte wird nie geändert.

Alarme, Warnungen und Benachrichtigungs-Mail

Alarmregeln senden eine E-Mail, einen Eintrag in der Glocke oder einen signierten Webhook, wenn eine Sicherung fehlschlägt, eine Restore-Prüfung nicht besteht oder Speicher beschädigt ist, und jede Zustellung wird protokolliert. Ein Webhook kann stattdessen eine Chatnachricht senden: an Discord, Slack oder Microsoft Teams, gewählt anhand der URL des Webhooks, neben dem signierten Restow-Umschlag. Eine 4xx-Antwort eines Chat-Dienstes beendet eine Zustellung sofort, statt sie zu wiederholen.

Das Ereignis backup.overdue erfasst Postfächer, OneDrives, IMAP-Konten, Rechner und Proxmox-Gäste, berücksichtigt die Zeitpläne der Backup-Jobs, und eine Alarmregel kann eine eigene Frist setzen, von 24 bis 720 Stunden. Warnungen nennen, warum einzelne Elemente nicht gesichert wurden (Ordner, Betreff, Datum, Ursache und was zu tun ist), und lassen sich mit einer Notiz bestätigen. Die Glocke führt zur Ursache, und eine Seite Benachrichtigungen bewahrt den Verlauf.

Seit 0.4.0 zeigt die Benachrichtigungsmatrix unter Integrationen, Benachrichtigungen die Ereignisse als Zeilen, gruppiert und nach Schwere gekennzeichnet, und die Glocke, jeden Webhook und jeden Benachrichtigungsempfänger als Spalten, jeweils mit den Schnellauswahlen „Nur Fehler“, „Fehler und Warnungen“ und „Alle“. Eine Alarmregel sendet ein Ereignis nicht mehr an einen Kanal, dessen Spalte es ausgeschaltet hat. Beim Update änderte sich nichts, weil die Migration jede Spalte mit dem füllte, was der Kanal zuvor bekam. Ein später angelegter Webhook startet mit den Voreinstellungen seines Formats: Discord, Slack und Teams bekommen Fehler und Warnungen, ein signierter JSON-Webhook alles. Das Speichern der Matrix steht im Audit-Log.

Seit 0.4.7 erinnert Restow Sie außerdem, bevor das Client-Secret oder das Zertifikat der zentralen Microsoft-365-App-Registrierung oder der eigenen App einer Quelle abläuft: 30 Tage vorher, erneut 7 Tage vorher und nach dem Ablauf (die Ereignisse installation.app_secret_expiring für Provider-Administratoren und source.app_secret_expiring, das auch Mandanten-Administratoren wählen können). Das Datum wird eingetragen oder ist das Ende des Zertifikats selbst; Restow liest es nicht aus Microsoft. Objekte, die nicht mehr gesichert werden, lösen object.inactive (ein Hinweis je Objekt) oder object.inactive_many (eine Warnung je Mandant und Tag) aus.

Die Benachrichtigungs-Mail wird über SMTP, über Microsoft 365 (eine eigene App mit Mail.Send oder die Backup-App) oder über Google Workspace (ein Dienstkonto mit gmail.send) gesendet, mit Anleitungen und klaren Fehlermeldungen.

Server, Clients, Freigaben, Proxmox VE und Mail-Dateien

Microsoft 365 und IMAP sind nicht die einzigen Quellen. In jeder Edition sichert ein Agent für Linux und macOS Server und Clients auf Ihr eigenes Restow, nur ausgehend über HTTPS und nur anhängend: Der Rechner kann Backups hinzufügen, aber nie löschen. Siehe Server- und Client-Backup. SMB-Freigaben und NFS-Exporte werden vom Restow-Server aus gesichert, ohne Agent auf dem Dateiserver, siehe Dateifreigaben. VMs und Container auf Proxmox VE ab 8.4 werden als Preview gesichert, ebenfalls in jeder Edition, siehe Proxmox-VE-Backup. Postfächer, die nur noch als Dateien vorliegen (EML, MSG, MBOX, ein MailStore-Export), lassen sich als Altpostfach importieren und wieder exportieren, siehe Mail-Import und -Export.

Wenn ein Backup fehlschlägt

Jeder fehlgeschlagene Job, jedes fehlgeschlagene Element, jeder fehlgeschlagene Abgleich und jede fehlgeschlagene Prüfung sagt, was passiert ist, warum und was zu tun ist, statt nur eine nackte Fehlermeldung zu zeigen. Fehler werden einem stabilen Ursachencode zugeordnet: eine fehlende Microsoft-365-Berechtigung, mit Namen; fehlende Administrator-Zustimmung; Drosselung, mit der Wartezeit, die Microsoft verlangt hat; ein fehlgeschlagener IMAP-Login; Speicher, der voll ist oder den Zugriff verweigert; ein Hash-Mismatch. Ein deaktiviertes oder unlizenziertes Konto und ein OneDrive oder eine Website, die Microsoft gesperrt hat, sind seit 0.4.7 kein Fehler: Sie stehen mit „Nicht gesichert“ und dem Grund da. Zu jeder Ursache gibt es nächste Schritte mit Link zur passenden Einstellungsseite, und die technischen Details (HTTP-Status, Graph-Fehlercode, Request-IDs, ohne Geheimnisse) bleiben für einen Support-Fall abrufbar. Siehe die Fehlererklärungen in der Dokumentation.

Benannte Grenzen, nicht versteckte

• Microsoft-Teams-Chats und -Kanalnachrichten gehören vorerst nicht zum Funktionsumfang. Von einer Microsoft-365-Gruppe werden Kalender und Unterhaltungen auf Wunsch gesichert; die Anhänge von Kalenderereignissen nicht.
• IMAP-Quellen melden sich nur mit Passwort an. OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant.
• Das Microsoft-365-Backup und der Microsoft-365-Restore, SharePoint-Websites sowie Gruppenkalender und Unterhaltungen eingeschlossen, wurden in den Release-Prüfungen noch nicht gegen einen echten Microsoft-365-Mandanten ausgeführt. Sie sind durch Tests gegen eine simulierte Graph-API abgedeckt. Das erste Backup eines großen Mandanten kann wegen der Graph-Drosselung Tage dauern, der Job zeigt die Wartezeit. Vor dem Tag von 0.3.5 wurde kein Microsoft-365-Tenant verwendet; weder das Weiterlaufen langer erster Backups noch die Wiederholung nach 5 Minuten ist daher gegen einen echten Tenant gelaufen. Die Erkennung deaktivierter, unlizenzierter und gesperrter Objekte wurde ebenso getestet; eine Antwort von Microsoft, die Restow nicht erkennt, bleibt ein gezählter Fehler.
• Das Ablaufdatum eines Client-Secrets wird eingetragen, nicht aus Microsoft gelesen: Ohne Datum gibt es keine Erinnerung, und eine Quelle, die vor 0.4.7 über eine eigene App verbunden wurde, hat keines, bis es auf der Seite der Quelle eingetragen ist.
• Die Umwandlung des Backup-Index einer bestehenden Installation wurde an erzeugten Verläufen getestet, noch nicht an einer Produktivdatenbank von 25 GB; wie lange sie dort dauert, ist eine Schätzung.
• Eine eigene Graph-App für eine Quelle wurde nur mit Unit-Tests und den CI-Suiten getestet, nicht gegen einen echten Microsoft-365-Tenant. Die Chat-Webhooks und die Benachrichtigungs-Mail über Microsoft 365 oder Google Workspace wurden nur gegen Attrappen getestet.
• Das Proxmox-VE-Backup ist eine Preview und wird als einzige Sicherung noch nicht empfohlen. Details auf der Seite Proxmox VE.
• Google-Workspace-Backup (Gmail, Google Drive) ist geplant. Teams-Chats und Exchange Public Folders sind bewusst noch nicht im Funktionsumfang, und für SharePoint-Websites gelten die oben genannten Grenzen. PST- und OST-Import ist geplant: Heute werden solche Dateien erkannt und mit einer Erklärung abgelehnt, Mail-Dateien kommen als EML, MSG, MBOX oder ZIP herein. Die Roadmap zeigt, was danach geplant ist.
• Das Server- und Client-Backup hat noch keinen Windows-Agent, keine Datenträger-Images und keinen Bare-Metal-Restore (es ist dateibasiert; Abbilder sind geplant), und noch keine LVM-, ZFS- oder btrfs-Snapshots und kein mTLS. Details auf der Seite Server- und Client-Backup.

Häufig gefragt

Weiter zu: Wie Restore funktioniert →

Mehr in Wissen: Sichert Microsoft 365 Ihre Daten? →

Mehr in Wissen: RPO und RTO, wie ein Zeitplan bestimmt, wie viele Daten Sie verlieren können →