Endpoint-Backup im Überblick

Endpoint-Backup schützt Server und Client-Rechner, etwa Laptops und Desktops, dateiweise. Ein kleines Programm, der Restow-Agent, läuft auf dem Rechner, steuert restic und sendet das Backup per HTTPS an Ihre Restow-Instanz. Die Backups landen im Speicherziel des Mandanten, wie jedes andere Backup in Restow auch.

Dieser Abschnitt nennt einen solchen Rechner Endpoint. Die Weboberfläche sagt an manchen Stellen „Rechner“. Ein Endpoint hat eines von zwei Profilen: Server oder Client.

Was Sie bekommen

Dateibasierte Backups mit restic 0.19.1. Dedupliziert, komprimiert und verschlüsselt. Einzelne Dateien und Ordner werden gesichert und wiederhergestellt.
Ein Repository pro Endpoint. Jeder Endpoint hat ein eigenes restic-Repository mit eigenem Passwort. Der Server erzeugt das Passwort und speichert es dort, mit dem Mandantenschlüssel verschlüsselt.
Append-only. Der Agent kann Backups hinzufügen. Er kann nie eines löschen oder überschreiben. Das erzwingt die Instanz, nicht der Agent. Aufbewahrung, Prune und Integritätsprüfungen laufen ausschließlich auf dem Restow-Server.
Nur ausgehend. Der Agent öffnet keinen Port. Er spricht per HTTPS mit Ihrer Restow-Instanz und mit nichts sonst.
Ein Restore überschreibt nie. Er landet in einem neuen Ordner auf dem Rechner, oder Sie laden Dateien in der Weboberfläche als ZIP herunter.
Restore-Tests. Restow liest Stichproben-Dateien des neuesten Backups zurück und vergleicht ihre SHA-256-Hashes. Das Ergebnis fließt in die Wiederherstellbarkeit ein, wie bei Postfächern und OneDrives.
Alarme für Server, die sich nicht melden, Clients ohne aktuelles gutes Backup, fehlgeschlagene Backups, fehlgeschlagene Restores sowie fehlgeschlagene Restore-Tests und Repository-Prüfungen.
Befehle vor und nach dem Backup (Hooks), zum Beispiel für einen Datenbank-Dump. Siehe Profile, Zeitplan und Hooks.

Unterstützte Systeme

System	Unterstützt in der Beta 0.1.0
Linux	Mit systemd, auf x86_64 und aarch64. Die Binärdateien sind statisch und laufen auf jeder Distribution mit systemd.
macOS	macOS 13 (Ventura) oder neuer, auf Intel und Apple Silicon.
Windows	Geplant, nicht Teil von 0.1.0. Es gibt kein Windows-Build, keinen Installer und keinen Dienst. Die Weboberfläche zeigt Windows als „Geplant“ und lässt die Auswahl nicht zu. Siehe die Roadmap.

So greift es ineinander

In der Weboberfläche legen Sie einen Server oder Client an. Restow erzeugt einen einmaligen Installationsbefehl.
Sie führen den Befehl auf dem Rechner aus. Das Skript lädt Agent und restic von Ihrer Restow-Instanz, prüft sie, installiert einen Dienst und meldet den Rechner an. Siehe Installation unter Linux und macOS.
Der Agent meldet sich alle 5 Minuten bei Ihrer Instanz (ein „Heartbeat“) und erhält Aufgaben, holt sich seine Konfiguration, wenn er sie braucht, und startet Backups nach seinem Zeitplan. Die Instanz verbindet sich nie mit dem Rechner: Aufgaben wie „Jetzt sichern“ oder „Wiederherstellung“ reisen in der Antwort auf den Heartbeat.
Die Backup-Daten gehen in ein restic-Repository, das Ihre Instanz nur diesem einen Agent im Append-only-Modus bereitstellt. Das Repository liegt im primären Speicherziel des Mandanten unter endpoints/<Endpoint-ID>/.
Der Server wendet die Aufbewahrung an, prüft das Repository und führt Restore-Tests aus.

Wo Endpoints erscheinen

Im Abschnitt Server-/Endpoint-Backup der Seitenleiste, mit den Seiten Agenten (jeder Endpoint), Server und Clients. Ihn sehen nur Mandanten-Administratoren und Provider-Administratoren.
In der Übersicht der Wiederherstellbarkeit, im Abschnitt Server und Clients. Endpoints zählen auch in der Zusammenfassung des Mandanten mit.
In der Integrations-API: GET /api/v1/endpoints listet sie auf, und die Daten der Wiederherstellbarkeit enthalten ein Feld endpoints. Ein fehlgeschlagener Lauf eines Endpoints löst außerdem den Webhook job.failed aus. Siehe Integrations-API.

Alarme

Endpoint-Backup nutzt dieselben Alarm-Regeln, Empfänger und Kanäle (Glocke, E-Mail, Webhook) wie jeder andere Auftrag. Siehe Alarme und Berichte.

Ereignis	Wann es auslöst
Server oder Client meldet sich nicht (`endpoint.stale`)	Ein Server hat sich seit mehr als 2 Stunden nicht gemeldet. Ein Client hatte seit 7 Tagen kein gutes Backup. Clients gelten nie als „still“, denn ein Laptop ist nachts aus. Beide Grenzen lassen sich je Endpoint einstellen.
Sicherung fehlgeschlagen (`backup.failed`)	Ein Backup-Lauf ist fehlgeschlagen. Dazu zählt ein Lauf, dessen Agent verschwand und der nach 6 Stunden ohne Fortschritt geschlossen wurde.
Wiederherstellung fehlgeschlagen (`restore.failed`)	Ein Restore-Lauf auf dem Endpoint ist fehlgeschlagen.
Restore-Prüfung nicht bestanden (`verify.red`)	Ein Restore-Test ist fehlgeschlagen. `verify.recovered` folgt, wenn ein späterer Test besteht.
Speicherschaden gefunden (`scrub.corrupt`)	Die Repository-Prüfung hat Schäden gefunden.

Eine bestehende Regel für „Sicherung fehlgeschlagen“ und „Restore-Prüfung nicht bestanden“ deckt Endpoints deshalb ohne Änderung mit ab. Ein Lauf, der unterbrochen wurde, weil der Agent neu startete (ein Update, ein Neustart), ist kein Fehler: Er setzt sich von selbst fort und löst weder einen Alarm noch den Webhook job.failed aus.

Aufbewahrung und Repository-Prüfung

Die Aufbewahrung läuft einmal täglich auf dem Server für jeden aktiven Endpoint. Standardmäßig bleiben 30 tägliche, 12 wöchentliche und 12 monatliche Snapshots erhalten. Die Zahlen lassen sich je Endpoint ändern. Wer eine Zahl senkt, entfernt ältere Snapshots beim nächsten Aufbewahrungslauf endgültig. Ein gesperrter Endpoint wird nicht mehr bereinigt.
Die Repository-Prüfung läuft einmal pro Woche für jeden Endpoint. Sie führt restic check auf einem Zwanzigstel der gespeicherten Daten aus, in fester Reihenfolge, sodass das ganze Repository in etwa fünf Monaten gelesen wird. Ein Schaden setzt den Endpoint auf Nicht wiederherstellbar und löst scrub.corrupt aus.
Restore-Tests laufen nach jedem neuen guten Backup. Siehe Restore.

Was es nicht ist

Kein Festplatten-Abbild. Es gibt keine Images und keine Bare-Metal-Wiederherstellung. Einen ganzen Rechner wiederherzustellen heißt, das Betriebssystem neu zu installieren und die Dateien zurückzuspielen.
Noch nichts für Windows. Windows ist geplant.
Noch keine Snapshots des Dateisystems. LVM-, ZFS-, btrfs- und APFS-Snapshots werden nicht genutzt. Konsistenz entsteht über optionale Hooks.

Bekannte Grenzen

Noch kein mTLS. Jeder Agent authentifiziert sich mit einem eigenen Secret über HTTPS. Siehe Sicherheitsmodell.
Keine LVM-, ZFS- oder btrfs-Snapshots und keine APFS-Anbindung. Dateien, die sich während des Lesens ändern, können im Snapshot inkonsistent landen.
Nur dateibasiert: keine Festplatten-Abbilder, keine Bare-Metal-Wiederherstellung.
Kein Windows in 0.1.0.
Agent-Updates sind nicht signiert. Die Installationsskripte und Selbst-Updates prüfen SHA-256-Prüfsummen von derselben Instanz.
Linux ohne systemd wird vom Installer und den service-Befehlen nicht unterstützt.
Die Erkennung, ob der Rechner im Akkubetrieb läuft, arbeitet nach dem Best-Effort-Prinzip, und ein laufendes Backup wird nicht gestoppt, wenn das Netzteil abgezogen wird.
Ein Rechner führt ein Backup, einen Restore oder einen Restore-Test nach dem anderen aus. Weitere Aufgaben warten in der Schlange.
Es gibt noch kein Löschen des Repositorys eines Endpoints. Sie können einen Endpoint sperren, seine Daten bleiben im Speicher.
Der Wechsel des primären Speicherziels eines Mandanten kopiert die Daten des Mandanten, aber nicht den Ordner endpoints/. Kopieren Sie diesen Ordner von Hand, bevor Sie das primäre Ziel wechseln.
Stand der Beta 0.1.0 liefen die Tests des Projekts mit dem Agent auf Linux (Debian, arm64, in Docker) und nativ auf macOS 26 (Apple Silicon). Die amd64-Builds wurden dort cross-kompiliert und geprüft, aber nicht ausgeführt, und die systemd-Unit sowie der LaunchDaemon wurden in dieser Umgebung nicht auf einem echten systemd oder launchd gestartet. Machen Sie eine erste Installation auf einem Testrechner.