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 Endpoint und dann den Tab Einstellungen.
Die zwei Profile
Abschnitt betitelt „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) | Bei Verbindung: 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 |
| 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.
Zeitplan
Abschnitt betitelt „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. 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. 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.
Einstellungen
Abschnitt betitelt „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. |
| Nur am Netzstrom sichern | Ein Laptop im Akkubetrieb überspringt das geplante Backup, bis er am Strom hängt. |
| 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). |
Ordner und Ausschlüsse
Abschnitt betitelt „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
/etcund/varLinks. - 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.
Upload-Begrenzung
Abschnitt betitelt „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
Abschnitt betitelt „Nur am Netzstrom“Die Prüfung erfolgt vor einem geplanten Start. Ist das Gerät im Akkubetrieb, wartet das Backup. 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 liestpmset -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)
Abschnitt betitelt „Befehle vor und nach dem Backup (Hooks)“Ein Hook ist ein Shell-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.sqlAchten 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.
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_IDundRESTOW_HOOK. Der Befehl nach dem Backup erhält außerdemRESTOW_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 ein Teilweise.
- 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, 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
Abschnitt betitelt „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, Teilweise, Fehlgeschlagen oder Unterbrochen.
Teilweise 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 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, 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
Abschnitt betitelt „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
Abschnitt betitelt „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.
In der Übersicht eines Endpoints zeigt Repository die Größe im Speicher, die vorhandenen Snapshots und den letzten Aufbewahrungslauf.
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.