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.

restic ist das bekannte Open-Source-Backupprogramm, und Restow liefert sein unverändertes Release aus (geprüft gegen festgelegte Prüfsummen; die Release-Signatur des Agenten deckt es ebenfalls ab). Die Sicherung jedes Endpunkts ist deshalb ein gewöhnliches restic-Repository, das restic selbst mit dem Repository-Passwort öffnen kann, auch ohne Restow (siehe Restore). restic ist ein unabhängiges Open-Source-Projekt unter der Lizenz BSD-2-Clause (restic.net); Restow ist nicht mit ihm verbunden. Die Lizenzen von restic und der 79 Go-Module, die in restic einkompiliert sind, werden mit dem Agent installiert, in THIRD_PARTY_NOTICES.txt neben seinen Binärdateien, und sind in THIRD_PARTY_NOTICES.md des Restow-Quellcodes aufgeführt.

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, und der Server entscheidet anhand seiner eigenen Aufzeichnungen, welche Snapshots die Aufbewahrung entfernt.
Nur ausgehend. Der Agent öffnet keinen Port. Er spricht per HTTPS mit Ihrer Restow-Instanz und mit nichts sonst.
Signierte Releases, root-eigene Installation. Jedes Agent-Release ist vom Maintainer signiert. Das Installationsskript und das Selbst-Update des Agents prüfen die Signatur, bevor etwas läuft, und der Agent liegt in einem Ordner, den nur root ändern kann. Siehe Installation.
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.
Richtlinie der Agenten (seit 0.4.0). Ein Sicherungsfenster, das Nachholen verpasster Sicherungen, ein Upload-Limit, das Netzteil und Wiederholungen, festgelegt für die Installation, einen Mandanten oder einen Backup-Job. Siehe Richtlinie der Agenten.
Datenordner, die ein Job auslässt (seit 0.4.0). Der Agent meldet, welche gängigen Linux-Datenordner es gibt, und der Job-Editor und die Seite des Rechners bieten an, die hinzuzufügen, die ein Job auslässt. Siehe Profile, Zeitplan und Hooks.
Ransomware-Anzeichen und unveränderbare Backups (seit 0.4.0). Jeder neue Sicherungsstand wird auf Anzeichen von Ransomware beurteilt, und der Speicher kann restic-Repositorys sperren. Siehe Ransomware-Erkennung und Unveränderbare Backups.
Datei-Restore für die Restore-Rolle (seit 0.4.0). Restore-Operatoren durchsuchen, laden und stellen Dateien von Rechnern wieder her. Siehe Restore.
Speicherbudgets je Rechner und je Mandant, damit ein einzelner Rechner das Speicherziel nicht füllen kann. Siehe Speicherbudgets.
Alarme für Server, die sich nicht melden, Clients ohne aktuelles gutes Backup, fehlgeschlagene Backups, fehlgeschlagene Restores, fehlgeschlagene Restore-Tests und Repository-Prüfungen, verdächtige Snapshots, Speicherbudgets und Repositorys, die gesperrt bleiben.
Befehle vor und nach dem Backup (Hooks), zum Beispiel für einen Datenbank-Dump. Sie sind aus, bis root auf dem Rechner sie erlaubt. Siehe Profile, Zeitplan und Hooks.

Unterstützte Systeme

System	Unterstützt in 0.4.7
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.4.7. 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 und fügen das einmalige Token ein, wenn er danach fragt. Das Skript lädt Agent und restic von Ihrer Restow-Instanz, prüft die Signatur des Maintainers und die Prüfsummen, installiert beide root-eigen mit einem Dienst und meldet den Rechner an. Siehe Installation unter Linux und macOS.
Der Agent meldet sich alle 5 Minuten bei Ihrer Instanz, seit 0.4.2 jede Minute, solange eine Sicherung läuft (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 & Clients der Seitenleiste: Inventar listet jeden Endpoint, mit den Chips Alle, Server und Clients, und öffnet die Seite eines Rechners; Datei-Restore stellt Dateien aus einem Sicherungsstand eines Rechners wieder her oder lädt sie herunter. Beide Einträge sehen Mandanten-Administratoren und Provider-Administratoren. Seit 0.4.0 sehen Restore-Operatoren Datei-Restore und sonst nichts aus diesem Abschnitt. Seit 0.4.0 sind gesperrte Rechner im Inventar ausgeblendet, bis Sie Gesperrte Rechner anzeigen wählen, und Datei-Restore führt sie in der Gruppe Gesperrte Rechner. Seit 0.4.5 öffnet ein Klick auf eine Zeile des Inventars einen Detailbereich des Rechners (?machine=<id> in der Adresse, ein Link öffnet ihn also): jeden Zustand, die vollständigen Fehler- und Warntexte der neuesten Sicherung in einem kopierbaren Block (bei einem Rechner auch das Ende des Protokolls), was Aufmerksamkeit braucht, die Restore-Prüfungen, die Eckdaten, die neuesten Läufe und die Aktionen, darunter Jetzt sichern, Stoppen, Jetzt sperren und, bei einem gesperrten Rechner, Aus Restow entfernen. Das Inventar behält ein festes Layout, mit einem kompakten Badge Zustand je Zeile. Unter den Rechnern führt es die entfernten Rechner auf, deren Sicherungen noch gespeichert sind (Deinstallation). Der Eintrag Jobs des Abschnitts enthält die Backup-Jobs für Server und Clients (ab 0.2.0). Seit 0.2.1 wird ein Rechner nur gesichert, solange er in einem Job ist: Das Inventar markiert jeden Rechner ohne Job als Ohne Backup und bietet Job anlegen und Zu Job hinzufügen… an, und ein Rechner lässt sich einer Person aus dem Verzeichnis zuordnen (Zugeordnet zu).
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.
Sicherung überfällig (`backup.overdue`, seit 0.3.1)	Ein Server oder Client hatte länger keine erfolgreiche Sicherung, als seine Backup-Jobs vorsehen, oder länger als die eigene Frist der Regel (24 bis 720 Stunden). Einmal je Rechner, bis wieder eine Sicherung gelingt.
Wiederherstellung fehlgeschlagen (`restore.failed`)	Ein Restore-Lauf auf dem Endpoint ist fehlgeschlagen.
Restore-Prüfung nicht bestanden (`verify.red`)	Ein Restore-Test hat belegt, dass die Sicherung beschädigt ist (ein abweichender Hash, Daten, die im Repository fehlen oder beschädigt sind). Ein Test, der nicht abgeschlossen werden konnte, löst nichts aus. `verify.recovered` folgt, wenn ein späterer Test besteht.
Speicherschaden gefunden (`scrub.corrupt`)	Die Repository-Prüfung hat Schäden gefunden.
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.
Verdächtiger Sicherungsstand (`backup.suspicious`, seit 0.4.0)	Die Ransomware-Erkennung hat in einem neuen Sicherungsstand des Rechners Anzeichen eines Angriffs gefunden. Einmal je Angriffsepisode, und die Aufbewahrung dieses Rechners ist angehalten. Siehe Ransomware-Erkennung.
Speicherbudget von Servern und Clients (`endpoint.storage_quota`)	Ein Repository hat 90 Prozent seines Speicherbudgets erreicht, das Budget ist ausgeschöpft, oder ein Upload wurde abgelehnt. Außerdem höchstens einmal am Tag, wenn alle Server und Clients eines Mandanten zusammen 90 Prozent des Mandantenbudgets erreichen.
Repository eines Servers oder Clients bleibt gesperrt (`endpoint.repository_locked`)	Aufbewahrung und Prüfungen haben das Repository sechsmal in Folge gesperrt vorgefunden, über mindestens 12 Stunden.

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. Ebenso wenig ein Restore-Test auf dem Rechner, der nicht abgeschlossen werden konnte, auch einer, den der Server nach sechs Stunden ohne Bericht geschlossen hat: Er löst weder einen Alarm noch job.failed aus und wird nach 1 bis 24 Stunden erneut angeboten (siehe Prüfung im Detail).

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. Ein Rechner, der mit der Wahl, seine Sicherungen zu behalten, aus Restow entfernt wurde, bekommt stattdessen ein Enddatum (die neueste Sicherung plus die längste Regel seiner Aufbewahrung), nach dem sie gelöscht werden (Deinstallation).
Der Server entscheidet, was die Aufbewahrung entfernt, und zwar anhand von Fakten, die er selbst aufzeichnet: Es zählen nur Snapshots, die ein Sicherungslauf gemeldet hat, und jeder gilt als so alt wie der frühere von zwei Zeitpunkten: wann der Speicher seine Datei erhalten hat und wann der meldende Lauf endete. Die Zeit, die im Snapshot steht, entscheidet nichts. Snapshots, die kein Lauf gemeldet hat oder die in der Zukunft datiert sind, werden nie gelöscht, in den Sicherungsständen markiert und mit dem Alarm Verdächtiger Snapshot gemeldet. Siehe Profile, Zeitplan und Hooks.
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.

Ransomware-Erkennung und unveränderbare Backups

Beides kam mit 0.4.0 und gilt für Rechner wie für jede andere Art von Backup.

Die Ransomware-Erkennung beurteilt jeden neuen Sicherungsstand eines Rechners anhand von Daten, die das Backup ohnehin hat: dem Ausmaß der Änderung (neue und geänderte Dateien, hinzugefügte Bytes) gegenüber dem eigenen Verlauf des Rechners. Der Agent 0.4.0 liefert zusätzlich einen Aktivitätsbericht (Löschungen, umbenannte Endungen, bekannte Ransomware-Endungen und Erpresserbriefe, die Entropie ausgewählter neuer Dateien) und die Daten für das Kompressionssignal. Ein älterer Agent sendet beides nicht, und ein Signal ohne Daten sagt „nicht verfügbar“, nie unauffällig. Ein verdächtiger Sicherungsstand bekommt ein rotes Kennzeichen, und die Aufbewahrung behält die Sicherungsstände des Rechners, bis ein Administrator den Fall klärt. Sie ist kein Virenscanner und blockiert nie ein Backup. Siehe Ransomware-Erkennung.
Unveränderbare Backups sperren die Objekte des restic-Repositorys des Rechners (data/, snapshots/, keys/ und config) mit S3 Object Lock, wenn beim Repository des Mandanten die Unveränderbarkeit an ist. Die Dateien locks/ und index/ von restic werden nicht gesperrt. Die Sicherungsstände eines Rechners zeigen Unveränderbar bis <Datum>, grün nur bei einer Compliance-Sperre, die der Speicher selbst gemeldet hat. Siehe Unveränderbare Backups.

Speicherbudgets

Ein Agent kann nur Daten hinzufügen, aber das genügt, um ein Speicherziel zu füllen, das auch die Postfachsicherungen trägt. Jedes Endpoint-Repository hat deshalb ein Budget, und alle Endpoint-Repositorys eines Mandanten teilen sich ein weiteres.

Je Rechner: RESTOW_ENDPOINT_QUOTA_GIB, Standard 2048 (2 TiB). Für einen einzelnen Rechner setzen Sie unter Speicherbudget in seinen Einstellungen einen anderen Wert. Leer heißt Standard der Installation.
Je Mandant: RESTOW_ENDPOINT_TENANT_QUOTA_GIB, Standard 20480 (20 TiB), für alle Server und Clients eines Mandanten zusammen.
0 schaltet ein Budget ab. Beide Variablen lesen die Rollen api und worker. Siehe Umgebungsvariablen.
Ein Upload, der nicht mehr passt, wird abgelehnt. restic bricht dann ab, und die Sicherung schlägt fehl. Lock-Dateien zählen nicht gegen das Budget, Wiederherstellungen funktionieren also auch bei ausgeschöpftem Budget. Gleichzeitige Uploads können das Budget um einige Packs überschreiten.
Die Karte Sicherungsdaten auf der Seite des Rechners zeigt die Belegung gegen beide Budgets, welches Budget gilt, den zuletzt abgelehnten Upload und ab 90 Prozent einen Hinweis. Der Alarm Speicherbudget von Servern und Clients warnt bei 90 Prozent und wenn Uploads abgelehnt werden.
Seit 0.4.1 enthalten die Zahlen unter Gespeichert der Installation (Repositories → Belegung, die Kachel des Dashboards, die Statistik und die API) auch die restic-Repositorys von Rechnern, Freigaben und Proxmox-VE-Containern. Vorher zählten sie nur den Chunk-Store. Die Größe eines Repositorys hat keinen Verlauf, die Wachstumszahlen stammen deshalb weiter allein aus dem Chunk-Store.

Agent-Updates

Der Agent prüft eine Minute nach seinem Start und danach alle 6 Stunden auf eine neuere Version und installiert nur vom Maintainer signierte Releases, und nur, solange kein Lauf aktiv ist. Der Schalter Automatische Agent-Updates auf der Seite Inventar pausiert die Updates für alle Rechner des Mandanten, auch für später hinzugefügte. Er erscheint, sobald der Mandant mindestens einen Rechner hat. Mehrere Einstellungen einer Richtlinie der Agenten, die Datenordner und die Fakten über den Rechner brauchen den Agent 0.4.0, ein Mandant, der Updates pausiert hat, behält also alte Agents ohne sie.

Seit 0.4.2 ziehen die Agenten ein Server-Update nach, und Sie können selbst ein Update anfordern:

Agenten ziehen dem Server nach. Nach dem Update des Servers bleiben neue Läufe angehalten, während die Agenten (und die Proxmox-VE-Knoten) das neue Release installieren, höchstens 15 Minuten lang. Jeder Agent hinter dem Release bekommt mit seinem nächsten Heartbeat gesagt, dass er jetzt aktualisieren soll, und installiert es, sobald er frei ist. Auf einen Agenten, dessen Mandant oder Rechner Updates pausiert hat, wird nicht gewartet. Der Reiter Updates zeigt den Fortschritt und nennt den Befehl für Agenten, die er nicht erreicht hat. Siehe Knoten und Agenten ziehen das Update nach.
Auf X.Y.Z aktualisieren auf der Seite eines Rechners (die Schaltfläche erscheint, sobald ein neueres Release angeboten wird, mit der Version in ihrer Beschriftung) bittet den Agent, es bei seiner nächsten Meldung zu installieren, sobald auf dem Rechner keine Sicherung und keine Wiederherstellung läuft, und neu zu starten. Das wird als endpoint.update_requested im Audit-Log festgehalten. Sind Updates für den Rechner oder seinen Mandanten pausiert, sagt die Seite das.
sudo restow-agent update auf dem Rechner installiert das angebotene Release sofort, über denselben signierten Download wie das automatische Update, startet den Dienst neu und sagt, was es getan hat („No newer release is offered“, englischer Text, wenn es keines gibt). Solange eine Sicherung, eine Wiederherstellung oder ein Restore-Test läuft, lehnt er ab („A backup is running; the update waits“, Exit-Code 1), und der Agent installiert das Update selbst, sobald er frei ist. Agenten vor 0.4.2 kennen den Befehl nicht: Starten Sie ihren Dienst neu (sudo systemctl restart restow-agent, unter macOS sudo launchctl kickstart -k system/com.restowbackup.agent), und sie suchen eine Minute später nach dem Update. Siehe Befehle.

Eine Sicherung stoppen

Seit 0.4.2 lässt sich eine laufende Sicherung eines Servers oder Clients in der Weboberfläche stoppen und eine angeforderte zurückziehen:

Sicherung stoppen steht auf der Seite des Rechners und im Detail des Laufs (Verlauf). Es fragt vorher nach. Wer eine Sicherung starten darf, darf auch eine stoppen, und das Audit-Log hält endpoint.backup.cancelled fest, mit der Person, die es angefordert hat.
Aus dem Inventar und für einen ganzen Job (seit 0.4.5). Stoppen steht auch in der Zeile des Inventars, ihrem …-Menü und im Detailbereich des Rechners, und Stoppen unter Server & Clients → Jobs stoppt jede wartende oder laufende Sicherung der Rechner eines Jobs in einer Anfrage (Backup-Jobs); es wird als backup_job.run_cancelled am Job und endpoint.backup.cancelled je Rechner auditiert.
Eine Sicherung, die noch nicht begonnen hat (die Anforderung wartet auf dem Server), wird sofort zurückgezogen („Sicherung zurückziehen“): Der Agent bekommt sie nie, und die Aufgabe steht als zurückgezogen da.
Eine laufende Sicherung erhält eine Abbruchanforderung, und die Seite sagt „Wird abgebrochen…“. Der Agent 0.4.2 oder neuer bekommt sie mit seinem nächsten Heartbeat (jede Minute, solange eine Sicherung läuft, sonst alle 5 Minuten) und beendet den Lauf: restic bekommt einen Interrupt und hört sauber auf, sodass weder ein Snapshot noch eine Sperre zurückbleibt, und der Befehl nach dem Backup läuft wie immer. Rechnen Sie mit etwa einer Minute.
Das Ende ist „Abgebrochen“, kein Fehler. Der Lauf zeigt Abgebrochen (der Fehlercode ist cancelled, „In der Oberfläche abgebrochen“, mit „Abgebrochen von“ und dem Namen der Person). Er löst keinen Alarm und keinen Webhook job.failed aus, der Zeitpunkt der letzten Sicherung und die Zahl der fehlgeschlagenen Sicherungen bleiben, wie sie waren, und der Agent setzt den Lauf nicht fort: Die nächste geplante Sicherung startet wie gewohnt.
Ältere Agenten. Ein Agent vor 0.4.2 kennt die Anforderung nicht, seine laufende Sicherung läuft also zu Ende. Startet er eine Aufgabe, die zurückgezogen wurde, lehnt der Server den Lauf ab (409), und ein aktueller Agent versucht es nicht erneut.

Eine Sicherung eines Proxmox-VE-Gasts und ein Lauf einer Freigabe haben ein eigenes Stoppen (Proxmox VE, Freigaben).

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.4.7.
Die erste Installation vertraut dem Installationsskript, das Ihre Instanz ausliefert, wie jedes curl | sh. Vergleichen Sie den Fingerabdruck des Release-Schlüssels, den das Skript ausgibt, mit dem veröffentlichten (SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o). Siehe Installation.
RHEL, Rocky Linux und AlmaLinux 8 sowie Amazon Linux 2 haben kein Werkzeug, mit dem das Installationsskript die Signatur prüfen kann. Dort prüfen Sie sie auf einem anderen Rechner und übergeben dem Skript das Ergebnis.
Hooks mit der Regel any führen jeden Befehl aus, den die Einstellungen des Endpoints in Restow nennen, als root. Bevorzugen Sie scripts.
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.
Das Sperren eines Endpoints löscht nichts: Seine Daten bleiben im Speicher. Seit 0.4.5 lässt sich ein gesperrter Rechner aus Restow entfernen, wobei seine Sicherungen sofort oder bei Ablauf gelöscht werden; vor 0.4.5 gab es kein Löschen des Repositorys eines Endpoints.
Solange ein Update von Restow wartet oder läuft, halten Agents älter als 0.4.0 ihre eigenen Zeitpläne nicht an: Eine Sicherung, die ein solcher Rechner in dieser Zeit selbst beginnt, läuft und kann fehlschlagen, wenn die API unter ihr neu startet. Siehe Richtlinie der Agenten.
Die Richtlinie der Agenten, die Ransomware-Erkennung und unveränderbare Backups wurden nur gegen simulierte Dienste und simulierte Angriffe getestet, nicht gegen echte Systeme.
Der Wechsel des primären Speicherziels eines Mandanten wird abgelehnt, solange Endpoints aktiv sind (HTTP 409, storage-active-endpoints), weil ein aktiver Agent weiter auf das alte primäre Ziel schreibt, während es kopiert wird. Um es zu wechseln, widerrufen oder deinstallieren Sie die Rechner, wechseln das primäre Ziel mit einem Verschieben und melden die Rechner danach neu an: Sie werden zu neuen Endpoints mit neuen Repositories im neuen primären Ziel. Seit 0.4.2 kopiert dieses Verschieben die restic-Repositories der widerrufenen Rechner (und von Containern und Dateifreigaben) auf das neue primäre Ziel, geprüft nach Größe und SHA-256, sodass sich ihre Backups von dort weiter durchsuchen und herunterladen lassen und das alte Ziel danach entfernt werden kann. Mit „Vorhandene Backups dort belassen, wo sie sind“ bleiben sie stattdessen auf dem alten Ziel, das schreibgeschützt angebunden bleibt. Siehe Das primäre Repository ersetzen und Restow selbst sichern.
Stand der Beta 0.2.1 liefen die Tests des Projekts mit dem Agent auf Linux (Debian, arm64, in Docker) und nativ auf macOS 26 (Apple Silicon). Das Linux-Install-Skript lief vollständig in einem Linux-Container, das macOS-Install-Skript nativ auf macOS 26 als normaler Benutzer unter einem verlegten Wurzelverzeichnis. Die systemd-Unit und ihre Härtung liefen unter einem echten systemd (Debian 12, in einem privilegierten Container). Die amd64-Builds wurden cross-kompiliert und geprüft, aber nicht ausgeführt, und der LaunchDaemon wurde nie von einem echten launchd gestartet. Der Release-Smoke-Lauf führte das echte Install-Skript nur in einem Linux-Container aus (Prüfung 10); der macOS-Installer und der Agent gehörten nicht zu den Release-Prüfungen. Machen Sie eine erste Installation auf einem Testrechner und führen Sie danach restow-agent status, restow-agent backup-now und den Restore eines Ordners aus, bevor Sie ausrollen.