System absichern mit btrfs snapshots

[tazinblack]

Hallo zusammen,

da ich mir gerade einen Rechner kaputt upgedatet hab würde ich hier gerne die best practices zum Thema btrfs snapshots diskutieren.

Hintergrund:

Es ist nicht das erste Mal bei mir, dass obwohl portage meint alles updaten zu können, der ganze Prozess irgendwo mittendrin auf die Nase fällt.
Im aktuellen Fall will portage gerne ~openssl-1.1.0j verwenden um die Updates machen zu können. Eigentlich nichts besonderes. Kommt schon mal vor, dass man ein Paket in der Testingversion installieren muss um von einem anderen Paket eine neuere Version installieren zu können. Also Genehmigung erteilt und die openssl Version in /etc/portage/package.keywords eingetragen. So, jetzt meint portage, dass alles ok ist und es geht los. Irgendwo zwischendrin, als dann python-3.4.8 reinstalliert werden soll fliegt einem dann das Ganze um die Ohren. Man hat also ein System welches Teilweise upgedatet ist. Manchmal kann man einfach das fehlerhafte Paket auslassen und weiterupdaten, dann geht das gut, manchmal geht das soweit, dass irgendwas nicht tut oder es nicht weitergeht. Das kann unwichtig sein, also irgendwas, das man selten braucht aber auch durchaus was Essentielles.
In meinem Fall startet die grafische Umgebung nicht mehr.

Ha, clever me. Zum Glück hab ich vorher einen Snapshot des rootfs angelegt. Dazu verwende ich ein einfaches Skript:

Code: Select all

#!/bin/bash
NOW=$(date +"%Y-%m-%d_%H:%M:%S")
 
if [ ! -e /mnt/backup ]; then
  mkdir -p /mnt/backup
fi
  
cd /
/sbin/btrfs subvolume snapshot / "/mnt/backup/backup_${NOW}"

So, sprich bevor ich was wildes mache und in regelmäßigen Abständen, führe ich kurz das Skript aus.
Zusätzlich muss ich mich natürlich drum kümmern, dass ich nicht endlos Snapshots rückwärts habe, da sonst irgendwann die Platte voll läuft. Außerdem dürfte es dann langsam werden. Also regelmäßig mal

Code: Select all

btrfs subvolume list /
ID 685 gen 260347 top level 5 path mnt/backup/backup_2018-12-27_20:51:42
ID 686 gen 260435 top level 5 path mnt/backup/backup_2018-12-30_18:29:49
ID 687 gen 260516 top level 5 path mnt/backup/backup_2019-01-01_19:02:27
ID 688 gen 260793 top level 5 path mnt/backup/backup_2019-01-10_09:02:07
ID 689 gen 261248 top level 5 path mnt/backup/backup_2019-01-11_11:53:00

und zum Löschen des ältesten hier im Beispiel

Code: Select all

btrfs subvolume delete /mnt/backup/backup_2018-12-27_20:51:42

Dann wird der benötigte Speicherplatz für die Änderungen wieder freigegeben.

So, will man jetzt auf Daten zugreifen, wie sie vor der Änderung waren, kann man das über den Pfad machen, wo der Snapshot gemountet ist.
Hier im Beispiel wäre das unter /mnt/backup/<Snapshot>.

Oder, wenn man das ganze System haben will, wie es vorher war einfach

Code: Select all

btrfs subvolume set-default 689 / 

oder mit

Code: Select all

btrfs subvolume set-default  /mnt/backup/backup_2018-12-27_20:51:42 

.

Damit wird beim nächsten mounten nicht die oberste Ebene (btrfs id 5) eingehängt, sondern der Snapshot. Bei einen Dateisystem z.B. für Daten könnte man jetzt einfach unmounten und neu mounten. Beim rootfs muss man neu booten und kommt damit raus auf dem System wie es vorher war.

In meinem Fall habe ich damit erst mal wieder ein lauffähiges System mit funktionierender grafischer Umgebung.

Leider fängt jetzt bei mir die Unwissenheit an. Klar könnte ich jetzt warten, bis das Problem im portage-tree gefixt worden ist, wieder auf dem defekten System booten und von einer Textconsole aus das Update fertig machen. So lange man seine Daten in einem extra Dateisystem ablegt ist das kein Thema. Unschön wirds, wenn man die aber im gleichen FS hat. Dann lebt man nicht so gerne innerhalb von dem Snapshot, da man die Änderungen an seinen Daten nachher nicht mehr hat.

Aus meiner Sicht gibts also die folgenden Möglichkeiten:

1.: Das defekte System booten (btrfs id 5), einen neuen Snapshot machen (für alle Fälle), per rsync die geänderten/neuen Dateien aus dem Snapshot von vor der Aktion rückgängig machen

2.: Auf dem Snapshot weiterarbeiten (so fern die Daten wo anders liegen). Wenn der portage-tree bzw. das Problem mit dem betroffenen Paket behoben ist das defekte System booten und reparieren

3.: Evtl gibts eine Möglchkeit, wie man btrfs anweist, den funktionierenden Snapshot weiterhin als Top Volume zu verwenden und den defekten Teil wegzuschmeißen.

Leider hab ich das bisher noch nicht so oft gebraucht. Was macht ihr an der Stelle? Hab ihr vielleicht einen besseren Ansatz?

Also, Tipps und Hinweise sind willkommen.

[musv]

Erstmal einen herzlichen Dank für das Tutorial. Ich hatte bisher nur https://btrfs.wiki.kernel.org/index.php ... #Snapshots als Anleitung. Das war für mich viel zu verwirrend. Deswegen hab ich bisher von BTRFS-Snapshots die Finger gelassen. Durch Deine kurze Anleitung hab ich's endlich kapiert.

Bei SLES konnte man irgendwie die Snapshots aus dem Grub heraus booten. Die haben dazu Snapper verwendet. Damit könntest du zumindest auf ein funktionierendes System umschalten, wenn du das aktive so zerschossen hast, dass du nicht mal mehr booten kannst.

[tazinblack]

Jap, snapper gibts ja auch im portage tree.
Wobei es mir reicht manuelle snapshots zu machen.
Und wie es aussieht wird das noch relativ wenig verwendet.
Ich finde es unkompliziert und auch der Mehrbedarf an Plattenplatz hält sich echt in Grenzen.

Bin gespannt, ob noch Ideen / Tipps kommen.

[bbgermany]

Guten Morgen,

ich hoffe Ihr hattet alle ein schönes WE. Nun aber zum Thema:

Ich verwende zwar kein BTRFS aber Backups mache ich regelmäßig (jede Nacht). Ich zwar habe primär AMANDA im Einsatz, aber um ein paar Einzelverzeichnisse zu sichern nehme ich gerne tar. Als Verbesserungsvorschlag könnte ich hier "anbieten", wenn man das Script vielleicht automatisieren möchte, die Uhrzeit weg zu lassen und dann das ganze via Cronjob zu starten. Damit dann die Platte nicht mit Snapshots zuläuft, noch die gewünschte Anzahl an Snapshots definieren mit einem "${NOW}-X Days" und das dann an den subvolume delete Job im Anschluss an das Backup übergeben:

Code: Select all

#!/bin/bash 

# your settings
DESTDIR="/mnt/backup"
SOURCE="/"
BACKUPCOUNT="14"

# define backup dates
NOW=`date +'%Y-%m-%d'`
OLD=`date --date="$date-${BACKUPCOUNT}days"+ '%Y-%m-%d'`
  
# check for backupdir and create one...
if [ ! -e ${DESTDIR} ]; then 
  mkdir -p ${DESTDIR} 
fi 

# run actual backup
/sbin/btrfs subvolume snapshot "${SOURCE}" "${DESTDIR}/backup_${NOW}"

# delete old backups
if [ -e ${DESTDIR}/backup_${OLD} ]; then
  /sbin/btrfs subvolume delete ${DESTDIR}/backup_${OLD}
fi

Multi-Source ist jetzt noch nicht dabei aber das könnte man ja auch als Variable übergeben, um das Script allgemeiner zu machen.

MfG. Stefan