← Alle Funktionen

Server- und Client-Backup

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Restow sichert Linux- und macOS-Server sowie Client-Rechner mit einem kleinen Agenten, der restic steuert, in Ihre eigene Restow-Instanz. Die Funktion gehört zur Community-Edition und steht damit in jeder Edition zur Verfügung, und sie ist seit 0.1.0 (Beta) verfügbar. Die Backups sind dateibasiert, dedupliziert und verschlüsselt abgelegt, und sie werden so geprüft wie Postfach-Backups: Ein Backup, das nie zurückgelesen wurde, gilt nicht als bewiesen.

Was es tut

Der Agent ist ein kleines Go-Programm für Linux (systemd, x86_64 und aarch64) und macOS ab Version 13 (Intel und Apple Silicon). Er sichert die von Ihnen gewählten Ordner mit restic 0.19.1 in ein Repository auf Ihrer Restow-Instanz, dedupliziert, komprimiert und verschlüsselt. Heute dateibasiert: noch keine Datenträger-Images und kein Bare-Metal-Restore. Eine ganze Maschine wiederherzustellen heißt, das Betriebssystem neu zu installieren und die Dateien zurückzuspielen; Abbild-Backup mit Bare-Metal-Restore ist geplant.

restic ist das bekannte Open-Source-Backupprogramm hinter dem Agenten: schnell, dedupliziert, verschlüsselt, mit offenem Repository-Format. Restow liefert sein unverändertes Release aus, geprüft gegen festgelegte Prüfsummen. Die Sicherung eines Rechners ist deshalb ein gewöhnliches restic-Repository, das restic selbst mit dem Repository-Passwort öffnen kann, auch ohne Restow. restic ist ein unabhängiges Open-Source-Projekt (BSD-2-Clause, restic.net); Restow ist nicht mit ihm verbunden.

Virtuelle Maschinen und Container auf Proxmox VE sichert nicht dieser Agent, sondern Restow über die Backup-Provider-API von Proxmox, als Preview, siehe Proxmox-VE-Backup.

Backup-Jobs für Rechner

Rechner werden über Backup-Jobs gesichert. Ein Job legt fest, was gesichert wird, wann, in welches Repository, wie lange und wie oft eine Restore-Prüfung es nachweist, für viele Rechner zugleich, mit Abweichungen je Rechner. Für Server und Clients wählen Sie die zu sichernden Ordner aus und schließen Dateitypen aus. Sie können begrenzen, wie viel Bandbreite ein Backup nutzen darf, innerhalb eines Zeitfensters, das Sie festlegen. Hooks, Bandbreite und Zeitplan eines Rechners, der in einem Job ist, werden im Job gesetzt.

Ein Rechner sichert, sobald er in einem Job ist. Jeder Rechner ohne Job ist mit „Ohne Backup“ markiert, wird in einem Banner gezählt und bekommt „Job anlegen“ oder „Zu Job hinzufügen“ angeboten, und ein neu angemeldeter Rechner wartet auf einen Job, statt eigenmächtig zu sichern. Server sichern standardmäßig ihre Anwendungsdaten (/opt, /usr/local, /var/lib). Eine Tabelle aller Rechner zeigt Hostname, die Person, der der Rechner zugewiesen ist, die letzte Sicherung und die Wiederherstellbarkeit.

Seit 0.3.5 nennt bei Linux-Rechnern ein Hinweis im Job und im Datei-Restore die üblichen Datenordner (/opt, /srv, /var/lib, /home und weitere), die die Pfade des Jobs auslassen, mit einer Schaltfläche, um sie hinzuzufügen. Seit 0.4.0 meldet der Agent außerdem, welche Ordner einer festen Liste von Linux-Datenordnern (/opt, /usr/local, /srv, /var/www, Docker- und Podman-Volumes, die PostgreSQL-, MySQL- und MongoDB-Ordner unter /var/lib) existieren und Dateien enthalten, nur die Namen. Der Job-Editor nennt dann die Ordner, die die Rechner des Jobs wirklich haben und der Job auslässt, und die Seite eines Rechners hat eine Schaltfläche, um jeden solchen Ordner zum Job hinzuzufügen. Bei älteren Agents bleibt der Hinweis von 0.3.5. Die Seite eines Rechners sagt auch, als was er läuft: Container, virtuelle Maschine oder physisch, mit oder ohne Desktop. Ein Linux-Rechner, der mit einem Client-Token angemeldet wurde und dessen Agent einen Container oder eine virtuelle Maschine ohne Desktop meldet, bekommt das Server-Profil, weil er Dienste betreibt; die Seite sagt, warum.

Laufende Jobs aktualisieren sich von selbst, ohne dass Sie die Seite neu laden, und ein Lauf öffnet ein Detailpanel mit Diagrammen seines Durchsatzes. Der Verlauf listet jeden Lauf, auch die Läufe der Agents auf Ihren Servern und Clients, mit Filtern nach Art (Backup, Restore, Restore-Prüfung, Export, Import, Wartung) und nach Job.

Richtlinien der Agenten

Seit 0.4.0 lassen sich einige Einstellungen aller Agents einmal statt je Rechner festlegen, auf drei Ebenen: die Installation (Installation, Richtlinie der Agenten), der Mandant (die Mandantenseite, Agents) und der Backup-Job (der Job-Editor). Jede Ebene darf eine Einstellung überschreiben, außer die Installation sperrt sie, und jede Ansicht sagt, woher ein Wert kommt und ob er gesperrt ist. Die Einstellungen sind:

• ein Sicherungsfenster: Wochentage und ein Zeitraum, auch über Mitternacht, in der Zeitzone des Zeitplans des Jobs, in dem geplante Backups, Nachholläufe und Wiederholungen starten dürfen. Ein laufendes Backup läuft weiter, und „Jetzt sichern“ ignoriert das Fenster;
• verpasste Sicherungen nachholen, sobald der Rechner wieder an ist oder im nächsten Sicherungsfenster, wahlweise nur bis zu einem Höchstalter;
• das Upload-Limit eines Jobs, der kein eigenes hat (ein Job kann auch „Unbegrenzt“ wählen, was das Limit einer Richtlinie beiseitelegt, außer die Installation sperrt es);
• nur am Netzstrom;
• die Zahl der automatischen Wiederholungen, 0 bis 10.

Ohne Richtlinie verhalten sich die Agents genau wie bisher. Die Seite eines Servers oder Clients zeigt die Richtlinie, die für ihn gilt, jede Einstellung mit ihrer Quelle (Standard, Installation, Mandant, Backup-Job oder der Rechner selbst) und ob sie gesperrt ist, nur lesend, und warum ein fälliges Backup wartet, neben seinem nächsten geplanten Start: auf das Sicherungsfenster, auf das Ende eines Updates, auf das Netzteil oder um im nächsten Fenster nachzuholen. Jede Änderung steht im Audit-Log. Fenster, Nachholen, Wiederholungen und der Wartegrund brauchen Agent 0.4.0; Upload-Limit und Netzstrom erreichen auch ältere Agents.

Solange ein Update von Restow neue Läufe anhält, startet der Agent 0.4.0 kein geplantes Backup, keine Wiederholung und keinen Nachhollauf und wartet das Ende der Pause ab; das Warten zählt nicht als verpasstes oder fehlgeschlagenes Backup. Eine Anforderung „Jetzt sichern“ bleibt auf dem Server in der Warteschlange, bis die Pause vorbei ist, auch für ältere Agents, und restow-agent backup-now auf dem Rechner wartet mit einer Meldung. restow-agent status zeigt die Richtlinie und warum ein fälliges Backup wartet. Agents vor 0.4.0 halten ihre eigenen Zeitpläne bei einem Update nicht an: Ein Backup, das ein solcher Rechner in dieser Zeit selbst startet, läuft und kann fehlschlagen, wenn die API unter ihm neu startet.

Wie ein Rechner hinzukommt

In der Restow-Weboberfläche legen Sie einen neuen Server oder einen neuen Client an. Restow zeigt den Installationsbefehl und getrennt davon ein Einmal-Token, das 24 Stunden und nur für einen einzigen Einsatz gilt. Sie führen den Befehl mit sudo auf dem Rechner aus; das Skript fragt nach dem Token und liest es verdeckt ein, sodass es weder in der Befehlszeile noch in der Prozessliste steht. Für unbeaufsichtigte Installationen (RMM, Skripte) liest das Skript das Token aus einer Datei, die nur root lesen kann. Das Installationsskript liefert Ihre eigene Instanz aus: Es lädt den Agenten und restic von dieser Instanz, prüft die Signatur des Maintainers über die Prüfsummenliste des Releases und den SHA-256 beider Programme, bevor es etwas ausführt, installiert sie in einen Ordner, den nur root ändern kann (/opt/restow-agent/bin unter Linux, /Library/Application Support/Restow/bin unter macOS), richtet den Dienst ein (systemd oder launchd), meldet den Rechner an und startet ihn. Ein erneuter Aufruf repariert oder aktualisiert an Ort und Stelle.

Der Agent baut ausgehende HTTPS-Verbindungen zu Ihrer Restow-Instanz auf und zu nichts sonst, und er öffnet keinen Port auf dem Rechner. Unter macOS erlauben Sie dem Agenten in den Systemeinstellungen den „Vollen Festplattenzugriff“; ohne ihn werden geschützte Ordner übersprungen, und das Backup wird als teilweise gemeldet, mit dem Grund im Laufprotokoll.

Warum der Agent seine Backups nicht zerstören kann

„Nur anhängend“ erzwingt Ihre Restow-Instanz, es bleibt nicht dem Wohlverhalten des Agenten überlassen. Der Agent schreibt in ein restic-Repository, das die Instanz im Append-only-Modus anbietet: Er kann Backups hinzufügen, aber nicht löschen oder überschreiben. Die Ende-zu-Ende-Tests von Restow prüfen, dass forget, prune, Löschen und Überschreiben mit dem Zugang des Agenten verweigert werden und die gespeicherten Bytes unverändert bleiben. Aufbewahrung, Bereinigung und Integritätsprüfungen laufen ausschließlich auf dem Restow-Server.

„Nur anhängend“ schützt vor dem Rechner. Gegen jemanden auf dem Restow-Server oder mit dessen Speicherschlüssel lässt sich das primäre Repository des Mandanten seit 0.4.0 unveränderbar machen (S3 mit Object Lock): Der Speicher sperrt dann die Objekte data, snapshots, keys und config des Repositorys jedes Rechners, nicht aber die Lock- und Index-Dateien von restic. Es ist aus, bis ein Administrator es einschaltet, und das Standard-Repository der Installation lässt sich nicht unveränderbar machen. Siehe Speicher.

Der Agent hält nie Zugangsdaten des Speicherziels, etwa S3-Schlüssel oder Mount-Pfade. Er kennt nur sein eigenes Agent-Geheimnis und das Passwort seines eigenen Repositorys. Jeder Rechner hat ein Repository und ein zufälliges Passwort; der Server bewahrt dieses Passwort mit dem Mandantenschlüssel verschlüsselt auf, sodass ein Administrator auch dann wiederherstellen kann, wenn der Rechner selbst nicht mehr existiert.

Restore

Ein Restore auf den Rechner (seit 0.4.0 auch durch Restore-Operatoren) landet immer in einem neuen Ordner und nie über vorhandenen Dateien: Das Ziel darf nicht existieren oder muss leer sein, sonst schlägt der Lauf fehl und nichts wird angefasst. Alternativ durchsuchen Sie ein Backup in der Restow-Oberfläche und laden Dateien oder Ordner als ZIP herunter: Ein ZIP kann bis zu 10.000 Pfade enthalten, und Ordner werden seitenweise durchsucht („Mehr laden“). Ein Restore-Auftrag in einen neuen Ordner auf dem Rechner nimmt bis zu 200 Pfade auf. Durchsuchen, Downloads und Restore-Anforderungen stehen im Audit-Log. Das Repository ist ein gewöhnliches restic-Repository; ein Restore ohne Restow ist daher mit dem Repository-Passwort möglich. Ein Administrator kann sich dieses Passwort von Restow anzeigen lassen (Restow verlangt dafür eine frische Anmeldung und schreibt den Zugriff in das Audit-Log). Das Passwort liegt außerdem, mit dem Mandantenschlüssel versiegelt, neben dem Repository; mit dem Master-Key der Installation und dem Speicher allein gewinnt das eigenständige Restore-Werkzeug es zurück, ohne laufendes Restow. Die allgemeinen Restore-Regeln stehen auf der Restore-Seite.

Bewiesen wiederherstellbar

Nach jedem Backup hält der Agent den SHA-256 von bis zu 20 zufälligen Dateien fest. Später liest der Server diese Dateien aus dem Snapshot zurück und vergleicht die Hashes; das Ergebnis ist nur dann grün, wenn sie übereinstimmen. Dieses Ergebnis fließt in die Wiederherstellbarkeit (im Englischen Recovery readiness) ein, denselben Status wie bei Postfächern, sodass ein Rechner nur dann als bewiesen gilt, wenn sein neuestes Backup zurückgelesen wurde. Mehr zum Ansatz steht auf der Verifizierungs-Seite.

Jeder neue Sicherungsstand eines Rechners wird außerdem auf Anzeichen von Ransomware beurteilt: Menge der Änderungen, Löschungen, umbenannte Endungen, bekannte Namen, Stichprobendateien, die verschlüsselt wirken, und Daten, die sich weder komprimieren noch deduplizieren lassen. Der Aktivitätsbericht braucht Agent 0.4.0. Ein verdächtiger Sicherungsstand hält die Aufbewahrung dieses Rechners an, bis ein Administrator ihn klärt. Siehe Ransomware-Erkennung.

Jede Woche prüft der Server außerdem jedes Repository und liest dabei pro Lauf ein Zwanzigstel der Daten, sodass das gesamte Repository über etwa fünf Monate gelesen wird. Auch die Aufbewahrung läuft auf dem Server; der Standard behält 30 tägliche, 12 wöchentliche und 12 monatliche Backups und lässt sich je Rechner ändern. Was gelöscht wird, entscheidet der Server nach seinen eigenen Aufzeichnungen der Sicherungsläufe, nicht nach den Zeiten, die der Rechner in seine Snapshots schreibt.

Jeder Rechner hat ein Speicherbudget, standardmäßig 2 TiB und je Rechner einstellbar, und alle Rechner eines Mandanten zusammen 20 TiB. Ein Upload, der nicht mehr hineinpasst, wird abgelehnt, Restores funktionieren weiter, und ein Alarm warnt bei 90 Prozent.

Eine Sicherung stoppen und den Agent sofort aktualisieren

Seit 0.4.2 stoppt Sicherung stoppen auf der Seite eines Rechners und in der Lauf-Schublade eine laufende Sicherung, und Sicherung zurückziehen nimmt ein „Jetzt sichern“ zurück, das noch nicht begonnen hat. Wer eine Sicherung starten darf, darf sie stoppen; jedes Stoppen fragt vorher nach und wird im Audit-Log festgehalten, mit dem, der gestoppt hat. Der Agent bekommt den Auftrag bei seiner nächsten Meldung (jede Minute während einer Sicherung, sonst alle fünf Minuten), beendet restic sauber, sodass kein Snapshot und keine Sperre zurückbleiben, und ein Post-Hook läuft wie sonst. Der Lauf endet als Abgebrochen, nicht als fehlgeschlagen: kein Fehleralarm, kein Webhook job.failed, die letzte Sicherung und die Zahl fehlgeschlagener Sicherungen bleiben, wie sie waren, und die nächste geplante Sicherung startet normal. Es braucht Agent 0.4.2; ein älterer Agent kennt den Auftrag nicht und führt seine Sicherung zu Ende.

Neben der Selbstaktualisierung alle sechs Stunden fordert „Auf <Version> aktualisieren“ auf der Seite eines Rechners das Update jederzeit an, und sudo restow-agent update auf dem Rechner installiert das angebotene Release sofort, über denselben signierten Download, startet den Dienst neu und sagt, was es getan hat. Läuft gerade eine Sicherung, eine Wiederherstellung oder ein Restore-Test, lehnt er ab, und der Agent installiert das Update selbst, sobald er frei ist. Läuft der Server mit einem neuen Release, ziehen Agents nach, während neue Läufe warten, höchstens 15 Minuten; der Reiter Updates zeigt ihren Fortschritt und nennt für einen nicht erreichten Agent den Befehl.

Einen Rechner entfernen

Seit 0.4.5 lässt sich ein gesperrter Rechner aus Restow entfernen, mit oder ohne seine Sicherungen. Aus Restow entfernen im Gefahrenbereich der Rechnerseite bietet Aus der Liste entfernen, Sicherungen bis zum Ablauf behalten (die neueste Sicherung plus die längste Regel der Aufbewahrung des Rechners, als Zeit gelesen) oder Rechner und seine Sicherungen löschen. Beides braucht den eingetippten Hostnamen und eine junge Anmeldung, und der Rechner muss zuerst gesperrt sein. Der Rechner verschwindet aus jeder Liste, Auswahl, Übersicht und Zählung und aus seinem Backup-Job; seine Läufe, Berichte und Audit-Einträge bleiben. Der Worker löscht das restic-Repository des Rechners auf jedem Ziel, das Dateien von ihm hält: dem primären, seinen Kopien und ausgemusterten primären. Sofortiges Löschen wird abgelehnt, solange eine Legal Hold über dem Mandanten oder ein ungeklärter verdächtiger Sicherungsstand die Sicherungen hält, und der Worker wartet auf eine solche Hold, wenn die Sicherungen ablaufen. Objekte, die der Speicher noch sperrt (S3 Object Lock, die Löschverzögerung eines Verzeichnisses), werden gelöscht, sobald ihre Sperre abläuft; die Rechnerseite listet die noch offenen Entfernungen mit dem Datum, der Hold oder der Sperre. Jeder Schritt wird protokolliert.

Bis die Sicherungen gelöscht sind, bietet die Seite eines entfernten Rechners sie zum Durchsuchen und für den ZIP-Download an (seit 0.4.6), und die Liste der entfernten Rechner verlinkt „Dateien wiederherstellen“; das Wiederherstellen auf den Rechner und jede andere Aktion bleiben abgelehnt. Eine Deinstallation, die auf einen ausgeschalteten Rechner wartet, bietet Jetzt sperren an, und ein Rechner, der sich länger als eine von Ihnen gesetzte Zahl von Tagen nicht gemeldet hat (standardmäßig 30, unter Alarme des Rechners), schlägt vor, ihn zu sperren.

Alarme

Restow löst einen Alarm aus, über dieselben Kanäle wie bei jedem anderen Job (Glocke, E-Mail, Webhook), wenn:

• ein Server still ist: standardmäßig länger als 2 Stunden kein Kontakt;
• ein Client länger kein gutes Backup hatte: standardmäßig 7 Tage, denn ein Laptop ist nachts aus;
• ein Backup überfällig ist (backup.overdue): Die Alarmregel berücksichtigt den Zeitplan des Jobs und kann eine eigene Frist setzen, von 24 bis 720 Stunden;
• ein Backup fehlschlägt oder ein Restore auf einem Rechner fehlschlägt;
• ein Restore-Test fehlschlägt oder eine Repository-Prüfung Schäden findet.

Warnungen sagen, warum einzelne Elemente nicht gesichert wurden, und lassen sich mit einer Notiz bestätigen. Webhook-Alarme können auch in Discord, Slack oder Microsoft Teams posten, siehe Microsoft-365- und IMAP-Backup.

Profile und Hooks

Das Profil Server sichert täglich (Standardzeit 22:00 Uhr). Das Profil Client sichert, sobald der Rechner Ihre Restow-Instanz erreicht, höchstens alle 4 Stunden, und lässt sich in der Bandbreite begrenzen und so einstellen, dass es nur am Netzteil läuft (die Erkennung ist ein bestmöglicher Versuch). Optionale Pre- und Post-Hooks führen Befehle rund um ein Backup aus, zum Beispiel einen Datenbank-Dump. Sie laufen als root, deshalb entscheidet der Rechner: Auf einem neuen Rechner sind Hooks aus, und nur root auf dem Rechner kann sie erlauben, entweder nur benannte Skripte, die root in /etc/restow-agent/hooks.d abgelegt hat (sudo restow-agent hooks scripts), oder beliebige Befehle (sudo restow-agent hooks any). Restow kann diese Einstellung nicht ändern: Es zeigt die Regel jedes Rechners und lehnt Hooks ab, die der Rechner nicht ausführen würde. Nur mit any kann, wer die Konfiguration eines Rechners in Restow ändert, dort beliebige Befehle als root ausführen; nehmen Sie daher lieber scripts. Einen Hook zu setzen oder zu ändern verlangt außerdem eine frische Anmeldung.

Benannte Grenzen, nicht versteckte

• Noch kein Windows-Agent. Er ist geplant, siehe die Roadmap.
• Noch keine LVM-, ZFS- oder btrfs-Snapshots und unter macOS keine APFS-Snapshots. Die Konsistenz kommt aus den optionalen Hooks (zum Beispiel ein Datenbank-Dump); Dateien, die sich während des Lesens ändern, können im Snapshot inkonsistent landen.
• Noch kein mTLS: Jeder Agent authentifiziert sich mit einem eigenen Geheimnis über HTTPS. Ein gestohlenes Geheimnis erlaubt nicht, etwas zu löschen.
• Solange ein Rechner des Mandanten aktiv ist, lehnt Restow einen Wechsel des primären Speicherziels ab, weil ein aktiver Agent weiter in das alte primäre Repository schreibt. Zum Wechseln widerrufen oder deinstallieren Sie die Rechner, ändern das primäre Ziel und melden die Rechner erneut an; dabei entstehen neue Repositories. Seit 0.4.2 kopiert „Vorhandene Backups verschieben“ die Repositories der widerrufenen Rechner ebenfalls in das neue primäre Repository, geprüft per SHA-256, und die Seite eines Rechners nennt das Repository, in dem seine Sicherungen landen (das Anmelden eines Rechners warnt, wenn das die eigene Platte des Servers ist); mit „Vorhandene Backups dort belassen, wo sie sind“ bleiben sie auf dem vorherigen Ziel und lassen sich weiterhin durchsuchen und herunterladen. Siehe Speicher.
• Was die Release-Prüfungen abdecken: Das Installationsskript des Agents läuft in den Release-Prüfungen nur in einem Linux-Container. Der macOS-Installer wurde außerhalb der Release-Prüfungen auf einem Mac getestet, und der launchd-Dienst selbst lief noch nicht unter echten Bedingungen.
• Noch keine Image- oder Bare-Metal-Backups: Das Backup ist heute dateibasiert. Abbild-Backup ist geplant.
• Der Agent läuft als root, weil er jede Datei lesen muss, die er sichert.
• Der Agent sucht eine Minute nach dem Start und dann alle 6 Stunden nach Updates, außerdem wenn der Server es verlangt (ein Update des Servers oder „Auf <Version> aktualisieren“), und installiert nur Releases, die der Maintainer signiert hat: Er prüft die Ed25519-Signatur über die Prüfsummenliste des Releases mit dem in ihn einkompilierten Schlüssel, dann den SHA-256 jeder Datei, sodass eine kompromittierte Instanz ihn kein eigenes Programm ausführen lassen kann. Automatische Agent-Updates lassen sich je Mandant pausieren. Die Erstinstallation 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 (Ed25519, auch in den Release-Notes).
• Restow ist eine Beta. Betreiben Sie es neben Ihren bestehenden Backups, bis Sie selbst daraus wiederhergestellt haben.

Dokumentation

Das Administrator-Handbuch enthält die Übersicht und die Installationsschritte, einschließlich der macOS-Berechtigung.

Häufig gefragt

Weiter zu: Wie Restore funktioniert →

Mehr in Wissen: wie tägliche, wöchentliche und monatliche Aufbewahrung funktioniert (Generationenprinzip) →

Mehr in Wissen: unveränderliche Backups, WORM und Air Gap (append-only im Zusammenhang) →