Quellen verbinden

Eine Quelle ist der Ort, von dem Restow sichert. Restow unterstützt zwei Arten: Microsoft-365-Mandanten (über Microsoft Graph: Mail, Kalender, Kontakte, OneDrives und, seit 0.4.0, SharePoint-Websites) und IMAP-Postfächer (über IMAP, heute mit Passwort-Authentifizierung; OAuth2 für IMAP-Quellen ist noch nicht umgesetzt; geplant). Eine dritte Art, Importierte Mail-Dateien, enthält Mail, die Sie aus Dateien einbringen (siehe unten). Server, Client-Rechner, Proxmox-VE-Gäste und Dateifreigaben sind keine Quellen: siehe Server und Clients sind keine Quellen. Diese Seite ist die Referenz dafür, wie Quellen im Alltag funktionieren; die genaue Schritt-für-Schritt-Anleitung, wie Sie Ihre erste Quelle verbinden, einschließlich der Entra-App-Registrierung und ihrer Berechtigungen, steht unter Erste Schritte.

Microsoft 365

Restow spricht mit Microsoft 365 ausschließlich über die Microsoft-Graph-API. Restow hat Exchange Web Services (EWS) nie benutzt; Microsoft schaltet EWS für Exchange Online seit dem 1. Oktober 2026 schrittweise ab, endgültig am 1. April 2027. PowerShell-Remoting nutzt Restow ebenfalls nicht. Das Verbinden eines Mandanten läuft über den Entra-Admin-Consent-Flow:

Eine Administration mit den nötigen Rechten im Microsoft-365-Mandanten erteilt Restow die angefragten Berechtigungen, begrenzt auf das, was Sicherung und Restore tatsächlich brauchen.
Restow prüft die Freigabe und meldet genau, was zugestimmt wurde und was nicht. Eine teilweise Freigabe wird als solche angezeigt, nicht stillschweigend als vollständig behandelt.
Nach dem Verbinden synchronisiert Restow das Verzeichnis des Mandanten (Nutzer, Postfächer, OneDrives, seit 0.4.0 SharePoint-Websites und, seit 0.4.5, Microsoft-365-Gruppen) per Entra-ID-Sync, nach dem von Ihnen gewählten Schutzumfang: alle Nutzer, eine bestimmte Gruppe, alle außer einer Ausschlussliste, oder nur ausgewählte Objekte (Postfächer und OneDrives, die eine Administration einzeln auswählt, einzeln oder per Sammelaktion (Einschließen, Ausschließen, „Regeln wieder anwenden”) auf dem Reiter Schutz der Mandanten-Einrichtung (Mandanten-Einstellungen → Schutz), einschließlich „alle N passenden auswählen” innerhalb eines Filters, bis zu 1.000 Objekte auf einmal). Eine neu angelegte Quelle startet im Umfang „alle” oder „Gruppe”; auf „nur ausgewählte Objekte” wechseln Sie danach auf dem Reiter Schutz, falls gewünscht.

Das Verbinden einer Quelle (oder ein erneutes Prüfen einer Quelle, deren erster Abgleich nie gelaufen ist) reiht diesen Verzeichnisabgleich sofort ein, statt auf den nächsten geplanten Lauf zu warten (standardmäßig bis zu sechs Stunden): Postfächer und OneDrives eines neu verbundenen Mandanten bleiben in der Zwischenzeit nicht leer.

Sicherungen laufen danach inkrementell über die Delta-Query-Unterstützung von Microsoft Graph, sodass jeder Lauf nach dem ersten nur noch betrachtet, was sich geändert hat. Ein neu geschütztes Objekt erhält außerdem automatisch eine erste Sicherung eingereiht, sobald es aktiv wird (ein Einschließen, ein Verzeichnisabgleich, der es neu aktiv findet, oder bei IMAP ein Kontenimport), statt auf den nächsten geplanten Sicherungslauf des Mandanten zu warten.

Postfächer und OneDrives tragen den Namen ihrer Person: den Anzeigenamen, sonst die Adresse. Die technische ID steht im Tooltip. Eine SharePoint-Website trägt ihren Titel.

Die erste Sicherung eines großen Postfachs zeigt Erste Sicherung: X von Y Elementen über alle Versuche hinweg, mit einer geschätzten Restzeit. Ein OneDrive zeigt X Elemente bisher, bis es vollständig aufgelistet ist, weil Microsoft die Zahl seiner Elemente erst nach der vollständigen Auflistung nennt.

SharePoint Online

Seit 0.4.0 findet jeder Verzeichnisabgleich auch die SharePoint-Websites des Tenants (Websites von Microsoft-365-Gruppen und Teams eingeschlossen; persönliche Websites bleiben dem OneDrive ihrer Besitzerin oder ihres Besitzers überlassen). Jede Website ist ein eigenes geschütztes Objekt und läuft in den Mail-Jobs wie ein Postfach oder ein OneDrive. Die Schutzregeln haben einen Websites-Modus: alle Websites (Standard) oder nur die, die Sie auswählen. Sicherung und Restore beschreibt SharePoint Online.

SharePoint braucht eine weitere Anwendungsberechtigung, Sites.ReadWrite.All, an der App-Registrierung der Sicherung und einen neuen Admin-Consent in jedem Tenant, der schon vorher verbunden war: Die Administration des Kunden öffnet den Consent-Link der Quelle erneut (Neuen Link zur Administratorzustimmung erzeugen). Bis dahin laufen Mail und OneDrive weiter, und der Verzeichnisabgleich warnt, dass Websites weder gefunden noch gesichert werden. Die Entra-Anleitung mit der Berechtigungsliste steht unter Erste Schritte.

Microsoft-365-Gruppen (seit 0.4.5)

Seit 0.4.5 sichert Restow den Kalender und die Unterhaltungen von Microsoft-365-Gruppen und der Gruppen hinter Teams als geschützte Objekte einer eigenen Art, group. Jede Microsoft-365-Gruppe hat ein Gruppenpostfach mit einem Kalender und ihren Unterhaltungen; Sicherheitsgruppen und Verteilerlisten haben keines und werden übergangen. Die Dateien eines Teams bleiben in seiner SharePoint-Website (SharePoint Online); die Chats und Kanalnachrichten von Teams werden nicht gesichert.

Opt-in. Gruppenpostfächer werden nicht gesichert, solange Sie es nicht verlangen. Die Schutzregeln (Mandanteneinstellungen → Schutz → Quellen und Regeln → Regeln bearbeiten) haben einen Schalter Alle Microsoft-365-Gruppen schützen (groups ist standardmäßig selected oder all), und einzelne Gruppen lassen sich in die Liste der geschützten Objekte aufnehmen. Das unterscheidet sich bewusst von SharePoint-Websites: Ein Tenant mit Tausenden Gruppen soll nach einem Update nicht ungefragt alle sichern. Ein Mail-Job mit dem Umfang „alle“ umfasst jede geschützte Gruppe, wie bei Websites; ein Job mit ausgewählten Objekten die gewählten Gruppen. Eine neu geschützte Gruppe bekommt sofort ihre erste Sicherung. Gruppenpostfächer zählen nie als geschützte Postfächer.
Finden. Die Verzeichnissynchronisierung liest groups/delta als zweiten Delta-Strom neben den Nutzern: eine vollständige Aufzählung bei der ersten und bei jeder vollständigen Synchronisierung, dazwischen nur die Änderungen. Sie behält nur Microsoft-365-Gruppen; eine gelöschte Gruppe wird verwaist und behält ihre Sicherungsstände. Die erste Synchronisierung nach dem Update auf 0.4.5 liest die Gruppen jeder Microsoft-365-Quelle einmal vollständig.
Keine neue Berechtigung und keine neue Administratorzustimmung. Gruppen nutzen Group.Read.All und Calendars.ReadWrite, die die Backup-App schon immer brauchte. Hat der Tenant Group.Read.All nicht erteilt, warnt die Verzeichnissynchronisierung, dass Gruppen nicht gelesen werden („Microsoft-365-Gruppen werden nicht gelesen: Der Tenant hat der App der Sicherung Group.Read.All nicht erteilt“), und lässt die bekannten Gruppen unverändert: Öffnen Sie den Zustimmungslink erneut.
Der Kalender wird mit demselben Code gesichert wie der Kalender eines Nutzers (Serienmaster mit ihren Ausnahmen). Verweigert Microsoft Graph einer App die Ereignisliste, weicht Restow auf die calendarView der Gruppe aus und liest jeden Serienmaster einmal; dieser Ausweg sieht Ereignisse vor seinem Fenster nicht. Ein Kalender, den Graph ganz verweigert, auch durch eine Exchange Application Access Policy, die Gruppenpostfächer ausschließt, ist eine Warnung am Lauf, kein Fehler, und die Unterhaltungen werden trotzdem gesichert.
Die Unterhaltungen. Jeder Beitrag jeder Unterhaltung wird als RFC-5322-Nachricht unter mail/Conversations gespeichert, mit seinen Dateianhängen, wenn Graph sie herausgibt (sonst wird ihr Fehlen vermerkt). Nur Threads mit neuen Beiträgen werden erneut gelesen. Eine Gruppe, die nicht mehr existiert, scheitert mit der Erklärung Diese Microsoft-365-Gruppe existiert nicht mehr (graph.group_unavailable, siehe Fehlererklärungen); die vorhandenen Sicherungen bleiben wiederherstellbar.
Wiederherstellen. Der Restore-Explorer führt 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. Eine Wiederherstellung in das Postfach eines Benutzers bringt die Ereignisse und die Unterhaltungen zurück; eine Wiederherstellung in die Gruppe bringt nur Kalenderereignisse zurück, weil Microsoft Graph keiner App erlaubt, in eine Gruppenunterhaltung zu schreiben (der Bericht führt jeden Beitrag als nicht wiederherstellbar auf). Siehe Backup und Restore.
Prüfungen und Dashboard. Die Restore-Prüfung, die Ransomware-Signale und die Aufbewahrung arbeiten wie bei Postfächern, und das Dashboard führt Gruppenkalender und Unterhaltungen unter den letzten Sicherungen auf.
Nicht gegen einen echten Tenant getestet. Gruppenkalender und Unterhaltungen wurden nur gegen eine simulierte Graph-API getestet, und welche Kalender-Lesezugriffe Graph einer App auf einer Gruppe erlaubt, kann je Tenant verschieden sein (bekannte Probleme von 0.4.5).

Archiv-Erfassung aus Microsoft-365-Postfächern

Seit 0.4.4 kann Restow die Postfächer einer Microsoft-365-Quelle über Graph-Änderungsbenachrichtigungen archivieren: Microsoft meldet Restow, dass eine Mail angekommen ist, und der Worker holt sie innerhalb von Minuten. Das ist zeitnah und nicht vollständig (siehe Archivierung). Was es von Microsoft 365 und von Ihrem Netzwerk braucht:

Berechtigungen und Consent: nichts Neues.

Es nutzt die Anwendungsberechtigung Mail.ReadWrite, die Sicherung und Wiederherstellung ohnehin haben. Das Abonnieren neuer Mail in users/{id}/messages und das Abholen der Mail deckt sie ab.
Kein neuer Admin-Consent und keine Änderung an der App-Registrierung. Ein Tenant, der für die Sicherung verbunden ist, ist bereit. Eine Änderungsbenachrichtigung trägt hier keine Ressourcendaten, nur die Tatsache, dass eine Mail existiert, deshalb braucht Restow auch kein Verschlüsselungszertifikat.
Ein Abonnement gehört der App, die es angelegt hat. Verbinden Sie die Quelle mit einer anderen Entra-App (der mandantenfähigen App der Installation oder der eigenen App der Quelle), prüft Restow das alle fünf Minuten und legt die Abonnements für die neue App neu an.
Microsoft erlaubt 1000 Abonnements je Postfach über alle Apps; Restow nutzt eines je archiviertem Postfach.

Das Netzwerk: Microsoft ruft Ihre Installation auf. Das ist die eine Stelle, an der eine Verbindung von Microsoft kommt. Microsoft Graph sendet jede Benachrichtigung als HTTPS-POST an zwei öffentliche Adressen Ihrer Installation:

https://restow.example.com/api/v1/hooks/graph/notifications
https://restow.example.com/api/v1/hooks/graph/lifecycle

Damit das funktioniert:

Die öffentliche URL der Installation muss https:// sein, ohne Port oder mit Port 443, mit einem Namen, den Microsoft aus dem Internet auflösen kann: nicht localhost, keine private Adresse, kein Name, der auf .local, .internal oder .lan endet. Restow nimmt die URL aus Installation → Server & Betrieb → Server, wenn sie dort gesetzt ist, sonst aus RESTOW_PUBLIC_URL. Das Zertifikat muss eines sein, das Microsoft bei der Prüfung der Adresse validieren kann; der Caddy-Edge mit seinem eigenen Let’s-Encrypt-Zertifikat tut das.
TCP 443 muss aus dem Internet erreichbar sein, zum Web-Edge. Eine öffentliche Installation hat das ohnehin, weil die Agenten es brauchen. Ein Host im LAN hinter einem Reverse-Proxy braucht einen Proxy, der /api/v1/hooks/graph/ unverändert an Restow durchreicht: POST-Anfragen, keine Anmeldung oder Single Sign-on vor dem Pfad, kein Filter, der Microsoft aussperrt, und ein Body von mindestens 1 MiB (größere Bodys lehnt Restow selbst ab). Siehe Netzwerk und Ports.
Die Hooks antworten schnell, denn Microsoft wartet nur Sekunden: Die Validierungsanfrage beim Anlegen eines Abonnements wird innerhalb von 10 Sekunden mit ihrem Token beantwortet, eine Benachrichtigung innerhalb von 3 mit 202. Restow prüft jede Benachrichtigung gegen das Geheimnis des Abonnements (clientState, nur als SHA-256-Hash gespeichert) und ignoriert alles andere, ebenfalls mit 202. Eine Benachrichtigung trägt nie Mail; sie stellt nur einen Abruf in die Warteschlange.
Restow prüft die Absenderadresse einer Benachrichtigung nicht; das Geheimnis entscheidet. Restow liefert keine Liste der Quelladressen von Microsoft für diese Aufrufe mit, schränken Sie die Hooks also nicht nach Quelladresse ein, es sei denn, Sie pflegen die aktuelle Liste von Microsoft selbst.

Ohne öffentliche HTTPS-URL (eine Installation nur im LAN oder lokal, oder ein Name, den Microsoft nicht erreicht) geht nichts kaputt: Restow legt keine Abonnements an und prüft stattdessen jedes Postfach alle 15 Minuten auf Änderungen (ARCHIVE_GRAPH_POLL_MINUTES). Die Archiv-Seite sagt das, mit dem Grund graph.notification_url_unavailable. Lehnt Microsoft ein Abonnement ab (zum Beispiel, weil es die Adresse nicht validieren kann), wird das Postfach vorerst im Intervall geprüft (graph.subscription_failed), und Restow versucht es jede Stunde erneut. Auch mit Benachrichtigungen läuft alle 6 Stunden ein Abgleich über jeden Ordner (ARCHIVE_GRAPH_CATCHUP_MINUTES) und sofort nach einer verpassten Benachrichtigung.

Ausgehend ändert sich nichts: login.microsoftonline.com und graph.microsoft.com wie bei der Sicherung. Restow folgt der Drosselung von Microsoft (429 mit Retry-After) und legt Abonnements in Batches zu höchstens 20 an und verlängert sie, ein Batch je Sekunde und Microsoft-Mandant.

Im Mandanten sollte eine Aufbewahrungsrichtlinie oder ein Litigation Hold gelöschte Mail halten, damit auch Mail erfasst wird, die gleich nach der Zustellung gelöscht wird. Graph v1.0 bietet keinen Weg, das zu lesen. Eine Administration prüft es mit den Exchange-Online-PowerShell-Befehlen, die nur lesen und die die Archiv-Seite zeigt, und bestätigt es je Quelle; siehe Archivierung. Restow liest nur den Ordner der Löschungen in den Wiederherstellbaren Elementen. Mail, die endgültig gelöscht wurde, bevor Restow sie geholt hat, kann fehlen, und Graph kann Mail über etwa 150 MB nicht exportieren (sie wird protokolliert und nicht archiviert).

Benachrichtigungs-Mail über die Backup-App

Läuft die Benachrichtigungs-Mail über die App-Registrierung der Sicherung (der Microsoft-Graph-Transport, Berechtigung Mail.Send) aus einem Tenant, der der App nie den Admin-Consent erteilt hat, sagt der Test der Benachrichtigungs-Mail, dass die Backup-App im Tenant des Absenderpostfachs keinen Admin-Consent hat, und verlinkt die Administratorzustimmung. Vor 0.4.0 meldete er „App nicht gefunden“ und bat darum, IDs zu prüfen, die richtig waren. Siehe Benachrichtigungen und Berichte.

Objekte, die nicht mehr gesichert werden (seit 0.4.7)

Seit 0.4.7 lässt Restow ein Postfach, ein OneDrive, eine SharePoint-Website oder ein Gruppenpostfach nicht mehr jede Nacht fehlschlagen, wenn die Quelle selbst sagt, dass es nichts zu sichern gibt. Das Objekt wird als Nicht gesichert mit dem Grund markiert, seine Sicherungen bleiben erhalten, und eine Administration wird gebeten zu bestätigen, dass das beabsichtigt ist. IMAP-Konten werden nie so markiert: Sie haben keinen Verzeichnisabgleich, Sie pflegen sie von Hand.

Was die Quelle meldet	Bezeichnung	`statusReason` in der API
Das Konto ist deaktiviert, und Exchange Online stellt dafür kein Postfach bereit	Nicht gesichert: Konto deaktiviert	`account_disabled`
Das Konto hat keine Exchange-Online-Lizenz (das Postfach wurde nie bereitgestellt, die Lizenz wurde entzogen, oder das Postfach ist inaktiv)	Nicht gesichert: keine Lizenz	`no_license`
Microsoft hat das OneDrive oder die Website gesperrt (HTTP 423, „Access to this site has been blocked“; Microsoft tut das nach einiger Zeit mit dem OneDrive eines Kontos ohne Lizenz, und eine Administration kann eine Website sperren)	Nicht gesichert: gesperrt	`locked`
Das Objekt gibt es in der Quelle nicht mehr	Nicht mehr in der Quelle	`null` (Status `orphaned` ohne Grund)

Wie Restow es erfährt. Der Verzeichnisabgleich prüft das Postfach jedes Nutzers, und die Sicherung fragt Microsoft noch einmal, bevor sie etwas markiert: Der Nutzer muss noch existieren, und Exchange muss eindeutig sagen, dass es kein Postfach gibt. Nur die Antwort von Exchange zählt, nicht das Kennzeichen des Kontos: Ein deaktiviertes Konto, dessen Postfach Microsoft noch bereitstellt (ein geteiltes Postfach, eine ausgeschiedene Person), wird wie bisher gesichert. Ein 401 oder 403 wird nie so gelesen; das bleiben Berechtigungsfehler. Eine Sperre bestätigt ein einziger billiger Lesezugriff auf das Laufwerk oder die Website; ein 423, den dieser Zugriff nicht bestätigt, bleibt ein gezählter Fehler mit seiner Meldung backup.failed, und ein 423 bei einer einzelnen Datei bleibt ein Elementproblem. Eine Website, deren Bibliotheken alle mit 423 antworten, endet ohne Sicherungsstand, statt alte Kopien weiterzutragen.
Was es bedeutet. Kein Fehler und kein rotes Readiness wegen des Alters der letzten Sicherung, nie überfällig, keine Meldung backup.failed und kein Webhook job.failed. Vorhandene Sicherungsstände bleiben wiederherstellbar, und eine Wiederherstellung in das ursprüngliche Postfach eines solchen Kontos wird mit dem Grund abgelehnt (Backup und Restore). Der Scheduler plant für das Objekt keinen Lauf.
Es setzt von selbst wieder ein. Die Sicherung startet gleich nach dem Verzeichnisabgleich, der das Konto wieder aktiviert oder lizenziert oder die Sperre aufgehoben findet. Der Abgleich schaltet ein gesperrtes Objekt nie aktiv, nur weil es noch gelistet ist: Er liest jedes gesperrte Laufwerk oder jede gesperrte Website noch einmal und nimmt die Sicherung nur wieder auf, wenn dieser Zugriff gelingt; sonst bleibt das Objekt gesperrt, und der Abgleich meldet, dass die Prüfung fehlschlug (lock_probe_failed).
Bitte bestätigen. Bis eine Administration bestätigt, steht das Objekt gelb da, Nicht mehr gesichert, bitte bestätigen, mit dem Grund und dem Datum. Es ist kein Fehler, aber die Warnungen, das Dashboard und die Wiederherstellbarkeit des Mandanten bleiben mindestens gelb (nie grün), und ein Provider sieht inactive_to_confirm unter den Warnungen des Mandanten. Die Dashboard-Kachel, die Seite Warnungen und ein Banner über der Liste der geschützten Objekte führen dorthin (Prüfen und bestätigen, Anzeigen).
Ja, beabsichtigt. Eine Administration bestätigt je Objekt oder für mehrere in der Liste der geschützten Objekte, durch Auswahl von Zeilen oder durch den Filter der Liste (höchstens 1000 auf einmal, hinter einer Bestätigung, die die Zahl nennt). Die Liste filtert nach den Zuständen Nicht mehr gesichert, bitte bestätigen und Absichtlich nicht mehr gesichert. Bestätigte Objekte stehen grau da, Absichtlich nicht mehr gesichert, mit Angabe, wer es wann bestätigt hat. Mandanten-Administratoren und die Provider-Rollen, die konfigurieren dürfen (Administratoren und Inhaber), dürfen bestätigen; jede Bestätigung wird auditiert (directory.inactive.confirmed, directory.inactive.bulk_confirmed). Die Oberfläche fragt keinen Grund ab; über die API kann eine Bestätigung eine Notiz von bis zu 1000 Zeichen für das Audit-Log tragen (API-Referenz).
Wird es wieder aktiv, entfällt die Bestätigung, und die Sicherung setzt wieder ein; hört das Objekt später erneut auf, fragt Restow erneut. Ein Objekt, das ausgeschlossen war und dann aus der Quelle verschwindet, wurde nie gesichert und gilt als bestätigt (War ausgeschlossen und wurde nie gesichert). Nach dem Update auf 0.4.7 gelten Objekte, die schon verwaist waren, als bestätigt (Schon vor dem Update nicht mehr gesichert) und lösen keinen Hinweis aus.
Hinweise. Das Ereignis Objekt nicht mehr gesichert, bitte bestätigen (object.inactive) wird einmal je Objekt und Übergang ausgelöst, ein Hinweis, der standardmäßig in der Glocke erscheint. Hören mehr als 10 Objekte oder mehr als 20 % der zuvor gesicherten Objekte eines Mandanten (und mindestens zwei) innerhalb eines Tages auf, ersetzt eine Warnung je Mandant und Tag, Viele Objekte nicht mehr gesichert (object.inactive_many), die Hinweise, zum Beispiel weil Lizenzen entfernt wurden oder der Abgleich falsch eingegrenzt ist. Beide führen zu den Objekten, die warten. Siehe Benachrichtigungen und Berichte.

Die Erkennung wurde gegen eine simulierte Microsoft-Graph-API getestet, nicht gegen einen echten Tenant; eine Antwort von Microsoft, die Restow nicht als „kein Postfach“ oder als Sperre erkennt, bleibt ein gezählter Fehler, wie bisher (Update auf 0.4.7).

Erinnerungen, bevor Zugangsdaten einer App ablaufen (seit 0.4.7)

Ein Client-Secret oder Zertifikat einer App-Registrierung läuft ab, und von diesem Tag an schlägt jede Microsoft-365-Sicherung fehl, die die App nutzt. Seit 0.4.7 erinnert Restow 30 Tage vorher, erneut 7 Tage vorher und nach dem Ablauf, jede Stufe einmal je Ablaufdatum. Ein neues Datum (ein neues Secret oder Zertifikat, ein geändertes Datum) oder eine andere Registrierung beginnt von vorn, und ein Datum, das erst spät bekannt wird, löst nur die Stufe aus, in der es gerade steht. Restow liest das Datum nicht aus Microsoft Graph: Dafür wäre Application.Read.All nötig, das es nicht anfordert. Sie tragen es ein, oder Restow liest das Ende des Zertifikats (notAfter).

Die zentrale App (Installation → Microsoft-Multi-Tenant-App): Tragen Sie das Ablaufdatum des Secrets im Feld Läuft ab am ein, oder setzen Sie ENTRA_CLIENT_SECRET_EXPIRES_AT (JJJJ-MM-TT, wie Entra es zeigt), wenn das Secret aus .env kommt, und starten Sie die api neu. Die api prüft alle 15 Minuten (das erste Mal zwei Minuten nach dem Start; nicht in der öffentlichen Demo) und löst das Installationsereignis Zugangsdaten der Microsoft-365-App laufen ab (installation.app_secret_expiring, eine Warnung, ein Fehler nach dem Ablauf) für die Provider-Administratoren aus: in der Glocke sowie in den Mails und Webhooks jeder Regel, die es aufführt. Die Seite zeigt Läuft ab mit einer Badge, die 30 Tage vor dem Ende gelb und ab 7 Tagen rot wird (in ganzen Kalendertagen gezählt, UTC) und, bei einem Secret aus der Umgebung ohne Datum, wie man es setzt.
Eine Quelle mit eigener App (Verbindungsart Eigene Graph-App): Das Formular hat Secret läuft ab am (optional), und die Verbindungskarte der Quelle zeigt Läuft ab mit derselben Badge und, innerhalb von 30 Tagen oder nach dem Ablauf, was zu tun ist. Bei einem Client-Secret lässt sich das Datum dort eintragen, ändern oder entfernen, ohne das Secret erneut einzugeben (Ablaufdatum eintragen, Ablaufdatum ändern; auditiert als source.own_app.expiry_updated). Der Worker prüft jede Microsoft-365-Quelle eines aktiven Mandanten, die nicht deaktiviert ist (auch eine mit Fehler), alle fünf Minuten und löst Zugangsdaten der eigenen App einer Quelle laufen ab (source.app_secret_expiring) aus, das auch Mandanten-Administratoren wählen können. Eine Quelle, die vor 0.4.7 über eine eigene App verbunden wurde, hat kein Datum, bis Sie es eintragen; ein Zertifikat bekommt sein Datum, wenn es erneut eingegeben wird. Eine Quelle mit einem älteren eigenen Secret, aber ohne eigene App (gemeinsame Client-ID), hat in Restow kein Datum: Stellen Sie sie auf eine eigene App oder auf die zentrale App um.
Was die Erinnerungen sagen. Die Glocke nennt die Stufe („läuft in 5 Tagen ab“, „Bitte jetzt erneuern“, „sind abgelaufen“) und führt zur Seite der Quelle oder zu Installation → Microsoft-Multi-Tenant-App. Die Alarm-Mail nennt das Ablaufdatum, die verbleibenden Tage, die Art der Zugangsdaten, die Anwendungs-ID (Client) und wie man ohne Lücke erneuert: das neue Secret anlegen, es mit seinem neuen Datum eintragen und erst dann das alte in Entra löschen. Beide Ereignisse gehören zur Wahl Fehler und Warnungen der Benachrichtigungsmatrix und zur Voreinstellung der Glocke, und jede Stufe passiert die Drosselung einer Regel für sich.

IMAP

Bei einer IMAP-Quelle geben Sie Server (Host, Port, Sicherheit) an und wie sich die Quelle anmeldet. Heute bedeutet das Anmeldung mit Benutzername und Passwort. Da IMAP-Postfächer kein Entra-Verzeichnis zum Synchronisieren haben, fügen Sie sie als manuelle Liste hinzu oder importieren sie aus einer CSV-Datei (Spalten login, name, email, dazu eine optionale Spalte password).

Jede Quelle nutzt eines von drei Anmeldeverfahren:

Gemeinsamer Zugang (Standard): ein Login und ein Passwort an der Quelle, verwendet für jedes Postfach darunter. Das passt zu einem App-Passwort oder einem Backup-Konto, das Ihr Anbieter alle Postfächer öffnen lässt.
Eigenes Passwort je Postfach: für Anbieter, bei denen jedes Postfach ein eigenes Passwort hat und es kein Master-Konto gibt. Die Quelle selbst hat keinen Login zum Testen. Sie fügen die Postfächer hinzu und nutzen dann im Reiter Verzeichnis je Postfach Passwort setzen und Anmeldung testen. Bei einem Postfach ohne Passwort ist keine Anmeldung möglich, es wird also erst gesichert, wenn eines gesetzt ist.
Master-User: ein Master-Konto meldet sich als jedes Postfach an, entweder in der Form master*postfach, die Dovecot nutzt, oder per SASL PLAIN mit einer Autorisierungs-ID. Ihr IMAP-Server muss eines von beiden unterstützen.

OAuth2 für IMAP-Quellen (auch Microsoft-365- und Google-Postfächer, die per IMAP statt Graph angebunden werden) ist noch nicht umgesetzt; geplant. Das gilt auch für die Archivierung des Kontos.

IMAP-Archivierung und Google-Workspace-Konten

Seit 0.4.4 kann Restow IMAP-Konten laufend archivieren. Das ist zeitnah und nicht vollständig; wo der Anbieter eine Kopie weiterleiten kann, ist die Weiterleitung der stärkere Weg, und beide können zusammen laufen (was beide erfassen, wird einmal archiviert).

Was gelesen wird. Jeder auswählbare Ordner außer Entwürfen, auch Gesendet, Papierkorb und Spam. Bei Gmail und Google Workspace nur Alle Nachrichten, Spam und Papierkorb, die jede Mail genau einmal halten (Gmail zeigt eine Mail sonst einmal je Label). Restow erkennt ein Google-Konto an seinem Host (imap.gmail.com, imap.googlemail.com) oder an einer OAuth2-Quelle von Google; das entscheidet, welche Wege der Job-Editor anbietet. Beim Lesen des Kontos erkennt es außerdem die Ordnerliste von Gmail ([Gmail]/All Mail).
Wie neue Mail bemerkt wird. Bei der Aktivierung hält Restow fest, wo jeder Ordner steht. Mail bis dahin wird einmalig übernommen; danach liest es nur Neues. Mit IMAP IDLE meldet der Server es Restow nach Augenblicken; alle 5 Minuten (ARCHIVE_IMAP_POLL_MINUTES) prüft dieselbe Verbindung die übrigen Ordner, und alle 30 Minuten läuft zur Sicherheit ein voller Durchlauf. Ohne IDLE wird ein Konto alle 10 Minuten per Anmeldung abgefragt (ARCHIVE_IMAP_LOGIN_POLL_MINUTES). Die Archiv-Seite sagt, welche Konten abgefragt werden und warum: imap.idle_unsupported (der Server hat kein IDLE), imap.idle_disabled (für die Quelle ausgeschaltet) oder imap.idle_budget (kein freier Platz dafür).
Die Anmeldung ist wie bei der Sicherung. Die Archivierung nutzt dieselben Zugangsdaten wie die Sicherung des Kontos (gemeinsamer Zugang, eigenes Passwort je Postfach oder Master-User). Restow meldet sich nur mit Passwort an: OAuth2 für IMAP-Quellen gibt es in API und Oberfläche noch nicht, und Restow legt keine App-Passwörter an und fragt keine ab. Für ein Google-Workspace-Konto heißt das ein Passwort, das Google für IMAP akzeptiert; ob dafür ein App-Passwort nötig ist, hängt von den Regeln von Google für Ihr Workspace ab, die Restow nicht sehen kann. IMAP muss für das Konto erlaubt sein.
IMAP auf einem Microsoft-Host (outlook.office365.com und weitere) wird wie jedes Konto archiviert, aber das Verbinden des Mandanten als Microsoft-365-Quelle erfasst seine Postfächer vollständiger. Der Job-Editor sagt das.

Verbindungen: Planen Sie das Limit Ihres Anbieters ein. Viele Anbieter begrenzen gleichzeitige Verbindungen je Konto (Gmail 15, Exchange Online 20, viele Hoster 2 bis 5).

Mit IDLE hält Restow je Konto eine Verbindung dauerhaft offen. Während eines Durchlaufs oder einer Übernahme nutzt es kurz eine zweite, und eine laufende Sicherung nutzt bis zu zwei weitere, ein Konto kann also gleichzeitig bis zu vier Verbindungen nutzen. Die Mailclients Ihrer Nutzer brauchen eigene.
Jeder Worker-Prozess beobachtet bis zu ARCHIVE_IMAP_IDLE_MAX Konten mit IDLE (300; 0 schaltet IDLE ab). Mehr Konten als das werden im Intervall per Anmeldung geprüft.
Bei einem Anbieter mit knappem Limit öffnen Sie die Quelle und stellen Archivierung → Konten mit IMAP IDLE beobachten auf Nur in Abständen prüfen. Dann bleibt keine Verbindung offen; Restow prüft die Konten alle paar Minuten auf neue Mail. Die Worker übernehmen die Einstellung innerhalb einer Minute. Über die API ist es PATCH /api/v1/sources/:id mit {"archiveIdle": "off"} ("auto" ist die Vorgabe).

Weitergeleitete Kopien vom Mailanbieter

Bei Anbietern ohne Exchange-Journaling kann der Anbieter selbst eine Kopie jeder ein- und ausgehenden Mail an Restow schicken, während er die Mail transportiert. Das erfasst Mail, bevor ein Nutzer sie löschen kann, ist also stärker als die IMAP-Archivierung, und braucht keine IMAP-Verbindung. Es hat zwei Hälften: Regeln beim Anbieter und einen Empfänger auf Ihrer Seite. Restow kann die Regeln nicht setzen; es erzeugt die Adressen und die Konfiguration zum Kopieren.

Was Sie als Betreiber einrichten. Der Empfänger ist der SMTP-Empfänger der Journal-Einrichtung, Sie richten ihn also einmal für Journaling und Weiterleitung zusammen ein; die Schritte stehen unter Exchange-Journaling und TLS-Zertifikat:

In .env: JOURNAL_SMTP_PORT=25, JOURNAL_SMTP_BIND=0.0.0.0 (Release-Stack) und JOURNAL_HOSTNAME=archive.example.com, nur der Hostname. Starten Sie die api neu.
DNS: ein A- oder AAAA-Eintrag für diesen Hostnamen (oder ein MX-Eintrag, der auf einen Host mit einem solchen zeigt), der zu diesem Server führt.
Öffnen Sie TCP 25 eingehend aus dem Internet (oder von den Mailservern Ihres Anbieters), direkt zum Empfänger, nie über Caddy (Netzwerk und Ports).
Ein TLS-Zertifikat einer öffentlich vertrauten Stelle für diesen Hostnamen (JOURNAL_TLS_CERT_PATH, JOURNAL_TLS_KEY_PATH). STARTTLS ist Pflicht: Der Empfänger weist einen Absender ab, der nicht auf TLS umstellt (530), der Mailserver des Anbieters muss es also können. Ohne gültiges Zertifikat startet der Empfänger nicht.
Leitet ein Hoster die Mail vieler Konten weiter, gelten die Grenzen je Absender-IP-Adresse (JOURNAL_RATE_PER_IP, 600 Verbindungen pro Minute) und je Archivadresse (JOURNAL_RATE_PER_ADDRESS, 300 Zustellungen pro Minute) je api-Prozess; erhöhen Sie sie, wenn Kopien mit 421 oder 451 abgewiesen werden.

Zwei Arten von Adresse. Regeln werden je Konto oder je Domäne geschrieben, deshalb hat Restow zwei:

Archivadresse eines Kontos: archive+<token>@<Journal-Host>. Eine Kopie an sie gehört genau diesem IMAP-Konto, die Zuordnung ist also sicher. Nutzen Sie sie für Regeln je Konto.
Die Journal-Adresse des Mandanten: journal+<token>@<Journal-Host>, die des Exchange-Journalings. Eine Kopie an sie wird den Postfächern zugeordnet, deren Adresse in den Kopfzeilen der Kopie steht (From, To, Cc, Delivered-To und weitere) oder im MAIL FROM. Nutzen Sie sie für Regeln für eine ganze Domäne und für Google Workspace.

Was Sie beim Anbieter einrichten. Wählen Sie im Mail-Job für die Art des Kontos Weiterleitung an die Archivadresse (IMAP) oder Routing an die Archivadresse (Google Workspace). Wählen Sie auf der Seite Archiv unter Weiterleitung an das Archiv für jedes Konto Adresse anlegen (eine Adresse wird einmalig ausgestellt). Die Reiter Postfix, mailcow, Sieve und Google Workspace zeigen dann die Konfiguration mit eingesetzten Adressen:

Postfix (ein eigener Server): je Konto eine Zeile in sender_bcc_maps (ausgehende Mail) und recipient_bcc_maps (eingehende Mail), zum Beispiel anna@example.com archive+<token>@archive.example.com; dann postmap und postfix reload. Für alle Konten einer Domäne auf einmal always_bcc an die Journal-Adresse des Mandanten.
mailcow: Legen Sie unter E-Mail, Konfiguration, BCC für jedes Postfach eine BCC-Zuordnung an, einmal vom Typ Absender und einmal vom Typ Empfänger, mit der Archivadresse des Kontos als Ziel.
Sieve (Dovecot Pigeonhole, viele Hoster): im Filter des Kontos require ["copy"]; redirect :copy "archive+<token>@archive.example.com";. Sieve sieht nur eingehende Mail; ausgehende Mail kommt über die IMAP-Archivierung.
Google Workspace: Fügen Sie in der Admin-Konsole unter Apps, Google Workspace, Gmail, Routing eine Regel für eingehende, ausgehende, interne sendende und interne empfangende Nachrichten hinzu und wählen Sie unter Zusätzlich zustellen an Weitere Empfänger hinzufügen mit der Journal-Adresse des Mandanten. Die Adresse entsteht im Abschnitt Exchange-Journaling der Archiv-Seite, wofür ein gültiger Journal-Host nötig ist; öffnen Sie den Abschnitt einmal. Änderungen können bis zu einer Stunde dauern. Eine Weiterleitung, die ein einzelner Nutzer in Gmail setzt, wird nicht unterstützt: Sie verlangt eine Bestätigung im Postfach, und der Nutzer kann sie abschalten.

Prüfen. Der Status jedes Kontos lautet Kopien kommen an, Noch keine Kopien oder Seit mehr als 24 Stunden keine Kopie, mit den Zählern für 24 Stunden und 7 Tage. Ein Konto, das vorher Kopien erhielt und seit 24 Stunden keine mehr, löst die Warnung Seit 24 Stunden keine weitergeleiteten Kopien aus (Benachrichtigungen und Berichte).

Grenzen einer weitergeleiteten Kopie. Sie hat keinen Umschlag wie ein Journal-Report, BCC-Empfänger sind also nur sichtbar, wenn der Anbieter sie in eine Kopfzeile schreibt (Delivered-To, X-Original-To). MAIL FROM ist oft eine SRS-Adresse des Weiterleiters. Der Empfänger prüft den Absender nicht (SPF); das zufällige Token in der Adresse ist das Geheimnis. Erneuern Sie eine Archivadresse, ist die alte sofort ungültig und Kopien an sie werden abgewiesen: Ändern Sie die Regel beim Anbieter gleich. Eine SMTP-Transaktion liefert in das Archiv genau eines Mandanten.

Importierte Mail-Dateien

Importierte Mail-Dateien ist eine Quelle für Mail, die Sie aus Dateien einbringen, statt sie von einem Server abzugleichen: EML-Dateien, Ordner oder ZIP-Archive, MSG, MBOX (Thunderbird, Apple Mail) und MailStore-Exporte in EML- oder MSG-Form. Es gibt eine je Mandant, ohne Server und ohne Zugangsdaten. Sie legen sie unter Mandanten-Einstellungen → Verbindungen → Quelle hinzufügen → Mail-Dateien importieren an und laden dann Dateien im Browser hoch oder wählen Dateien aus dem Ordner des Mandanten auf dem Server.

Von dieser Quelle wird nichts gesichert, weil es kein Postfach zum Lesen gibt. Jeder Import erzeugt stattdessen ein importiertes Postfach, das Sie im Restore-Explorer durchsuchen und wiederherstellen, als Dateien exportieren und optional ins Archiv übernehmen können. Siehe Mail-Dateien importieren und exportieren.

Server und Clients sind keine Quellen

Server und Client-Rechner sind keine Quellen. Sie sind Endpoints: Ein kleiner Agent auf dem Rechner sendet Datei-Sicherungen an Ihre Restow-Instanz, und Sie richten sie im Bereich für das Endpoint-Backup ein, nicht unter Quellen. Siehe Endpoint-Backup. Auch die VMs und Container von Proxmox VE sind keine Quellen: Sie verbinden die Proxmox-VE-Knoten unter Server & Clients → VMs & Container. Siehe Proxmox-VE-Backup. Auch Dateiserver sind keine Quellen: Seit 0.4.0 sichert Restow deren SMB- und NFS-Freigaben vom Server aus, wie Proxmox-VE-Gäste, ohne Agent auf dem Dateiserver, und Sie legen sie als Freigaben an. Siehe Dateifreigaben.

Was das Verbinden einer Quelle nicht tut

Das Verbinden einer Quelle legt über den Sicherungsstatus hinaus keine Postfachdaten irgendwo in der Restow-Oberfläche offen: Endnutzer sehen ihre eigenen Daten immer erst, nachdem sie sich selbst angemeldet haben (siehe Für Endnutzer), und jeder administrative Lesezugriff auf Nutzerdaten wird im Audit-Log erfasst.