Fortsetzung von : mx-linux-meine-persönliche-backup-strategie
Voraussetzung: mindestens 2 physikalische Laufwerke (3 und mehr schaden aber auch nicht ;-} )
Bei mir sind /root und /home NICHT getrennt, ABER bei mir sind die Verzeichnisse mit den Massendaten auf einer anderen Partition und werden während des starten in der etc/rc.local über "mount --bind" eingebunden.#!/bin/sh -e
#
# rc.local
#
#starte swap in zram
zramswap start
mount --bind /media/DATA/Apps /home/winnI/Apps/
mount --bind /media/DATA/Musik /home/winnI/Musik/
mount --bind /media/DATA/Bilder /home/winnI/Bilder/
mount --bind /media/DATA/Videos /home/winnI/Videos/
mount --bind /media/DATA/Downloads /home/winnI/Downloads/
mount --bind /media/DATA/temp_media /home/winnI/temp_media
mount --bind /media/DATA/tmp /home/winnI/tmp
# mount --bind /media/DATA/Dokumente /home/winnI/Dokumente/
exit 0
Die andere Variante die auch möglich ist, direkt in der fstab:
der relevante Teil sieht ähnlich aus /media/DATA/Apps /home/winnI/Apps none bind 0 0
Dadurch hat man alle "Platzfresser" schon mal aus der Sicht von mx-snapshot entfernt und bekommt ein relativ kompaktes Systembackup (Programme und Konfigurationen), dass bei mir immer noch auf einen 8GB Stick passt, während die Daten separat mit Grsync (oder was immer man persönlich bevorzugt) gehandhabt werden und z.B. auf die zweite Platte geschrieben werden. Für Backup Paranoiker wie mich geht dann der Weg weiter von dieser zweiten Platte auf mehrere externe Festplatten, je nach Umfang der Änderungen zwischen täglich (selten) bis 1x wöchentlich (fast immer).
/media/DATA/Downloads /home/winnI/Downloads none bind 0 0
/media/DATA/temp_media /home/winnI/temp_media none bind 0 0
/media/DATA/tmp /home/winnI/tmp none bind 0 0
/media/DATA/Musik /home/winnI/Musik none bind 0 0
/media/DATA/Videos /home/winnI/Videos none bind 0 0
/media/DATA/Bilder /home/winnI/Bilder none bind 0 0
Was sich im Forum und in FB als gelegentliches Problem herausgestellt hat: zu wenig/zu kleine USB Sticks.
Zu klein weist auf ein schlechtes Konzept hinsichtlich des "was sichere ich wie", mein root&home hat nach meinen Auslagerungsoptimierungen immer noch um 15-16GB was ein ~5GB snapshot.iso ergibt.
Zu wenig USB Sticks kann ich dagegen nachvollziehen. Oder auch die "falschen". Ich fühle mich einfach nicht wohl eine 5GB ISO auf einen 64gb oder 128GB Stick zu schreiben und 8-16GB habe ich inzwischen nur noch 2 (und eigentlich ist einer für die Musik im Auto ...)
Also eine praktikable Lösung muss her um zumindest die letzten 3-4 snapshots im Zugriff haben zu können.
Die gibt es tatsächlich, da man auch die Möglichkeit hat eine Iso direkt von der Platte zu starten und, was noch besser ist, man kann von dieser ISO aus auch installieren!. Einzige Einschränkung dabei: man kann NICHT auf der Platte installieren, auf der diese ISO liegt (Platte, nicht Partition, deswegen benötigt man auch mindestens 2 Platten)
Realisiert wird das über eine custom.cfg die man in /boot/grub ablegt.# custom.cfg file
# save under /boot/grub/custom.cfg
#
menuentry "ISO-Boot MX-snapshot-20221122_0825.iso" {
isopath=/iso/snapshot-20221122_0825.iso
bootoptions="kbd=de kbvar=nodeadkeys kbopt=caps:none lang=de tz=Europe/Amsterdam"
insmod ext2
insmod part_gpt
insmod part_msdos
insmod probe
insmod loopback
# use this to search for the full isopath
# search --no-floppy --file --set=root $isopath
# probe -u $root --set=buuid
# use this if you know the UUID XXX-XXX-XXX of the partition wich contains the isopath:
buuid=f9f19b93-0389-4b11-b878-70c32755f9de
search --no-floppy --fs-uuid --set=root $buuid
loopback loop $isopath
linux (loop)/antiX/vmlinuz buuid=$buuid fromiso=${isopath} $bootoptions quiet splasht nosplash
initrd (loop)/antiX/initrd.gz
}
der Inhalt ist "fast" selbsterklärend, wichtig sind eigentlich nur zwei Werte die man anpassen muss:
isopath=[pfad auf der Festplatte]
buuid=UUID der Festplatte
Bei mir eine 2TB Crucial auf der u.A. auch das Backup der Daten liegt.
Und schon hat man genug Platz für ein dutzend snapshots, oder halt für die Menge die man meint zu benötigen.
Meine Danksagung an die Entwickler von MX, die mir (mal wieder) bei der korrekten Syntax der custom.cfg geholfen haben