Hinweis für Betreiber

Direkt nach dem Setup-Token zeigt der Einrichtungsassistent einen kurzen Hinweis, Ihre Verantwortung als Betreiber. Er sagt, was für ein Werkzeug Restow ist: ein Werkzeug für Backup und Archivierung, das Ihre Daten auf Speicher schreibt, den Sie betreiben, und Ihnen hilft, sie zurückzuholen. Es betreibt diesen Speicher nicht für Sie und kann Ihre Infrastruktur nicht absichern. Was auf der Hardware- und Speicherebene geschieht, liegt bei Ihnen. Restow lässt sich erst einrichten, wenn Sie den Hinweis akzeptiert haben.

Was er sagt

Der Hinweis hat acht Punkte. Kurz gefasst:

1. Kein Ersatz für eine Backup-Strategie. Halten Sie sich an die 3-2-1-Regel: drei Kopien auf zwei Arten von Medien, eine davon an einem anderen Ort oder offline, und bewahren Sie eine unabhängige Kopie auf, die Restow weder erreichen noch löschen kann. In der Beta darf Restow nie Ihre einzige Sicherung sein.
2. Hardware und Speicher. Server, Datenträger, Netzwerke und Speicherziele sowie deren Redundanz, Kapazität und Zustand liegen in Ihrer Verantwortung. Fällt ein Ziel aus, läuft es voll oder geht es ohne getrennte Kopie verloren, kann Restow es weder reparieren noch die Daten zurückbringen.
3. Ransomware und Löschen. Daten sind nur dann unveränderbar, wenn der Speicher sie unveränderbar macht. Ohne WORM oder Object Lock auf dem Ziel kann jeder, der es erreicht, auch Ransomware oder ein kompromittiertes Konto, Sicherungen und Archiv gleichermaßen ändern oder löschen.
4. Verschlüsselungsschlüssel. Ihre Daten sind mit Schlüsseln verschlüsselt, die aus dem Master-Schlüssel dieser Installation abgeleitet sind. Bewahren Sie diesen Schlüssel sicher und getrennt von den Daten auf. Geht er verloren, kann niemand die Daten entschlüsseln.
5. Netzwerk und Zugriff. Die Sicherheit von Server, Netzwerk, Konten und Zugangsdaten, die Restow und seinen Speicher erreichen, liegt bei Ihnen: Updates, Firewall, HTTPS, starke Anmeldung und wer worauf zugreifen darf.
6. Restore testen. Tun Sie es regelmäßig und prüfen Sie die Ergebnisse, zusätzlich zur Prüfung, die Restow selbst durchführt.
7. Archiv und GoBD. Die Archivfunktionen sind für den GoBD-konformen Einsatz ausgelegt. Ob Ihr gesamtes Verfahren konform ist, müssen Sie beantworten: Verfahrensdokumentation, Aufbewahrungsfristen, Zugriffsrechte, organisatorische Maßnahmen und der Speicher hinter dem Archiv. Restow leistet keine Rechts- oder Steuerberatung.
8. Keine Gewährleistung. Restow wird unter seinen Lizenzbedingungen bereitgestellt, ohne Gewährleistung darüber hinaus und über das hinaus, was zwingendes Recht vorschreibt.

Welche Lizenz für welchen Teil von Restow gilt, steht unter Lizenz und Editionen.

Zur Unveränderbarkeit in 0.4.7 im Besonderen: Punkt 3 des Hinweises betrifft den Speicher, den Sie betreiben, und er gilt weiter. Restow macht Speicher nicht von selbst unveränderbar. Seit 0.4.0 hat jedes Repository eine Einstellung für unveränderbare Backups, aus, bis eine Administration sie einschaltet. Auf S3 mit Object Lock schreibt Restow dann jedes Backup-Objekt mit einer Sperre, die der Speicher durchsetzt (Compliance- oder Governance-Modus, 1 bis 3650 Tage), und verlängert sie, solange die Daten verwendet werden. Bei einem Verzeichnis (dem Docker-Volume, einer NFS-Freigabe) bietet es nur eine Löschverzögerung, die Restow selbst einhält, die vor Missbrauch von Restow schützt und keine Unveränderbarkeit ist. Das Standard-Repository der Installation lässt sich nicht unveränderbar machen. Die Datensätze der Archivelemente tragen die eigene Object-Lock-Aufbewahrung des Archivs, und sein Nachrichteninhalt ist nur dort zusammen mit den Backup-Daten gesperrt, wo unveränderbare Backups eingeschaltet sind. Diese Funktionen wurden gegen einen nachgebauten S3-Dienst getestet, noch nicht gegen einen echten. Die Ransomware-Erkennung markiert verdächtige Sicherungsstände und hält Restows Aufbewahrung für sie an; eine unabhängige Kopie ersetzt sie nicht. Siehe auch Archivierung und Journaling und die Roadmap.

Sie müssen ihn zuerst akzeptieren

Sie setzen einen Haken, der besagt, dass Sie den Hinweis gelesen haben und wissen, dass Sie als Betreiber für diese Punkte verantwortlich sind, und fahren mit dem Rest des Assistenten fort.

• Der Server setzt es durch. Die Zustimmung wird zusammen mit der Einrichtung gesendet, und ohne sie lehnt der Server die Einrichtung ab (HTTP-Status 428, „Operator notice not accepted“). Die Reihenfolge der Bildschirme ist nicht der Schutz: Ein Skript, das die Zustimmung weglässt, erhält dieselbe Ablehnung.
• Was gespeichert wird. Die Zustimmung wird in derselben Transaktion wie die Einrichtung gespeichert. Die Fassung des Textes, der Zeitpunkt und die Client-Adresse werden in den Einstellungen der Installation gespeichert, der neue erste Administrator wird als die Person vermerkt, die zugestimmt hat, und ein Eintrag wird ins Audit-Log geschrieben (settings.disclaimer_accepted, mit der Fassung und dem Ort der Zustimmung). Die Aufzeichnung läuft in jeder Edition, die Ansicht des Logs ist eine Business-Funktion, siehe Audit-Log.
• Vor dem Ende wird nichts gespeichert. Brechen Sie den Assistenten ab, bevor er fertig ist, bleibt weder die Zustimmung noch sonst etwas von der Einrichtung zurück.

Was Sie bereithalten sollten

Der Hinweis ist nichts zum Abhaken und Vergessen. Eine kurze Checkliste für das, was er von Ihnen verlangt:

• RESTOW_MASTER_KEY ist offline gesichert, getrennt vom Server, zusammen mit Ihrer .env. Ohne ihn lässt sich keine Sicherung lesen. Siehe Restow selbst sichern.
• Der Speicher ist redundant, Sie beobachten freien Platz und Zustand, und für alles, was zählt, gibt es ein zweites Ziel (ein Kopie-Ziel) oder eine getrennte Sicherung davon.
• WORM oder Object Lock ist auf dem Speicher eingerichtet, wo Sie auf Unveränderbarkeit angewiesen sind, vor allem beim Archiv. Für Backups legen Sie den S3-Bucket mit Object Lock an, geben dem Zugriffsschlüssel von Restow kein s3:BypassGovernanceRetention und schalten am Repository Unveränderbarkeit ändern ein (siehe Unveränderbare Backups). Restow ist nur so unveränderbar wie der Speicher darunter: Ein Verzeichnis bekommt bestenfalls eine Löschverzögerung, und das ist keine Unveränderbarkeit.
• Jemand sieht Ransomware-Befunde. Die Ereignisse Verdächtige Sicherung (Anzeichen von Ransomware) und Aufbewahrung nach verdächtiger Sicherung weiter angehalten erreichen einen Kanal, den jemand liest, und eine Administration weiß, wie man das Anhalten der Aufbewahrung beendet (siehe Ransomware-Erkennung).
• Eine unabhängige Kopie existiert, die Restow weder erreichen noch löschen kann, und in der Beta läuft Restow neben Ihren bestehenden Sicherungen.
• Sie testen Restores nach Plan, an einen Ort, an dem ein Fehler nichts kostet, und Sie lesen das Ergebnis. Siehe Backup und Restore.
• Der Zugriff ist gesichert: Der Server ist aktuell (siehe Updates), nur die Ports, die Sie brauchen, sind offen, die Adresse wird über HTTPS ausgeliefert, die Anmeldung nutzt nach Möglichkeit Passkeys, und Rollen geben niemandem mehr, als er braucht.
• Restow selbst ist gesichert: seine Datenbank, die .env und der Chunk-Store, und Sie wissen, wie Sie ohne laufenden Server wiederherstellen.
• Für das Archiv: Ihre Verfahrensdokumentation, Aufbewahrungsfristen und Zugriffsrechte sind schriftlich festgehalten, und Sie haben sie von der Person prüfen lassen, die dafür in Ihrer Organisation zuständig ist, zum Beispiel Ihrer Steuerberatung.