Du hast die Idee hinter der 3-2-1 Backup Strategie doch schön verbalisiert und führst dann auch noch sehr richtig aus, wieso ein stabiles und ausfallsicheres Storage wie dein ZFS selbst mit Snapshots noch Daten verlieren kann. Wie man es dann dennoch schafft sich so eine vermeintliche Nachfolgestrategie einfallen zu lassen, musst du mir erklären
Nach deiner neuen Strategie hättest du insgesamt nur noch
zwei statt zuvor
drei Kopien:
- 1x auf deinem bestehenden ZFS (quasi die Live-Daten)
- 1x auf dem S3 Dienst deiner Wahl
An den zuvor von dir ausgeführten Risiken,
Blitzschlag, Diebstahl, Amok Hardware; Sabotage und das wars dann.
hat sich nichts geändert. Das kann dir auch bei deinem S3 Dienst deiner Wahl passieren. Es ist noch wahrscheinlicher, wenn du statt auf AWS S3, GCS, R2 oder B2 auf einen S3 Dienst setzt, der nicht auf professioneller, redundanter Hardware in entsprechender Umgebung läuft wie beispielsweise bei einem deiner Freunde oder der Familie.
Bedenke dabei auch noch folgendes: Eine Datei in S3 zu speichern, ist nicht vergleichbar mit einer einfachen Kopie auf einem zweiten Datenträger. Denn neben dem Datenträger (Storage) den der S3-Dienst selbst verwendet (vergleichbar mit dem zweiten Datenträger) liegt die Datei jetzt nicht mehr "unverarbeitet" vor, sondern "verarbeitet", d.h. du hast einen Komplexitätslayer hinzugefügt der auch für eigene Probleme Sorgen kann. Vor allem dann, wenn du auf die Kompetenz eines Dritten wie die deines Freundes oder die Familie angewiesen bist (Stichwort Ende von MinIO).
Die Verwendung von restic, kopia usw. erhöht abermals die Komplexität denn jetzt musst du nicht nur die Daten aus dem S3 Storage selbst herausbekommen, sondern bist auch noch darauf angewiesen, dass die jeweilige "Hülle" -- das Backupformat -- auch noch intakt ist. Das kann sich manchmal auch als Problem entpuppen, siehe
https://github.com/kopia/kopia/issues/4788 oder
https://github.com/kopia/kopia/issues/5049
Was ich dir sagen will: Ich verstehe nicht, weswegen du glaubst jetzt mit zwei statt drei Kopien auszukommen. An den von dir aufgeführten Risiken hat sich nichts geändert.
PS: Trotz der zuvor verlinkten Probleme setze ich selbst seit 2024 auf kopia. Mein kopia Repository liegt lokal auf einer zweiten Festplatte (quasi ein Storage ausschließlich für kopia). Dieses Repository repliziere ich mit rsync als Kopie auf Speicher bei rsync.net wo ich wiederum Geo-redundanten Speicher gebucht habe. Das ganze ist für mich nur dadurch finanzierbar, weil die Datenmenge, also das Kopia Repository, nur 1-2TB groß ist. Sollte das einmal nicht mehr reichen würde ich Stand heute wohl die Geo-Redundanz aufgeben wodurch sich mein Speicherplatz bei rsync.net verdoppeln würde und ich würde stattdessen auf deren ZFS und den dort regelmäßig automatisch erzeugten Snapshots vertrauen (damit sichere ich mich bspw. gegen Ransomeware-Attacken ab, die auch mein lokales Backup erreichen könnten was dann evtl. automatisiert Remote landen würde.
PS2: Hast du eigentlich schon einmal die Wiederherstellungs Mittels kopia von Remote getestet? Ich musste schon mehrfach mehrere 100GB aus dem Backup wiederherstellen. Das hat jeweils zwischen 12-20 Stunden mit einer 100/40er DSL-Leitung gedauert. Das macht keinen Spaß. Selbst wenn du 1GBit Glasfaser haben solltest: Bedenke die Chunk-Große und wie kopia und Co. intern arbeiten. Der direkte Dateizugriff gewinnt immer um Welten. Und selbst wenn du dir jetzt sagst, "Mein Gott, ist bislang noch nie vorgekommen, dass ich an dieses Backup musste... dann warte ich halte 20 Stunden!": Das Erlebnis wenn man nach 20 Stunden feststellt, dass man sich da mit dem relativen Pfad verhauen hat und weiß, dass man jetzt weitere 20 Stunden wird warten dürfen weil kopia alles noch einmal laden darf... es prägt einen
Daher mein Tipp: kopia Repository lokal vorhalten!
