Barrios
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Hallo zusammen, ich war etwas experimentierfreudig und habe mein bisher unverschlüsseltes System auf LVM/ext4-Basis durch ein vollverschlüsseltes mit LUKS/LVM/btrfs ersetzt. Das ging nicht ganz so trivial über den Installer, Details für Interessierte finden sich hier. Bevor ich nun anfange an dem System rumzubasteln hätte ich gern eine gute Backupstrategie. Ich habe die Beträge hier im Wiki und im btrfs-Wiki gelesen und bin etwas erschlagen von den vielen Backuptools. Daher würde ich gern mein Partitionslayout skizzieren und meine Anwendungsbereiche beschreiben und hätte gern Rückmeldungen von den btrfs- und ggf. LUKS-Usern über deren Erfahrungen mit den verschiedenen backuptools. Früher habe ich von meinen LVM-volumes einfach tar-Pakete geschnürt, ich würde jetzt allerdings gern inkrementelle Backups auf einer externen HDD machen. Dazu schon die erste Frage: Hat es deutliche Vorteile diese auch auf btrfs zu formatieren? Mein physisches Systemlaufwerk ist eine SSD, darauf gibt es zuerst eine /boot/efi-Partition, dann eine /boot-Partition und als drittes den LUKS-Container, welcher mittels LVM in ein logisches /root- & ein /swap-volume aufgeteilt wurde. Das LVM-root-volume wiederum wurde dann unter btrfs in ein @(=root) & @home subvolume unterteilt, Details folgen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 | barrios@tuxedo:~$ mount | grep sda
/dev/sda2 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)
/dev/sda1 on /boot/efi type vfat (rw,relatime,gid=46,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
barrios@tuxedo:~$ sudo cryptsetup status /dev/mapper/sda3_crypt
/dev/mapper/sda3_crypt is active and is in use...
barrios@tuxedo:~$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root ubuntu -wi-ao---- 222,69g
swap ubuntu -wi-ao---- 9,00g
barrios@tuxedo:~$ mount | grep /dev/mapper/ubuntu-root
/dev/mapper/ubuntu-root on / type btrfs (rw,relatime,ssd,space_cache,subvolid=257,subvol=/@)
/dev/mapper/ubuntu-root on /home type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@home)
barrios@tuxedo:~$ sudo btrfs subvolume list /
ID 257 gen 5157 top level 5 path @
ID 258 gen 5157 top level 5 path @home
|
Soviel der Vorrede. Der Laptop wird überwiegend zur Programmierung genutzt, auch mit virtuellen Maschinen. Dazu die Frage: Sollte man auf einer SSD CoW für die VM-Datei ausschalten wegen der Fragmentierung oder ist das egal? Der VM Ordner sollte NICHT zusammen mit /home gesichert werden, bräuchte als ein eigenes subvolume, oder? Ich habe dieses subvolume-Layout entlehnt aus dem SysadminGuide im Auge:
| toplevel (volume root directory, not mounted)
+-- root (subvolume root directory, to be mounted at /)
+-- home (subvolume root directory, to be mounted at /home)
\-- VMs (subvolume?)
\-- snapshots (directory)
+-- root (directory) --> exklusive home?
+-- 2015-01-01 (root directory of snapshot of subvolume "root")
+-- 2015-06-01 (root directory of snapshot of subvolume "root")
\-- home (directory) --> exklusive VMs?
\-- 2015-01-01 (root directory of snapshot of subvolume "home")
\-- 2015-12-01 (root directory of snapshot of subvolume "home")
|
Was haltet ihr soweit davon? Welches tool würdet ihr benutzen, ich bin pythonaffin, könnte also auch gern ein Skript sein? Wichtig wäre mir, das sich root & home separat rückspielen lassen, falls ich z. B. mal wieder das Paketsystem schrotte. Auch ein kurzer Hinweis, wie ich die verschlüsselte Partition vom Live-Stick einbinde und dann ein Backup von einem subvolume rückspiele wäre toll. Vielen Dank schonmal im voraus!
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Barrios schrieb: Was haltet ihr soweit davon?
Passt meiner Meinung nach soweit alles.
Welches tool würdet ihr benutzen, ich bin pythonaffin, könnte also auch gern ein Skript sein? Wichtig wäre mir, das sich root & home separat rückspielen lassen, falls ich z. B. mal wieder das Paketsystem schrotte.
Da gäbe es mehrere Möglichkeiten. Wenn du voll auf btrfs setzen willst gäbe es send/receive, siehe hier. Aktuell wird für gewöhnlich BorgBackup empfohlen, und das möchte ich hier auch machen. Voll verschlüsselt, du bekommst volle Backups die dank Deduplizierung erstaunlich wenig Platz einnehmen, man kann das ganze sowohl in die Cloud/Server/Whatever als auch auf eine normale Festplatte schieben und selbstverständlich lässt sich das Tool sauber automatisieren. Oder man setzt auf tar-Dateien o.ä als Backup. Ich persönlich rate davon mittlerweile aber ab. Die Frage die ich noch an dich hätte: Musst du denn zwingend das komplette System sichern? Ich selbst sichere ausschließlich meine Home-Partition und die Liste aller installierten Pakete. Ein System ist relativ schnell wieder neu aufgesetzt, und dank Snapshots kannst du auch ganz easy einen älteren Stand booten, ohne auf ein Backup zurückgreifen zu müssen. Vorausgesetzt, man legt vor einem Upgrade einen Snapshot an. Und Backups solle man sowieso regelmäßig machen.
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
BorgBackup ist wohl exakt was ich suche. Inkrementell, deduplizierend, mountbar, verschlüsselbar, files einzeln wiederherstellbar, dazu noch schlank und komplett in der shell zu bedienen. Und als Krönung noch in Python3 implementiert 😊 Besser geht es nicht für mich, DANKE! Damit kann ich stow zum Verwalten meiner dotfiles auch gleich getrost entsorgen... Auch die Idee eine Liste der installierten Paket zu sichern ist großartig und so naheliegend, da hätte ich auch selbst drauf kommen können... Machst Du das so wie hier? Wenn ich dann noch die VMs und fetten IDEs mittels eigener subvolumes ausschließe, werden die inkrementellen Sicherungen wohl so winzig, dass ich die sehr engmaschig machen kann. Problem gelöst.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Barrios schrieb: BorgBackup ist wohl exakt was ich suche. Inkrementell, deduplizierend, mountbar, verschlüsselbar, files einzeln wiederherstellbar, dazu noch schlank und komplett in der shell zu bedienen. Und als Krönung noch in Python3 implementiert 😊 Besser geht es nicht für mich, DANKE!
Gern geschehen ☺
Auch die Idee eine Liste der installierten Paket zu sichern ist großartig und so naheliegend, da hätte ich auch selbst drauf kommen können... Machst Du das so wie hier?
Mehr oder weniger. Ich versuche nur diejenigen Pakete in einer Liste zu sichern, welche ich manuell installiert habe. Abhängigkeiten müssen nicht mitgesichert werden, da diese falls nötig ja sowieso automatisch mitinstalliert werden. Die Ausgabe von apt-mark showmanual ist dafür ganz praktisch, das einfach in eine Datei im Homeverzeichnis schieben und fertig.
Wenn ich dann noch die VMs und fetten IDEs mittels eigener subvolumes ausschließe, werden die inkrementellen Sicherungen wohl so winzig, dass ich die sehr engmaschig machen kann.
Subvolumes brauchst du dafür nicht. BorgBackup kennt den --exclude-Parameter, d.h. du kannst beliebige Dateien und Verzeichnisse vom Backupprozess ausschließen.
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Developer92 schrieb:
Ich versuche nur diejenigen Pakete in einer Liste zu sichern, welche ich manuell installiert habe. Abhängigkeiten müssen nicht mitgesichert werden, da diese falls nötig ja sowieso automatisch mitinstalliert werden. Die Ausgabe von apt-mark showmanual ist dafür ganz praktisch, das einfach in eine Datei im Homeverzeichnis schieben und fertig.
Ich bin auf so etwas ähnliches, nämlich apt-clone gestoßen.
Wenn ich dann noch die VMs und fetten IDEs mittels eigener subvolumes ausschließe, werden die inkrementellen Sicherungen wohl so winzig, dass ich die sehr engmaschig machen kann.
Subvolumes brauchst du dafür nicht. BorgBackup kennt den --exclude-Parameter, d.h. du kannst beliebige Dateien und Verzeichnisse vom Backupprozess ausschließen.
Ja, das habe ich auch bemerkt, geht genau wie mit tar. Ich habe zum testen mal die Systemdateien als Liste mit apt-clone gesichert, dazu noch /etc & /home mittels | tar -cp --lzma -f backup.tar.lzma
|
Das ganze sind auf dem frischen System <20Mb ☺ Das Rückspielen der Systemdateien und Usersettings funktioniert, das Rückspielen von /etc in der Vm leider nicht. 😐
Beim Testen in Virtualbox schmiert das System kurz nach Eingeben des LUKS-Passworts ab. Bis auf unterschiedliche Passwörter und die Größe der virtuellen HDD & swap ist eigentlich alles gleich. Ideen, woran das liegen kann? Sind in /etc low-level Einstellungen, sodass dies in der VM nicht testbar ist? Oder verändern die guest-additions /etc (die waren nötig für den shared folder)?
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Barrios schrieb: Sind in /etc low-level Einstellungen, sodass dies in der VM nicht testbar ist? Oder verändern die guest-additions /etc (die waren nötig für den shared folder)?
In /etc gibt es zumindest Dateien, die man nicht einfach so überschreiben sollte. Wenn überhaput, würde ich nur diejenigen Dateien in /etc sichern, die auch verändert worden sind.
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Ich habe jetzt den 1. Versuch mit borg gemacht, zuerst sichern mit:
| sudo apt-clone clone --with-dpkg-repack /media/barrios/...
sudo -s
borg create --compression lzma --exclude-caches --one-file-system -v --stats --progress -e /home/barrios/VirtualBox\ VMs -e /home/barrios/Downloads -e /home/barrios/shared /media/barrios/TOSHIBA\ EXT/borgbackups::'{hostname}-{now:%Y-%m-%d-%H%M%S}' /etc /usr/local /var /home
|
Dann restore in der VM via:
| sudo apt-clone restore apt-clone-state-tuxedo.tar.gz
sudo -s
borg extract --debug --list /media/sf_borgbackups::tuxedo-2017-12-30-151709
|
Developer92 schrieb: In /etc gibt es zumindest Dateien, die man nicht einfach so überschreiben sollte. Wenn überhaput, würde ich nur diejenigen Dateien in /etc sichern, die auch verändert worden sind.
Hier steht man solle /etc üblicherweise komplett sichern, jedenfalls verstehe ich es so?!? Wie sichert man denn nur die geänderten separat? Seltsam ist auch, das borg nicht alle Dateien rückspielt, z. B. nicht meine .vimrc. Ich finde sie, wenn ich das Archiv mounte, aber sie wird nicht rückgesichert??? Irgendwie scheint mir ein Vollbackup alles andere als trivial. Vielleicht mache ich dann doch erst mal eines mit clonezilla oder btrfs send oder so... 😐
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Barrios schrieb: Hier steht man solle /etc üblicherweise komplett sichern, jedenfalls verstehe ich es so?!?
Ich würde das anders interpretieren. Einfache Frage: Wie sieht dein Backupplan aus? Bzw. besser: Was muss dein Backp wirklich können? Ich halte es für mich so, dass ich /etc nicht sichere (und auch nicht sichern will), weil ich es für sinnlos erachte. Sollte irgendwann einmal mein Rechner abrauchen, dann installiere ich eine beliebige Distribution und stelle meine persönlichen Dateien wieder her. Alles, was in /etc und sonstwo lag ist für mich nicht relevant. Das sind System- bzw. Konfigurationsdateien, mehr nicht. Die sind für mich absolut irrelevant. Relevant sind für mich nur meine persönlichen Dateien, meine Erinnerungen, Fotos, Videos, Texte, Steuerunterlagen. Ich würde auch nicht alle installierten Programme aus der Liste automatisch wieder installieren lassen. Häufig sammelt sich da Software, die man gar nicht mehr braucht. Sollte bei mir einmal das System abrauchen gehe ich die Liste händisch durch, und installiere die Programme auch händisch, weil ich dann wieder ein schönes, schlankes System habe. Du kannst /etc natürlich trotzdem sichern. Ist halt die Frage, wie dein Plan aussieht, wenn du das Backup mal brauchst. Sprich: Willst du ein sofort startbares System erzeugen können oder handhabst du das evtl. auch eher so wie ich?
Wie sichert man denn nur die geänderten separat?
Gute Frage. Mit der Shell kann man da mit Sicherheits was nettes basteln, aber ich hab dafür gerade keine Lösung parat.
Seltsam ist auch, das borg nicht alle Dateien rückspielt, z. B. nicht meine .vimrc. Ich finde sie, wenn ich das Archiv mounte, aber sie wird nicht rückgesichert???
Eigenartig, ist mir noch nicht aufgefallen. Ich hab zum Testen borg mount ausgeführt und darüber die Dateien wiederhergestellt, das hatte geklappt. Aber ich denke mal du hast das via borg extract gemacht, was eigentlich auch dafür gedacht ist? Notfalls ein Issue bei GitHub aufmachen.
Irgendwie scheint mir ein Vollbackup alles andere als trivial. Vielleicht mache ich dann doch erst mal eines mit clonezilla oder btrfs send oder so... 😐
Wieso, das Backup hat ja geklappt 😬 Nur der Restore scheint nicht so zu gehen wie erwartet.
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Alles, was in /etc und sonstwo lag ist für mich nicht relevant. Das sind System- bzw. Konfigurationsdateien, mehr nicht.
Ich habe vor ein bischen am System rumzutweaken, u. a. hibernate wiederherstellen usw, daher sind die Systemeinstellungen schon wichtig für mein Backup.
Wieso, das Backup hat ja geklappt 😬
Nur der Restore scheint nicht so zu gehen wie erwartet.
😊 LOL, der ist gut!
Ich habe jetzt nach der offiziellen Anleitung im Ubuntu Wiki root mit tar gesichert und restored. Dummerweise bootet die VM danach wieder nur in die emergency console 😕 Wie soll man also ein backup vernünftig testen??
Ach, kauf ich mir eben nochmal meinen Laptop, man hats ja... 😊
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Barrios schrieb: Alles, was in /etc und sonstwo lag ist für mich nicht relevant. Das sind System- bzw. Konfigurationsdateien, mehr nicht.
Ich habe vor ein bischen am System rumzutweaken, u. a. hibernate wiederherstellen usw, daher sind die Systemeinstellungen schon wichtig für mein Backup.
Dafür könntest du dann auch auf btrfs Snapshots setzen (Also: Tweaken, ausprobieren, und dann entweder zurückgehen oder es so lassen wie es ist). Aber ja, dann würde ich tatsächlich auch /etc sichern. Das Verzeichnis beim Zurücksichern aber nicht einfach überschreiben, sondern (händisch) nur die Dateien, die relevant sind. Eine andere (einfache) Lösung scheint es hierfür nicht zu geben. Alternativ könntest du dir auch das Programm etckeeper ansehen. Wurde mir kürzlich empfohlen. Ich selbst habe es noch nicht benutzt und kann dir damit dementsprechend auch nicht weiterhelfen, aber es scheint eine Art Versionsverwaltung für /etc zu sein.
Wie soll man also ein backup vernünftig testen??
Kann ich dir ehrlich nicht sagen. Im laufenden System Systemdateien zu überschreiben ist auch nicht gerade gefahrlos. Live System booten und von da aus das System wiederherstellen müsste aber gehen, oder nicht? (Apropos finde ich super, dass du auch den restore testest. Das machen nur sehr, sehr wenige)
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Im laufenden System Systemdateien zu überschreiben ist auch nicht gerade gefahrlos. Live System booten und von da aus das System wiederherstellen müsste aber gehen, oder nicht?
Ja, das hatte ich mir auch schon gedacht...
(Apropos finde ich super, dass du auch den restore testest. Das machen nur sehr, sehr wenige)
Nach mehreren schmerzvollen Erfahrungen mit nicht funktionierenden Backups bin ich jetzt an dem Punkt das Motto "An untested backup is no bakup" zu beherzigen... Der Supergau ist übrigens schon eingetreten: Nach Reaktivieren von hibernate klappte es erst ein paar mal, dann nach mißglücktem Reaktivieren lässt sich das System nun nicht mehr booten... Es gibt wohl doch gute Gründe, weshalb das per default aus ist, wenn es nicht mal auf einer Tuxedokiste funktioniert... Zum Glück habe ich ein tar-Backup von home / etc + apt-clone-Liste sowie ein Komplettbackup via btrbk. Da beide jedoch ungetestet sind, versuche ich erstmal ein chroot aus der Live-CD heraus. Aber da fangen die Probleme schon an, dafür mache ich dann aber mal einen neuen Thread auf. etckeeper werde ich mir auch mal ansehen. So, jetzt gehe ich statt in der VM gleich in echt an die Wiederherstellung, drück mir die Daumen...
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Da es leider keine Ideen gab, den klemmenden LUKS-Container irgendwie zu öffnen, habe ich mein System jetzt neu aufgesetzt. Das Rückspielen mit btrbk führte zu freeze nach reboot, kann ich also nicht weiterempfehlen... Werde jetzt borg nochmal testen und berichte dann.
|
Barrios
(Themenstarter)
Anmeldungsdatum: 21. Mai 2006
Beiträge: 60
Wohnort: Göttingen
|
Habe dann apt-btrfs-snapshot probiert, welches automatisch vor jedem apt install / remove einen snapshot zieht. Eigentlich sehr praktisch, aber nach Wiederherstellen eines snapshots → emergency console... Auf github vor 7 Jahren der letzte commit, sollte man mal aus den Ubuntu-sourcen rausschmeißen... Zum Glück vorher mit borg einen Backup gezogen, und TARA: Hat funktioniert! Von diesen halbgaren btrfs-apps kann ich nach bisherigen Erfahrungen nur abraten. Die Idee automatische snapshots per apt-hooks zu ziehen ist eigentlich super, ich nehme das mal als Ansporn was eigenes zu schreiben.
|