btrfs Backup und Rekonstruktion (via ssh) auf Leap 15.1

Hi allerseits,

ich dachte, ich habe hier ein "Standard-Szenario" und finde gute Anleitungen ... Irgendwie nicht.

Folgende Idee: Ich habe zwei Maschinen, auf deinen jeweils openSUSE Leap 15.1 läuft. Beide benutzen btrfs (außer für /home, aber das ist in diesem Kontext erstmal egal) in openSUSE's Standard-Konfiguration (Subvolumes für /var, /usr/local, /tmp, /srv, /root, /opt, /boot/grub2/x86_64-efi, /boot/grub2/i386-pc). Beide Maschinen benutzen Snapper - ebenfalls in openSUSE's Standard-Konfiguration. Sagen wir die eine Maschine ist eine Workstation, die andere ist ein Datengrab (Backup-System). Das Datengrab hat reichlich freien Platz - bisher unpartitioniert und unformatiert.

Die Workstation soll ihre Subvolumes und durch Snapper angelegten Snapshots via ssh in das Datengrab sichern. Ob als cron-job oder manuell ist mir für's erste egal. Mir geht es ums Prinzip. Interessant wäre für mich, wie ich das aufbaue, so dass ich im Falle eines sagen wir Defektes der betreffenden Festplatte in der Workstation das ganze möglichst effizient (schnell, einfach) wieder aus den Backups im Datengrab rekonstruieren kann. Sagen wir spaßeshalber einmal auf die gleiche, geplättete Festplatte in der Workstation und einmal auf eine neue, Ersatz-Festplatte in der Workstation.

Bisher hatte ich noch keinen Defekt und will auch keinen provozieren. Ich wäre aber sehr daran interessiert, das ganze mal "live" mit zwei virtuellen Maschinen durchzuspielen - also alles von Backup über "Defekt" bis zur Rekonstruktion. Wäre hier jemand daran interessiert, das ganze als Experiment einmal mit mir durchzugehen?

Ich habe vergleichbare Vorgänge schon erfolgreich mit ZFS durchlaufen und bin mir zumindest da mit Prozeduren und Terminologie sicher. btrfs hingegen hat ein leicht anderes Verständnis von Snapshots, Subvolumes und Mounten, was mich nach intensiver Lektüre von btrfs.wiki.kernel.org im Moment etwas ratlos zurücklässt :???:

Grüße, ~

Hi sme,

Ein aktives, d.h. sich veränderndes System als Backup-Lösung? Ich nehme an, daß alle Backups in einem separaten Subvolume @/backup landen sollen.

Subvolumes, und damit auch Snapshots sind an das physikalische Volume gebunden. Ein Kopierprogramm würde die gemounteten Snapshots auflösen und Redundanzen erzeugen. Das ist sicher nicht im Sinn einer späteren Wiederherstellung. Wenn du die Snapshots sichern willst, bleibt nach meiner Ansicht nur physikalisch zu kopieren, also dd.

Viele Grüße
Bequimão

Bequimão schrieb:

Ich nehme an, daß alle Backups in einem separaten Subvolume @/backup landen sollen.

Zum Vergrößern anklicken....

Richtig. Das, oder sogar ein separates (btrfs-) Dateisystem - je nach dem, was einfacher zu betreiben geht.

Bequimão schrieb:

Subvolumes, und damit auch Snapshots sind an das physikalische Volume gebunden. [...]

Zum Vergrößern anklicken....

Ist das nicht genau das, wozu man inkrementelles send/receive benutzt, siehe beispielsweise https://btrfs.wiki.kernel.org/index.php/Incremental_Backup?

Danke für den Hinweis! Btrfs send / receive war bisher nicht auf meinem Schirm. Bisher habe ich /root nur sporadisch gesichert, etwa vor Upgrades. Meine reguläre Sicherung enthält nur /home und Datenpartition (ebenfalls nicht btrfs).

Ich werde das mal mit einer externen Festplatte testen. Dein Szenario sollte funktionieren. Mir wäre im Moment der Aufwand mit einem Zweitsystem zu hoch.

Viele Grüße
Bequimão