Benachrichtigungen und Berichte

Restow informiert in drei Schritten. Ein Ereignis (eine Sicherung ist fehlgeschlagen, eine Restore-Prüfung nicht bestanden, ein Datenträger wird knapp) löst das Produkt aus. Jeder Kanal eines Mandanten (die Glocke, jeder Webhook, jeder Benachrichtigungsempfänger) führt die Liste der Ereignisse, die er erhält: die Benachrichtigungsmatrix (seit 0.4.0). Alarm-Regeln ergänzen, was die Matrix nicht entscheidet: wie oft sich derselbe Alarm wiederholen darf, eine eigene Frist für fehlende Sicherungen sowie eigene Adressen und ein eigener Webhook. Berichte sind Zusammenfassungen zu einer festen Zeit.

Was	Wo
Die Matrix: welcher Kanal welches Ereignis erhält	Integrationen → Benachrichtigungen
Benachrichtigungsempfänger (Personen) sowie die Alarm- und Berichts-Regeln	Mandanten-Einstellungen → Benachrichtigungen
Was gesendet wurde, und das Zustellprotokoll	Täglich → Alarme
Webhooks (URL, Format, Secret)	Integrationen → Webhooks
Der Mailversand (SMTP oder Microsoft Graph)	Installation → Benachrichtigungs-Mail

Mandanten-Administratoren und Provider-Administratoren verwalten alles. Jeder Mandant hat eine eigene Matrix und eigene Regeln.

Die Benachrichtigungsmatrix (seit 0.4.0)

Integrationen → Benachrichtigungen, überschrieben mit „Wer welche Benachrichtigung erhält“, zeigt die Ereignisse als Zeilen, gruppiert (Läufe, Wiederherstellbarkeit, Speicher, Installation) und nach Schweregrad gekennzeichnet (Fehler, Warnung, Info). Die Spalten sind die Kanäle des Mandanten:

Glocke: alle Personen im Mandanten.
Jeder Webhook des Mandanten, mit Host und Format. Ein pausierter Webhook ist als solcher gekennzeichnet.
Jeder Benachrichtigungsempfänger, eine Spalte je Person.

Haken Sie die Ereignisse an, die ein Kanal erhalten soll. Jede Spalte hat Schnellauswahlen: Nur Fehler, Fehler und Warnungen und Alle; eine Spalte, die zu keiner passt, zeigt Eigene Auswahl. Änderungen bleiben ungespeichert, bis Sie Speichern wählen, und das Speichern schreibt einen Eintrag ins Audit-Log (report.matrix_updated, mit den Kanälen und der Zahl ihrer Ereignisse, nie mit einer Adresse).

Eine Spalte ist ein echter Filter: Eine Alarm-Regel sendet nie ein Ereignis an einen Kanal, bei dem es abgewählt ist. Die Regel bestimmt weiter, wie oft sie alarmiert und wann Berichte gehen. Überspringt eine Regel einen Kanal aus diesem Grund, steht im Zustellprotokoll „Der Kanal erhält dieses Ereignis nicht mehr (Integrationen › Benachrichtigungen)“.

Die Installationsereignisse (Update verfügbar und Wenig Speicherplatz) sind Zeilen nur für Provider-Administratoren. Das Speichern durch einen Mandanten-Administrator lässt sie, wie sie waren.

Womit ein Kanal beginnt

Die Glocke zeigt jedes Ereignis außer den beiden Routine-Ereignissen Sicherung erfolgreich und Restore-Prüfung abgeschlossen, bis der Mandant etwas anderes wählt. Eine Zeile je Lauf würde alles andere verdecken.
Ein Webhook, der mit 0.4.0 oder später angelegt wird, in der Oberfläche oder über die API ohne events, beginnt mit den Voreinstellungen seines Formats: Ein Discord-, Slack- oder Teams-Webhook erhält Fehler und Warnungen, ein signierter JSON-Webhook (restow) alles. Eine Regel, die andere Ereignisse an ihn sendet, liefert sie erst, wenn sie in der Matrix eingeschaltet sind.
Ein Benachrichtigungsempfänger erhält die Ereignisse der für ihn gewählten Kategorien (siehe Benachrichtigungsempfänger) und alles, was zusätzlich in der Matrix angehakt ist.
Alles, was vor dem Update bestand, behält genau das, was es vorher erhielt. Die Migration 0038 hat jede Spalte mit dem gefüllt, was der Kanal bekam, daher ändert sich beim Update nichts.

Die Ereignisse

Ein Ereignis gehört zu einer Gruppe, hat einen Schweregrad und einen stabilen Code. Die Glocke, die Regeln, das Zustellprotokoll und die Mails benutzen dieselben Namen.

Gruppe	Ereignis	Code	Schweregrad
Läufe	Sicherung fehlgeschlagen	`backup.failed`	Fehler
Läufe	Sicherung überfällig	`backup.overdue`	Warnung
Läufe	Sicherung erfolgreich (jeder Lauf, in der Glocke standardmäßig aus)	`backup.succeeded`	Info
Läufe	Wiederherstellung fehlgeschlagen	`restore.failed`	Fehler
Läufe	Wiederherstellung abgeschlossen	`restore.completed`	Info
Läufe	Archiv-Abgleich fehlgeschlagen (auch: Archiv-Erfassung gestoppt, seit 0.4.4)	`archive.failed`	Fehler
Läufe	Verzeichnisabgleich fehlgeschlagen	`directory.failed`	Warnung
Läufe	Objekt nicht mehr gesichert, bitte bestätigen (seit 0.4.7)	`object.inactive`	Info
Läufe	Viele Objekte nicht mehr gesichert (seit 0.4.7)	`object.inactive_many`	Warnung
Läufe	Zugangsdaten der eigenen App einer Quelle laufen ab (seit 0.4.7)	`source.app_secret_expiring`	Warnung, Fehler nach dem Ablauf
Läufe	Server oder Client meldet sich nicht	`endpoint.stale`	Warnung
Läufe	Sicherungsdaten eines Servers oder Clients bleiben gesperrt	`endpoint.repository_locked`	Warnung
Läufe	Sicherungsdaten einer Freigabe bleiben gesperrt	`file_share.repository_locked`	Warnung
Wiederherstellbarkeit	Restore-Prüfung nicht bestanden	`verify.red`	Fehler
Wiederherstellbarkeit	Restore-Prüfung mit Hinweisen	`verify.yellow`	Warnung
Wiederherstellbarkeit	Wieder wiederherstellbar	`verify.recovered`	Info
Wiederherstellbarkeit	Restore-Prüfung abgeschlossen (jede Prüfung, in der Glocke standardmäßig aus)	`verify.completed`	Info
Wiederherstellbarkeit	Verdächtige Sicherung (Anzeichen von Ransomware)	`backup.suspicious`	Fehler
Wiederherstellbarkeit	Aufbewahrung nach verdächtiger Sicherung weiter angehalten	`backup.suspicious_hold`	Warnung
Wiederherstellbarkeit	Startprüfung nicht bestanden	`boot_test.failed`	Fehler
Wiederherstellbarkeit	Startprüfung ohne Nachweis	`boot_test.unproven`	Warnung
Speicher	Speicherschaden gefunden (seit 0.4.2 auch, wenn Packs in 3 Prüfungen in Folge über mindestens 24 Stunden nicht lesbar blieben)	`scrub.corrupt`	Fehler
Speicher	Speicherschaden behoben	`scrub.repaired`	Info
Speicher	Verdächtiger Snapshot eines Servers oder Clients	`endpoint.suspicious_snapshot`	Fehler
Speicher	Speicherbudget von Servern und Clients	`endpoint.storage_quota`	Warnung
Speicher	Speicherbudget der Freigaben	`file_share.storage_quota`	Warnung
Installation	Update verfügbar (nur Provider-Administratoren)	`update.available`	Info
Installation	Wenig Speicherplatz (nur Provider-Administratoren)	`installation.disk_low`	Warnung
Installation	Zugangsdaten der Microsoft-365-App laufen ab (nur Provider-Administratoren, seit 0.4.7)	`installation.app_secret_expiring`	Warnung, Fehler nach dem Ablauf

Das Ereignis Archiv-Abgleich fehlgeschlagen meldet einen fehlgeschlagenen Archiv-Job und seit 0.4.4, dass die Archiv-Erfassung gestoppt hat (siehe Warnungen, wenn die Archiv-Erfassung stoppt). Was die Ereignisse bedeuten:

Sicherung überfällig (backup.overdue, seit 0.3.1) löst einmal je Objekt aus, wenn ein Postfach, OneDrive, IMAP-Konto, eine Freigabe, ein Rechner oder Proxmox-VE-Gast (siehe Proxmox VE: Wiederherstellbarkeit, Warnungen und Alarme) länger keine erfolgreiche Sicherung hatte, als seine Backup-Jobs vorsehen (doppelter längster geplanter Abstand des entspanntesten aktiven Jobs seiner Art, ohne Zeitplan zwei Tage), und erst wieder, nachdem dazwischen eine Sicherung gelungen ist. Eine Regel kann stattdessen eine eigene Frist von 24 bis 720 Stunden setzen, unter Frist für fehlende Sicherungen; die Glocke folgt weiterhin den Zeitplänen. Seit 0.4.7 wird ein Postfach-Mitglied mit eigenem Zeitplan, nur für dieses Mitglied, nach diesem Zeitplan oder nach den Mail-Jobs des Mandanten (dem entspanntesten) beurteilt, je nachdem, was länger erlaubt, sodass ein wöchentliches Mitglied eines täglichen Jobs zwei Tage nach seiner Sicherung nicht mehr überfällig ist. Ein Objekt, dessen Sicherung begonnen hat und noch läuft (bis zu 21 Tage, eine große erste Sicherung), ist nicht überfällig, und eine Sicherung, die nur in der Warteschlange wartet, hält den Alarm nicht zurück. Ein Objekt, das nicht mehr gesichert wird, ist nie überfällig (Objekte, die nicht mehr gesichert werden).
Sicherung erfolgreich und Restore-Prüfung abgeschlossen (verify.completed, beide seit 0.4.0) sind die Routine-Ereignisse: eines je beendetem Lauf. Sie sind für einen Kanal gedacht, der jeden Lauf sehen soll, etwa einen Chat-Kanal oder eine Mail an eine Person.
Restore-Prüfung nicht bestanden löst nur aus, wenn eine Prüfung einen Beleg für einen Schaden gefunden hat; eine Prüfung, die nicht abgeschlossen werden konnte, löst nichts aus (siehe Prüfung im Detail). Ist der einzige rote Grund eine Sicherung, die 7 Tage oder älter ist, sagen die Glocke und die Alarm-Mail stattdessen Sicherung zu alt.
Verdächtige Sicherung (Anzeichen von Ransomware) (backup.suspicious, seit 0.4.0) ist ein Fehler, einmal je Angriffsepisode ausgelöst, und sagt, dass die Aufbewahrung des Objekts angehalten ist. Aufbewahrung nach verdächtiger Sicherung weiter angehalten (backup.suspicious_hold) ist eine Warnung, die sich nach 14 Tagen und danach alle 14 Tage wiederholt, solange niemand den Befund geklärt hat. Siehe Ransomware-Erkennung.
Startprüfung nicht bestanden und Startprüfung ohne Nachweis (seit 0.4.0) betreffen einen Sicherungsstand aus Proxmox VE, dessen temporärer Gast nicht gestartet ist oder zwar gestartet ist, aber nie über den QEMU Guest Agent geantwortet hat. Siehe Startprüfungen.
Wenig Speicherplatz (installation.disk_low, seit 0.4.0): Auf dem Datenträger unter der Datenbank oder unter dem lokalen Standard-Repository (und, seit 0.4.5, der Systemplatte des Servers) ist weniger als ein Zehntel frei, und weniger als 5 GiB. Einmal je Episode für die gesamte Installation ausgelöst. Siehe Datenbank.
Server und Clients. Server oder Client meldet sich nicht löst aus, wenn ein Server sich länger als 2 Stunden nicht gemeldet hat oder ein Client seit 7 Tagen keine gute Sicherung hat. Beide Grenzen sind je Endpoint einstellbar, und ein Client gilt nie als still, nur weil er nachts ausgeschaltet ist. Die übrigen Ereignisse decken Endpoints ebenfalls ab: Eine fehlgeschlagene Sicherung oder Wiederherstellung eines Servers oder Clients löst Sicherung fehlgeschlagen bzw. Wiederherstellung fehlgeschlagen aus, ein fehlgeschlagener Restore-Test Restore-Prüfung nicht bestanden und ein beschädigtes Repository Speicherschaden gefunden. Eine bestehende Regel für diese Ereignisse deckt Endpoints daher ohne Änderung mit ab. Drei Ereignisse gehören nur zu Servern und Clients:
- Verdächtiger Snapshot eines Servers oder Clients (endpoint.suspicious_snapshot): Die Aufbewahrung hat einen Snapshot gefunden, den kein Sicherungslauf gemeldet hat, oder einen, der in der Zukunft datiert ist. Die Aufbewahrung behält ihn, und der Rechner könnte kompromittiert sein. Einmal je Snapshot.
- Speicherbudget von Servern und Clients (endpoint.storage_quota): Das Repository eines Rechners hat 90 Prozent seines Speicherbudgets erreicht, das Budget ist ausgeschöpft, oder Uploads wurden abgelehnt. Außerdem höchstens einmal am Tag, wenn alle Server und Clients eines Mandanten zusammen 90 Prozent des Mandantenbudgets erreichen.
- Sicherungsdaten eines Servers oder Clients bleiben gesperrt (endpoint.repository_locked): Aufbewahrung und Prüfungen haben das Repository sechsmal in Folge über mindestens 12 Stunden gesperrt vorgefunden.
Siehe Endpoint-Backup.
Freigaben. Eine fehlgeschlagene Sicherung einer Freigabe löst Sicherung fehlgeschlagen aus (ein geändertes Passwort, share.auth_failed, erreicht so noch in derselben Nacht jemanden), eine Freigabe ohne Sicherung über zu lange Zeit löst Sicherung überfällig aus, eine fehlgeschlagene Wiederherstellung oder Kopie Wiederherstellung fehlgeschlagen. Zwei Ereignisse gehören nur zu Freigaben: Speicherbudget der Freigaben (file_share.storage_quota, bei 80 Prozent des Budgets und wenn es aufgebraucht ist und neue Sicherungen abgelehnt werden) und Sicherungsdaten einer Freigabe bleiben gesperrt (file_share.repository_locked). Siehe Freigaben.
Update verfügbar. Restow löst dieses Ereignis einmal je neuer Version für die gesamte Installation aus, nachdem die Update-Prüfung unter Einstellungen, Updates eingeschaltet wurde. Nur Provider-Administrationen können es in eine Regel oder eine Spalte aufnehmen: Die eigenen Administrationen eines Mandanten erfahren nichts von Ihren Updates. Siehe Updates.

Neue Ereignisse und geänderte Warnungen (seit 0.4.7)

Vier Ereignisse sind neu, und einige Warnungen folgen neuen Regeln. Webhooks und Benachrichtigungsempfänger bekommen die neuen Ereignisse erst, wenn sie in der Matrix angehakt sind (eine Glocken-Spalte, die nie geändert wurde, zeigt sie), und die neuen Ereignisse haben im Webhook-Strom (job.*) kein eigenes Ereignis: Ein Webhook bekommt sie als signiertes report.alert.

Objekte, die nicht mehr gesichert werden. Zwei Ereignisse, beide führen zu den geschützten Objekten, die auf eine Bestätigung warten (Objekte, die nicht mehr gesichert werden):

Objekt nicht mehr gesichert, bitte bestätigen (object.inactive, ein Hinweis): einmal je Objekt und Übergang, wenn Restow aufhört, ein Objekt zu sichern, weil die Quelle es nicht mehr hat, das Konto deaktiviert oder unlizenziert ist oder Microsoft das OneDrive oder die Website gesperrt hat. Es ist kein Fehler: Bestätigen Sie unter Schutz mit Ja, beabsichtigt. Es erscheint standardmäßig in der Glocke.
Viele Objekte nicht mehr gesichert (object.inactive_many, eine Warnung): eine je Mandant und Tag, statt der Hinweise, wenn mehr als 10 Objekte oder mehr als 20 % der zuvor gesicherten Objekte des Mandanten (und mindestens zwei) innerhalb eines Tages aufhören, zum Beispiel weil Lizenzen entfernt wurden oder der Abgleich falsch eingegrenzt ist. Es gehört zur Wahl Fehler und Warnungen. Zwei Ereignisse, weil die Kanäle nach dem festen Schweregrad des Ereignisses filtern.

Ablaufende App-Zugangsdaten. Beide Ereignisse warnen, bevor das Client-Secret oder das Zertifikat einer App-Registrierung abläuft, 30 Tage vorher, erneut 7 Tage vorher und nach dem Ablauf, jede Stufe einmal je Ablaufdatum und nur, wenn der Ablauf bekannt ist (ein eingetragenes Datum oder das Ende des Zertifikats). Sie sind eine Warnung und nach dem Ablauf ein Fehler. Die Glocke nennt die Stufe („läuft in 5 Tagen ab“, „Bitte jetzt erneuern“, „sind abgelaufen“); 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, erst dann das alte in Entra löschen); Chat-Webhooks verlinken auf die Seite der Quelle. Beide gehören zur Wahl Fehler und Warnungen und zur Voreinstellung der Glocke, und jede Stufe passiert die Drosselung einer Regel für sich. Siehe Erinnerungen, bevor Zugangsdaten einer App ablaufen.

Zugangsdaten der Microsoft-365-App laufen ab (installation.app_secret_expiring) gilt für die zentrale App-Registrierung. Es wird für die gesamte Installation ausgelöst, daher können nur Provider-Administratoren es wählen.
Zugangsdaten der eigenen App einer Quelle laufen ab (source.app_secret_expiring) gilt für eine Quelle, die über eine eigene App verbunden ist. Es gehört zur Gruppe der Läufe, daher können es auch Mandanten-Administratoren wählen.

Sicherungen, die ein Dienst gebremst hat, lösen keine Fehler-Warnung aus. Eine Mail-&-SaaS-Sicherung, die nach allen Wiederholungen mit graph.throttled, graph.service_unavailable oder storage.rate_limited endet, zeigt Vom Dienst gedrosselt, wird wiederholt und löst weder Sicherung fehlgeschlagen noch den Webhook job.failed aus. Dasselbe gilt für eine Sicherung, die neutral endet, weil ein Objekt nicht mehr gesichert wird (graph.mailbox_inactive, graph.object_locked, config.object_inactive). Der nächste geplante Lauf versucht es erneut, und ein Objekt, das länger gebremst bleibt, fängt Sicherung überfällig ab, das auf das Alter der neuesten Sicherung schaut. Eine Wiederherstellung, ein Export, ein Import oder eine Prüfung, die ein Dienst gebremst hat, hat keinen nächsten Lauf und bleibt ein Fehler, mit Wiederherstellung fehlgeschlagen und Ähnlichem. Siehe Fehlererklärungen.

Wiederherstellungen, die nichts wiederhergestellt haben. Eine abgeschlossene Wiederherstellung mit fehlgeschlagenen Elementen und keinem wiederhergestellten (Nichts wiederhergestellt) löst Wiederherstellung fehlgeschlagen und den Webhook job.failed aus, mit „Nothing was restored: N items failed.“ als Fehlermeldung. Eine, die jedes Element übersprungen hat (Alles übersprungen), bleibt Wiederherstellung abgeschlossen und sagt es, in Chat-Kanälen als Information, nicht als Erfolg. Ein Job, den der Reconciler endgültig beendet, löst job.failed, die Glocke und die Regeln aus wie jeder andere.

Warnungen, wenn die Archiv-Erfassung stoppt (seit 0.4.4)

Mit der Erfassung aus den Postfächern und weitergeleiteten Kopien kann das Archiv verstummen, ohne dass ein Lauf fehlschlägt: ein Postfach, das nicht mehr gelesen werden kann, eine Regel beim Anbieter, die entfernt wurde, eine Journalregel, die ausgeschaltet wurde. Seit 0.4.4 löst Restow für diese Fälle das bestehende Ereignis Archiv-Abgleich fehlgeschlagen (archive.failed) mit einem Grund aus. Es sind keine eigenen Ereignisse, deshalb gelten die Matrix, die Regeln und die Empfängerkategorie Fehlgeschlagene Läufe, die archive.failed schon abdecken, auch dafür, und ein Kanal, bei dem Archiv-Abgleich fehlgeschlagen aus ist, bekommt keinen davon. Glocke und Mail sagen, welcher der drei es ist, und führen zu seinem Abschnitt der Archiv-Seite (Erfassung aus den Postfächern, Weiterleitung an das Archiv oder Exchange-Journaling):

Grund in den Details	Titel in Glocke und Mail	Ausgelöst, wenn
`capture_error`	Archiv-Erfassung seit über einer Stunde fehlerhaft: Postfach	Der Erfassungsstrom eines Postfachs, über Graph oder IMAP-Archivierung, steht seit mehr als einer Stunde im Fehler. Neue Mail dieses Postfachs kommt erst wieder ins Archiv, wenn es funktioniert.
`forward_stale`	Seit 24 Stunden keine weitergeleiteten Kopien: Konto	Weitergeleitete Kopien eines IMAP-Kontos kamen an, seit seine Archivadresse ausgestellt wurde, aber seit 24 Stunden keine, während ein Mail-Job, der das Konto archiviert, die weitergeleitete Kopie gewählt hat. Prüfen Sie die Regel beim Mailanbieter.
`journal_stale`	Seit 24 Stunden keine Journal-Reports	Die Journal-Adresse des Mandanten hat vorher Journal-Reports empfangen, aber seit 24 Stunden keine. Prüfen Sie die Journalregel und den Connector in Exchange Online und ob der Journal-Empfänger erreichbar ist.

Die beiden zu Kopien und Reports kommen nur, nachdem vorher etwas empfangen wurde (Restow schaut 7 Tage zurück, eine Adresse, die nie funktioniert hat, löst also nichts aus), und jede kommt einmal je Abschnitt: Sie wiederholt sich nicht, solange der Fehler dauert, und eine neue Warnung kommt erst, nachdem die Erfassung, die Kopien oder die Reports wieder funktioniert haben. Ein angehaltener Job erfasst weiter, seine Konten zählen also mit. Die Prüfung läuft etwa alle fünf Minuten, mit höchstens 100 Warnungen je Mandant und Durchlauf. Der Glockeneintrag zeigt das Problem, seit wann es besteht und die letzte Ankunft.

Alarm-Regeln: wenn etwas passiert

Eine Alarm-Regel sendet für jedes Ereignis, das sie nennt, eine Nachricht, per E-Mail und optional an einen Webhook. Legen Sie Regeln unter Mandanten-Einstellungen → Benachrichtigungen an. Eine Regel sendet nie ein Ereignis an einen Kanal, bei dem es in der Matrix abgewählt ist.

Wiederholte Alarme begrenzt, wie oft dieselbe Regel zum selben Postfach (oder zum selben Auftragstyp) alarmiert: jedes Mal oder höchstens alle 15 Minuten, stündlich, alle 4 Stunden oder einmal am Tag. Die Glocke zeigt jedes Ereignis, das ihre Spalte eingeschaltet hat, mit oder ohne Regel: Die Matrix, nicht eine Regel, bestimmt, was die Glocke zeigt.

Berichte: zu einem Zeitpunkt

Eine Berichts-Regel sendet zu einer festen Zeit eine Zusammenfassung des letzten Tages, der letzten 7, 30 oder 90 Tage: täglich, wöchentlich an einem gewählten Tag, monatlich am 1. oder nach einem Cron-Ausdruck. Die Zeitzone gehört zur Regel. Wählbare Inhalte:

Sicherungen: Erfolgsquote und fehlgeschlagene Elemente, jeweils mit dem Vorzeitraum zum Vergleich.
Wiederherstellbarkeit: Anteil der nachweislich wiederherstellbaren Postfächer und OneDrives und wie viele geschützt sind.
Fehler: die häufigsten Fehlerursachen.
Speicher: geschützte Daten und ihr Platz nach Deduplizierung.
Wiederherstellungen: wie viele liefen.

Die Zahlen sind dieselben, die die Übersicht im Reiter Statistik für diesen Zeitraum zeigt. Zeitgesteuerte Berichte haben noch keinen Block für Freigaben.

Empfänger und Kanäle

E-Mail: die Benachrichtigungsempfänger und alle Adressen, die eine Regel nennt, eine pro Zeile. Versand über den unter Installation → Benachrichtigungs-Mail eingerichteten Weg (SMTP oder Microsoft Graph). Ohne eingerichteten Versand steht das im Zustellprotokoll. Seit 0.4.0 sagt eine Mail über die App-Registrierung der Sicherung aus einem Mandanten, der ihr nie zugestimmt hat, dass die Zustimmung im Mandanten des Absenders fehlt, und verlinkt die Administrator-Zustimmung, statt „App nicht gefunden“ zu melden. Eine Mail.Send-Berechtigung, die Sie später erteilen, greift für diese Mail, sobald das zwischengespeicherte Token von Restow abläuft: Anders als die Sicherung holt die Mail nach einer Ablehnung kein neues Token (ein bekanntes Problem in 0.4.7).
Glocke: die Glocke aller Personen im Mandanten. Ihre Spalte in der Matrix bestimmt, was dort erscheint. Berichte können zusätzlich dort erscheinen, wenn eine Regel die Glocke nennt. Das Abzeichen an der Glocke zählt ungelesene Einträge. Es ist blau, solange sie nur Informationen sind (etwa eine abgeschlossene Wiederherstellung oder ein versendeter Bericht), und wird nur rot, solange ein ungelesener Eintrag eine Warnung oder ein Fehler ist.
Webhook: ein Webhook des Mandanten (Integrationen), etwa an ein RMM, Teams oder ein Ticketsystem. Seine Spalte in der Matrix bestimmt, welche Ereignisse er erhält, und eine Alarm-Regel, die den Webhook nennt, sendet ihm (als signiertes Ereignis report.alert) nur die Ereignisse, die seine Spalte eingeschaltet hat. Eine Berichts-Regel sendet report.summary.
Chat-Formate (ab 0.3.1): Ein Webhook bekommt ein Format. restow ist der signierte JSON-Umschlag (Standard und das Format jedes bestehenden Webhooks). discord, slack und teams senden eine Chatnachricht, die die eingehenden Webhooks dieser Dienste annehmen: Discord eine Nachricht mit einem Embed, Slack Text mit Blöcken, Teams eine Adaptive Card für Workflows (Power Automate) und die älteren Office-365-Connectors. Die Weboberfläche wählt das Format anhand der URL beim Eintippen; Sie können es von Hand ändern. Chatnachrichten enthalten Ursache und nächste Schritte in der Sprache des Mandanten und einen Link zu Restow; sie werden ohne Signatur gesendet, daher zeigt die Oberfläche für sie kein Secret. Antwortet ein Chatdienst mit 400, 401, 403, 404, 410, 413 oder 422, endet die Zustellung sofort; 429 und 5xx werden nach Retry-After wiederholt.

Nachrichten sind in der Sprache der Regel, ohne Angabe in der Sprache des Mandanten.

Benachrichtigungsempfänger

Benachrichtigungsempfänger sind die Personen, die ein Mandant direkt informiert. Fügen Sie sie beim Anlegen eines Mandanten hinzu (Assistent) oder später unter Mandanten-Einstellungen → Benachrichtigungen → Empfänger. Jeder Empfänger hat eine Adresse, einen optionalen Namen und die Ereignisse, die er erhält.

Die Kategorien im Assistenten und auf der Mandantenseite sind Abkürzungen für Gruppen von Ereignissen. Wer eine anhakt, fügt ihre Ereignisse der Spalte des Empfängers in der Matrix hinzu, wer sie abwählt, nimmt sie weg, und alles andere, was in der Matrix gewählt ist, bleibt unverändert:

Kategorie	Ereignisse
Fehlgeschlagene Läufe	`backup.failed`, `restore.failed`, `archive.failed`, `directory.failed`
Wiederherstellbarkeit wird rot	`verify.red`, `scrub.corrupt`
Wochenbericht (Business)	der Wochenbericht, montags um 07:00, sofern Berichte auf der Installation verfügbar sind

Das Speichern der Empfänger bringt die Regeln, die sie tragen, ab dem nächsten Alarm auf den neuen Stand. Die alte Kategorie „Lizenz- und Update-Hinweise“ hat nie etwas gesendet und wird nicht mehr zurückgegeben. Die Empfänger erscheinen als Spalten in der Matrix, in der Sie ihre Ereignisse einzeln wählen können.

Webhook-Ereignisse und die Matrix

Der Strom eines Webhooks behält seine Namen und Nutzdaten: job.failed, job.completed und verify.completed (siehe Integrations-API), dazu die signierten report.alert und report.summary aus Regeln. Die Matrix spricht in Ereignissen des obigen Katalogs. Sie hängen so zusammen:

Ereignis des Stroms	Ereignisse der Matrix, die es trägt
`job.failed`	Sicherung fehlgeschlagen, Wiederherstellung fehlgeschlagen, Archiv-Abgleich fehlgeschlagen, Verzeichnisabgleich fehlgeschlagen
`job.completed`	Sicherung erfolgreich, Wiederherstellung abgeschlossen
`verify.completed`	Restore-Prüfung abgeschlossen

backup.succeeded ist der Name der Matrix für das, was der Strom job.completed nennt: ein Alias, keine Umbenennung. Ein Webhook, der job.completed abonniert hat, erhält es weiter. Wer eines der Ereignisse einschaltet, die ein Strom-Ereignis trägt, abonniert den Webhook auf dieses Strom-Ereignis; wer also Sicherung erfolgreich anhakt, bekommt die Posts. In der API bedeutet events beim Anlegen und Ändern eines Webhooks weiterhin die abonnierten Strom-Ereignisse, und events ist beim Anlegen eines Webhooks optional (Integrations-API-Vertrag 1.4.0). Die Sitzungs-API liefert die Spalte des Webhooks in der Matrix außerdem als notifyEvents. Der Webhook-Dialog hat keine Ereignisauswahl mehr: Wählen Sie die Ereignisse eines Webhooks unter Integrationen → Benachrichtigungen.

Was sich mit 0.4.0 geändert hat

Beim Update hört nichts auf zu funktionieren: Bestehende Webhooks, Benachrichtigungsempfänger und API-Clients arbeiten weiter. Was sich anders verhält:

Jeder Kanal führt seine eigenen Ereignisse, und eine Regel sendet kein Ereignis mehr an einen Kanal, bei dem es abgewählt ist. Die Migration 0038 hat jede Spalte mit dem gefüllt, was der Kanal vorher erhielt.
Ein Webhook, der nach dem Update angelegt wird, beginnt mit den Voreinstellungen seines Formats (siehe oben).
Die vier Schalter der Benachrichtigungsempfänger eines Mandanten (notify_job_failures, notify_weekly_report, notify_readiness_red, notify_license_updates) sind durch eine Ereignisliste ersetzt. Die Mandanten-API akzeptiert und liefert weiter categories; ein Empfänger trägt jetzt zusätzlich events. Nur Skripte, die diese Spalten direkt aus der Datenbank lesen, brauchen eine Änderung.

Siehe Update auf 0.4.0.

Test und Zustellprotokoll

Jetzt Test senden (im Menü einer Regel) sendet eine als Test markierte Nachricht auf allen Kanälen der Regel. Das Zustellprotokoll zeigt jede Mail, jeden Glocken-Eintrag und jeden Webhook mit Ergebnis: in Warteschlange, gesendet, fehlgeschlagen oder übersprungen, und warum. Eine fehlgeschlagene Mail wird nach 1, 5, 15 und 60 Minuten wiederholt und dann aufgegeben. Seit 0.3.1 lässt sich das Zustellprotokoll mit den Filtern der Liste in jeder Edition als CSV exportieren.

Was protokolliert wird

Anlegen, Ändern und Löschen einer Regel, jede Testsendung und jedes Speichern der Benachrichtigungsmatrix stehen im Audit-Log. Der Gelesen-Status der Glocke gehört zum Mandanten: Was eine Person als gelesen markiert, ist für alle im Mandanten gelesen.