Andy123Andy Die beiden Platten als btrfs aufgesetzt mit -draid0 -mraid0.
Wirklich als Raid0, oder nur Tippfehler? Raid0 bedeutet hier ja: eine Platte kaputt, alles kaputt.
Andy123Andy Die ganz wichtigen Daten werde ich wohl nochmal mit borg Backup oder sowas irgendwo hin kopieren
Seine Backups muß man so erstellen, daß man den Prozeß der Sicherung vollständig "versteht" und es einfach&praktikabel ist. Oftmals vergessen - aber eigentlich viel wichtiger - ist der Prozeß der Wiederherstellung, der ebenfalls "verstanden", am besten mal "geübt" und einfach&praktikabel sein muß.
Ich lege bei meinen Backups auf folgendes wert:
- kein proprietäres Ablageformat oder Zusatzprogramm notwendig, v.a. nicht zur Wiederherstellung von Gesamt- als auch Einzel-Dateien.
- Meine SIcherungen sollen ein ganz normales Dateisystem mit Einzeldateien sein, die ich mit jedem Kopier-/Editier-/Betrachter-Werkzeug ohne weiteres Zutun verwenden kann. Das schließt dann auch Archiv-Formate und v.a. evtl. komprimierte Formate aus.
- Ich möchte von fast allem "Generationen" von Sicherungen haben, also u.U. auf mehrere Versionen einer Sicherungsdatei zurückgreifen können. Und das möglichst platzsparend. Im Ablageort verwende ich also die Möglichkeit des "Hartverlinkens" von nicht geänderten Dateien (verglichen mit dem vorherigen Sicherungslauf), nur veränderte Dateien beanspruchen realen, zusätzlichen Sicherungsplatz.
- Meine Sicherungen haben einen Namen-Zeitstempel als Startverzeichnis, dortdrin ist dann der Inhalt der Sicherung. Ich bevorzuge eine Form, in der immer alle Dateien sichtbar unterhalb dieses Startverzeichnis wie im Original vorhanden sind. Ich also nicht meine "Wiederherstellung" für "Zeitpunkt X" aus unterschiedlichen Orten zusammensuchen muß. Das ermöglichen mir o.a. Hardlinks.
Ohne btrfs lief mein Backup über rsync, was mir das Alles geboten hat. Nicht-btrfs Dateisysteme behandele ich auch weiterhin so.
Bei btrfs (ähnlich wie bei zfs) schätze ich nun eben die Möglichkeit, daß im Dateisystem mittels send/receive zur Verfügung zu haben.
Beispiel mein btrfs Daten-Volume(vereinfacht):
/data
/data/doku/
/data/devel/
/data/@bilder
/data/@musik
Die mit @ hier markierten sind Subvolumes, da ich den Inhalt beim Erstellen eines Snapshots für /data nicht mit drin haben will. Für diese Subvolumes werden eigene Snapshots erstellt. Snapshots sind eine sehr elegante Möglichkeit eben eine Basis für die Sicherung eben genau für den Zeitpunkt X zu haben, da dessen Inhalt sich eben nicht mehr ändert.
Mein Backup läuft nun grob so ab:
Ich sende den/die Snapshots nun mittels btrfs send 2023-12-17_data an einen anderen Prozeß, der mittels btrfs receive /backupmedium/data diesen Datenstrom empfängt. /backupmedium ist ebenfalls ein btrfs-Volume, meine Backup-Platte(n).
Lokal kann das mittels Pipe geschehen:
btrfs send <quelle> | btrfs receive <ziel>
Übers LAN-Netz verwende ich einen TCP-Socket mittels netcat, also sowas wie:
btrfs send <quelle> | nc <remote_host_port> <-LAN-> nc -listen | btrfs receive <ziel>
Ein Komplett-Restore("Wiederherstellung") funktioniert nun umgekehrt.
Ich schätze also sehr diese Möglichkeit die sich durch Send/Receive innerhalb des Dateisystems realisieren lassen. Beim Senden verwende ich später den Modus incremental, was mir im Backup genau meine o.a. Anforderungen zur Ablage erfüllt.
Dieses Procedere ist IMHO auch effektiver, ressourcenschonender als rsync, da beim "Senden" zu keinem Zeitpunkt mit "Dateien" gearbeitet wird, sondern nur mit Datenstreams. Gerade beim Erstellen der Fileliste ist rsync deutlich "stressiger" als diese Variante, v.a. was die Quellen-Seite betrifft.
Snapshots als Funktion im Dateisystem sind also nicht nur hilfreich um "lokal" ggf. ungewollte Änderungen zu widerrufen, sondern eben auch eine Möglichkeit der Daten-Sicherung/-Wiederherstellung.