BTRFS und Backups

[smutbert]

Meine Begeisterung über BTRFS habe ich schon hier http://debianforum.de/forum/viewtopic.p ... 83#p927620 Kund getan. In diesem Thema würde ich gerne mein Vorgehen beim Erstellen von Backups mit BTRFS zur Diskussion stellen:


Die Situation auf dem (meinem) PC

Das Betriebsystem (Debian Wheezy) und die Daten befinden sich auf der ersten Festplatte auf je einem Subvolume in einem BTRFS. Auf dem gemounteten Rootvolume, sehen die Subvolumes wie ganz normale Verzeichnisse aus. So kann auf das laufende System zugegriffen werden, ohne dass „lästige“ tmpfs und virtuelle Dateisysteme in /sys, /proc, /dev, /run,… berücksichtigt werden müssen.
Für die Backups steht eine weitere Platte zur Verfügung, die ebenfalls eine mit BTRFS formatierte Parition enthält. Es gibt also zwei BTRFS

• Ein BTRFS auf der ersten Platte, gemountet in /mnt/btrfs.
  • /mnt/btrfs/debian.root
  • /mnt/btrfs/debian.home
  debian.root und debian.home sind Subvolumes, die darüber hinaus naheliegenderweise auch in / und /home gemountet sind .
• Das BTRFS auf der zweiten Platte ist in /mnt/backup gemountet und enthält:
  • /mnt/backup/current/debian.root
  • /mnt/backup/current/debian.home
  • /mnt/backup/snapshots
  current und snapshots sind ordinäre Verzeichnise, nur debian.root und debian.home sind wieder Subvolumes.

Das Backup

Für das eigentliche Backup werden debian.root und debian.home auf der Platte mit rsync mit den entsprechenden Subvolumes in current auf der zweiten Platte synchronisiert und sofort danach wird je ein readonly Snapshot in /mnt/backup/snapshots/ erstellt.
Für das komplette Backup sind also 4 Befehle notwendig:

Code: Alles auswählen

rsync -a --delete /mnt/btrfs/debian.root/ /mnt/backup/current/debian.root/
rsync -a --delete /mnt/btrfs/debian.root/ /mnt/backup/current/debian.root/

btrfs subvolume snapshot -r /mnt/backup/current/debian.root /mnt/backup/snapshots/debian.root.'date +%Y%m%d'
btrfs subvolume snapshot -r /mnt/backup/current/debian.home /mnt/backup/snapshots/debian.home.'date +%Y%m%d'

Allerdings wird, wenn man während des Backups normal weiterarbeitet, während des rsync Laufs unter Umständen die eine oder andere (Quell)Datei gelöscht und rsync meldet einen Fehler. Darüber hinaus ist der Name des Snapshots ungünstig gewählt, wenn man mehr als ein Backup an einem Tag machen will, aber ich finde das kurze Datumsformat wesentlich übersichtlicher.
Deshalb habe ich ein kleines Skript geschrieben, das ich in meinem nächsten Beitrag herzeigen will…

[smutbert]

…die Schwierigkeiten haben mich auf die Idee gebracht vor dem Ausführen von rsync einen readonly Snapshot von System (debian.root) und Home (debian.home) zu machen, damit man beim Arbeiten dem Erstellen des Backups nicht in die Quere kommen kann. Herausgekommen ist


das Skript

Code: Alles auswählen

#!/bin/bash
#

TOBACKUP[0]="/mnt/btrfs/debian.root"
BACKUPTO[0]="/mnt/backup/current/debian.root"
SNAPSHOT[0]="/mnt/backup/snapshots"
SNAPNAME[0]="debian.root"
RSYNCOPT[0]="-a --delete"
EXCLUDES[0]="--exclude-from /root/backup/exclude.debian.root"

TOBACKUP[1]="/mnt/btrfs/debian.home"
BACKUPTO[1]="/mnt/backup/current/debian.home"
SNAPSHOT[1]="/mnt/backup/snapshots"
SNAPNAME[1]="debian.home"
RSYNCOPT[1]="-a --delete"
EXCLUDES[1]="--exclude-from /root/backup/exclude.debian.home"

LOGFILE="/var/log/backupscript.log"

typeset -i BACKUPNR=0
typeset -i BACKUPCT=1

while [ ${BACKUPNR} -le ${BACKUPCT} ] ; do
	SNAPSRC[${BACKUPNR}]="${TOBACKUP[${BACKUPNR}]}.${BACKUPNR}.`date +%Y%m%d%H%M%S`"
	SNAPDST[${BACKUPNR}]="${SNAPSHOT[${BACKUPNR}]}/${SNAPNAME[${BACKUPNR}]}.`date +%Y%m%d`"
	if [ -d "${SNAPDST[${BACKUPNR}]}" ]; then
		SNAPDST[${BACKUPNR}]="${SNAPSHOT[${BACKUPNR}]}/${SNAPNAME[${BACKUPNR}]}.`date +%Y%m%d`.`date +%H%M%S`"
	fi
	echo -n "create source snapshot[${BACKUPNR}]..."
	btrfs subvolume snapshot -r "${TOBACKUP[${BACKUPNR}]}" "${SNAPSRC[${BACKUPNR}]}" 2>&1 >> "${LOGFILE}" && echo "ok."|| exit ${BACKUPNR}
	BACKUPNR=${BACKUPNR}+1
done

typeset -i BACKUPNR=0

while [ ${BACKUPNR} -le ${BACKUPCT} ] ; do
	echo -n "rsync[${BACKUPNR}]..."
	rsync ${RSYNCOPT[${BACKUPNR}]} ${EXCLUDES[${BACKUPNR}]} "${SNAPSRC[${BACKUPNR}]}/" "${BACKUPTO[${BACKUPNR}]}/" 2>&1 >> "${LOGFILE}" && echo "ok."|| exit ${BACKUPNR}
	echo -n "create backup snapshot[${BACKUPNR}]..."
	btrfs subvolume snapshot -r "${BACKUPTO[${BACKUPNR}]}" "${SNAPDST[${BACKUPNR}]}" 2>&1 >> "${LOGFILE}" && echo "ok."|| exit ${BACKUPNR}
	BACKUPNR=${BACKUPNR}+1
done

typeset -i BACKUPNR=0

while [ ${BACKUPNR} -le ${BACKUPCT} ] ; do
	echo -n "remove source snapshot[${BACKUPNR}]..."
	btrfs subvolume delete "${SNAPSRC[${BACKUPNR}]}" 2>&1 >> "${LOGFILE}" && echo "ok."|| exit ${BACKUPNR}
	BACKUPNR=${BACKUPNR}+1
done

echo "done."

Die Variablen zu Beginn definieren nur was wohin gesichert werden soll, dabei sind excludes für rsync dazugekommen, damit keine unnötigen Dinge gesichert werden. Viel habe ich da aber nicht drin stehen, vom System nur den Cache von apt

Code: Alles auswählen

- /var/cache/apt/archives/*.deb
- /var/cache/apt/pkgcache.bin
- /var/cache/apt/srcpkgcache.bin

und für Home nur Downloads, Papierkorb und Cache

Code: Alles auswählen

- /*/Downloads/*
- /*/.local/share/Trash/
- /*/.thumbnails/
- /*/.cache/

Kurze Zusammenfassung

1. Die erste Schleife legt von allen zu sichernden Subvolumes readonly Snapshots an und definiert bereits den Namen für den Snapshot des Backups. Hier wäre es noch schön sicherheitshalber einige Dinge zu überprüfen, z.B. ob debian.root und debian.home tatsächlich vorhanden und Subvolumes und nicht etwa normale Verzeichnisse sind.
2. Die zweite Schleife synchronisiert die eben erstellten readonly Snapshots von System und Home mit den entsprechenden Subvolumes auf der zweiten Platte und legt auch gleich readonly Snapshots vom fertigen Backup an.
3. Die letzte Schleife schließlich löscht die in der ersten Schleife erstellten Snapshots der zu sichernden Subvolumes (hier debian.root und debian.home).

Mir ist klar, dass das Ganze nichts Besonderes ist und eigentlich habe ich nicht die Absicht das Skript noch zu verändern oder gar zu erweitern, aber über Anmerkungen und Hinweise was ich alles falsch oder ungünstig mache und sonstige Verbesserungsvorschläge, würde ich mich trotzdem freuen.

[peschmae]

Naja, wie man das macht ist natürlich in jedem Falle verhandelbar. Ist denke ich auf jeden Fall ein guter Ansatz so wie du das beschreibst.

Alternativen:
Ich bin derzeit bei einer Lösung ganz ohne snapshots gelandet - nur rsync (mit --link-dest um hardlinks zu erzeugen und damit im Prinzip inkrementelle Backups zu ermöglichen, mittlerweile auch auf btrfs wegen Kompression, Checksummen und Deduplikation). Grund ist vor allem dass mir die ganze Snapshotterei einfach zu riskant ist, weil ich die Befehle viel zu wenig benutze und deswegen wenns dann mal drauf an kommt mit grosser Wahrscheinlichkeit beim wiederherstellen einfach mal schnell alles kaputt machen. Ausserdem kann so auch einfach mehrere Backupversionen durchsuchen, etc - so Dinge wie cp --backup=t */home/peschmae/.zshrc /tmp um mal alle vorhandenen Versionen meiner zshrc zu kriegen oder so... (ok, schlechtes Beispiel, für die Konfigurationsdateien verwende ich eh git, aber im Prinzip...)

Andererseits: wenn man schon die Möglichkeiten von btrfs so richtig nutzen will - wieso nicht gleich ein raid1 machen mit der Backupplatte, und dann ab und zu mal von letzterer Snapshots erstellen? Möglicherweise auch die Backupplatte zwischendurch mal rausnehmen und dann beim wiedereinbau wieder syncen lassen, etc - das rsync ist da eigentlich überflüssig und wohl eher ineffizient.

Ist aber am Ende nicht so wichtig - solange man ein System hat was zuverlässig tut - nicht mehr anfassen

MfG Peschmä

[smutbert]

Gerade das Wiederherstellen ist bei meiner Lösung denkbar einfach (finde ich). Nach dem Formatieren lege ich die Subvolumes an und kopiere die Daten von current oder einem Snapshot zurück.

Dazu habe ich sogar extra auf beiden Platten einen von Debian unabhängigen GRUB eingerichtet, der sich nicht an den UUIDs sondern an den LABLELn der Dateisysteme orientiert. D.h. ich muß mich nach dem Wiederherstellen auch nicht mit einer Neuinstallation von GRUB herumschlagen und kann auch den GRUB auf der ersten Platte (dank EFI) einfach durch Zurückkopieren wiederherstellen.


Die Variante mit dem BTRFS-eigenen raid1 klingt aber auch sehr gut. Wenn ich Zeit habe, probiere ich das einmal aus.

[schorsch_76]

Also ich nutze hier schon länger btrfs und bin ebenfalls begeistert. Mittels

Code: Alles auswählen

btrfs subvolume snapshot rootfs rootfs-YYYYMMDD

klappt das super. Der einzige Nachteil ist, dass fsarchiver das ganze nicht mag und sich weigert davon ein Image zu machen. rsync oder ein anderer Mechanismus kann genutzt werden um die Daten auf eine externe Platte zu bringen.

Gruß
schorsch

[charno]

Dazu habe ich sogar extra auf beiden Platten einen von Debian unabhängigen GRUB eingerichtet, der sich nicht an den UUIDs sondern an den LABLELn der Dateisysteme orientiert. D.h. ich muß mich nach dem Wiederherstellen auch nicht mit einer Neuinstallation von GRUB herumschlagen und kann auch den GRUB auf der ersten Platte (dank EFI) einfach durch Zurückkopieren wiederherstellen.

Ich kenne mich mit btrfs nicht aus, aber heisst das dann durch die fortgesetzte Logik nicht auch, dass du im Notfall direkt von der 2. Platte booten kannst? Wenn sich der GRUB an den Labels orientiert, die wahrscheinlich auf beiden Platten dieselben sind KÖNNTE das funktionieren, oder?

[smutbert]

Dem BTRFS auf der 2. Platte habe ich ein anderes Label verpaßt damit nichts durcheinander kommt - ich weiß gar nicht wie sich Grub und Kernel verhalten, wenn sie mehrere Dateisysteme mit passendem LABEL finden… Aber du hast recht, ich könnte genauso gut von der 2. Platte starten. Tue ich nur nicht, weil ich die Backupplatte so unberührt wie möglich lassen will.

Aber um das Bild zu vervollständigen:
Zusätzlich zu je einer BTRFS Partition auf den Platten habe ich auch noch eine SWAP und je eine EFI System Partition. Und eben auf letzterer findet nicht nur mein "standalone GRUB" sondern auch noch ein grml ISO Image Platz, von dem ich notfalls starten kann.

[scientific]

Hab letztens einen spannenden Vortrag von VEEAM gehört.

Und der Typ brachte das durchaus brauchbare Argument ein "Wie oft haben Sie schon getestet, ob ihr Backup wieder herstellbar ist?"

VEEAM legt bootbare Backups an... Und er meinte, dass es sinnvoll ist, regelmässig von den Backups zu booten (und sei es nur in einer virtuellen Maschine) um zu kontrollieren, ob WIRKLICH das Backup funktioniert.

Nur mal so als Hinweis.

Ich hab mir jetzt auch mal btrfs auf die Festplatte geklatscht - und natürlich gleich bei der Installation einen Topfen gebaut... Werd mal ein passendes Backup auf einer zweiten Platte davon anfertigen und dann nochmal von vorne beginnen...

lg scientific

[Cae]

Was soll die Veeam-Werbung hier? Abgesehen davon kann ich deren Software absolut nicht empfehlen. Ich hatte vor einiger Zeit (in nicht von mir administrierter Umgebung, Vmware mit Veeam-Backup) eine gute Stunde Ausfall in Produktion, weil das Veeam-Restore nicht gescheit funktionierte. Eine essentielle Datei war geloescht worden, welche wiederhergestellt werden musste. Zeitaufwand und Ausfall von unter fuenf Minuten, sollte man meinen. Datei auswaehlen, Timestamp von letzter Nacht waehlen, ab die Post.

Nix war, Datei-basiertes Restore hat aufgrund von UTF-8-kodierter Dateinamen nicht funktioniert (selbstverstaendlich mit unpraeziser Fehlermeldung). Also gut, es gibt einen Modus, wo man ein temporaeres Mini-System bootet, welches das Dateisystem vom Backupzeitpunkt sehen kann. Diese wurde irrtuemlich im anderen Subnetz als der Backupserver gestartet (ist Scheisse erklaert an der Stelle), weshalb der Boot ein zehn Minuten langes (!) Timeout verursachte, inklusive Deadlock der Bedienoberflaeche. Letztendlich gab es dasselbe Kodierungsproblem wie zuvor und ich hatte einen kompletten Klon restoren muessen: zusaetzlicher Zeitaufwand fuer's Restore von dutzenden Gigabyte, nur um ein paar KB wiederherzustellen. Der Klon konnte dann per scp auf sein sein Original restoren.

Einen groesseren Mist hab' ich nicht erlebt. Da lobe ich mir doch ein vernuenftiges rdiff-backup oder ein simples rsync auf den Backup-Storage. Ob das dann bootbar ist oder nicht, ist bei kleineren Ausfaellen schnuppe, weil man die Maschine einfach debootstrappen (PXE, preseed.cfg) und danach restoren kann. Fuer Desaster Recovery ist vielleicht ReaR [1] besser geeignet, was man auch per rsync und Hardlinks arbeiten lassen kann.

Gruss Cae

[1] http://relax-and-recover.org/

[scientific]

Was bist denn so empfindlich?
Ausser einem Usb-stick mit deren Aufschrift wo ich ein Life-Linux draufgespielt hab, hab ich von denen nix.
Und ein paar gute Ideen... Wo ich nachdenke, wie man das mit Linux lösen kann.

Was mir definitiv fehlt ist ein Beißreflex, wie du ihn hast.

Dir ist offenbar nicht bewusst, dass du viel bessere Werbung gerade produziert hast, als ich jemals hätte beabsichtigen können... (dass der zweite Stick sofort einen Hardewareaussetzer hatte, hab ich gard nicht erwähnt, da ich weiß, dass Negativwerbung Produkt und Marke viel besser in erinnerung behält und viel neugieriger macht...)

Und damit ist das Thema für mich abgehandelt, weil es mir nicht wichtig ist.

*kopfschüttel*

[smutbert]

Also bei meiner Strategie habe ich nicht viel getestet, aber was soll beim Hin- und Herkopieren mit rsync und/oder cp -a schon schief gehen

Ich bin sogar gerade erst in die Verlegenheit gekommen, ein Backup direkt vom Backupmedium booten zu wollen und mit meinem „Standalone-Grub“ war das erwartungsgemäß kein Problem. Ich musste nur vorher die fstab anpassen. Dank UEFI kann ich auch grub ganz normal als Datei sichern und wiederherstellen - schlimmstenfalls lande ich in der Grub-Kommandozeile, von der aus es mir nicht schwer fällt initrd und Kernel mit den richtigen Parametern zu laden.
Ich habe auch noch extra einen Stick auf dem nur ein 32Bit-efi Grub, ein amd64-efi Grub und ein althergebrachter Grub-pc nebeneinander installiert sind, quasi mein persönlicher, etwas spartanische Super Grub Boot Stick, der hat mir bei Freunden schon gute Dienste geleistet.

[scientific]

Wie stehst du zu btrfs send/recive?

Ich habe meine Konvertierung auf eine große btrfs-Partition jetzt fast abgeschlossen (Sind doch einige Daten zum Schaufeln...) und muss dann noch meine externe Festplatte auf btrfs konvertieren. Dann bin ich soweit, meine neue Backup-Strategie zu implementieren.

Ich habe hier https://btrfs.wiki.kernel.org/index.php ... tal_Backup nachgelesen, dass btrfs send/recive nur die Datenblöcke überträgt, die tatsächlich geändert wurden... Also nicht einmal die ganzen Files, und dann im Ziel einen Snapshot erstellt, der dem auf der Quelle entspricht.
Ich vermute einmal, dass das noch schneller gehen müsste, als mit rsync durch das Dateisystem zu rödeln...

lg scientific

[smutbert]

btrfrs send/receive wollte ich schon ausprobieren, aber erstens geht das Backup mit rsync so verflixt schnell, dass es mir schon unheimlich ist — andere Befehle/Varianten brauchen schon länger, um alleine die Liste der zu kopierenden Dateien zu erstellen und zweitens sichere ich auch meine EFI System Partition auf einem BTRFS und dafür könnte ich es sowieso nicht verwenden.

Sobald ich einmal irgendwelche qemu/vbox/…-Images oder dergleichen sichern will, werde ich aber noch einmal darüber nachdenken

[scientific]

Kennst du https://github.com/ruediste1/btrbck. Das wird hier empfohlen https://btrfs.wiki.kernel.org/index.php ... tal_Backup

Ich hab es mal ausprobiert, aber das Problem ist, dass es nur Subvolumes erkennt und behandelt, die mit diesem Programm angelegt wurden.
Wenn ich auf meiner HD jetzt schon ein oder mehrere Subvolumes habe (debian.root, debian.home...) dann weiß ich nicht, wie ich diese in diese Streams bekomme... :-/

lg scientific

[minimike]

Wir haben viele FreeBSD Syteme mit ZFS. Und sichern trotzdem mit Bacula. Auch XEN und Hyper-V Umgebungen würde ich bevorzugt mit Bacula/Baeros sichern. Klar gibt es besseres. Aber Bacula/Baeros ist fast schon large scale Enterprise. Und wenn man ein paar 100000 € nicht im Budget hat wird man damit schnell glücklich

[scientific]

Ich habe hier Debian.

Und eine konkrete Frage in smutberts Thread angehängt, die thematisch passt... Was konkret hat ZFS und Freebsd mit btrfs und Linux zu tun?

[minimike]

Ich habe hier Debian.

Und eine konkrete Frage in smutberts Thread angehängt, die thematisch passt... Was konkret hat ZFS und Freebsd mit btrfs und Linux zu tun?

Im Gegensatz zu BTRFS funktiniert ZFS stabiel und zuverlässig seit vielen Jahren. Du kennst die Designziele von BTRFS? Ich glaube nicht aber darum geht es mir nicht.
ZFS kann Snapshots und solch Voodoo.. Trotzdem wird mit Bacula gesichert. Weist Du was Bacula ist? Und wie es funktioniert? Ach Egal.. Bacula macht es im Gegensatz zu den Dateisystemsnapshotgeschichten effizient, mission critical und schont die Kasse

[scientific]

Hmmm... Hätt ich nach Zfs und Bacula gefragt... Ich wär in einem anderen Thread.

[scientific]

Hi!

Ich studiere gerade dein Skript und adaptiere es für meine Zwecke. Dabei ist mir etwas aufgefallen, und wollte dich fragen, ob das Absicht ist, oder nicht.

Die Ausgabeumleitung scheint mir nämlich falsch zu sein (und hat bei mir auch dementsprechende Fehler produziert)

Code: Alles auswählen

#!/bin/bash
	btrfs subvolume snapshot -r "${BACKUPTO[${BACKUPNR}]}" "${SNAPDST[${BACKUPNR}]}" 2>&1 >> "${LOGFILE}" && echo "ok."|| exit 

Soviel ich weiß, muss es in der bash so gehen:

Code: Alles auswählen

programm >> /path/to/file 2>&1

damit auch die Fehlermeldungen im Logfile landen....

lg scientific

[smutbert]

Die Umleitungen machen mich fertig (☺ es war keine Absicht), Danke für die Berichtigung.

Ich habe mein Skript so ausgebaut, dass ich für einzelne Quellen die erste Schleife überspringen kann, damit auch Backups von anderen Dateisystemen gemacht werden können und dann wollte ich noch die Möglichkeit einbauen auf oder alternativ auch von Remote-Hosts zu sichern.
Dabei habe ich mich dann mit den über ssh auszuführenden Befehlen etwas verzettelt und jetzt ist mein Skript in einem zwar funktionierenden aber nicht vorzeigbaren Zustand, sonst hätte ich meine neuen Errungenschaften wahrscheinlich schon hier gepostet.

[scientific]

Jaja... diese Umleitungen

Ich hab die Anregungen von dir genommen und mein für mich passendes Skript zusammengebaut.
Ganz fertig bin ich aber auch noch nicht. (Wenn ich es habe, darf ich es hier in deinem Thread posten, oder soll ich einen eigenen aufmachen?)

Mein Konzept schaut so aus:
Ich lege in einem Verzeichnis im pool (also auf /dev/sda2 OHNE subvolumes gemountet) von jedem subvolume (wird aus einem Config-File ausgelesen, notation ist so ähnlich wie in rsnapshot) ein Snapshot mit Datum angelegt. Zusätzlich bekommt der aktuelle und der letzte Snapshot noch einen Symlink mit z.B. @home.CURRENT und @home.LAST.

Zusätzlich wird mit btrfs send / receive auf Wunsch (also mit Option -r) der Snapshot auf die externe Festplatte übertragen. Hier könnte man durchaus noch einen ssh-Aufruf einbauen. Aber mangels externem Rechner, brauch ich das momentan noch nicht.

Existiert auf dem Remote-Laufwerk für dieses Subvolume noch kein Snapshot, wird der (auf Wunsch mit der Option -i im Aufruf) initial erstellt, sodass beim nächsten Aufruf nur mehr das inkrementelle Backup erstellt wird.

Ich habs noch nicht ganz behirnt, wie ich grub und die fstab so modifizieren kann, dass ich z.B. mit den beiden Symlinks .CURRENT und .LAST für alle Subvolumes wahlweise booten kann.
Und ich bin mir noch nicht sicher, ob ich von vornherein readonly- und readwrite-Snapshots anlegen soll. Momentan lege ich nur readonly Snapshots an, da die für btrfs send benötigt werden.

Ach ja, was noch wichtig ist... Man kann keine Ausnahmen für btrfs-send definieren. Das heißt, für div. Verzeichnisse, die viel Datenverkehr mit geringer Aufhebewichtigkeit haben (~/.cache ~/tmp...) sind daher subvolumes anzulegen.

[smutbert]

Natürlich freue ich mich, wenn du das Ergebnis hier postest.

zu fstab und grub:
Meine fstab sieht zB so aus

Code: Alles auswählen

LABEL=BTRFS.SSD    /          btrfs  discard,noatime,subvol=debian.root   0 0
LABEL=BTRFS.SSD    /home      btrfs  discard,noatime,subvol=debian.home   0 0
LABEL=EFI.SSD      /boot/efi  vfat   noatime,dmask=077,fmask=177          0 0

Da muss ich im Backup subvol=… und die Dateisystemlabels anpassen.

Ähnliches gilt für Grub, wobei es da einfacher ist, weil ich auf dem Backup-Laufwerk einfach einen eigenen komplett unabhängigen Grub in die EFI Systempartition installiert habe, mit einer eigenen minimalen grub.cfg:

Code: Alles auswählen

insmod part_gpt
insmod btrfs
insmod png
insmod gzio

loadfont /efi/grub/fonts/unicode.pf2
insmod efi_gop
insmod efi_uga
insmod gfxterm
set locale_dir=/efi/grub/locale
set lang=en_US
insmod gettext
terminal_output gfxterm

set timeout=2

set color_normal=white/black
set color_highlight=black/white

menuentry 'Debian GNU/Linux (BTRFS.SSD/debian.root)' {
	search --no-floppy --label --set=root BTRFS.SSD
	linux	/debian.root/boot/vmlinuz root=LABEL=BTRFS.SSD ro rootflags=subvol=debian.root quiet
	initrd /debian.root/boot/initrd.img
}

(mit --boot-directory=… von grub-install läßt sich ein eigenes Verzeichnis auf einer FAT/EFI Partition angeben, in dem dann in grub/grub.cfg nach der Konfiguration gesucht wird — einige Dateien fehlen dann auch noch, zB unicode.pf2 oder die Module, wobei man sich letztere wohl genauso wie die insmod-Befehle sparen kann, weil ein grub-efi-Image meines Wissens sowieso mit allen Modulen fix eingebaut gebaut wird — das ließe sich imho aber auch noch mit --modules=… steuern)

/boot/vmlinuz und /boot/initrd.img sind bei mir symbolische Links auf Kernel bzw. Initrd, die normalerweise in / angelegt werden, aber das habe ich mit einer /etc/kernel-img.conf geändert:

Code: Alles auswählen

$ cat /etc/kernel-img.conf 
do_symlinks = yes
relative_links = yes
link_in_boot = yes

[scientific]

Ok. Efi hab ich nicht. Mein Laptop ist 7 Jahre alt... (Kann ich da überhaupt EFI verwenden??? GPT funktioniert auf jeden Fall...)

Ich hätte ja gehofft, dass das booten von einem Snapshot "etwas" weniger aufwändig ist... Glücklicherweise versteht sogar Grub mit btrfs einen Symlink auf ein Subvol (habs grad getestet!)
Ich glaube, ich hab irgendwo mal von einem Skript gelesen, welches mit Grub2 ermöglicht, in einer Liste von allen Snapshots auszuwählen und davon zu booten...

Und diesen Moment fällt mir auf, dass ich z.B. von initrd wirklich wenig Ahnung habe. Hast du ev. da Ahnung, ob es möglich ist, über die initrd eine System-Environment-Variable mitzugeben, die auf das Datum des Snapshots gesetzt ist, und mit dem man auch die /etc/fstab füttern kann?
Oder kann ich dem Kernel einen Bootparameter mitgeben, der dann im laufenden System als Environment vorhanden ist und damit auch in der fstab genützt werden kann?

lg scientific

[smutbert]

Ein UEFI wird ein 7 Jahre alter PC eher nicht haben. Mit grub-pc sollte es im Prinzip genauso funktionieren, nur dass das grub-Image in der Größe beschränkt ist und du deshalb beim Booten auf die Module angewiesen sein wirst. Ich glaube aber grub-pc kopiert die Module automatisch beim Installieren nach --boot-directory/grub/<architektur>, sollte also vielleicht gar kein Problem sein.


und Ja, irgendwie muss, das was du willst, wohl funktionieren. Es gab ja auch ein Paket in Debian, das bei jeder apt-get-Aktion einen Snapshot angelegt hat und ich meine die Idee kam aus der Fedora-Richtung. Dort glaube ich war das dann so umgesetzt, dass man von den Snapshots starten konnte (?), aber ich habe keine Idee wie man das machen könnte (könnte auch sein, dass ich das mit zfs und Solaris verwechle, bei zfs muss man sich ja um das mounten nicht kümmern, soweit ich weiß).

Ich frage mich gerade, was passiert, wenn der /-Eintrag in der fstab fehlt oder mit dem root=…-Kernelparameter nicht übereinstimmt — ich habe den Verdacht, dass nur letztere richtig sein muss…

[scientific]

Ein UEFI wird ein 7 Jahre alter PC eher nicht haben. Mit grub-pc sollte es im Prinzip genauso funktionieren, nur dass das grub-Image in der Größe beschränkt ist und du deshalb beim Booten auf die Module angewiesen sein wirst. Ich glaube aber grub-pc kopiert die Module automatisch beim Installieren nach --boot-directory/grub/<architektur>, sollte also vielleicht gar kein Problem sein.


und Ja, irgendwie muss, das was du willst, wohl funktionieren. Es gab ja auch ein Paket in Debian, das bei jeder apt-get-Aktion einen Snapshot angelegt hat und ich meine die Idee kam aus der Fedora-Richtung. Dort glaube ich war das dann so umgesetzt, dass man von den Snapshots starten konnte (?), aber ich habe keine Idee wie man das machen könnte (könnte auch sein, dass ich das mit zfs und Solaris verwechle, bei zfs muss man sich ja um das mounten nicht kümmern, soweit ich weiß).

Ich frage mich gerade, was passiert, wenn der /-Eintrag in der fstab fehlt oder mit dem root=…-Kernelparameter nicht übereinstimmt — ich habe den Verdacht, dass nur letztere richtig sein muss…

Dann bekommt man eine emergency-Shell.

Das apt-get-snapshot hat einige Limitierungen. Und ein boot von einem Snapshot wird dort mittels ändern des Default-Snapshots realisiert. Also auch nicht das, was ich suche.
In der Grub-devel-list wird eine "dynamische" grub.cfg bzw. ein Eintrag, der mittels regexpress und Schleife automatisch Einträge abhängig von den Snapshots ins Grub-Menü erstellt, disktuiert. Nur hab ich noch nicht ganz überrissen, wie das genau funktionieren soll... bin da zu wenig firm mit grub2. Das löst aber immer noch nicht das Problem der fstab.

Ich hab zumindest einmal eine Umgebungsvariable erfolgreich von der Bootzeile bis zu systemd.services durchschleusen können, die aber von mount-units nicht ausgewertet wird... :-/

lg scientific