News Sicherungen und Backups: Habt ihr schon mal Daten verloren und wie schützt ihr euch?

[MaverickM]

In wie weit waren die Ergebnisse unzuverlässig?

Backup-Tasks die nicht zur eingestellten Uhrzeit liefen. Datei-Backups/Sync, der nichts gemacht hat. Eine Recovery habe ich dann auch gar nicht erst probiert, glaube ich. Irgendwo im Forum habe ich da auch ausführlich was dazu berichtet... Ich war jedenfalls nicht angetan.

 

[LiniXXus]

Erstelle meine Backups manuell oder automatisch mit dem Paragon Festplattenmanager und hier ist auch mit vorbestimmt, dass ein automatisches Backup mit dem nächsten Rechnerstart ggf. nachträglich noch vollzogen wird.


Das klappt auch soweit gut.

In meinem Fall wird hiermit auf eine NAS gesichert. Manuell mache ich es aber zusätzlich noch mit einer externen angeschlossenen Festplatte an meinem Rechner. Das mache ich manuell zusätzlich dazu, da ich diese Festplatte nicht immer eingeschaltet habe.

 

[bogge101]

Ich habe ein Datengrab auf einer Synology DS115j
die Backup HDD steckt in einer DS216j

mit HyperBackup habe ich eine "rsync Kopie (Einzelversion)" eingerichtet
so bekomme ich eine 1:1 Kopie (Mirror) und keine verschlüsselte HBK Datei

2x Seagate Ironwolf 10 TB aus 2017

 

[gea]

Ich entwickle gerade ein neues Betriebs und Backup Konzept für mein Multi-OS/ MultiServer Tool napp-it cs für Storage Spaces und ZFS und das lautet:

ZFS ist das Beste, was man lokal auf dem Rechner haben kann, von der Datensicherheit und von von den Features her wie Hybrid Pools, Raid Funktionen, Verschlüssellung und vieles mehr. Das ist ausgereift und es fehlt nur noch sehr wenig wie AnyRaid für "wunschlos glücklich".

Aber auch mit ZFS und Snapshots kann man Daten verlieren. Blitzschlag, Diebstahl, Amok Hardware; Sabotage und das wars dann. Dann braucht man auch mit ZFS Disaster Backup, traditionell als 321 Backup (3x Kopien auf 2x Datenträger, davon 1x Extern). Das kann man immer noch so machen z.B. mit externen (USB) ZFS Pools oder einem oder zwei weiteren NAS Systemen und ZFS Replikation.

Es geht aber auch viel moderner. Als Nachfolger des 321 Prinzips sehe ich 1S3 (Eine Kopie der Daten lokal und eine remote auf einem S3 Einzelserver oder idealerweise S3 Cluster. Einen S3 Server oder Cluster kann relativ günstig bei einem Hoster mieten oder selbst aufbauen, privat bei Freunden oder Familie sonst als On Premise im Büro, Betrieb oder Schule. Die lokalen Daten werden dann aus einem ZFS Snap auf den S3 Server übers Internet syncronisiert. Deduplizierung und Verschlüssellung ist mit Tools wie rclone, restic oder kopia plattformübergreifend möglich. Hat man einen S3 Cluster so repliziert der die Daten automatisch im Cluster und man hat Backup Hochverfügbarkeit.

Ein oder mehrere ZFS Server mit einem oder mehreren S3 Installationen als Backup Cluster, zentral und remote gemanagt mit meinem multi os/multi server napp-it cs , das ist mein Konzept.

 

[Whistl0r]

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!

 

[gea]

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,

1S3 heißt ja nicht, dass nur eine Kopie auf S3 liegt. Jeder kommerzielle S3 Dienst ist als Hochverfügbarkeits Cluster konfiguriert, bei dem die Daten selbsständig im Cluster repliziert werden. Privat oder Inhouse hat man die Option, nur einen einfachen S3 Server zu nutzen oder auch mit mehreren einen Cluster zu bilden, der automatisch die Daten mehrfach hält, inkl. Versionierung so wie lokale ZFS Snaps. Der manuelle Aufwand des 321 Verfahrens entfällt.

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.

Redundanz bei S3 erfolgt auf Node Ebene, auch mit einfacher Hardware. Fällt ein Node aus, arbeitet der Cluster weiter.

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).

Umsonst ist der Tod und der kostet das Leben. Wenn man es gut machen will, nimmt man einen S3 Hoster oder macht den S3 Cluster selbst an mehreren Orten. Ein Problem des S3 Backups könnten ACL Permissions sein. Die landen nicht so ohne weiteres im S3 Backup.

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

Problem kann es mit jeder Software geben. Meist sind aber Daten gut, kann man ja mit dem unabhängigen Tool Restic Browser testen (Ich werde wohl auf das Multi-OS CLI Tool Restic setzen).

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.

Rsync ist local schnell, nicht so sehr bei großen Internet Backups - möchte ich nicht nutzen, sondern Restic das auch deduplizierung beherrscht. Da dauert das erste Backup etwas länger, Folgebackups sind dafür erheblich schneller, auch ein teilweiser Restore sollte sehr schnell sein. Die grundsätzliche Verschlüssellung bei schwacher Hardware bremst eventuell. Mit dem unabhängigen Restic Browser kommt man direkt an die Daten, ist eventuell etwas langsamer.

PS2: Hast du eigentlich schon einmal die Wiederherstellungs Mittels kopia von Remote getestet?

1S3 Backup Ist bei mir momentan noch Proof of Concept Phase. Wie integriert man 1S3 Backup/Restore mit einer ZFS web-gui am sinnvollsten wenn man gleichzeitig von Amazon S3 und minIO wegwill - hin zu restic und einem S3 Hoster oder inhouse mit einem minIO Ersatz wie RustFS (einfacher, resourcenschonender und einer offenen Lizenz).

 

[Whistl0r]

1S3 heißt ja nicht, dass nur eine Kopie auf S3 liegt. Jeder kommerzielle S3 Dienst ist als Hochverfügbarkeits Cluster konfiguriert, bei dem die Daten selbsständig im Cluster repliziert werden. Privat oder Inhouse hat man die Option, nur einen einfachen S3 Server zu nutzen oder auch mit mehreren einen Cluster zu bilden, der automatisch die Daten mehrfach hält, inkl. Versionierung so wie lokale ZFS Snaps. Der manuelle Aufwand des 321 Verfahrens entfällt.

[...]

Redundanz bei S3 erfolgt auf Node Ebene, auch mit einfacher Hardware. Fällt ein Node aus, arbeitet der Cluster weiter.

Ich glaube du hast meinen Punkt nicht verstanden. Mit dieser Argumentation könnte man sich auch ein einzelnes Storage-System schönreden. Von wegen, "Das besteht aus mehreren Nodes, Controllern, whatever... ist also redundant... da passiert nichts".
Kann man alles so machen. Aber das zeigt dann nur, dass man entweder den Kern hinter der 3-2-1 Strategie nicht verstanden hat bzw. es dir nie darum ging bzw. zukünftig nicht mehr darum gehen wird.

Bei der 3-2-1 Strategie ist der Hauptgedanke/Hauptanspruch, dass du drei physisch komplett unabhängige Kopien deiner Daten hast. Damit, vereinfacht gesagt, das täglich genutzte Storage ausfallen kann und während du vom eigentlichen Backup wiederherstellst auch einen Ausfall des vermeintlichen Backup-Storages überstehst.

In der Praxis sind die ersten beiden Kopien, also der Ort wo die Daten täglich verwendet werden und auch wo sie täglich als Sicherung abgelegt werden, meistens am gleichen Ort. Jetzt braucht es aber nur ein Feuer, eine Naturkatastrophe, teilweise nur einen Blitzvolltreffer oder einen Ransomeware-Incident um diese beiden Kopien mit einem Schlag unbrauchbar zumachen. Und in dem Moment hilft dir dann die dritte Kopie an einem ganz anderen Ort.

Ich bezweifle stark, dass du ein Ceph, S3 oder was auch immer mit 3 Nodes an verschiedenen Orten betreiben wirst. Das ist illusorisch. Es gibt Gründe wieso das niemand macht. Der nennt sich Latenz. Und selbst wenn du das wirklich machen würdest hast du eben nicht wirklich 3 völlig unabhängige Kopien: Wenn dir auf einer Node eine Datei kaputt geht, repliziert sich diese Änderung im Idealfall auf alle anderen Nodes und du hast jetzt 4 unbrauchbare Kopien (das "Original" + die 3 Kopien von deinen S3 Nodes).

Ein Problem des S3 Backups könnten ACL Permissions sein. Die landen nicht so ohne weiteres im S3 Backup.

Hier geht man hin und erstellt unter Windows bspw. mit icacls oder unter Linux mit getfacl ein Textfile in welchem die ACLs gespeichert sind was selbst wiederum normal gesicht wird.

Problem kann es mit jeder Software geben. Meist sind aber Daten gut, kann man ja mit dem unabhängigen Tool Restic Browser testen (Ich werde wohl auf das Multi-OS CLI Tool Restic setzen).

Ich fürchte, auch hier konntest du mir nicht folgen. Selbst wenn ich meine Daten in vermeintlich einfache ZIP-Archiven ablege (das Windows Backup hat dies ja einmal so gemacht) ist das bereits ein Komplexitätslayer der Probleme machen kann. Und wenn wir von Dateien sprechen, sprechen wir irgendwann unweigerlich von Bitrot/CRC Fehlern. Und nein, dem kann man nicht damit begegnen indem das jeweilige Backup-Programm von Haus aus Reed-Solomon oder ähnliches unterstützt. Wieso nicht? Schau' dir an was genau passiert, wenn eine Datei kaputt geht. Nutzt du NTFS wird also ein kompletter Cluster (Standardmäßig 4KB, kann aber größer sein) ausfallen. Wenn diese 4KB an der falschen Stelle fehlen, ist mitunter das gesamte Archiv/Chunk kaputt. D.h. du bist zwar irgendwie etwas geschützt, aber nicht wirklich. Und genau das ist nicht der Sinn von einem Backup. Ein Backup muss vorhersagbar und verlässlich sein.

Rsync ist local schnell, nicht so sehr bei großen Internet Backups

Auch hier scheinst du mich nicht verstanden zu haben. Dein Restic/kopia legt irgendwo das Backup ab (bspw. in D:\Kopia-Backup). In der kopia-Fachsprache wird der Ort "Repository" genannt. Dieses Verzeichnis, in dem jetzt die deduplizierten und meinetwegen komprimierten Chunks liegen (D:\Kopia-Backup) dupliziere ich in meinem Falle auf das Storage von rsync.net. Um die Verzeichnisse synchron zu halten verwende ich rsync. Ich verwende rsync nicht um das eigentliche Backup zu erstellen.
Analogie: Statt D:\Kopia-Backup hönnte ich das Backup auch auf der lokalen MinIO-Instanz ablegen. Statt rsync würde ich dann bspw. rclone nutzen um das lokale Bucket zusätzlich auf an einem anderen, entfernten Ort vorzuhalten.

Wenn du bislang die Wiederherstellung noch gar nicht getestet hast empfehle ich dir sehr, dich damit zu erst auseinander zusetzen bzw. mit allem was essentiell ist, bevor du dich um Quality-Of-Life Verbesserungen wie kümmerst. Denn wenn das Konzept an sich schon nicht aufgeht, weil bspw. die Mean Time To Recover zu hoch ist, interessiert der Rest nicht mehr.


PS: Von welchen Datenmengen sprechen wir eigentlich, die du mit deinem Konzept sichern möchtest? GB? 1-5TB? 50TB? 100TB? Und wie häufig ändern sich die Daten?

 

[gea]

Jeder kommerzielle S3 Hoster realisiert Backup Verfügbarkeit mit einem Cluster, vielleicht nicht so extrem wie Amazon mit seinen vielen regionalen Standorten. Latenz ist meist nicht das Problem, es sei denn wegen der eigenen Internet Anbindung. Die Daten liegen regional und werden mehrfach in verschiedenen weiteren lokalen Rechenzentren an anderen regionalen Orten repliziert. So ein Rechenzentrum darf ohne Datenverlust abbrennen.

Ein eigener lokaler miniOS oder RustFS Cluster via LAN oder Internet muss ja nicht großräumig verteilt sein, unterschiedliche Gebäude ist auch schon etwas damit eine Kopie bei einem Großbrand erhalten bleibt. S3 ohne Clusterreplikation geht auch, ist halt ein einfaches Backup im Lan oder Internet ohne Redundanz.

Datenmenge und Backup/Restorezeit stehen natürlich in einer Beziehung zur Netzwerk Leistungsfähigkeit. S3 an sich hat keine Limits und Deduplizierung sorgt dafür dass nur der erste Lauf länger dauert. Bei meinen bisherigen Tests mit minIO war S3 ultra schnell. RustFS sollte eher schneller sein, muss man noch etwas abwarten, da noch 1.0 Beta.

Wenn man 2x lokale und n mal S3 Kopien im Lan oder Internet will, kann man 12S3 machen (1. lokale Originaldaten +2. lokale Backup Kopie + 3. einzelnes S3 Lan/Internet Backup oder n mal S3 mit Cluster). Mit ZFS Replikation bleiben ZFS properties und ACL erhalten.

 

[Whistl0r]

Sind dir "Regionen" oder "Zonen" bei Cloudbetreibern ein Begriff? Angenommen du erstellst ein S3 Bucket bei AWS in der Region eu-central-1 (Frankfurt) dann kannst du dir das vereinfacht so vorstellen, als wenn da ein einziges Rechenzentrum irgendwo in Frankfurt steht, was von Amazon genutzt wird, und da stecken jetzt 3 Server im gleichen Rack auf dem dein Bucket liegt. Jetzt kannst du dir selber ausmalen wie "sicher" das ist. Wenn jetzt die PDU des Racks sich verabschiedet sind alle 3 Nodes offline. Mit etwas Pech sind sogar die Server komplett hin. Oder wenn in diesem Bereich eben ein Feuer ausbricht... Das ist jetzt stark vereinfacht. Sehr wahrscheinlich werden die Nodes nicht im gleichen Rack sein und auch eu-central-1 besteht nicht nur aus einem physischen Gebäude (=Datacenter). Und dennoch: AWS sagt dir: Sind dir deine Daten wichtig, dann buche bitte Geo-Redundanz, d.h. mehrere Regionen. Dann macht AWS genau das, wovon ich die ganze Zeit spreche: Die Daten liegen auf mehreren physisch und logisch komplett getrennten, unabhängigen Instanzen (Cluster).

Sehr viele Firmen die in die Cloud gehen und ihr Zeugs nur in einer Region haben erleben über kurz oder lang, dass das ein Fehler ist. Die reden sich genau wie du ein, dass die Services ja auf hoch redundanten Systemen betrieben werden... wozu also für zwei Regionen zahlen?


Das Thema Latenz scheinst du überhaupt nicht zu verstehen. Mich würde dein Hintergrund tatsächlich interessieren. Wenn die einzelnen Nodes im gleichen Datacenter liegen, dann hast du da eine LAN-Umgebung mit traumhaften Latenzen. Selbst über die verschiedenen Gebäude in der gleichen Region hinweg wirst du noch 0.xer Latenzen haben, weil sie die Rechenzentren untereinander per Glasfaser direkt verbinden. Aber sobald keine direkte Verbindung mehr möglich ist, sieht es ganz anders aus.

Und in deinem Beispiel sprichst du ja davon bei Freunden/Familie zu hosten. Ich nehme jetzt einmal an, dass ein kompletter "Cluster" (die 3 Nodes von denen du immer sprichst) nicht bei einem einzigen Freund stehen wird (dann hättest du ja wieder ein Problem wenn dessen Haus abbrennt). Dass du vor hattest die Nodes an unterschiedlichen Orten zu betreiben. Und genau dann hast du plötzlich mit Latenzen zu kämpfen die richtig reinhauen.

Datenmenge und Backup/Restorezeit stehen natürlich in einer Beziehung zur Netzwerk Leistungsfähigkeit. S3 an sich hat keine Limits und Deduplizierung sorgt dafür dass nur der erste Lauf länger dauert.

Ich muss es so deutlich sagen: Du scheinst in meinen Augen überhaupt kein tieferes Verständnis von der Materie zu haben. Lies' dir mal Dinge wie https://github.com/kopia/kopia/issues/5113 durch. Da erfährst du etwas über die tatsächlichen Probleme.

Restoring a 400GB VM disk from S3 storage:

• Current speed: ~5-6 MB/s
• Expected speed: 50+ MB/s (based on available network bandwidth)
• Estimated restore time: ~16-18 hours for a single VM disk
• CPU/Memory utilization: Low (~30%) — not the bottleneck

The bottleneck is sequential chunk fetching: each ~4MB chunk requires a separate HTTP request to S3. With ~100,000 chunks and ~50ms latency per request, the latency alone accounts for ~5,000 seconds of overhead.

Verstehst du irgendeinen Teil dieser realen User-Erfahrung? Weißt du warum die modernen Backup-Lösungen standardmäßig eine recht geringe Chunk-Größe zu wählen? Verstehst du den Hintergrund wieso prinzipiell empfohlen wird, diese bei der Verwendung von Blob Storages zu erhöhen? Verstehst du aber gleichzeitig die Konsequenzen? Die Auswirkungen auf die De-Duplizierung bzw. Effektivität? Was dies für Daten/Anwendungen bedeutet wo du Effektivität durch Change Block Tracking erzielst? Ist dir bewusst, dass die hier beobachten ~50ms, die bereits signifikant zum Problem beitragen eigentlich ein recht guter Wert sind den du selber wahrscheinlich nicht erreichen wirst außer du hast ein direktes Peering mit dem Anbieter deines Blob Storages?

Du scheinst mir ein bisschen sehr blauäugig/naiv unterwegs zu sein...

Wenn man 2x lokale und n mal S3 Kopien im Lan oder Internet will, kann man 12S3 machen (1. lokale Originaldaten +2. lokale Backup Kopie + 3. einzelnes S3 Lan/Internet Backup oder n mal S3 mit Cluster).

Ja, aber der Ausgangspunkt war deine Aussage, deine 1-S3 Strategie als modernen Nachfolger der 3-2-1 Strategie zu positionieren. Das impliziert für mich, dass die Strategie mindestens ebenbürtig ist und eigentlich irgendwelche Vorteile/Verbesserungen bieten sollte. Genau dies ist aber nicht der Fall. Wie von mir ausgeführt reduzierst du die effektive Anzahl an Kopien. Stattdessen argumentierst du damit, dass so ein Blob-Storage ja einen Cluster bedingt und du damit mindestens 3 Nodes hättest (quasi 4 Kopien). Und das ist eben völliger Unfug. Selbst wenn du bei den Teil mit einer zusätzliche Kopie pro Node Recht hättest (was einfach nicht stimmt) wären dies keine zur 3-2-1 Strategie ebenbürtige Kopien, da sie weder logisch noch physisch voneinander getrennt sind.

 

[gea]

Wir können noch lange diskutieren, dass wir Dinge anders sehen. Ist ja auch egal. Backup per S3 ist Stand der Technik für (LAN)/WAN/Internet basiertes Backup, egal ob privat und einem Single Node, Single Disk S3 Server oder als Firma oder Hoster ab 4 Servern im hochverfügbaren Multi Node, Multi Disk Setup bei der nicht nur mehrere Platten sondern auch ein kompletter Server ohne Datenverlust ausfallen darf (an einem oder unterschiedlichen Standorten), siehe eine Default Installation bei OpenSource RustFS, ist identisch zu minIO, der bisher meist genutzten inhouse Amazon S3 Alternative, https://docs.rustfs.com/installation/linux/multiple-node-multiple-disk.html. Kann man weiter skalieren damit mehrere Server an mehreren Standorten gleichzeitig ausfallen dürfen, bei Amazon sogar komplette Rechenzentren, nur eine Frage des Aufwands und der Finanzen.

321 bedeutet 3 Kopien, 2 auf weiteren Datenträgern und eine davon extern. S3 bedeutet n Kopien auf x redundanten Servern an y Standorten, ohne dass man das selber organisiere muss, Replikation ist quasi eingebaut - je nach Aufwand den treiben möchte oder ob man das einfach bei einem S3 Hoster mietet, https://shop.plusserver.com/blog/s3-object-storage-kostenvergleich

Performance: https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-performance.html

 

[Whistl0r]

S3 bedeutet n Kopien auf x redundanten Servern an y Standorten, ohne dass man das selber organisiere muss, Replikation ist quasi eingebaut - je nach Aufwand den treiben möchte oder ob man das einfach bei einem S3 Hoster mietet,

Einfach NEIN.

Erst einmal ist S3 kein standardisierter Begriff wie bspw. ein RAID-Level. S3 ist ein reiner Produktname von Amazon. S3 bezieht sich dabei auch nicht die Anzahl der Nodes oder ähnliches. Der vollständige Produktname lautet Amazon Simple Storage Service und S3 ist hierbei lediglich die Abkürzung ("Der Dienst mit den drei S").

Anbieter wie MinIO, Cloudflare mit R2, Google mit GCS, Backblaze mit B2 oder eben das Angebot von Plusserver haben lediglich die gleiche API die Amazon ursprünglich für ihren Simple Storage Service entwickelt und implementiert hat. Oder anders formuliert: Sie haben die API von AWS S3 kopiert!

Daher gibt es formal keinen einzigen S3-Dienst außer AWS Simple Storage Service. Alle anderen darf man lediglich S3-kompatibel nennen. D.h. wenn du eine Software entwickelt hast wo du bislang AWS S3 verwendet hast kannst du einfach den AWS S3-Dienst durch MinIO, Cloudflare R2, Google Cloud Storage usw. austauschen ohne deinen Quellcode anfassen zu müssen.

Bzgl. AWS S3 behauptet Amazon lediglich, dass der Dienst innerhalb jeder Region auf 3 Availability Zones aufgeteilt ist, siehe https://aws.amazon.com/s3/storage-classes/:

S3 stores data redundantly across a minimum of 3 Availability Zones by default, providing built-in resilience against widespread disaster. Customers can store data in a single AZ to minimize storage cost or latency, in multiple AZs for resilience against the permanent loss of an entire data center, or in multiple AWS Regions to meet geographic resilience requirements.

Daher mag deine Aussage mit den 3 Nodes kommen. Das war aber nicht immer so: Bis Dezember 2017 (Launch von Paris) war es üblich, dass AWS neue Regionen mit 2 AZs eingeführt hat. Seit Paris gehen neue Regionen nur noch mit mindestens 3 AZs an den Start. Die obige Aussage findet sich übrigens erst seit April 2018 auf der AWS-Internetseite.
Der Absatz enthält aber sogleich noch einen anderen wichtigen Satz, "Customers can store data in a single AZ to minimize storage cost or latency". D.h. wo ich noch ausführte, dass AWS ihre Rechenzentren (AZs) untereinander in einer Region via Glasfaser verbunden haben und vermutlich keine Latenz-Probleme hat, warnt bzw. empfiehlt AWS selber, dass man für bessere Latenzen besser auf die Redundanz in einer Region verzichten sollte. Soviel zu dem Thema.

Ob alle anderen Anbieter von S3-kompatiblem Storage auf eine ähnliche Architektur (mind. 3 Availability Zones) wie AWS setzt, darf bezweifelt werden: Schaut man sich alleine an wie die Rechenzentren von Backblaze aussehen, dann haben sie gar nicht diese Möglichkeiten. Sicherlich werden sie innerhalb eines Datacenters (=einem physischen Gebäude), verschiedene Brandabschnitte etc. haben und hoffentlich die Nodes entsprechend verteilt haben. So ein Setup ist aber überhaupt nicht mit der Architektur von Amazon's Availability Zones vergleichbar, wo jede AZ eben ein eigenes Rechenzentrum (=Gebäude) ist, die jeweils mehrere Kilometer voneinander getrennt sind.

tl;dr
Die Aussage, dass "S3" impliziere, Daten seien als n Kopien auf x Sever an y Standorten verteilt, ist nicht korrekt. Der Begriff "S3" wird im Alltag als Gattungsbegriff verwendet, bezieht sich aber ausschließlich auf eine zu AWS S3-kompatible API.
Aus der Bezeichnung "S3" kann man des Weiteren keine verlässliche Aussagen über die tatsächliche Architektur, Redundanz oder Datenverteilung ableiten. Im Gegensatz zu klar definierten Konzepten wie RAID-Levels ist "S3" kein standardisierter Begriff mit eindeutig festgelegten technischen Eigenschaften.

 

[tolga9009]

Backup per S3 ist Stand der Technik für (LAN)/WAN/Internet basiertes Backup, egal ob privat und einem Single Node

Das halte ich für eine gewagte These. Enterprise ist klar. Aber im privaten Bereich kenne ich kaum jemanden, der S3 nutzt. Wichtiger als das Backend ist meiner Meinung die Backup-Software selbst; wie wird mit Konflikten umgegangen? Wird Uni- oder Bi-Directional synchronisiert? Sind asynchrone Workflows möglich (Extrembeispiel: kann ich im Flugzeug arbeiten?)? Ob das Backend nun ein Synology mit BTRFS, ein Nextcloud, ein TrueNAS mit ZFS oder eben S3 Storage bei Amazon ist, ist zunächst unerheblich.

siehe eine Default Installation bei OpenSource RustFS, ist identisch zu minIO, der bisher meist genutzten inhouse Amazon S3 Alternative, https://docs.rustfs.com/installation/linux/multiple-node-multiple-disk.html.

RustFS könnte ich nicht trauen. Das Projekt wirkt leider sehr stark vibecoded. Einmal steht CVE-2025-68926 im Raum mit hardcoded Tokens (ist inzwischen gefixt, hinterlässt aber einen faden Beigeschmack). Und dann grüßt einem auf der "About Us" Seite (https://docs.rustfs.com/about/) dieser Handschlag mit einmal 6 und einmal 4 Fingern:

Wenn man sich bei so einem Bild auf der "About Us" Seite schon keine Mühe gibt, wie sieht dann der Code aus, den die meisten User niemals zu Gesicht bekommen werden? Finde ich schon sehr unprofessionell für ein Projekt, das sich vorgenommen hat, eine Industriegröße wie MinIO ersetzen zu wollen.

MinIO gibt es ja auch nicht mehr; das wurde von den Eigentümern beerdigt, um im KI-Zeitalter mit AIStor auch was vom KI-Kuchen abzubekommen. Da hoffe ich noch auf einen Fork, der MinIO würdevoll weiterführt - d.h. ohne ahnungsloses Vibecoding. Optimalerweise unter dem Dach der Linux Foundation oder Apache. Garage sieht noch interessant aus und eignet sich meiner Meinung nach bisher am besten als MinIO-Nachfolger; dafür ist es aber noch zu früh.

Fazit: S3 ist etabiliert im Enterprise, keine Frage. Da kommen auch völlig andere Stacks und Anbieter zum Einsatz. S3 im privaten Gebrauch halte ich aber (zumindest in der aktuellen Lage) für einen Irrweg. Bis die Community sich auf einen würdigen MinIO-Nachfolger geeinigt hat, bleibt das Thema self-hosted S3 (im Privatbereich) schnelllebig und spannend. Das Thema Backup sollte hingegen stabil und langweilig sein.

 

[scooter010]

Nextcloud, persönliche ordner sind per MP in die docker-VM in den docker durchgereicht. Gleiches mit shared foldern. Host macht regelmäßige zfs snap + incrementelles raw (zum Erhalt verschlüsselung) zfs send|zfs receive. Es gibt ein lokales nicht verschlüsseltes Ziel und ein remote verschlüsseltes Ziel. Fertisch.

 

[Dreifach-Opa]

Hallo, hier scheint es ein grundsätzliches Problem mit der Verständlichkeit zu geben. Die Frage war:

Habt ihr schon mal Daten verloren?​

Es geht hierbei nicht um irgendwelche Backups von kompletten Rechnern und Betriebssystemen, sondern nur um die damit erarbeiteten Daten. Daten - Dateien! Es wäre ein unersetzbarer Verlust, diese zu verlieren!

Nur diese sind mir wichtig, Rechner / Betriebssysteme etc. sind schnuppe und jederzeit ersetzbar. Und damit zu meinem Konzept: Ja, es scheint für manchem etwas aufwändig, aber ich synchronisiere meine Daten mit dem Total Commander regelmäßig auf mehrere externe Datenträger und verteile sie damit auf meine anderen Rechner.

Ansonsten empfehle ich, die 3-2-1 Regel zu überbieten. Bei mir liegt übrigens ein Datenträger in einem 6 Zentner schweren Gußkessel, dieser würde auch einen Atomschlag (EMP) überstehen.

ps: ich bin noch im Besitz aller Daten seit 1992, damals noch unter Windows 3.1
Grüße

 

[gea]

Fazit: S3 ist etabiliert im Enterprise, keine Frage. Da kommen auch völlig andere Stacks und Anbieter zum Einsatz. S3 im privaten Gebrauch halte ich aber (zumindest in der aktuellen Lage) für einen Irrweg. Bis die Community sich auf einen würdigen MinIO-Nachfolger geeinigt hat, bleibt das Thema self-hosted S3 (im Privatbereich) schnelllebig und spannend. Das Thema Backup sollte hingegen stabil und langweilig sein.

Wann ist S3 gut?

Wenn Google das intern macht oder Telekom das mit Amazon macht, oder mit Hetzner oder Ionos und was es sonst noch an S3 Anbieter in DE gibt für unter 10 Euro/TB. Ist es schlecht wenn es Inhouse mit minIO gemacht wird?

Welches Produkt MinIO wegen der Lizenzprobleme beerben wird, ist noch offen, das ist aber eher unerheblich, da schnell austauschbar. RustFS ist eine heiße Option, ist aber erst beta, dauert noch bis man das produktiv einsetzen sollte.

S3 Backup in der Cloud oder im LAN, mit oder ohne automatische Redundanz damit ein kompletter Node ausfallen darf, ist auf jeden Fall spannend und meiner Ansicht nach die Zukunft für Backup, nicht nur für die Top 500. Jedes bessere NAS bietet zunehmend S3.

 

[mchawk777]

Die Frage war:

Habt ihr schon mal Daten verloren?​

Du solltest nicht bei der Hälfte des Titels aufhören zu lesen. 🤷‍♂️

 

[Boimler]

Ansonsten empfehle ich, die 3-2-1 Regel zu überbieten. Bei mir liegt übrigens ein Datenträger in einem 6 Zentner schweren Gußkessel, dieser würde auch einen Atomschlag (EMP) überstehen.

Würde die HDD in einem ESD-Beutel auch oder soll der Gußkessel dafür sorgen, dass die Platte übrig bleibt, wenn die Stadt drumherum nicht mehr existiert ?

 

[MaverickM]

Nur diese sind mir wichtig, Rechner / Betriebssysteme etc. sind schnuppe und jederzeit ersetzbar.

Schön für dich. Aber wenn ich mindestens einen halben bis ganzen Arbeitstag damit verschwenden muss, meinen Arbeitsplatz wieder so einzurichten, wie ich ihn zum Arbeiten brauche, ist das zumindest mir ganz sicher nicht Schnuppe.

Ein Image-Backup ist in 15 Minuten wieder zurück gespielt und ich kann weiter arbeiten.

 

[Dreifach-Opa]

mchawk777, Boimler, MaverickM,​

Danke für Eure kritischen Anmerkungen.
@mchawk777:
Ich habe nicht nur die Hälfte des Titels gelesen, sondern den gesamten. Lies meinen Beitrag bitte komplett durch, und Du erkennst, wie ich mich präventiv vor Datenverlust schütze.

Du schaffst das.

@Boimler
Deinen Beitrag habe ich nicht so recht verstanden (Was soll ein ESD-Beutel, den Du erwähnt hast, sein?). Ich wollte in meinem Beitrag lediglich ausdrücken, dass einer meiner Datenträger EMP-sicher verstaut ist. EMP = Elektromagnetischer Impuls (siehe Wikipedia), da muss nicht gleich eine Kernwaffe auf meinen Ort fallen.

Grüße

@MaverickM
Tja, Du brauchst 15 Minuten, um weiterzuarbeiten? Ich brauche nur 2 Minuten, schmeiße den Reserverechner mit den fleißig synchronisierten Daten an und es geht weiter. Programme und Betriebssystem sind bei mir auf beiden identisch, Daten sind, wie gesagt, synchronisiert.

Wobei, wir haben sicherlich unterschiedliche Arbeitsprofile auf unseren Rechnern, ich bin ein alter Rentner, Du sicherlich noch im erwerbsfähigen Alter.

Liebe Grüße

 

[mchawk777]

Ich habe nicht nur die Hälfte des Titels gelesen, sondern den gesamten. Lies meinen Beitrag bitte komplett durch, und Du erkennst, wie ich mich präventiv vor Datenverlust schütze.

Jaja - schon gut - hier hastn Keks - alles gut.
(Fühlste Dich nicht ernst genommen? Nun, das hat einen Grund. End of line!)