← Alle Funktionen

Bringen Sie Ihren eigenen Speicher mit

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

Restow schreibt Backup-Daten als deduplizierte, verschlüsselte Chunks (inhaltsbasiertes Chunking, SHA-256-Hashes, gepackt in Pack-Dateien) auf Speicher Ihrer Wahl. Das Standardziel braucht überhaupt keinen zusätzlichen Dienst: lokale Platte auf einem Docker-Volume im selben Container, sodass Restow vollständig eigenständig läuft, nur mit sich selbst plus PostgreSQL, und keine Daten je Ihren Server verlassen müssen. Zeigen Sie stattdessen auf S3-kompatiblen Objektspeicher, oder ein gemountetes NFS-Share, und der Speicher ist genau so gut, günstig oder geografisch nah, wie das, was Sie gewählt haben, ganz ohne Aufschlag obendrauf.

Warum „eigener Speicher“ statt einer Restow-Cloud

Restow betreibt keinen gehosteten Speicherdienst, und das ist auch nicht geplant. Siehe Ihre Daten sind Ihre Daten für die vollständige Begründung. Praktisch bedeutet das: Ihre Speicherrechnung ist Ihre Speicherrechnung. Wählen Sie einen günstigen S3-kompatiblen Anbieter, nutzen Sie Kapazität, die Sie ohnehin schon bezahlen, oder behalten Sie alles auf lokaler Platte, ganz ohne Abrechnung pro Gigabyte, pro Restore oder pro API-Aufruf. Mehr als ein Speicherziel je Organisation wird unterstützt: ein Primärziel plus eine Kopie ist das übliche Muster, um ein Backup vom Backup zu haben.

Repositories, die Sie hinzufügen können

Wo Backups liegen, heißt Repository: Ein Menüeintrag Repositories steht unter Ihrer Organisation. Der Inhaber der Installation legt den Standardspeicher (einen lokalen Pfad oder einen S3-kompatiblen Bucket) unter Installation, Standard-Repository fest, und Restow prüft ihn mit einem Test, bevor es ihn speichert. Mandanten darauf bleiben durch eigenes Präfix und eigenen Schlüssel getrennt. Ein Repository kann sein:

• Eine lokale Platte.
• S3-kompatibler Objektspeicher, mit einem Preset für Hetzner Object Storage. Es hat eine Standortauswahl (Falkenstein, Nürnberg, Helsinki), die Endpunkt und Region zusammen setzt, und die Object-Lock-Erkennung akzeptiert die Antworten S3-kompatibler Dienste wie Hetzner. Mit Object Lock am Bucket kann es auch unveränderbare Backups aufnehmen, siehe unten.
• NFS, hinzugefügt über die Weboberfläche unter Installation, Netzlaufwerke, oder per NFS-Adresse im Pfadfeld eines Verzeichnis-Repositorys (zum Beispiel 192.168.1.10:/export/backup, nas.local:/volume1/restow oder eine nfs://-Adresse). Der Provider-Inhaber kann es dort testen und einbinden, und Restow trägt den Pfad ein. Laufen Jobs, wartet das Einbinden, bis keiner läuft, und lässt sich abbrechen.

NFS läuft über den optionalen Mounter-Container (docker compose --profile mounts up -d mounter oder die Installer-Option --with-mounter). Der Mounter prüft ein Netzlaufwerk, bevor er docker-compose.override.yml schreibt, startet die Dienste api und worker neu und rollt bei einem Fehler zurück; der Updater zieht ihn bei jedem signierten Update mit.

Seit 0.3.6 zeigt die Seite Netzlaufwerke, wenn der Mounter nicht läuft, den Befehl zum Starten, beginnend mit dem Verzeichnis der Installation. Stammt die docker-compose.yml der Installation aus der Zeit vor dem Mounter, sagt die Seite das und zeigt den Installer-Befehl: Führen Sie install.sh erneut aus, ersetzt es die Datei durch die des Releases, behält die alte als Sicherung und lässt die .env unverändert.

Seit 0.3.6 sagt Restow beim Einbinden eines NFS-Exports, den es auf dem Server nicht gibt, genau das: „Der Exportpfad … existiert auf … nicht.“, und wie Sie den richtigen finden. Welche Pfade der Server freigibt, zeigt showmount -e <server>. Auf einer Synology-NAS beginnt der Pfad mit dem Volume, zum Beispiel /volume1/restow. Bei NFSv4 zeigen manche Server ihre Exporte unterhalb einer Pseudo-Root mit anderen Pfaden; versuchen Sie dann NFS-Version 3. Zuvor endete das Einbinden mit einem knappen „No such file or directory“.

Wo Sicherungen landen, und der Wechsel des Primärziels

Seit 0.4.2 nennt Restow das wirksame primäre Repository des Mandanten dort, wo ein Backup eingerichtet oder gestartet wird: auf der Seite eines Gasts und in dessen Dialog „Jetzt sichern“, in den Dialogen für Proxmox-VE-Jobs und -Anbindung, auf der Seite eines Rechners und einer Dateifreigabe und in den Job-Editoren, mit dem Installationsstandard auf der lokalen Platte des Servers hervorgehoben. Der Bereich Repositories und die Dialoge, die Proxmox-VE-Knoten, Rechner und Dateifreigaben hinzufügen, warnen „Sicherungen landen auf der eigenen Platte des Servers“, wenn das primäre Repository ein Verzeichnis auf einer Platte des Restow-Servers selbst ist, keine Netzwerkfreigabe: Fällt dieser Server oder seine Platte aus, sind die Sicherungen mit ihm verloren.

Seit 0.4.5 sagt Restow außerdem, wenn das Verzeichnis auf der Systemplatte des Servers liegt, der Platte unter Betriebssystem, Docker und Datenbank: Eine volle Systemplatte hält alles an, nicht nur die Sicherungen. Die API erkennt das aus ihrem Container heraus am Gerät und am Blockgerät des Pfads, einschließlich des Installationsstandards und der Freigaben des Mounters. Die Seite Repositories, die Zeile „Sicherungen landen in:“ der Job-Editoren (mit dem Kennzeichen „Systemplatte“) und die Speicherkachel des Dashboards warnen, und Provider-Admins sehen auf der Kachel den freien Platz, seinen Verlauf über die letzte Woche und den Zeitpunkt, an dem die Platte voll wäre. Nichts wird blockiert.

Backups von Servern und Clients (siehe Server- und Client-Backup), Freigaben (siehe Dateifreigaben) und Proxmox-VE-Container nutzen je ein restic-Repository ebenfalls im primären Ziel, und Kopie-Repositories decken sie nicht ab. Der Wechsel des Primärziels berücksichtigt sie seit 0.4.2:

• Vorhandene Backups verschieben (empfohlen): Ein Hintergrundlauf kopiert jedes Pack, jedes Manifest und jeden Schlüssel, die Manifeste der Sicherungsstände von VMs und Containern und die restic-Repositories von Containern, Rechnern und Dateifreigaben in das neue Repository, prüft sie nach Größe und SHA-256 wie Packs, wartet auf laufende Container-Sicherungen und Läufe von Dateifreigaben und schaltet erst dann das primäre Repository um. Der alte Ort bleibt schreibgeschützt angebunden, bis Sie ihn entfernen, und lässt sich nicht entfernen, solange er allein ein solches Repository hält.
• Vorhandene Backups dort belassen, wo sie sind kopiert nichts und wird abgelehnt, solange Container oder Dateifreigaben restic-Repositories haben (der Dialog zeigt es deaktiviert), weil nach einem solchen Wechsel jeder Container und jede Freigabe auf dem neuen primären Repository ein leeres Repository fände. Vor 0.4.2 scheiterte dann jeder Container mit vorhandenem Repository mit „repository does not exist“. Das Befördern einer Kopie wird aus demselben Grund abgelehnt.
• Rechner. Solange ein Rechner des Mandanten aktiv ist, lehnt Restow weiterhin jeden Wechsel des primären Repositorys ab, weil ein aktiver Agent weiter in das alte primäre Repository schreibt. Widerrufen oder deinstallieren Sie zuerst die Rechner, wechseln Sie das primäre Repository (Verschieben kopiert auch die Repositories der widerrufenen Rechner) und melden Sie die Rechner dann erneut an; dabei entstehen neue Repositories im neuen primären Ziel. Bei „Dort belassen“ bleiben die Repositories widerrufener Rechner auf dem alten Ziel, das ein schreibgeschützter Rückfall bleibt: durchsuchbar und herunterladbar.

Unveränderbare Backups

Seit 0.4.0 hat jedes Repository eine eigene Einstellung für Unveränderbarkeit. Sie ist aus, bis ein Administrator sie einschaltet, auf der Karte des Repositorys unter Repositories („Unveränderbarkeit ändern“), und vorher ist nichts gesperrt. Was sie bedeutet, hängt von der Art des Repositorys ab.

• S3 mit Object Lock, im Compliance- oder Governance-Modus, für 1 bis 3650 Tage. Der Speicher selbst lehnt dann ab, eine gesperrte Version vor ihrem Datum zu löschen oder zu überschreiben, wer auch fragt: Restow, jemand mit dem Zugriffsschlüssel von Restow, ein gestohlenes Administratorkonto. Der Compliance-Modus lässt sich von niemandem verkürzen oder aufheben, auch nicht vom Inhaber des Buckets. Der Governance-Modus lässt sich von jedem Konto aufheben, das die Umgehungsberechtigung (s3:BypassGovernanceRetention) hat; Restow nutzt sie nie, und sein Zugriffsschlüssel sollte sie nicht haben. Das Einschalten prüft den Bucket und lehnt einen ohne Object Lock ab. Object Lock lässt sich nur beim Anlegen eines Buckets einschalten: Bei einem bestehenden Bucket lässt es sich nicht nachrüsten.
• Ein Verzeichnis (das Docker-Volume, ein NFS-Share) bekommt nur eine Löschverzögerung: Restows eigener Code lehnt ab, eine Backup-Datei vor Ablauf des Zeitraums zu löschen oder zu überschreiben. Das schützt vor Missbrauch von Restow, etwa einem gestohlenen Administratorkonto oder einer Aufbewahrungsrichtlinie, die verkürzt wurde, um Sicherungsstände zu löschen. Es schützt nicht vor jemandem mit Zugriff auf den Server oder die Freigabe, und die Oberfläche sagt, dass es keine Unveränderbarkeit ist. Für echte Unveränderbarkeit vor Ort nutzen Sie einen S3-Dienst mit Object Lock auf einer getrennten Maschine, als Repository oder als Kopie.

Was gesperrt ist und was nicht

Gesperrt sind die Packs, die festgeschriebenen Manifeste und die umhüllten Schlüssel des Chunk-Stores (Microsoft 365, IMAP und Proxmox-VE-VM-Datenträger sowie der Nachrichteninhalt des Archivs, der im selben Chunk-Store liegt) und die Objekte data, snapshots, keys und config jedes restic-Repositorys (Server und Clients, Freigaben, Proxmox-VE-Container). Nicht gesperrt sind Checkpoints, Staging, Exporte und Downloads sowie restics eigene Dateien locks und index; restic kann den Index aus den gesperrten Packs neu aufbauen. Die Datensätze der Archivelemente behalten ihre eigene Aufbewahrung, wie bisher.

Wie die Sperre den Daten folgt

Jedes gesperrte Objekt wird mit einem Aufbewahrungsende von Zeitraum plus 7 Tagen geschrieben. Weil die Deduplizierung einen neuen Sicherungsstand auf Packs aufsetzen lässt, die vor Monaten geschrieben wurden, verlängert der tägliche Aufbewahrungslauf die Sperre jedes noch verwendeten Objekts, sobald die letzte vollständige Verlängerung 6 Tage alt ist; was ein Sicherungsstand braucht, bleibt so mindestens den Zeitraum über heute hinaus gesperrt. Trifft die Aufbewahrung oder die Garbage Collection auf ein Objekt, das noch gesperrt ist, zählt die Löschung als „noch nicht“: Der Sicherungsstand bleibt sichtbar und wiederherstellbar, und der Platz kommt zurück, sobald die Sperre abgelaufen ist, bis zu Zeitraum plus 7 Tage später.

Was Sie sehen, und wer es ändern darf

Die Karte des Repositorys zeigt die Einstellung in Worten, die letzte Verlängerung und die letzte Prüfung und stellt Warnungen nach vorn: Objekte ohne Sperre, ein schwächerer Modus als eingestellt, eine Verlängerung, die überfällig ist oder fehlschlug, und Löschungen, die auf ihre Sperre warten. „Jetzt prüfen“ und der tägliche Aufbewahrungslauf fragen den Speicher nach der Aufbewahrung einer Stichprobe jüngster Objekte. Sicherungsstände zeigen „Unveränderbar bis“ mit einem Datum, grün nur, wenn der Speicher selbst eine Compliance-Sperre gemeldet hat; Governance und eine Löschverzögerung werden neutral gezeigt. Auch die Speicherkachel des Dashboards und die Provider-Ansicht warnen. Den Schutz zu erhöhen steht jedem offen, der das Repository konfigurieren darf. Ihn zu senken (weniger Tage, ein schwächerer Modus, aus) ist dem Provider-Inhaber mit einer Anmeldung der letzten zehn Minuten vorbehalten und gilt nur für Daten, die ab dann geschrieben werden. Jede Änderung und jede Prüfung steht im Audit-Log.

Wovor es nicht schützt

• Wer Restow kontrolliert, kann das Schreiben neuer Sperren und die Verlängerung anhalten. Was gesperrt war, bleibt bis zu seinem Datum gesperrt, aber neue Backups danach sind nicht geschützt.
• Eine Governance-Sperre hebt jedes Konto mit der Umgehungsberechtigung auf. Geben Sie dem Zugriffsschlüssel von Restow eine Richtlinie ohne sie, oder nutzen Sie den Compliance-Modus.
• Wer den Schlüssel von Restow hat, kann Objekte hinter Löschmarkern verstecken oder Müll-Versionen darüberschreiben. Die gesperrten Versionen bleiben und lassen sich zurückholen, indem man die neueren Versionen oder Marker entfernt.
• Der Hauptschlüssel liegt nicht im Bucket. Bewahren Sie eine Kopie davon getrennt vom Server auf, sonst lassen sich gesperrte Daten nicht öffnen.

Der Zugriffsschlüssel eines unveränderbaren S3-Repositorys braucht s3:GetBucketObjectLockConfiguration, s3:PutObjectRetention, s3:GetObjectRetention, s3:ListBucketVersions und s3:DeleteObjectVersion und sollte s3:BypassGovernanceRetention, s3:PutBucketObjectLockConfiguration oder s3:PutBucketVersioning nicht haben.

S3-Endpunkte müssen HTTPS nutzen

Ein S3-Repository schickt seine Zugriffssignaturen und jedes Pack an den Speicherdienst, daher wird seit 0.4.0 ein neuer oder geänderter Endpunkt über reines http:// abgelehnt, auch für Provider-Administratoren und den Installations-Standard. Die einzige Ausnahme ist die Maschine selbst (localhost, 127.0.0.1, [::1]). Früher gespeicherte Endpunkte funktionieren weiter, bei einem Update bleibt also kein Backup stehen: Ihre Repository-Karte, Installation, Standard-Repository und jeder Test sagen in Rot, dass sie auf HTTPS umziehen sollten, und eine Änderung ihres Orts braucht https://. Test- und Entwicklungsumgebungen können reines HTTP mit S3_ALLOW_INSECURE=true annehmen; setzen Sie es nie in der Produktion.

Speicherzahlen und Plattenplatz

Seit 0.4.1 addiert die Zahl „Gespeichert“ (die Dashboard-Kachel, Repositories, Nutzung, die Statistik und die API) die restic-Repositories von Servern und Clients, Freigaben und Proxmox-VE-Containern zum Chunk-Store; vorher zählte sie nur den Chunk-Store, sodass ein Mandant mit 10 GB Container-Backups „Gespeichert 10,9 kB“ sah. Die Nutzungskarte zeigt, wie viel davon im Chunk-Store und wie viel in restic-Repositories liegt. Die Deduplizierungsersparnis, das Wachstum und das Diagramm, jetzt „Chunk-Store pro Tag“ genannt, bleiben Zahlen des Chunk-Stores, weil die restic-Repositories keinen Größenverlauf führen, und „Geschützte Daten“ zählt weiterhin nur die Quellen des Chunk-Stores.

Seit 0.4.0 zeigt das Dashboard das Speicherwachstum für 1 Woche, 1 Monat, 3 Monate oder 1 Jahr, ab 3 Monaten mit der Schätzung als Band zwischen dem langsamsten und dem schnellsten Wachstum, und wann das Repository bei diesem Wachstum voll ist, wo sein freier Platz bekannt ist. Alle 15 Minuten prüft die API außerdem die Platte unter der Datenbank und unter dem lokalen Standard-Repository und warnt Provider-Administratoren unter einem Zehntel frei und immer unter 5 GiB. Seit 0.4.5 beobachtet sie auch die Systemplatte des Servers nach derselben Regel.

Die Speicherprüfung: beschädigt ist nicht dasselbe wie nicht lesbar

Die Speicherprüfung liest Packs zurück und vergleicht sie mit der aufgezeichneten Größe und Prüfsumme: jede Woche eine Stichprobe und jeden Monat jedes Pack, und „Wiederherstellbarkeit › Speicherintegrität“ kann von Hand eine Stichprobe, eine vollständige Prüfung oder eine erneute Prüfung starten. Seit 0.4.2 unterscheidet sie zwei Dinge. Ein Pack ist beschädigt, wenn jedes Repository mit einem Schaden geantwortet hat (fehlt, falsche Größe, abweichende Prüfsumme, kein gültiges Pack oder Inhalt, der vom Index abweicht); jedes Objekt, das es verwendet, wird sofort „Nicht wiederherstellbar“. Ein Pack ist vorübergehend nicht lesbar, wenn ein Repository im Moment nicht lesbar war, was nichts über die Daten beweist: ein mitten in der Übertragung abgebrochener Download, eine zurückgesetzte Verbindung, ein Timeout, S3 mit der Bitte um langsameres Tempo oder verweigerter Zugriff. Die Prüfung liest ein solches Pack zuerst erneut, ganz, bis zu dreimal, und führt, was unlesbar bleibt, als „vorübergehend nicht lesbar“ auf, mit dem Fehler, in wie vielen Prüfungen in Folge es nicht lesbar war und wann zuerst und zuletzt. Objekte, die es verwenden, bekommen „Achtung“. „Nicht wiederherstellbar“ werden sie erst, wenn ein Pack nachweislich beschädigt ist oder in 3 Prüfungen in Folge über mindestens 24 Stunden nicht gelesen werden konnte. Jede weitere Prüfung liest die markierten Packs zuerst, „Diese Packs erneut prüfen“ liest nur sie noch einmal, und lesen sie wieder intakt, endet der Befund, und die Restore-Prüfungen der Objekte bewerten sie wieder selbst. Lesezugriffe auf S3, auch Restores und Restore-Prüfungen, setzen außerdem einen abgebrochenen Download ab dem ersten fehlenden Byte fort.

Benannte Grenzen, nicht versteckte

• Das Verschieben der restic-Repositories, die Prüfung per SHA-256 und das Fortsetzen von S3-Lesezugriffen wurden gegen einen simulierten S3-Dienst und lokale Verzeichnisse getestet, nicht gegen einen echten S3-Anbieter. Eine Container-Sicherung, die im minutenlangen Speicher-Cache-Fenster der API rund um das Umschalten startet, kann noch in das alte primäre Repository schreiben; die Repository-Prüfung der nächsten Sicherung findet das Repository dann im neuen primären.
• Das Einbinden eines NFS-Netzlaufwerks über die Weboberfläche oder über das Pfadfeld eines Repositorys wurde gegen Attrappen getestet, nicht gegen einen echten NFS-Server. Solange ein Einbinden auf laufende Jobs wartet, starten neue Jobs weiter; auf einem Server, der nie leerläuft, wartet es daher weiter.
• Auf lokalen und NFS-Repositories gibt es eine Löschverzögerung, die Restow selbst erzwingt, keine Unveränderbarkeit: Wer Zugriff auf den Server oder die Freigabe hat, kann die Dateien trotzdem löschen. Unveränderbare Backups brauchen einen S3-Bucket, der mit Object Lock angelegt wurde. Das Standard-Repository der Installation lässt sich nicht unveränderbar machen: Geben Sie dem Mandanten ein eigenes Repository oder eine unveränderbare Kopie.
• Unveränderbare Backups wurden gegen einen simulierten S3-Dienst mit Object Lock getestet, noch nicht gegen einen echten S3-Dienst mit Object Lock und nicht gegen einen echten Hetzner-Bucket. Ein Mandant, dessen Aufbewahrungsplan gelöscht wurde, wird nicht verlängert, und der Platz gelöschter Daten kommt erst zurück, wenn ihre Sperre abgelaufen ist. Wie sich Restow bei einer Bucket-weiten Standard-Aufbewahrung von Object Lock verhält, ist ungetestet.
• Restow erkennt einen fehlenden NFS-Export am Fehlertext von Docker, und dieser Text stammt aus der Dokumentation von Docker, nicht aus einem echten fehlgeschlagenen Einbinden.
• Das Hetzner-Preset wurde nicht gegen einen echten Hetzner-Bucket getestet.

Wie sich das mit SaaS-gehostetem Backup vergleicht

Die meisten anbietergehosteten Microsoft-365-Backup-Produkte legen Ihre Daten per Definition in der Cloud des Anbieters ab (das bedeutet „gehostet“), und einige betreiben diese Infrastruktur wirklich gut; siehe den Anbietervergleich dafür, was jeder Einzelne tatsächlich dazu dokumentiert, wo die Bytes liegen. Restow' Antwort ist strukturell, kein Versprechen: es ist erst gar nicht dafür gebaut, diese Cloud zu betreiben, also gibt es nichts zu vertrauen außer Ihrer eigenen Speicherwahl und Restow' Verschlüsselung dessen, was hineingeht (siehe Verschlüsselung und Schlüsselverwaltung).

Häufig gefragt

Warum eigener Speicher wichtig ist, ausführlicher →

Mehr in Wissen: die 3-2-1-Backup-Regel und wo ein Kopie-Repository hineinpasst →

Mehr in Wissen: Backup-Speicher wählen, lokale Platte, NAS, S3 und Band im Vergleich →

Mehr in Wissen: unveränderliche Backups, WORM und Air Gap →