Systembackup vom laufenden System?

[Simaryp]

Hallo,

mein Debian-Heimserver läuft schon einige Monate produktiv und ich habe für meinen ZFS Pool borgbackup Skripte, die die Daten meines Dateiservers täglich sichern.

Ich habe allerdings noch kein Backup des eigentlichen Debian Systems und bin noch etwas ratlos, wie ich das am besten umsetze. Für borgbackup habe ich schon Hinweise zu Systembackups vom laufenden System gesehen, aber dort werden nur ausgewähle Ordner gebackupt. Ich bin bei dieser Lösung unsicher, was getan werden muss, um das ganze wieder zum Laufen zu bekommen, sollte die ganze Systemplatte abrauchen.

Ich brauche eigentlich nichts ultra spezielles, keine automatisierten Backups, keine Versionierung. An dem System wird im aktuellen Status nur noch wenig geändert. Zur Zeit nur apt upgrades und Updates der Dockercontainer. Aber da könnte ich auch nach dem Rückspielen einfach updates machen. Wenn doch mal wieder Änderungen anstehen, könnte ich einfach das Backup ersetzen oder ein neues hinzufügen.

Meine Systemplatte ist recht simpel partitioniert, / ist auf einem luks lvm:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/gringotts--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/nvme0n1p2 during installation
UUID=e90b53bf-9cc3-4569-9d22-96449c28ece1 /boot           ext2    defaults        0       2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=6E55-BEC2  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/gringotts--vg-swap_1 none            swap    sw              0       0

Am liebsten wäre es mir eigentlich ich könnte aus dem laufenden System ein Image der ganzen Platte auf meinen zpool schreiben. Und wenn es mal ein Problem gibt, schreibe ich das ganze Image aus einem Livesystem wieder auf die Platte und kann danach weiter machen.

Aber sowas ist aus dem laufenden System vlt nicht möglich/ratsam? Außerdem ist ja die Partition dann entschlüsselt wenn ich mit dd von /dev/nvme0n1p3 ein Abbild mache ist es dann das verschlüsselte? Wenn ja, kann man es wahrscheinlich auch nicht komprimieren.

Wenn ich das Backup auf eine andere SSD aufspielen müsste, bin ich mir unsicher, ob ich mit einer dd Lösung Probleme haben könnte, wenn sich dann die UUID und die Bezeichnungen unter /dev ändern oder die Platte größer ist.

So viele Fragen und ich bin etwas planlos. Das ganze habe ich etwas stiefmütterlich behandelt und ich habe im Desasterfall mein Skript, wie ich alles eingerichtet habe, aber es wäre schon angenehm, einfach ein Backup einzuspielen, als einen halben Tag das ganze System neu aufzusetzen.

[bluestar]

mein Debian-Heimserver läuft schon einige Monate produktiv und ich habe für meinen ZFS Pool borgbackup Skripte, die die Daten meines Dateiservers täglich sichern.

Ich nutze auch intensiv ZFS und habe neben dem Daten-Pool einfach das komplette Debian auf ZFS-on-Root (und /boot on BPOOL) installiert, dann kannst du einfach Snapshots erstellen und diese sichern, z.B. auf deinem Datenpool. Ob du noch LUKS bei deinem Rpool zwischenschaltest oder direkt die ZFS Encryption verwendest, das bleibt dir überlassen.

[schwedenmann]

Hallo


Ev. so

Hallo

Vllt per zfs send and rece

https://unix.stackexchange.com/question ... r-zfs-pool

jetzt richtiger link

mfg
schwedenmann

[Simaryp]

Was ich vlt. noch hätte explizit erwähnen sollen.

Mein / ist auf ext4. Ich kann also zfs-send nicht dafür nutzen. Wäre im Nachhinein vlt. clever gewesen.

[bluestar]

Was ich vlt. noch hätte explizit erwähnen sollen.

Das hast du erwähnt, steht in deinem fstab Code Block.

Ich kann also zfs-send nicht dafür nutzen. Wäre im Nachhinein vlt. clever gewesen.

Dann investiere doch lieber einmal die Zeit und baue dein / auf ZFS und genieße danach die Vorteile.

[Simaryp]

Naja, ich will das funktionierende und produktive System jetzt eigentlich ungern ersetzen.

So etwas grundlegendes wie das Filesystem einfach mal zu ersetzen, wird wahrscheinlich nicht ohne Hickups gehen und bringt Risiken mit sich. Ohne das Backup, welches ich gerne haben möchte, stehe ich dann im Zweifel auf einmal ohne funktionierenden Server da. Ich weiß auch nicht, wie ich ohne ein Backup überhaupt das Filesystem ändern können soll.

[Simaryp]

Hallo


Ev. so

Hallo

Vllt per zfs send and receive

https://serverfault.com/questions/65449 ... her-server

mfg
schwedenmann

Falscher link? Aber wie gesagt, zfs send steht mir für / aktuell nicht zur Verfügung.

[bluestar]

Naja, ich will das funktionierende und produktive System jetzt eigentlich ungern ersetzen.

* Live System booten
* Images von Root-Partition & Boot-Partionen auf deinem ZFS Pool anlegen via DD
* Rpool anlegen
* Images loopback mounten
* Daten auf rpool verschieben
* Mountpunkte und Grub anpassen
* Pools aushängen
* Reboot

Die Images deiner Root-Partition & Boot Partitionen könntest du dabei parallel auf eine ext. HDD kopieren zur Sicherheit.

[Simaryp]

Hmm das muss ich mir überlegen. Ich bin nur ein durchschnittlicher noob. Ich verstehe, was du meinst, aber bei der konkreten Umsetzung müsste ich mich noch mal ne ganze Ecke belesen.
Einige Fragen die mir spontan einfallen:

• Geht der rpool auf LUKS?
• Hat das Auswirkungen auf meine Refind Konfiguration.
• Hat das Auswirkungen auf die Benutzung von Dropbear, um meinen LUKS Container zu entschlüsseln?
• Ist außer der fstab noch etwas anzupassen?
• Kann ich das zfs receive nur von zfs volumes machen oder kann ich das auch direkt aus meinem borg repo heraus machen?

Ansonsten ist wahrscheinlich der Vorschlag mit dem Livesystem wohl auch für das generelle Backup das zielführendste oder? Allerdings brauche ich da, wenn ich das Image gleich auf meinem pool ablegen möchte wohl ein livesystem mit zol.

Dann würde ich den Server neustarten und lokal dieses Livesystem booten (Muss noch überlegen wie ich das komfortabel mache. Vielleicht mit meinem IPMS.)
Partition mit luks öffnen.
Zpool mounten.
Mit dd ein image von /dev/nvme0n1p3 und /dev/nvme0n1p1 machen.

[bluestar]

• Geht der rpool auf LUKS?
• Hat das Auswirkungen auf meine Refind Konfiguration.
• Hat das Auswirkungen auf die Benutzung von Dropbear, um meinen LUKS Container zu entschlüsseln?
• Ist außer der fstab noch etwas anzupassen?
• Kann ich das zfs receive nur von zfs volumes machen oder kann ich das auch direkt aus meinem borg repo heraus machen?

Um deine Fragen mal zu beantworten:

• Ja rpool auf LUKS geht, die Frage ist halt ob's nötig ist oder ob du nicht einfach die native ZFS Verschlüsselung verwenden willst.
• Refind sagt mir nichts
• Nein auf Dropbear hat es keine Auswirkungen, es mangelt hier wohl noch an Doku https://github.com/openzfs/openzfs-docs/issues/46 falls du die native ZFS Verschlüsselung nutzen willst.
• Neben der fstab sind noch ein paar Kleinigkeiten anzupassen, schau einfach mal in das Buster ON ZFS Howto (siehe unten)
• Ich kenne Borgbackup nicht, daher kann ich dir nicht sagen, wie Borgbackup intern mit ZFS Dateisystemen und Snapshots umgeht.

https://openzfs.github.io/openzfs-docs/ ... 20ZFS.html

Das mit dem Live-System mit ZFS ist immer ein bißchen umständlich bei Debian, daher bediene ich mich einfach beim aktuellen Ubuntu also Live-System, dort ist ZFS direkt enthalten.

[Simaryp]

Refind ist eine schlanke und simple alternative zu grub, was ich nicht wirklich leiden kann.
Die Grubinstallation ist bei meiner Standardebian Anfang des Jahres fehlgeschlagen...

Borgbackup kennt die FS nicht, es kennt einfach nur die Files. Man kann ein borgrepo mounten und dann zum Beispiel den Snapshot sich anschauen. Sollte man einen ZFS Snapshot, den man auf ein /ext4 kopiert hat, einfach receiven können auf einen zpool, dann sollte es auch gehen. Müssen beide Seiten ZFS sein, dann geht es nicht.

Danke für den Link, habe den auch gefunden. Die Liste an steps ist aber sehr lang. Ich kann leider nicht erkennen, was man davon noch machen muss, wenn man nur ein vorhandes / rüber kopieren möchte. Müssen die ganzen Unterordner in / dann trotzdem als datasets angelegt werden?
Da ich ja schon einen luks container habe, muss ich dann nur intramfs in die crypttab hinzufügen?

Gibt es mit dem lvm irgendwelche Probleme, dass Debian automatisch angelegt hat?

Der Hinweis mit Ubuntu Liveimage ist sehr praktisch. Danke dafür.

[Simaryp]

Hier nochmal der Überblick über die Platte, ist etwas übersichtlicher als fstab.

Code: Alles auswählen

nvme0n1                    259:0    0 465,8G  0 disk  
├─nvme0n1p1                259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2                259:2    0   244M  0 part  /boot
└─nvme0n1p3                259:3    0   465G  0 part  
  └─nvme0n1p3_crypt        254:0    0   465G  0 crypt 
    ├─gringotts--vg-root   254:1    0 433,1G  0 lvm   /
    └─gringotts--vg-swap_1 254:2    0  31,9G  0 lvm   [SWAP]

[Tintom]

Korrigiert mich wenn ich flasch liege, aber lvm kann doch von Haus aus Snapshots[1], die man mounten, entschlüsseln und anschließend die Daten kopieren kann?!

[1] https://www.thomas-krenn.com/de/wiki/LVM_Snapshots

[Simaryp]

Ah cool.

Im Prinzip so wie hier in dem Tutorial https://www.howtoforge.com/linux_lvm_snapshots

Dann kann ich mir viele Fragezeichen und Stress sparen.
Im Prinzip kann ich dann meine Borg Skripte darauf anpassen das komplette / zu backupen.

Denn für den pool erzeuge ich momentan einen zfs snapshot, mounte diesen, mache ein backup davon und zerstöre den Snapshot wieder.

[Simaryp]

Ich wollte mich mal gerade dran setzen, das umzusetzen.

Leider bin ich über ein Problem gestolpert. Meine VG enthält zwei LV die zusammen 100% des Speichers belegen.

LVM Snapshots funktionieren aber anscheinend anders als bei btrfs oder zfs. Hier wird ein neues LV erzeugt. Dafür braucht man natürlich Platz, den ich jetzt nicht habe.

Damit stehe ich vor der Auswahl:
1. Umzug der Systempartition auf ZFS.
2. Shrink des Root LV, um LVM Snapshots zu nutzen.
3. Ich mache doch Backups vom Livesystem.

Sowohl 1. und 2. sind Risikoreich und sollten nur mit Backup gemacht werden, welches man wohl gleich vom Livesystem machen könnte, wenn man es umsetzt.

3. Wird laut borg unterstützt https://borgbackup.readthedocs.io/en/st ... -with-borg. Allerdings weiß ich nicht, was passiert, wenn sich während des Backups irgendwas ändert. Das betrifft wohl am wahrscheinlichsten meinen Ordner /home/docker in dem die ganzen Docker configs liegen.

dd ist als tool im übrigen generell raus, weil ich einen Ordner /home/docker/recordings ausschließen möchte. Da liegen meine TVAufnahmen drin. Ohne die ist das ganze root backup dann wohl nur ca. 5GB groß.

[bluestar]

Ich wollte mich mal gerade dran setzen, das umzusetzen.

Leider bin ich über ein Problem gestolpert. Meine VG enthält zwei LV die zusammen 100% des Speichers belegen.

LVM Snapshots funktionieren aber anscheinend anders als bei btrfs oder zfs. Hier wird ein neues LV erzeugt. Dafür braucht man natürlich Platz, den ich jetzt nicht habe.

Du könntest risikofrei dein Swap-LV verkleinern.

dd ist als tool im übrigen generell raus, weil ich einen Ordner /home/docker/recordings ausschließen möchte. Da liegen meine TVAufnahmen drin. Ohne die ist das ganze root backup dann wohl nur ca. 5GB groß.

Vielleicht solltest du da auch mal drüber nachdenken für /home ein eigenes LV anzulegen um deine Daten besser vom System zu trennen.

[Simaryp]

Ah stimmt. Das muss ja nicht zwanghaft die gleiche Größe wie der ram haben.
Kann ich das SWAP auch live umounten und dann shrinken? Dann muss ich den Server gar nicht runter fahren.

/home auf extra Laufwerk mache ich eigentlich nicht mehr. War mir immer unsicher, ob ich am Ende den Bedarf nicht falsch einschätze und ich hab den Vorteil für mich nicht wirklich gesehen.

[Tintom]

Ah stimmt. Das muss ja nicht zwanghaft die gleiche Größe wie der ram haben.
Kann ich das SWAP auch live umounten und dann shrinken? Dann muss ich den Server gar nicht runter fahren.

Das sollte mit swapoff -a funktionieren. Anschließend dann SWAP verkleinern.

/home auf extra Laufwerk mache ich eigentlich nicht mehr. War mir immer unsicher, ob ich am Ende den Bedarf nicht falsch einschätze und ich hab den Vorteil für mich nicht wirklich gesehen.

Die separate Partition für /home erleichtert vieles. Ich kenne dein Anwendungsszenario nicht, aber für gewöhnlich (Desktopbenutzer) übersteigt die Datenmenge in /home die des restlichen Systems um ein vielfaches. Wenn du es umgekehrt betrachtest ist es evtl. einfacher: Du kannst anhand deiner Gewohnheiten eher abschätzen, wie groß / ohne /home sein muss, entsprechend kannst du / dann partitionieren und /home bekommt dann den Rest zugewiesen.

[Simaryp]

Danke, werde es ausprobieren.

Das Debian System ist mein Server. /home ist quasi leer, bis auf ein paar Skripte in meinem admin account und den docker Ordnern. Das einzige waa groß ist, sind die TVAufnahmen, die ich nicht über den zpool laufen lassen wollte.

Auch auf meinen clients nutze ich keine extra home Partition. Ich habe da keine dauerhadten Daten und wenn ich mal neu installieren muss, kann ich da auch tabula rasa machen. Ich leg mir aber demnächst mal ein github repo an für meine dotfiles, weil ich da zuletzt doch ein wenig Zeit rein gesteckt habe.

[Simaryp]

Das mit dem verkleinern vom Swap hat funktioniert. Das Snapshot erstellen funktioniert auch.

Ich habe mich dazu entschieden, keine extra Borg repositories dafür anzulegen, sondern einfach ein tar.gz in den Pool zu schreiben, der dann gebackupt wird.

Ich habe mir dafür ein Skript geschrieben, aber irgendwie will es noch nicht klappen und ich verstehe das nicht. Vielleicht sieht ja hier jemand das Problem.

Hier ist das Skript:

Code: Alles auswählen

#!/bin/bash

# This script automates a backup of the root lv of gringotts-vg via tar of a lvm snapshot run on demand.
# A snapshot volume of the root lv is created is created to avoid data corruption caused
# by file changes during backup process. The snapshot is mounted to the MountDir
# and a tar command is issued to create a compressed backup of selected files. 
# The /home/docker/recordings folder as well as folders filled during boot like /dev, /sys etc. are excluded.
# Afterwards the snapshot is unmounted and deleted.

IFS=$'\t\n'

#
# Getting time stamps
#

Day="$(date '+%Y-%m-%d')"
WeekDay="$(date '+%A')"
Time="$(date '+%H:%M:%S')"
TimeStamp=$Day" "$Time
TimeStampName=$Day"T"${Time//":"/"-"}

#
# Setting Variables
#

BackupName="/pool/jacob/Programme/Linux/"$TimeStampName"-root-backup.tar.gz"
MountDir="/mnt/backup/root"

#
# Backup section
#
echo "Backup of gringotts root lv to $BackupName on zpool is started at $TimeStampName."

# Create snapshot and mount it for backup to avoid conflicts and data corruption by changing files during backup
echo "Create lvm snapshot root_snap and mount snapshot to $MountDir:"
lvcreate -l100%FREE -s -n root_snap /dev/gringotts-vg/root
sleep 3
mount /dev/gringotts-vg/root_snap $MountDir
sleep 3

# Create archive of snapshot
tar -cvpzf $BackupName \
	--exclude=$MountDir/dev \
	--exclude=$MountDir/media \ 
	--exclude=$MountDir/mnt \
	--exclude=$MountDir/proc \
	--exclude=$MountDir/run \ 
	--exclude=$MountDir/sys \
	--exclude=$MountDir/tmp \
	--exclude=$MountDir/var/cache/apt/archives \
	--exclude=$MountDir/home/docker/recordings \
	--exclude=$MountDir/pool \
	$MountDir /boot

# Unmount and destroy snapshot
echo "Unmount and destroy snapshot:"
umount $MountDir
lvremove /dev/gringotts-vg/root_snap

echo "Backup process finished."

Eine Sache ist etwas unschön dabei. Die Dateien im Backup haben dann alle vorne weg den Mountpunkt des Snapshots. Keine Ahnung, ob das beim entpacken bei einer Wiederherstellung Probleme macht.

Das größere Problem ist aber, dass es noch nicht funktioniert. Ich erhalte die Fehlermeldung:

Code: Alles auswählen

tar:  : Funktion stat fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler
/etc/backups/./tar-root.sh: Zeile 46: --exclude=/mnt/backup/root/mnt: Datei oder Verzeichnis nicht gefunden
/etc/backups/./tar-root.sh: Zeile 49: --exclude=/mnt/backup/root/sys: Datei oder Verzeichnis nicht gefunden

Schaue ich aber solange der Snapshot gemountet ist mit ls, dann finde ich bei $MountDir/mnt etwas. sys ist zwar leer, aber es gibt keinen Fehler.

Ich verstehe das nicht .

[Simaryp]

Habe es hinbekommen. Da waren ein paar Leerzeichen und ich musste noch etwas mit dem tar Befehl rumspielen .

Das einzige Minimanko ist, dass in diesem tarball natürlich auch keyfiles etc. drin sind und ich mit meinem normalen Useraccount zugriff drauf habe. Naja, das kleine Sicherheitsmanko werde ich wohl verkraften.

[Tintom]

Habe es hinbekommen. Da waren ein paar Leerzeichen und ich musste noch etwas mit dem tar Befehl rumspielen .

Kannst du das bitte nochmal im Detail beschreiben? Ich habe gestern das Skript gefühlt zehn Mal gelesen aber keinen Fehler erkennen können.

[Simaryp]

Wenn man hinter media \ und run \ schaut, sieht man extra Leerzeichen. Die haben zum Absturz geführt. Ich habe parallel bei reddit nach ein bisschen Hilfe gesucht.

Dann habe ich noch Probleme mit der richtigen Benutzung von --exclude gehabt. Das hat seltsamerweise teilweise nicht funktioniert, wobei ich fest davon ausgegangen wäre, dass es gehen müsste.

Final sieht das Skript jetzt so aus, falls jemand etwas ähnliches machen möchte. Ich habe dann noch etwas rumgefrickelt und den tar output in openssl umgeleitet.

Code: Alles auswählen

#!/bin/bash

# This script automates a backup of the root lv of gringotts-vg via tar of a lvm snapshot run on demand.
# A snapshot volume of the root lv is created is created to avoid data corruption caused
# by file changes during backup process. The snapshot is mounted to the MountDir
# and a tar command is issued to create a compressed backup of selected files. 
# The /home/docker/recordings folder as well as folders filled during boot like /dev, /sys etc. are excluded.
# Afterwards the snapshot is unmounted and deleted.

IFS=$'\t\n'

#
# Getting time stamps
#

Day="$(date '+%Y-%m-%d')"
WeekDay="$(date '+%A')"
Time="$(date '+%H:%M:%S')"
TimeStamp=$Day" "$Time
TimeStampName=$Day"T"${Time//":"/"-"}

#
# Setting Variables
#

BackupName="/pool/jacob/Programme/Linux/"$TimeStampName"-root-backup.tar.gz"
MountDir="/mnt/backup/root/"

#
# Backup section
#
echo "Backup of gringotts root lv to $BackupName on zpool is started at $TimeStampName."

# Create snapshot and mount it for backup to avoid conflicts and data corruption by changing files during backup
echo "Create lvm snapshot root_snap and mount snapshot to $MountDir:"
lvcreate -l100%FREE -s -n root_snap /dev/gringotts-vg/root
mount /dev/gringotts-vg/root_snap $MountDir

# Create archive of snapshot
tar -cvpzf - \
    --exclude=./boot \
    --exclude=./dev \
    --exclude=./media \
    --exclude=./mnt \
    --exclude=./proc \
    --exclude=./run \
    --exclude=./sys \
    --exclude=./tmp \
    --exclude=./var/cache/apt/archives \
    --exclude=./home/docker/recordings \
    --exclude=./pool \
    -C $MountDir . /boot \
    | openssl enc -e -aes-256-cbc -pbkdf2 -out $BackupName -k Mypassword

# Unmount and destroy snapshot
echo "Unmount and destroy snapshot:"
umount $MountDir
lvremove /dev/gringotts-vg/root_snap

echo "Backup process finished."