Profile, Zeitplan und Hooks

Jeder Endpoint hat ein Profil. Das Profil legt die Standardwerte für den Zeitplan und die Alarmgrenze fest. Jede Einstellung lässt sich danach je Endpoint ändern: Öffnen Sie den Rechner unter Server & Clients → Inventar und dann den Tab Einstellungen.

Die zwei Profile

	Server	Client
Gedacht für	Rechner, die durchgehend laufen	Laptops und Desktops, die oft aus oder offline sind
Standard-Zeitplan	Täglich um 22:00 Uhr, in der Zeitzone des Mandanten (Europe/Berlin, wenn keine gesetzt ist)	Sobald der Rechner online ist (`on_connect`): sobald die Instanz erreichbar ist, höchstens einmal alle 4 Stunden
Alarm, wenn	Mehr als 2 Stunden kein Kontakt	7 Tage ohne gutes Backup. Ein Client gilt nie als „still“, denn ein Laptop ist nachts aus.
Nur am Netzstrom	Aus	Aus

Beide Profile starten mit diesen Standardwerten für Ordner und Ausschlüsse. Sie lassen sich ändern.

System	Gesicherte Ordner
Linux	`/etc`, `/home`, `/root`, `/srv`, `/var/www`; Server ab 0.2.1 zusätzlich `/opt`, `/usr/local`, `/var/lib` und `/var/backups`, ohne `/var/lib/docker`, `/var/lib/containerd` und `/var/lib/apt/lists`
macOS	`/Users`

Die Standard-Ausschlüsse lassen Caches, temporäre Dateien, den Papierkorb, node_modules, *.tmp und den restic-Cache aus.

„Nur am Netzstrom“ ist für beide Profile standardmäßig aus, denn ein Backup, das nie läuft, ist schlimmer als eines im Akkubetrieb.

Server-Profil für einen Container oder eine virtuelle Maschine (seit 0.4.0)

Der Agent 0.4.0 sagt Restow, als was der Rechner läuft, und die Seite des Rechners zeigt es unter Läuft als: Container (mit seiner Technik), Virtuelle Maschine oder Physischer Rechner, jeweils mit oder ohne Desktop. Ein Linux-Rechner, den Sie mit einem Client-Token angemeldet haben und dessen Agent einen Container oder eine virtuelle Maschine ohne Desktop meldet, bekommt das Profil Server, denn er betreibt Dienste, deren Daten in /opt, /usr/local und /var/lib liegen. Die Seite des Rechners sagt, warum. Bereits angemeldete Rechner behalten ihr Profil, und ein älterer Agent meldet nichts, sodass wie bisher das Token entscheidet.

Der Agent liest das nur aus Dateien: /run/systemd/container, /.dockerenv und ähnliche Kennzeichen bei Containern, Hersteller und Produkt der DMI-Tabelle, /sys/hypervisor/type und das CPU-Flag hypervisor bei virtuellen Maschinen, und eine Sitzungsdatei in /usr/share/xsessions oder /usr/share/wayland-sessions bei einem Desktop. Er startet kein Programm, um das herauszufinden.

Zeitplan

Es gibt drei Arten von Zeitplan.

Art	Verhalten
Täglich zu einer festen Uhrzeit	Läuft zur gewählten Uhrzeit in der gewählten Zeitzone (die Sommerzeit wird berücksichtigt). Ein verpasster Zeitpunkt, zum Beispiel weil der Rechner aus war, wird einmal nachgeholt, sobald der Rechner wieder da ist (eine Richtlinie der Agenten kann das ausschalten oder in ein Sicherungsfenster verlegen). Ein frisches Enrollment wartet auf den nächsten Zeitpunkt.
In einem festen Abstand	Alle N Minuten, mindestens 5. Der erste Lauf startet direkt nach dem Enrollment.
Sobald der Rechner online ist (`on_connect`)	Startet, sobald die Instanz erreichbar ist, standardmäßig höchstens einmal alle 4 Stunden. Die 4 Stunden lassen sich ändern.

Zufällige Verzögerung. Jeder Endpoint startet 0 bis 10 Minuten später, abgeleitet aus seiner ID, damit viele Server Ihre Instanz nicht in derselben Sekunde belasten.
Wiederholungen. Nach einem fehlgeschlagenen Lauf versucht der Agent es nach 5, 15, 30, 60 und 60 Minuten erneut und wartet dann auf den nächsten regulären Zeitpunkt. Das sind 5 Wiederholungen; eine Richtlinie der Agenten legt 0 bis 10 fest. Ein Fehler, der durch eine verlorene Verbindung entsteht, zählt als Unterbrechung, nicht als Fehlschlag.
Fortsetzen nach einer Unterbrechung. Ein Backup, das unterbrochen wurde (Agent gestoppt, Rechner im Ruhezustand, Verbindung verloren), setzt sich fort, sobald die Instanz erreichbar ist, ohne auf den nächsten Zeitpunkt zu warten.
Kontakt. Der Agent meldet sich beim Start bei der Instanz und danach alle 5 Minuten, plus oder minus 60 Sekunden. Ist die Instanz nicht erreichbar, versucht er es nach 30 Sekunden erneut und verdoppelt den Abstand bis auf 5 Minuten. Ein Ruhezustand des Systems löst sofort eine Prüfung aus, sodass ein Laptop, der gerade Netz bekommen hat, schnell bemerkt wird. Seine Konfiguration holt er beim Start, stündlich, auf Anforderung und vor jedem Backup.
Eines nach dem anderen. Ein Rechner führt ein Backup, einen Restore oder einen Restore-Test nach dem anderen aus. Weitere Aufgaben warten in der Schlange.
Sicherungsfenster, Nachholen und die Update-Pause. Seit 0.4.0 kann eine Richtlinie der Agenten die Stunden begrenzen, in denen geplante Sicherungen, Wiederholungen und nachgeholte Sicherungen beginnen dürfen. Solange ein Restow-Update neue Läufe pausiert, beginnt auch der Agent 0.4.0 keine davon und wartet.

Einstellungen

Eine Änderung wird in Restow sofort gespeichert. Der Rechner wendet sie bei seinem nächsten Kontakt an, meist innerhalb weniger Minuten. Läuft ein Agent mit einer älteren Konfiguration, als der Server hält, erhält er die Änderung von selbst.

Einstellung	Was sie tut
Name	Wird in den Listen statt des Hostnamens angezeigt.
Zu sichernde Ordner	Absolute Pfade auf dem Rechner. Alles unterhalb eines Ordners ist eingeschlossen.
Ausschlussmuster	Ein Muster pro Zeile, zum Beispiel `*.tmp` oder `node_modules`. Passende Dateien werden ausgelassen.
Zeitplan	Art, Uhrzeit, Abstand in Minuten und Zeitzone.
Upload-Begrenzung (kbit/s)	Begrenzt die Upload-Geschwindigkeit. Leer bedeutet unbegrenzt. Bei einem Rechner in einem Job liegt das Limit im Job, und eine Richtlinie der Agenten liefert eines, wenn der Job keines festlegt.
Nur am Netzstrom sichern	Ein Laptop im Akkubetrieb überspringt das geplante Backup, bis er am Strom hängt. Eine Richtlinie der Agenten kann das ebenfalls verlangen.
Befehle vor und nach der Sicherung	Die Hooks, siehe unten.
Aufbewahrung	Wie viele tägliche, wöchentliche und monatliche Snapshots aufbewahrt werden.
Alarme	Stunden ohne Kontakt (Server) und Tage ohne erfolgreiche Sicherung (Client).
Speicherbudget	Wie viel das Repository dieses Rechners im Speicherziel höchstens belegen darf, in GiB. Leer heißt Standard der Installation. Siehe Speicherbudget.

Ordner und Ausschlüsse

Ein eingestellter Ordner, der nicht existiert, wird übersprungen und protokolliert. Existiert keiner davon, schlägt der Lauf fehl und sagt das.
Ein Pfad, der ein symbolischer Link ist, wird über sein Ziel gesichert. Unter macOS sind /etc und /var Links.
Der Agent lässt immer seine eigenen Cache- und Temp-Ordner und jeden Ordner namens Restow-Restore-* aus, damit frühere Restores nicht erneut gesichert werden.
Snapshots tragen den beim Enrollment festgehaltenen Hostnamen und den Tag restow-agent.

Datenordner, die ein Job auslässt (seit 0.4.0)

Ein Job sichert nur die Ordner, die er nennt, sodass ein Server mit einem Backup enden kann, das kaum mehr als seine Konfiguration enthält. Der Agent 0.4.0 meldet deshalb, welche Ordner einer festen Liste von Linux-Datenordnern existieren und Dateien enthalten. Er sendet nur die Namen, nie Dateinamen oder Größen, und sieht stündlich neu nach:

/opt, /usr/local, /srv, /var/www, die Volumes von Docker (/var/lib/docker/volumes) und Podman (/var/lib/containers/storage/volumes) sowie die Ordner von PostgreSQL, MySQL und MongoDB unter /var/lib (/var/lib/postgresql, /var/lib/pgsql, /var/lib/mysql, /var/lib/mongodb).

/var/lib als Ganzes, /var/backups, /home und /root stehen nicht auf der Liste, ebenso wenig macOS, wo beide Profile /Users sichern.

Ein Ordner gilt als gesichert, wenn ein Ordner des Jobs ihn enthält und kein Ausschluss ihn oder einen Ordner auf dem Weg dorthin trifft. Der Standard-Ausschluss /var/lib/docker lässt deshalb auch die Docker-Volumes weg. Darum reichte es nicht, nur /var/lib hinzuzufügen, wie es der Hinweis von 0.3.5 anbot: Die Docker-Volumes blieben draußen.

Im Job-Editor nennt der Hinweis Ordner mit Daten auf den Rechnern werden nicht gesichert die Ordner, die die Rechner des Jobs wirklich haben und der Job auslässt, mit den Rechnern, die sie haben. Fügen Sie einen Ordner mit Hinzufügen hinzu, oder alle. Ein Rechner, der einen der Ordner nicht hat, überspringt ihn ohne Fehler: Der Agent sichert die vorhandenen Pfade und schreibt nur eine Warnung ins Protokoll des Laufs, und der Lauf bleibt erfolgreich.
Auf der Seite eines Rechners bietet der Hinweis Ordner mit Daten auf diesem Rechner werden nicht gesichert die Schaltfläche Diesen Ordner zum Job hinzufügen an (bei mehreren: Diese N Ordner zum Job hinzufügen). Der Ordner kommt in den Job, die anderen Rechner des Jobs bekommen ihn also ebenfalls. Wer Jobs ändern darf, kann die Schaltfläche nutzen; ein Rechner, der im Job eigene Ordner hat, wird stattdessen auf den Job verwiesen.
Das Hinzufügen schränkt den Ausschluss eines Elternordners ein. Fügen Sie die Volumes von Docker hinzu, wird aus dem Ausschluss /var/lib/docker die Regel /var/lib/docker/* mit !/var/lib/docker/volumes: Images und Container bleiben draußen, die Volumes werden gesichert.
Bei älteren Agents bleibt der Hinweis von 0.3.5. Er nennt die Standardordner eines Servers (/opt, /usr/local, /var/lib, /var/backups), die der Job nicht sichert.
Im Dateibrowser sagt ein Sicherungsstand, welche Ordner er enthält (Dieser Sicherungsstand enthält:), mit einem Link zu den Ordnern des Jobs. Fehlt ein Datenordner darin, nennt ihn Dieser Sicherungsstand enthält nicht alle Datenordner und verweist auf den Job. Siehe Restore.

Upload-Begrenzung

Die Begrenzung gilt in Kilobit pro Sekunde, wie der Name sagt. 1000 kbit/s sind etwa 1 Mbit/s. Der Agent rechnet sie in die Option --limit-upload von restic in KiB/s um, aufgerundet.

Nur am Netzstrom

Die Prüfung erfolgt vor einem geplanten Start. Ist das Gerät im Akkubetrieb, wartet das Backup, und die Seite des Rechners sagt „Fällig, wartet auf das Netzteil“. Zwei Grenzen gelten:

Jetzt sichern in der Weboberfläche wird nicht zurückgehalten, und ein bereits laufendes Backup wird nicht gestoppt, wenn das Netzteil abgezogen wird.
Die Erkennung des Netzstroms arbeitet nach dem Best-Effort-Prinzip. Linux liest /sys/class/power_supply. macOS liest pmset -g batt, und eine USV zählt als Akku. Lässt sich der Zustand nicht bestimmen, nimmt der Agent Netzstrom an, damit eine fehlschlagende Erkennung Backups nie blockiert, und protokolliert das einmal am Tag. Systeme ohne Akku-Informationen zählen als Netzstrom.

Befehle vor und nach dem Backup (Hooks)

Ein Hook ist ein Befehl, den der Agent rund um jedes Backup ausführt. Typisch ist ein Datenbank-Dump, damit die Dump-Datei gesichert wird statt einer Datenbankdatei, die sich während des Lesens ändert. Die Weboberfläche schlägt als Beispiel für den Befehl vor dem Backup vor:

pg_dumpall -U postgres > /var/backups/all.sql

Achten Sie darauf, dass der Ordner, der den Dump aufnimmt, zu den gesicherten Ordnern gehört. Weitere allgemeine Einsatzzwecke sind, einen Dienst für die Dauer des Backups zu stoppen oder ein Dateisystem mit fsfreeze einzufrieren und danach wieder freizugeben. Ein Einfrieren blockiert Schreibzugriffe, solange es dauert, also für das ganze Backup.

Der Rechner entscheidet: die Hook-Regel

Hooks laufen als root, deshalb entscheidet der Rechner, ob er die Hooks ausführt, die Restow schickt, und nur root auf dem Rechner kann das ändern. Die Regel liegt auf dem Rechner in /etc/restow-agent/state.json. Restow kann sie nicht ändern: Es erfährt sie nur vom Agent und lehnt Hook-Einstellungen ab, die der Rechner nicht ausführen würde.

Regel	Auf dem Rechner gesetzt mit	Was läuft
`off` (Standard)	`sudo restow-agent hooks off`	Nichts. Ein in Restow eingestellter Hook wird übersprungen, das Backup läuft ohne ihn und endet Mit Warnungen (`partial`) mit dem Code `hooks_not_allowed`.
`scripts`	`sudo restow-agent hooks scripts`	Nur ein Skript, das root in `/etc/restow-agent/hooks.d` abgelegt hat und das der Hook nennt, zum Beispiel `db-dump`. Das Skript muss eine reguläre ausführbare Datei sein, die root gehört und für andere nicht schreibbar ist, in einem Ordner, den nur root ändern kann. Es läuft direkt, ohne Shell und ohne Argumente.
`any`	`sudo restow-agent hooks any`	Jeder Befehl, über `/bin/sh -c`. Wer die Einstellungen des Endpoints in Restow ändern darf, kann dann Befehle als root auf dem Rechner ausführen.

sudo restow-agent hooks status zeigt die Regel und bei scripts die Skripte, die der Agent ausführen würde. Die Regel lässt sich auch bei der Installation setzen, mit --hooks=off|scripts|any (siehe Installation). Der Agent liest die Regel bei jedem Backup, eine Änderung gilt also ohne Neustart, und Restow erfährt sie beim nächsten Kontakt, innerhalb von fünf Minuten.

Das Beispiel oben nutzt eine Umleitung der Shell und braucht als Befehl deshalb die Regel any. Mit scripts legen Sie denselben Befehl in ein Skript auf dem Rechner, zum Beispiel eine Datei db-dump mit den Zeilen #!/bin/sh und pg_dumpall -U postgres > /var/backups/all.sql, installieren es als root und tragen in Restow db-dump als Hook ein:

sudo install -m 0700 -o root db-dump /etc/restow-agent/hooks.d/db-dump

Der Name ist ein schlichter Dateiname mit bis zu 64 Zeichen (Buchstaben, Ziffern, Punkt, Bindestrich, Unterstrich).

Hooks in Restow

Unter Befehle vor und nach der Sicherung in den Einstellungen des Endpoints zeigt Restow die Regel des Rechners:

Hooks sind auf diesem Rechner ausgeschaltet: Die Felder sind gesperrt, und der Abschnitt zeigt die Befehle, die Hooks auf dem Rechner erlauben. Der Server lehnt Hook-Einstellungen für einen solchen Rechner ab (endpoint-hooks-not-allowed).
Dieser Rechner führt nur eigene Skripte aus: Geben Sie den Namen eines Skripts ein, keinen Befehl. Der Abschnitt nennt die Skripte, die der Agent gemeldet hat (Skripte auf dem Rechner). Ein Befehl wird abgelehnt (endpoint-hook-not-a-script).
Dieser Rechner führt beliebige Befehle aus: Eine Warnung sagt, dass diese Befehle mit vollen Rechten laufen.

Einen Hook zu setzen oder zu ändern erfordert eine Anmeldung aus den letzten 10 Minuten. Ist Ihre älter, bittet Restow Sie zu bestätigen, dass Sie es sind (mit einem Passkey oder durch erneutes Anmelden), und speichert die Änderung danach. Alle Hooks eines Rechners zu entfernen erfordert keine Bestätigung, denn der Rechner führt danach weniger aus, nie mehr. Die Bestätigung kommt zur Zustimmung des Rechners hinzu, sie ersetzt sie nicht.

Sind Hooks eingestellt, die der Rechner nicht ausführt, zum Beispiel weil root die Regel später auf off gesetzt hat, sagt der Abschnitt Die Befehle unten werden nicht ausgeführt und bietet Befehle entfernen an. Bis sie entfernt oder erlaubt sind, ist jedes Backup des Rechners teilweise.

Wer den Hook-Text sieht. Nur Administratoren, die die Einstellungen des Endpoints ändern dürfen, sehen den Text eines Hooks. Alle anderen (die Provider-Rollen Nur lesen und Techniker) sehen, ob ein Hook eingestellt ist, und einen kurzen Fingerabdruck davon.

Wie sich Hooks verhalten:

Umgebung. Ein Hook erhält eine kurze Liste von Variablen, nicht die Umgebung des Dienstes, dazu RESTOW_ENDPOINT_ID, RESTOW_RUN_ID und RESTOW_HOOK. Der Befehl nach dem Backup erhält außerdem RESTOW_BACKUP_STATUS.
Zeitlimits. 60 Minuten für den Befehl vor dem Backup und 30 Minuten für den Befehl danach. Bei einem Zeitlimit wird die ganze Prozessgruppe gestoppt.
Ein fehlschlagender Befehl vor dem Backup stoppt das Backup, weil die Daten inkonsistent sein können. Der Befehl nach dem Backup läuft trotzdem.
Ein fehlschlagender Befehl nach dem Backup macht aus einem erfolgreichen Backup eines, das Mit Warnungen endet.
Ein Hook, den der Rechner nicht zulässt, wird übersprungen. Das Backup läuft ohne ihn und endet Mit Warnungen (hooks_not_allowed), weil Daten, die der Hook vorbereitet, etwa ein Datenbank-Dump, fehlen oder veraltet sein können.
Härtung. Hooks erben die Härtung des Dienstes. Ein Hook, der Namespaces braucht (zum Beispiel rootlose Container) oder Kernelmodule lädt, funktioniert nicht.
Ausgabe. Was ein Hook ausgibt, landet im Lauf-Protokoll. Ein Hook darf keine Geheimnisse ausgeben. Der Agent maskiert seine eigenen Geheimnisse und gängige Geheimnis-Muster, und der Server schwärzt Zugangsdaten noch einmal, bevor er das Protokoll speichert, nicht mehr.
Länge. Jeder Befehl darf bis zu 4096 Zeichen lang sein.
Audit-Log. Werden Hooks geändert, protokolliert das Audit-Log, dass sie sich geändert haben, und einen Fingerabdruck davon, nicht ihren Text, denn ein Hook enthält mitunter Zugangsdaten.

Laufgrenzen und Ergebnisse

72 Stunden. Ein Backup ist auf 72 Stunden begrenzt. Ein festgefahrenes restic wird dann gestoppt, und der Lauf schlägt fehl.
Ein Lauf endet als: Erfolgreich, Mit Warnungen, Fehlgeschlagen oder Unterbrochen.

Mit Warnungen (Status partial, Exit-Code 3) heißt: Das Backup ist abgeschlossen und ein Snapshot existiert, aber einige Dateien ließen sich nicht lesen, zum Beispiel weil sie geöffnet, gesperrt oder nicht lesbar waren. Diese Dateien fehlen in diesem Snapshot. Der Lauf nennt sie. Ein Teilweise entsteht auch durch einen fehlschlagenden Befehl nach dem Backup, durch einen Hook, den der Rechner nicht zulässt, und unter macOS durch fehlenden Vollzugriff auf die Festplatte. Besteht der Restore-Test eines teilweisen Backups, bewertet er den Endpoint mit Achtung statt Bereit.

Unterbrochen heißt: Der Agent wurde während des Laufs neu gestartet (ein Update, ein Neustart, ein gestoppter Dienst) und setzt sich von selbst fort. Das ist kein Fehler, löst keinen Alarm aus und verschiebt den Zeitpunkt des letzten Backups nicht.

Öffnen Sie einen Lauf unter Läufe in der Übersicht des Rechners, um sein Ergebnis, seine Fehler (höchstens 100) und das Ende seines Protokolls mit maskierten Geheimnissen zu lesen. Ist die Instanz am Ende eines Laufs nicht erreichbar, behält der Agent den Bericht und liefert ihn bei einem späteren Kontakt aus.

Exit-Codes von `backup-now`

restow-agent backup-now führt ein Backup im Vordergrund aus, zum Beispiel um einen neuen Hook oder die Verbindung zu testen.

Exit-Code	Bedeutung
0	Das Backup war erfolgreich.
3	Das Backup ist teilweise.
1	Das Backup ist fehlgeschlagen.

Aufbewahrung

Die Aufbewahrung läuft einmal täglich auf dem Server für jeden aktiven Endpoint. Standardmäßig behält sie die letzten 30 täglichen, 12 wöchentlichen und 12 monatlichen Snapshots. Die drei Zahlen stellen Sie je Endpoint unter Aufbewahrung ein.

Nur der Server entfernt Snapshots. Der Agent kann Backups hinzufügen, nie löschen.
Wer eine Zahl senkt, entfernt ältere Snapshots beim nächsten Aufbewahrungslauf endgültig.
Die Aufbewahrung gruppiert nicht nach Host oder Pfaden. Ein Repository gehört einer Maschine, und eine Änderung der gesicherten Ordner erzeugt keine zweite Snapshot-Reihe, die ewig behalten wird.
Ist das Repository gesperrt, weil gerade ein Backup läuft, wartet der Aufbewahrungsjob und wird wiederholt. Das ist kein Befund.
Ein gesperrter Endpoint wird nicht mehr bereinigt.
Aufbewahrung angehalten (seit 0.4.0). Solange ein Sicherungsstand des Rechners von der Ransomware-Erkennung als Verdächtig markiert ist und niemand ihn geklärt hat, löschen Aufbewahrung und Prune keinen Sicherungsstand dieses Rechners. Die Sicherungen laufen weiter. Ein Administrator beendet das mit Als Fehlalarm markieren oder Aufbewahrung freigeben.
Unveränderbare Backups (seit 0.4.0). Bei einem Repository mit Unveränderbarkeit gilt eine Löschung, die der Speicher ablehnt, als „noch nicht“: Der Sicherungsstand bleibt sichtbar und wiederherstellbar, und der Platz kommt zurück, sobald die Sperre abgelaufen ist.

Der Server entscheidet nach seinen eigenen Aufzeichnungen. Die Zeit, die in einem Snapshot steht, stammt vom Rechner und entscheidet deshalb nichts. Der Server listet die Snapshot-Dateien im Speicher und zählt nur die Snapshots, die ein Sicherungslauf gemeldet hat. Jeden datiert er auf den früheren von zwei Zeitpunkten: wann der Speicher seine Datei erhalten hat und wann der meldende Lauf endete (wie der Server es aufgezeichnet hat). Auf diese Daten wendet er die täglichen, wöchentlichen und monatlichen Regeln in der Zeitzone des Mandanten an, lässt restic genau die gewählten Snapshots vergessen und räumt danach auf (Prune).

Verdächtige Snapshots. Einen Snapshot, den kein Sicherungslauf gemeldet hat oder dessen Zeit in der Zukunft liegt, löscht die Aufbewahrung nie. Er wird in den Sicherungsständen markiert (Von keiner Sicherung gemeldet oder In der Zukunft datiert) und einmal mit dem Alarm Verdächtiger Snapshot eines Servers oder Clients gemeldet. Prüfen Sie den Rechner: Er könnte kompromittiert sein. Die Weboberfläche bietet keine Aktion, um einen solchen Snapshot zu löschen. Soll er weg, entfernen Sie ihn mit restic und dem Repository-Passwort (siehe Restore ohne Restow).

Sperren. Vor der Aufbewahrung und der Repository-Prüfung entfernt der Server Lock-Dateien, die der Speicher vor mehr als 30 Minuten erhalten hat, und die Locks des Agents, wenn kein Lauf des Agents aktiv ist. Die eigenen Arbeiten des Servers an einem Repository überschneiden sich nie: Aufbewahrung und Prüfung laufen allein, Restore-Tests, Durchsuchen und Downloads teilen es sich. Ein Job, der das Repository beschäftigt vorfindet, wartet bis zu einer Minute und wird später erneut versucht. Finden Aufbewahrung und Prüfungen das Repository sechsmal in Folge über mindestens 12 Stunden gesperrt vor, löst das den Alarm Repository eines Servers oder Clients bleibt gesperrt aus.

In der Übersicht eines Endpoints zeigt Sicherungsdaten die Größe im Speicher, die vorhandenen Snapshots, den letzten Aufbewahrungslauf und die Belegung gegen die Speicherbudgets.

Speicherbudget

Das Repository jedes Rechners hat ein Speicherbudget, und alle Server und Clients eines Mandanten teilen sich ein zweites. Die Standards legt die Installation mit RESTOW_ENDPOINT_QUOTA_GIB (je Rechner, 2048 GiB) und RESTOW_ENDPOINT_TENANT_QUOTA_GIB (je Mandant, 20480 GiB) fest. Siehe Umgebungsvariablen.

Unter Speicherbudget in den Einstellungen legen Sie ein Budget für diesen Rechner in GiB fest. Lassen Sie das Feld leer für den Standard der Installation. Das Mandantenbudget gilt zusätzlich.
Ein Upload, der nicht mehr passt, wird abgelehnt. restic bricht ab, und die Sicherung schlägt fehl. Wiederherstellungen funktionieren weiter.
Die Karte Sicherungsdaten zeigt die Belegung gegen beide Budgets, ab 90 Prozent mit einem Hinweis, und den zuletzt abgelehnten Upload. Der Alarm Speicherbudget von Servern und Clients warnt bei 90 Prozent und wenn Uploads abgelehnt werden.
Um Platz zu schaffen, erhöhen Sie das Budget, bewahren unter Aufbewahrung weniger Snapshots auf oder sichern weniger. Jeder Aufbewahrungslauf misst das Repository neu.

Alarme

Unter Alarme stellen Sie ein, wann Restow Ihnen meldet, dass ein Endpoint Aufmerksamkeit braucht:

Stunden ohne Kontakt bei einem Server. Standard: 2.
Tage ohne erfolgreiche Sicherung bei einem Client. Standard: 7.

Die übrigen Alarm-Ereignisse und wie Regeln und Empfänger funktionieren, steht unter Alarme und Berichte.