Private Backup-Strategie

[HumiNi]

Da ich das andere, wichtige Thema viewtopic.php?t=188525&start=75#p1347671nicht zerfleddern will, setze ich hier fort.

Ohne auf dir rumhacken zu wollen: dein Backup sollte im Optimalfall dagegen resilient sein, wenn es das Risiko nicht tragen soll. In dem Fall ists meins auch nicht, weil ich das zu sichernde System selbst auf das Dateisystem zugreifen lasse, wie vermutlich die meisten hier. Ist halt wie immer ne Abwägung, gegen welche Probleme du geschützt sein willst. Ich hab auch kein offsite-Backup.

Das ist schon klar: Aufwand und Nutzen.

Während meiner beruflichen Tätigkeit waren auch Ausfallsicherheit (Cluster) und Disaster Recovery mein Thema.
Meine Strategie für meine/unsere privaten Daten geht aber trotzdem über ein einfaches Backup hinaus und hat sich so entwickelt (in Zeiten, in denen Speicherplatz - externer soundso - rar und teuer war.
Gesichert wird regelmäßig (täglich, beim shutdown, ...) innerhalb des lokalen Systems in mehrere Archive, wenn es Veränderungen im Datenbestand gab. Dies möglichst auf separate HD (Desktop-Systeme) in mehrere Backup-Generationen.
Zusätzlich gibt es ein Archiv-Medium (früher eine manuell zu verbindende USB-HD, heute einen raspi mit Archiv-Speicher, der nach jedem Backup angestoßen wird, sich die letzten Archive abzuholen und sich danach wieder versteckt - als einfachen Schutz vor ungewolltem Zugriff).
Als letzte Stufe werden die Backup der wichtigsten Daten regelmäßig auf CD/DVD geschrieben.

Das ist alles nicht kommerziell ausreichend, aber schützt für meinen Hausgebrauch ausreichend gegen Datenverlust
- bei Ausfall der Daten-HD
- bei Ausfall des Rechners
und man hat bei Datenverlust durch "das Problem sitzt vor dem Bildschirm" sofort Zugriff auf die letzten gesicherten Versionen - besonders hilfreich unterwegs mit Notebooks.

Heutzutage klaut kein Einbrecher einen 0815-PC oder ein einfaches Notebook.
Ich könnte mich mit meinem Konzept dagegen schützen, dass die Hütte abbrennt oder ein Flugzeug darauf fällt. Ich müsste die Archive und/oder Archiv-Medien nur extern (digital oder analog) lagern.

Die Backups/Archive sind natürlich nicht auf lebenslange Verweildauer (wegen regelmäßiger Löschung) konzipiert und auch nicht auf lebenslange Lesedauer (CD/DVD). Das ist mir klar. Aber versteckte Daten-Beschädigungen durch Kernel-/Filesystem-Bugs haben in meinen Überlegungen bisher keine Rolle gespielt.

[slu]

Aber versteckte Daten-Beschädigungen durch Kernel-/Filesystem-Bugs haben in meinen Überlegungen bisher keine Rolle gespielt.

Ja und das Problem geht ja noch weiter, wir haben z.B. verschiedene Festplatten Hersteller und Modelle um einem Bug in Hardware oder Software
zu "entgehen".

Es gibt leider so viele Möglichkeiten und immer wenn ein Konzept fertig ist findet man wieder ein Fall der nicht gut bedacht war.

[cosinus]

Aber versteckte Daten-Beschädigungen durch Kernel-/Filesystem-Bugs haben in meinen Überlegungen bisher keine Rolle gespielt.

Bei mir auch nicht. Obwohl irgendwo schonmal erwähnt wurde, dass jederzeit ein bisher unentdeckter Bug zB in ext4 zuschnappen könnte.
Sollte man also nun für diesen Fall für seine Backupplatten ein anderes Filesystem nehmen und nicht das, was das zu sichernde System hat, also idR ext4? macht btrfs für eine Backupplatte Sinn?

Und was machen wir wenn der nächste Käfer in den Kernel wandert und jedes Dateisystem schrottet?

[hec_tech]

Die erste Frage die man sich stellen muss: Was sind meine Anforderungen?

Im Privatbereich würde ich mir überlegen mit ZFS zu arbeiten und die Snapshots an einen anderen Standort schicken.

Sobald wir aber im Firmenumfeld sind muss man sich überlegen welche Werte für RTO und RPO akzeptabel sind.
Wenn ich RPO == 0 definiert habe brauche ich zwingend eine Geo redundante Lösung. Beispielsweise NetApp MetroCluster oder ähnliches.

Man muss hier aber natürlich wissen wieviel kostet eine Minute/Stunde/Tag Ausfall bzw Datenverlust und dies gegen die Anschaffungskosten zu rechnen.
Eventuelle Imageschäden kommen noch dazu.

In der heutigen Zeit würde ich auf SnapShot Sicherungen als Mittel der Wahl zurückgreifen. Anschließend die SnapShots auf einen Backup Standort transferieren.

[TRex]

Klingt doch schon recht gut - wenn du dir Dateien per pull durch den Pi holst, dann trifft dich auch der Bug hier nicht so schnell. Eventuell ist das Backup defekt, das könnte das zugehörige Tool aber vielleicht prüfen (kommt halt wieder drauf an, wie kaputt).

[jph]

Im Privatbereich würde ich mir überlegen mit ZFS zu arbeiten und die Snapshots an einen anderen Standort schicken.

ZFS ist auch nicht vor Fehlern gefeit: https://www.theregister.com/2023/11/27/ ... orruption/

[hec_tech]

Im Privatbereich würde ich mir überlegen mit ZFS zu arbeiten und die Snapshots an einen anderen Standort schicken.

ZFS ist auch nicht vor Fehlern gefeit: https://www.theregister.com/2023/11/27/ ... orruption/

Deswegen bleibe ich auch bei WAFL.

[jph]

Deswegen bleibe ich auch bei WAFL.

https://en.wikipedia.org/wiki/West_Aust ... all_League

Das meinst du sicher nicht. Was bedeutet „WAFL“?

[TRex]

Er meint wohl das hier: https://en.wikipedia.org/wiki/Write_Any ... ile_Layout

Proprietär, deswegen raus. Ein Bekannter von mir schwärmte auch von der RAID-Technik in QNAP... (nur, um das komplett verranzte System in Synology in Grund und Boden zu vergleichen)