Voll-Backup eines Linux Systems im laufenden Betrieb

[DecaTec]

Hi!

Ich habe mich in letzter Zeit ein wenig mit Linux beschäftigt (komme aus der Windows-Welt) und bin nun an einem Punkt angekommen, wo ich trotz vieler Rumprobiererei nicht mehr weiterkomme. Ich hoffe, es gibt hier ein paar fachkundige Linuxer, die mir hier weiterhelfen können.

Ich möchte in naher Zukunft ein Linux-System auf einem Intel NUC aufsetzen. Zum Einsatz kommt hier entweder Debian oder Ubuntu Server (beides ohne grafische Benutzeroberfläche!). Darauf möchte ich einen LEMP-Stack (Nginx, MariaDB, PHP) betreiben.
Nun stellt sich die Frage, die ich von der Kiste am besten Backups machen kann. In der Windows-Welt geht das recht einfach und schnell mit der Systemabbildsicherung: Hier geht das ganze schnell, automatisiert und ein System lässt sich nach einem Ausfall innerhalb von Minuten wieder herstellen. Genau das gleiche hätte ich gerne auch unter Linux. Ganz wichtig ist, hier dass es sich um ein Live-Backup handeln muss, welches im laufenden Betrieb angefertigt werden kann.

Ich habe schon viel im Internet gesucht, aber konnte hier noch keine zufriedenstellende Lösung ausfindig machen. Dump oder dd wären zwar in der Lage, komplette Backups machen zu können, aber man sollte damit kein Live-System sichern (siehe hier). Im genannten Artikel ist zwar die Rede davon, vorher einen Snapshot anzulegen (ich werde auch LVM verwenden, sollte also kein Problem sein), jedoch habe ich das bisher nicht hinbekommen (der Artikel liefert hier nur Pseudo-Anweisungen).

Daher die Frage: Wie kann man das Vorhaben einfach und effektiv umsetzen? Diese Anforderung werden ja auch schon andere gehabt haben.
Ist die Sicherung des kompletten Dateisystems vielleicht auch gar nicht notwendig? Es geht ja primär darum, den LEMP-Stack zu sichern.

Wäre für jeden Tipp dankbar.

 

[DecaTec]

Ja, das war wohl nicht der korrekte Begriff. Ich habe den Thread-Titel angepasst.
Ich meine in der Tat ein Backup zur Laufzeit (Live-Backup/Hot-Backup).

 

[DecaTec]

Keiner eine Idee?

 

[fax668]

Schau dir mal Snapper an.

 

[DecaTec]

Schau dir mal Snapper an.

Wenn ich es richtig lese, ist dies ein Tool, um Snapshots anzufertigen und diese komfortabel zu verwalten. Ist nicht wirklich das, was ich suche.

Konnte gestern noch ein wenig herumprobieren: LVM-Snapshots anzulegen funktioniert nun.
Prinzipiell könnte das dann folgendermaßen ablaufen:

1. LVM-Snapshot der root-Partition erzeugen
2. Wegsichern aller Dateien aus der (Snapshot-)root-Partition (z.B. mittels rsync)
3. Snapshot enfernen

Zum Wiederherstellen dann:

1. Booten mit einer Live-CD
2. Mounten der wiederherzustellenden Partition
3. Zurückspielen des Backups (wieder mit rsync und --delete)
4. System normal booten

Für Disaster-Recovery (Platte defekt, o.ä) müsste man dann noch den Bootloader sichern/wiederherstellen.

Kann das ganze so funktionieren? Gerade weil rsync ja nur ein Backup auf Dateiebene durchführt...

 

[fax668]

Kann das ganze so funktionieren? Gerade weil rsync ja nur ein Backup auf Dateiebene durchführt...

Prinzipiell schon. Du musst nur aufpassen, dass /dev, /proc und diverse andere nicht mitgesichert werden.

SafeKeep macht im Prinzip genau das. Erst wird ein LVM Snapshot angefertigt, dann die Dateien mit rdiff-backup gesichert, dann der Snapshot deaktiviert.

 

[DecaTec]

SafeKeep macht im Prinzip genau das. Erst wird ein LVM Snapshot angefertigt, dann die Dateien mit rdiff-backup gesichert, dann der Snapshot deaktiviert.

Ein Client-/Server-System nur um simple Backups zu machen? Das muss doch irgendwie einfacher/intuitiver gehen...

Bin vorhin auf FSArchiver gestoßen. Werde das heute abend mal ausprobieren. Hat jemand damit schonmal Erfahrungen geasammelt?

 

[smutbert]

Ich würde etwas anders an die Sache herangehen:

In der Verzeichnisstruktur eines Linuxsystems (alles unterhalb von /) befinden sich viele Dinge, die es nicht Wert sind gesichert zu werden, bzw. Dinge die man gar nicht sichern kann.
/proc und /dev hat fax668 bereits erwähnt, darüber hinaus gibt es noch /sys, /run und/oder /var/run, /var/lock und vielleicht einige weitere. Fast allen diesen Verzeichnissen ist bei modernen Linuxdistributionen gemein, dass dort ein virtuelles Dateisystem gemountet ist, das auf keine Festplatte oder SSD existiert und die wird man mit einem einfachen Trick auf einen Schlag „los“.

Man mountet die zu sichernden realen Dateisysteme einfach in einem anderen Verzeichnis noch einmal, angenommen /dev/sda2 wäre das /-Dateisystem und es gäbe noch /dev/sdb1 mit /home. Dann könnte man einfach mit

# mkdir /mnt/rootfs
# mount /dev/sda2 /mnt/rootfs
# mkdir /mnt/homefs
# mount /dev/sdb1 /mnt/homefs

die entsprechenden Dateisysteme ohne den Inhalt von /sys, /proc, usw. noch einmal in /mnt/rootfs und /mnt/homefs mounten, es stört auch nicht weiter, wenn man das durch einen Eintrag in der fstab permanent macht. Von den neuen Mountpoints kannst du die Dateien und Verzeichnisse einfach mit cp, rsync, fsarchiver oder einem anderen Tool deiner Wahl auf ein anderes Speichermedium kopieren, synchronisieren oder was auch immer, ohne dass die virtuellen Dateisysteme im Weg wären.

Das Wiederherstellen erledigt man dann einfach ebenfalls mit rsync oder cp. Gegebenenfalls muss man sich noch etwas überlegen um auch den Bootloader wiederherzustellen, solange man die Festplatte/SSD nicht neu partitioniert und formatiert, sollte das aber noch kein Problem sein.


Ein Image kann man natürlich ebenfalls anlegen, im simpelsten Fall mit dd auf der Kommandozeile, allerdings bekommt man damit im laufenden Betrieb im Allgemeinen ein Image eines Dateisystems, das sich in einem inkosistenten Zustand befindet. Dagegen hilft auch das Snapshot-Feature von lvm alleine nichts, weil das Dateisystem gar nichts davon weiß. Etwas näher käme man der Sache mit einem Freeze des Dateisystems (xfs bietet das beispielsweise), dann dem Anlegen eines Snapshots und schließlich dem unfreeze des Dateisystems, aber das wird dann schon zu einer kleinen Herausforderung das alles vernünftig hinzubekommen...


Um den Inhalt eines Dateisystem zu sichern böte sich außerdem noch dump (für ext2/3/4 im gleichnamigen Debianpaket, für xfs im Paket xfsdump) an, aber damit habe ich keinerlei Erfahrungen.

 

[DecaTec]

So, habe nun (vermutlich) eine Lösung mit FSArchiver gefunden. Die ersten Tests auf einer VM sehen ganz gut aus. Nun muss die Sache nur noch in der Praxis funktionieren.

Falls jemand nach einer ähnlichen Lösung sucht, hier die einzelnen Schritte:

System wurde auf einer VM installiert

• OS: Ubuntu Server 15.04
• Installiert wurde mit LVM (Volume-Group heißt hier "Test-vg")
• Die Root-Partition nimmt nicht den gesamten Platz der HDD ein, hier habe ich für Snapshots 2GB frei gelassen
• Backup-Ziel ist eine Windows-Freigabe im Netzwerk

Backup anfertigen:

1. Windows-Freigabe mounten (benötigt cifs-utils):
   

   sudo mkdir -p /mnt/Freigabe
   sudo mount -t cifs //<IP-des-Backup-Servers>/Backup /mnt/Freigabe -o username=<Benutzer-auf-Windows-Rechner>

2. Snapshot anlegen (read-only), mit "lvdisplay" kann man sich Infos zur VolumeGroup anzeigen lassen:
   

   sudo lvmcreate -L1G -pr -s -n Snapshot /dev/Test-vg/root

   Hier kann man den Snapshot nochmal mit lvdisplay überprüfen.
   
3. Backup ziehen
   

   sudo fsarchiver savefs /mnt/Freigabe/image.fsa /dev/Test-vg/Snapshot

   Hier muss natürlich der Snapshot gesichert werden und nicht die Root-Partition!
   
4. Aufräumen (Snapshot löschen und Freigabe unmounten):
   

   sudo lvremove /dev/Test-vg/Snapshot
   sudo umount /mnt/Freigabe

Backup wiederherstellen:

1. Booten von Live-CD (z.B. SystemRescueCd)
   
2. Hier wieder die Windows-Freigabe mounten (s.o.)
   
3. LVM "laden". Wichtig, da ansonsten die LVM-Partitionen nicht sichtbar sind. Deshalb hat das Wiederherstellen bei mir immer nicht geklappt. Habe ewig gebraucht, um auf diesen "Trick" zu kommen:
   

   lvm vgsdcan -v
   lvm vgchange -a y

4. Partitionen prüfen, damit man die richtige Partition erwischt (in meinem Fall "dm-1"). Falls der vorherige Schritt nicht ausgeführt wurde, sieht man hier nur sda1 (o.ä.):
   

   fsarchiver probe

5. Backup wiederherstellen:
   

   fsarchiver restfs /root/Freigabe id=0,dest=/dev/dm-1

6. System normal starten

Wie gesagt: Es scheint nach dem ersten Test zu funktionieren. /boot, Grub, etc. werden damit natürlich nicht gesichert, d.h. für Disaster-Recovery taugt die Lösung nur bedingt. Aber die Wiederherstellung auf dem gleichen System funktioniert, das ist mir erst einmal das Wichtigste.
Das ganze lässt sich sicher auch mittels bash-Skript und cron automatisieren...

Vielleicht hat der eine oder andere ja noch einen Hinweis/Einwand zu dieser Lösung. Wäre super, denn ich habe mir das ganze jetzt innerhalb von 2 Tagen "zusammengefrickelt". Sozusagen meine ersten Linux-Erfahrungen. Keine Ahnung ob, das alles so stimmt...

@smutbert:
Ich weiß nicht, ob das mounten der zu sichernden Partitionen hier ausreicht. Wenn ich meine Root-Partition mounte (z.B. unter /mnt/root) und mit dem System weiter arbeite, dann sind die Änderungen doch in meiner Root-Partition, als auch unter /mnt/root "sichtbar". /mnt/root ist in diesem Sinne kein Snapshot, sondern nur meine gemountete Root-Partition, die in diesem Sinne immer noch "live" ist.
Oder sehe ich das falsch?

 

[smutbert]

Das siehst du richtig, aber es ist imho nur eine andere Ausprägung desselben Problems: Bei meiner Varianten können sich die Dateien während des Backups ändern, aber immerhin wird/bleibt das Zieldateisystem auf das das Backup geschrieben wird konsistent und rsync gibt beispielsweise eine Warnung aus, wenn Dateien während des Backups geändert wurden - dann könnte man den Vorgang einfach wiederholen, was bei rsync sehr schnell geht, womit die Wahrscheinlichkeit, dass das noch einmal auftritt stark verringert wäre.

Bei der Variante mit dem lvm-Snapshot dagegen hast du zwar einen Snapshot, der unverändert bleibt, aber wenn der in einem ungünstigen Moment gemacht wurde, dann ist das Dateisystem auf dem Snapshot in keinem besonders „guten“ Zustand.

 

[DecaTec]

Bei der Variante mit dem lvm-Snapshot dagegen hast du zwar einen Snapshot, der unverändert bleibt, aber wenn der in einem ungünstigen Moment gemacht wurde, dann ist das Dateisystem auf dem Snapshot in keinem besonders „guten“ Zustand.

Das sehe ich allerdings eher unkritisch: Auf der Linux-Kiste soll zunächst nur Fhem und owncloud laufen.
Fhem ist ein einfacher Perl-"Server", owncloud etwas komplexer mit Datenbank (MySQL bzw. MariaDB). Durch die ACID-Eigenschaften eines DBMS ist die Datenbank immer in einem konsistenten Zustand (sollte sie zumindest).
Da dürfte es ein einmal gemachter Snapshot auch einen konsistenten Zustand aufweisen - zumindest konsistent genug, um als Backup zu taugen.

Ein anderer Ansatzpunkt wäre natürlich, das fertig installierte Grundsystem mit Clonezilla zu sichern. Alle darauf folgenden Sicherungen erfolgen dann per Snapshot auf Datei-Ebene: MySQL-Dump, Systemdateien und User-Dateien bei owncloud und die Config-Dateien von Fhem.

Allerdings bin ich die "Ein-Klick-Lösung" von Windows gewohnt. Durch VSS sind hier einfache Live-Backups möglich, die auch innerhalb von wenigen Minuten wiederhergestellt werden können. Daher ist mein Ansatz nach wie vor die Sicherung per Image-Datei einer kompletten Partition.
Ich kann mir immer noch nicht vorstellen, dass es für Linux(-Server) keine äquivalente und ähnlich elegante Lösung gibt - ich habe sie bisher nur noch nicht gefunden.

 

[smutbert]

Wahrscheinlich gibt es sie und wir kennen sie nur nicht. Meine Ein-Klick-Lösung besteht in einem selbstgeschriebenen Skript, das mein Server, der die Backups macht, automatisch ausführt um eine Sicherung durchzuführen (bei mir mit Snapshots auf Dateisystemebene (btrfs) da gibt es keines dieser Probleme und da jedes Mal nur die Änderungen übertragen werden, ist das Backup in wenigen Sekunden erledigt).

 

[fax668]

Allerdings bin ich die "Ein-Klick-Lösung" von Windows gewohnt. Durch VSS sind hier einfache Live-Backups möglich, die auch innerhalb von wenigen Minuten wiederhergestellt werden können. Daher ist mein Ansatz nach wie vor die Sicherung per Image-Datei einer kompletten Partition.
Ich kann mir immer noch nicht vorstellen, dass es für Linux(-Server) keine äquivalente und ähnlich elegante Lösung gibt - ich habe sie bisher nur noch nicht gefunden.

Ich habe VSS bisher noch nie benutzt, daher frage ich mich, inwiefern sich das von Snapper unterscheidet? Snapper lässt sich übrigens sogar in manche Paketmanagementtools einhängen und macht automatisch einen Snapshot, bevor das System aktualisiert wird.

 

[DecaTec]

Ich habe VSS bisher noch nie benutzt, daher frage ich mich, inwiefern sich das von Snapper unterscheidet?

Also ich habe mich nun mal etwas mehr in das Thema reingelesen: Snapper basiert auf btrfs-Snapshots und bietet hier einige Komfort-Funktionen. btrfs-Snapshots sind denke ich durchaus vergleichbar mit VSS.

Das hat mich dann auf die Spur von btrfs gebracht: btrfs-Snapshots sind wohl auch robuster als LVM-Snapshots. Ist also eine Überlegung wert, Ubuntu direkt auf einer btrfs-Partition zu installieren.

Meine Ein-Klick-Lösung besteht in einem selbstgeschriebenen Skript, das mein Server, der die Backups macht, automatisch ausführt um eine Sicherung durchzuführen (bei mir mit Snapshots auf Dateisystemebene (btrfs) da gibt es keines dieser Probleme und da jedes Mal nur die Änderungen übertragen werden, ist das Backup in wenigen Sekunden erledigt).

Könntest du dein Skript hier mal posten?
Wie realisierst du ein Zurückspielen eines Backups?

 

[smutbert]

Zurück spiele ich einfach auf der Kommandozeile mit rsync oder wenn das Backup auf einer externen Platte liegt, mit cp, ohne dass ich daran gedacht habe das zu automatisieren. Das habe ich bis jetzt noch nie wirklich gebraucht und nur zur Sicherheit getestet, wobei mir das relativ leicht fällt, weil ich schon lange hauptsächlich Linux nutze und mich auf der Kommandozeile recht zu Hause fühle.
Auch wenn ich neu partitionieren und formatieren muss und deswegen den Bootloader neu installieren muss, fällt mir das nicht sonderlich schwer.


So habe ich angefangen (weiterentwickelt habe ich nur insofern als jetzt das Backup mit ssh über das Netzwerk läuft)
https://debianforum.de/forum/viewtopic.php?f=37&t=142116

dann hat scientific aus dem Debianforum die Grundidee aufgegriffen und selbst ein Skript geschrieben
https://debianforum.de/forum/viewtopic.php?f=9&t=156133
https://wiki.debianforum.de/Snapshots_und_Backup_mit_btrfs

Meine aktuelle Version zeige ich nur her, wenn du darauf bestehst ☺ - für das Skript schäme ich mich etwas. Momentan habe ich aber sowieso keinen Zugriff darauf - ich könnte es frühestens nächste Woche posten.

 

[DecaTec]

Zurück spiele ich einfach auf der Kommandozeile mit rsync oder wenn das Backup auf einer externen Platte liegt, mit cp, ohne dass ich daran gedacht habe das zu automatisieren.

Sorry, wenn ich langsam nerve, aber ich steh grad etwas auf der Leitung.

Habe nun Ubuntu Server mit btrfs auf VM installiert. Snapshots anfertigen und zurückspielen klappt nun (alles lokal!).
Das einzige, was mir nun noch fehlt: btrfs-Snapshot anfertigen und diesen Snapshot auf eine Windows-Freigabe übertragen. Das ginge vermutlich mit rsync (auch wenn das Ziel NTFS-formatiert ist?).

Aber wie spiele ich diesen Snapshot dann von der Windows-Freigabe zurück?


Edit: gleich noch eine Frage im Anschluss:

Habe die Partitionierung folgendermaßen vorgenommen:


Nun habe ich nach der Installation des OS 3 Subvolumes:

• @
• @home
• @/var/lib/machines

@ und @home ist wohl so eine Sache von Ubuntu. Aber wo kommt das "@/var/lib/machines" her? Das ist ja wohl ein Sumvolume von "@".

 

[smutbert]

Keine Angst du nervst nicht. Mit rsync kann man jedenfalls über ssh/sftp in der Form von (nur als ganz grobes Beispiel)

# rsync -a /mnt/zu_sichernde_Daten benutzername@backupserver:/mnt/backup
# rsync -a benutzername@backupserver:/mnt/backup /mnt/wiederherzustellende_Daten

Ordner kopieren bzw. synchronisieren. Das heißt ich habe zu dem Zweck nie etwas mit einer Freigabe oder etwas vergleichbarem gemacht, weil ich über ssh/sftp sowieso Zugriff habe und den auch brauche, damit ich über das Netzwerk btrfs-snapshots machen kann.

Bei mir gibt es 2 Rechner, den Desktop der gesichert werden soll und den Server auf dem das Backup gespeichert werden soll. Hier ein Überblick was ich mache, bzw. was mein Skript tut:

• Auf dem Desktop einen read-only-Snapshot vom zu sichernden btrfs-Subvolume anlegen und sicherstellen, dass auf dem Server ein btrfs-Volume zum speichern des Backups existiert.
• Mit rsync den read-only-Snapshot auf dem Client mit dem btrfs-Subvolume auf dem Server synchronisieren.
• Auf dem Server einen read-only-Snapshot vom btrfs-Subvolume anlegen.
• Den bereits gesicherte read-only-Snapshot auf dem Client wieder löschen.

Damit sammeln sich die älteren Backups in Form von read-only-Snapshots auf dem Server und es existiert ein Subvolume mit dem beim Backup immer synchronisiert wird und das daher zusätzlich zum letzten read-only-Snapshot das letzte Backup enthält, zu dem mit rsync immer nur die geänderten Dateien übertragen werden müssen. Tatsächlichen Speicherplatz verbrauchen bei jedem Backup nach dem allerersten immer nur die geänderten Dateien und das sind auch die einzigen die übertragen werden müssen.




Mit NTFS bzw. Windowsfreigaben wird es _vielleicht_ etwas schwierig, weil Linux mit den Rechten von ntfs nichts anfangen kann und auch keine erweiterten Dateiattribute oder dergleichen speichern kann. _Vielleicht_ deshalb weil Linux ja gar nicht direkt mit ntfs in Berührung kommt sondern vermutlich nur über die Windowsfreigaben also cifs/smb darauf zugreift und dann genügt es wenn Windows mit ntfs umgehen kann ☺ und smb/cifs auch die Metadaten wie Rechte und Attribute überträgt — ich habe nicht die geringste Idee ob letzeres der Fall ist.
Schlimmstenfalls müsstest du das Backup eben in einer Art Container oder Archivdatei speichern, aber das ist etwas was ich auf keinen Fall wollte, aber einen ssh/sftp-Server gäbe es auch für Windows, genauso wie rsync — wollte nicht sogar Microsoft im Rahmen der Powershell so etwas schreiben?

Um Containern, Archiven, Images aus dem Weg zu gehen (sind mir zu unhandlich) würde ich sonst wahrscheinlich eher zu backintime [2] greifen. Das speichert Rechte und Attribute noch einmal getrennt, es sind aber trotzdem alle gesicherten Dateien einzeln zugänglich und nicht in irgendwelchen Archiven versteckt.
Vielleicht wäre für dich auch "Relax-and-Recover" [3] das richtige. Der Name ist schon einmal sehr sympathisch und die Beschreibung klingt sehr vielversprechend.




zu BTRFS und den Subvolumes
Wenn man BTRFS anlegt gibt es bereits ein Volume, alle weiteren angelegten Subvolumes sehen aus wie Verzeichnisse, wenn man das komplette Dateisystem betrachtet. Es kann aber eben auch "beginnend mit einem Subvolume" gemountet werden, dann ist nur das sichtbar was sich unterhalb dieses Subvolumes befindet.

Ubuntu und womöglich auch Debian beginnnt die Namen der selbst angelegten Subvolumes für das System mit @, das root-Dateisystem liegt also in @ die Homeverzeichnisse in @home (und wird dann verwirrenderweise in @/home bzw. eigentlich /home gemountet), usw.
/var/lib/machines ist nur ein weiteres Subvolume, es liegt in @ im Verzeichnis var/lib und heißt machines, komplette Name ist also @/var/lib/machines
Dieses Verzeichnis gehört zur libvirt-Virtualisierung zB mit gnome-boxes und dort werden die Images für die virtuellen Maschinen gespeichert. libvirt macht dabei offensichtlich regen Gebrauch von den btrfs-Features und legt ein eigenes subvolume an. Falls man ein anderes Dateisystem verwendet wird an der Stelle offensichtlich ein btrfs-Image für diese Daten angelegt [1], damit man trotzdem die btrfs-Features nutzen kann.


[1] systemd/systemd - System and Session Manager
[2] https://wiki.ubuntuusers.de/back_in_time
[3] Relax-and-Recover - Linux Disaster Recovery

 

[DecaTec]

Erst einmal danke für deine ausführliche Erklärung!

Ich habe mir nun folgendes Backup-Konzept erdacht:

1. Disaster-Recovery
Nach der initialien Installation von OS/Programmen ziehe ich ein Image mit Clonezilla (kein Live-Backup). Dieses Backup ist nur für den allergrößten Notfall.

2. Allgägliche "Backups"
Für die alltägliche Arbeit verwende ich die btrfs-Snapshots (daher kein wirkliches Backup). Wenn z.B. neue Programme installiert werden, ziehe ich vorher einen Snapshot:

sudo mkdir /mnt/temp
sudo mount /dev/dsa6 /mnt/temp
cd /mnt/temp
sync

btrfs subvolume create snapshot /mnt/temp/@ /mnt/temp/@_snap

cd ~
umount /mnt/temp

Falls dann irgend etwas schief gehen sollte, kann ein solches Backup wiederhergestellt werden:

mount /dev/dsa6 /mnt/temp
cd /mnt/temp
sync

mv /mnt/temp/@ /mnt/temp/@_old
mv /mnt/temp/@_snap /mnt/temp/@

# nach einem Reboot dann:
btrfs subvolume delete /mnt/temp/@_old

3. Backups auf Windows-Share:
In regelmäßigen Abständen können dann auch Backups auf der Windows-Maschine gespeichert werden:

mkdir /mnt/share
mount /dev/dsa6 /mnt/temp

mount -t cifs //<Server-IP>/Backups /mnt/share -o username=<Windows-User>

cd /mnt/temp
sync

# Snapshot
btrfs subvolume create snapshot /mnt/temp/@ /mnt/temp/@_tempsnap

# Backup über "Container" mittels tar
tar -cfz /mnt/share/Snap.tar.gz /mnt/temp/@_tempsnap

# Nach dem Abziehen der Daten kann der Snapshot wieder gelöscht werden
btrfs subvolume delete /mnt/temp/@_tempsnap

cd ~
umount /mnt/temp
umount /mnt/share

Die Wiederherstellung sieht dann so aus:

mount /dev/sda6 /mnt/temp
mount -t cifs //<Server-IP>/Backups /mnt/share -o username=<Windows-User>

cd /mnt/temp
sync

# Neues leeres Subvolume anlegen
btrfs subvolume create /mnt/temp/@_rollback

# Daten aus Archiv zurück spielen
tar -xzf /mnt/share/Snap.tar.gz  -C /mnt/temp/@_rollback

# Subvolumes umhängen
mv /mnt/temp/@ /mnt/temp/@_old
mv /mnt/temp/@_rollback /mnt/temp/@

# Nach einem Reboot dann
btrfs subvolume delete /mnt/temp/@_old

Wenn das @home Subvolume auch gesichert werden soll, sind die Befehle quasi zwei mal auszuführen.

Fragen:

• Würde das so klappen und Sinn machen? Habe ich evtl. was wichtiges vergessen?
• Sollte ich beim Archivieren mit tar excludes hinzufügen (wären dann vermutlich /dev /mnt /proc und /tmp)?
• Ein bisschen Sorgen bereitet mir auch nicht das Subvolume @/var/lib/machines, da das @-Volume nicht entfernt werden kann, wenn sich darin noch das andere Subvolume befindet. Wenn ich smutbert's Antwort richtig deute, kann ich @/var/lib/machines gefahrlos löschen, wenn ich keine virtuellen Maschinen einsetze. Ist das so korrekt?

 

[TCM]

Mal ein anderer Ansatz: Trenne Nutzdaten und "entbehrliche Daten". Erarbeite dir für die entbehrlichen Daten eine Methode, um sie jederzeit "from scratch" reproduzierbar in minimaler Zeit wieder zu installieren und sichere nur die Nutzdaten (WWW-Verzeichnis, Datenbank, ...) und die relevanten Configs.

Sprich, wenn deine Distribution eine Möglichkeit hat, den Install zu scripten, arbeite dich da ein. Bei Debian z.B. kann man mit debootstrap sehr schön Systeme per Script aufsetzen, die man gleich komplett mit den benötigten Paketen versehen kann.

1. System aufsetzen
2. Config wiederherstellen
3. Nutzdaten wiederherstellen

Das bietet gleichzeitig den Vorteil, dass man nicht den kompletten Zustand des Systems sichert (inkl. aller kleinen "Fummeleien" und Workarounds, die man irgendwann mal irgendwo reingehackt hat), sondern dass man quasi dadurch, dass man nur die relevanten Configs und die Nutzdaten sichert, den "gewünschten" Zustand angibt und diesen zuverlässig und reproduzierbar von einem sauberen Ausgangspunkt aus wiederherstellt. Wenn man das einmal ordentlich scriptet, kann man sein System in minimaler Zeit in einen definierten Zustand bringen.

Edit: Das erspart einem auch diese ganzen Fummeleien mit Snapshots. Eine Datenbank z.B. sollte man atomisch sichern können in einer Transaktion. Das WWW-Verzeichnis sollte sich auch nicht permanent ändern. Die Config in /etc ist sowieso statisch etc.

 

[smutbert]

Ja, das geht toll, aber ich vermute, dass es für den Anfang etwas viel zu wäre…

[…]
Fragen:

• Würde das so klappen und Sinn machen? Habe ich evtl. was wichtiges vergessen?

ja, im wesentlichen denke ich schon

• Sollte ich beim Archivieren mit tar excludes hinzufügen (wären dann vermutlich /dev /mnt /proc und /tmp)?

Das wird wohl gar nicht notwendig sein. Die gemounteten Dateisysteme, egal ob virtuell oder nicht, wirst du schon dadurch los, dass du das komplette btrfs-Dateisystem unter /mnt/temp noch einmal mountest und Teil des angelegten Snapshots sind sie schon erst recht nicht.
Nur wegen /tmp musst du dir vielleicht etwas überlegen, weil das in der Standardkonfiguration kein eigenes Dateisystem ist. Du kannst aber entweder bereits bei der Installation ein eigenes Dateisystem dafür anlegen oder auch später einfach ein eigenes subvolume dafür oder - und das wäre vermutlich das einfachste - du nutzt die Möglichkeit dort automatisch ein tmpfs mounten zu lassen, also ein Dateisystem, das nur im Hauptspeicher existiert.
Unter den aktuellen Distributionen (bei Ubuntu seit dem Umstieg auf systemd) erreichst du das mit dem Befehl

# systemctl enable tmp.mount

(und einem Neustart - ginge auch ohne, aber das wär uU etwas komplizierter)

• Ein bisschen Sorgen bereitet mir auch nicht das Subvolume @/var/lib/machines, da das @-Volume nicht entfernt werden kann, wenn sich darin noch das andere Subvolume befindet. Wenn ich smutbert's Antwort richtig deute, kann ich @/var/lib/machines gefahrlos löschen, wenn ich keine virtuellen Maschinen einsetze. Ist das so korrekt?

K.A. die werden womöglich wieder automatisch angelegt?

Du könntest aber die Pakete zur Virtualisierung deinstallieren, wenn du sie gar nicht brauchst. Das sollte die subvolumes ebenfalls verschwinden lassen. Eigentlich kannst du alle Pakete mit libvirt im Namen deinstallieren (inklusive Konfigurationsdateien heißt das dann bei apt und apt-get purge)

 

[DecaTec]

@TCM: Wäre sicherlich eine elegante Lösung. Allerdings reichen da meine Linux-Kenntnisse noch nicht ganz aus. Ebenfalls wird sich an dem System (gerade am Anfang) ziemlich häufig etwas ändern. Würde also erst dann Sinn machen, wenn man ein System soweit eingerichtet/konfiguriert hat, dass man da in Zukunft nichts mehr ändern muss.


Wegen /var/lib/machines: Ein Subvolume im Subvolume macht die ganze Sache aus Backup-Sicht etwas kompliziert. Daher werde ich dieses Subvolume löschen und dann nur Snapshots von @ und @home machen.
Nun werde ich das ganze mal am Wochenende durchprobieren und evtl. Skripts basteln. Vielleicht kommt dabei ja noch die eine oder andere Frage auf. Falls nicht, kann ich hier ja nochmal meine Ergebnisse posten.

Ich bedanke mich schonmal für eure Hilfe!

 

[fsironman]

Mal ein anderer Ansatz: Trenne Nutzdaten und "entbehrliche Daten". Erarbeite dir für die entbehrlichen Daten eine Methode, um sie jederzeit "from scratch" reproduzierbar in minimaler Zeit wieder zu installieren und sichere nur die Nutzdaten (WWW-Verzeichnis, Datenbank, ...) und die relevanten Configs.
[...]

Das kann ich nur so unterzeichnen. Ich wünsche mir zwar auch VSS unter linux. Aber im Gegensatz zu Windows wo es fast unmöglich ist nur mit Dateisicherungen auf den aktuellen Stand zu kommen ist das unter linux sehr einfach möglich.

Configs, Paketquellen und Liste installierter Pakete sowie /home sichern

Damit hat man 90 % abgedeckt.

Die restlichen 10 % z.B. selber compilierte Sachen aus erfordern etwas mehr Aufwand.
Aber wenn man hingeht und schon vorher den "sauberen" weg gewählt hat und das ganze in Pakete die man mitsichert gepackt hat, ist das auch abgedeckt.

 

[jdl]

Durch die ACID-Eigenschaften eines DBMS ist die Datenbank immer in einem konsistenten Zustand (sollte sie zumindest).
Da dürfte es ein einmal gemachter Snapshot auch einen konsistenten Zustand aufweisen

Genau das ist nicht garantiert! Wenn man von einem RDBMS ein Backup machen will, muß man den Inhalt der Datenbank dumpen und diesen Dump sichern. Dann und nur dann bekommt ein dank ACID einen konsistenten Zustand. Wenn Du einen Snapshot machen willst, mußt Du vorher das RDBMS herunterfahren. Das geht vielleicht bei einem Entwicklersystem oder eine Privatinstallation, aber nicht im kommerziellen Umfeld, da laufen die Kisten 24*365 durch.

Ein Snapshot nutzt Dir eigentlich nur etwas bei einem Bedienungsfehler. Wenn das System wirklich heftig crasht nützt Dir das sehr wenig, die einfachen Crashes werden dank des Journalings der FS ohnehin abgefangen. Also was erhoffst Du Dir von einem Snapshot?

Du solltest die Paketliste im Backup erfassen - dazu die Konfigurationen, und natürlich die Nutzerdaten. Dann kann man schnell den alten Zustand wiederherstellen. Bei Großinstallationen betreibt man spezielle Server, die diesen Prozeß mit Hilfe von vorgefertigten Images automatisiert erledigen. Da reicht es aus, die einzelnen Server wieder zu starten und sie ziehen sich ihr Image und die Konfiguration selbst. Nutzerdaten werden üblicherweise auf speziellen RAIDs oder iSCSI Targets ausgelagert.

 

[DecaTec]

Also das mit der DB ist mir auch schon aufgefallen. Hier ist vor dem Ziehen des Snapshots wohl ein "FLUSH TABLES WITH READ LOCK" notwendig. Mal gucken, ob das per Skripting möglich ist.

Und ja: Ich will ein System mit Snapshots, die ich jederzeit wieder zurück spielen kann, um Bedienfehler auszuschließen. Ich werde am Anfang sehr viel mit dem System ausprobieren und hier und da sicher einen Fehler machen, den ich durch das Zurückspielen von Snapshots wieder beheben kann.

 

[TCM]

Das klingt für mich völlig unlogisch, dass eine Datenbank ein Problem damit haben soll, wenn man ihren Dateibestand snapshottet.

Die Datenbank selbst sollte doch transaktional sein, so dass bei einem Stromausfall immer entweder die Transaktion durch ist und auch auf der Platte gelandet ist, oder nichts von der Transaktion permanent gespeichert ist. Und was ist ein Snapshot aus der Sicht des Filesystems, wenn man ihn zurückrollt? Ein simulierter Stromausfall.

 

[fax668]

Also das mit der DB ist mir auch schon aufgefallen. Hier ist vor dem Ziehen des Snapshots wohl ein "FLUSH TABLES WITH READ LOCK" notwendig. Mal gucken, ob das per Skripting möglich ist.

Das klingt für mich völlig unlogisch, dass eine Datenbank ein Problem damit haben soll, wenn man ihren Dateibestand snapshottet.

FLUSH TABLES wird von MySQL so empfohlen: https://dev.mysql.com/doc/refman/5.6/en/backup-methods.html. Wobei mir auch nicht klar ist, wieso man sich nicht einfach auf die Transaktionsfestigkeit der Datenbank verlassen sollte. In der Doku steht zwar nichts davon, aber vielleicht macht FLUSH TABLES implizit auch ein Dateisystem Flush? Sonst hat eventuell die Datenbank die Transaktion schon abgeschlossen, während das Dateisystem die letzte Operation noch brav im Speicher hält und nicht weggeschrieben hat, wenn der Snapshot kommt.

Wenn ich mir das so recht überlege, wäre es generell vielleicht keine schlechte Idee, ein sync direkt vor dem Snapshot auszuführen. Ich habe mal kurz geschaut, ob LVM oder btrfs das auch von sich aus machen, aber konnte auf die Schnelle nichts dazu finden.

 

[TCM]

aber vielleicht macht FLUSH TABLES implizit auch ein Dateisystem Flush? Sonst hat eventuell die Datenbank die Transaktion schon abgeschlossen, während das Dateisystem die letzte Operation noch brav im Speicher hält und nicht weggeschrieben hat, wenn der Snapshot kommt.

Dann ist die Datenbank fürn Arsch oder das Filesystem.

 

[fax668]

[X] Du kennst MySQL.

 

[DecaTec]

Um hier mal ne weitere Frage in den Raum zu werfen:
Spricht irgend etwas dagegen, btrfs auf einem LVM zu verwenden?

Mir ist bewusst, dass LVM eine Art "Partitions-Verwaltung" ist und btrfs ein Dateisystem. Beide überschneiden sich hier und da im Funktionsumfang (z.B. Snapshots).
Ich frage mich nur, ob es nicht sinnvoller wäre LVM wegzulassen und direkt btrfs zu verwenden. Jede zusätzliche Schicht in einem Software-System macht die Sache ja auch komplizierter...

 

[smutbert]

Probleme darf es eigentlich keine verursachen und wie du selbst schreibst überschneiden sie sich im Funktionsumfang.
Es kann aber auch Gründe geben trotzdem bei lvm zu bleiben, zB weil man in btrfs keine btrfs-fremden Volumes anlegen kann wie unter zfs und man mit lvm flexibler ist, zB um eigene lvs anzulegen für swap oder für virtuelle Maschinen oder vielleicht auch nur um andere Distributionen ausprobieren zu können ohne Angst haben zu müssen, dass das Installationsprogramm zuviel am btrfs herummanipuliert oder vielleicht einfach um einzelne lvs verschlüsseln zu können, usw.