Auch wenn es ggf. offtopic ist (Mod kann es ja abtrennen):
tuxnix Kannst du mir konkret sagen, welche Verzeichnisse ich in meiner Datei: /[path]/snapshot_exclude.txt ausschließen muss, damit ich keine Verzeichnisse sichere in denen das laufende System gerade am Schreiben ist?
Oder sollte ich auch doch noch besser die aktuellen eingeloggten user abmelden bevor root das script automatisch ausführt?
Kommt auf $SOURCE an ;-) In deinem Beispielskript ist das ja:
SOURCE='/NAS/ /home/tuxnix/'
Das der User tuxnix und ggf. andere NAS-User Daten während des Backups verändern ist ziemlich wahrscheinlich. Eher als das sich z.B. im Root-FS /usr/bin/bash "ändert". Also ja: Ich würde die Sicherung ohne angemeldete User machen - außer ich nehme Inkonsistenzen bei Userdaten einfach in Kauf.
Bsp: Du editierst Tabelle A und die Anforderung ist ebenfalls daß du nach Abschluß des Editierens eine weitere Änderung in Datei B machen mußt um die Änderung in A zu dokumentieren. Wenn dein Backup-Lauf nun zeitlich ungünstig diese beiden Dateien "anfaßt" (rsync arbeitet nicht lexikalisch), dann ist die alte B-Datei(ungeändert) und die neue A-Tabelle(geändert) im Backup drin - also eine Inkonsistenz.
Snapshots als Quelle haben hier den eindeutigen Vorteil mögliche Inkonsistenzen auf eins, zwei Sekunden runterzubrechen im Gegensatz zu einem teils laaaangem rsync-Lauf (wobei rsync AFAIK intern über Dateilisten/Checksummen versucht solche Dinge zu vermeiden bzw. als Fehler meldet).
"Stolpersteine" beim Backup eines laufenden Systems aus Userseite:
a) Lockdateien. Während ein Programm/Prozedur läuft werden Dateien gelockt/gesperrt oder das Programm setzt ein Lockfile (pacman macht das z.B.). Wenn solche Lockfiles im Backup enthalten sind, dann wird die Anwendung nach einem Restore der Daten (inkl. des Lockfiles) erstmal meckern.
b) sqlite-Datenbankfiles vermerken AFAIK ihren Zustand (geöffnet, ungeöffnet) im Datenbank-File
c) Cache-Dateien/Ordner. Für User z.B. ~/.cache. Das würde ich definitiv vom Backup ausschließen wenn User noch aktiv sind während des Backups. Alles in diesem Verzeichnis (und Caches generell) kann von den Programmen/Prozeduren wieder hergestellt werden, dieser Vorgang dauert dann ggf. länger als wenn eben Daten direkt, aufbereitet vom Cache aus der Festplatte gelesen werden. Beispiel der font-cache: Wenn vorhanden werden Fontlisten etc. eben aus den Cacheeinträgen gelesen, wenn nicht dann wird diese Liste eben neu im Cache generiert.
Wenn $SOURCE nun '/' ist, also das Backup des Systems aus dem laufenden System gemacht werden soll:
a) zu deinen rsync-Flags kämen da IMHO unbedingt noch -A/--acls, -X/--xattrs und -H/--hard-links dazu. Das System an sich macht von alldem Gebrauch und benötigt diese auch bei einem Restore wieder.
b) Was soll ich excluden bzw. was kann sich normal im System verändern von Zeitpunkt X nach Y?
- Die ganzen virtuellen Dateisysteme (wie /proc, /dev, /sys usw.) Dieser werden ja bei jedem Boot neu erstellt bzw. enthalten "Daten" die nur genau zum Zeitpunkt X für das System von Bedeutung sind. Eine Zehntelsekunde später sind diese schon nicht mehr dieselben. Sowas braucht man nicht sichern, es wird eh "falsch" sein.
Wie stark diese "besonderen" Daten in heutigen Systemen eine Rolle spielen kann man sich beim Unterschied von
findmnt
zu
findmnt --real
vor Augen führen.
Bei rsync sehe ich nun oft die Syntax, daß bei --exclude eben explizit diese Ordner mit den "virtuellen" Dateisystemen mit drinstehen. Ich halte das für überflüssig, da rsync mit der Option -x/--one-file-system genau dafür eine bessere Lösung bietet.
Mein '/' ist auf /dev/sda3. Ohne --one-file-system müßte ich eine lange --exclude-Liste führen, und auch noch mein /home und /tank (andere Partitionen) ausschließen - aber halt, es muß ja /home/* und /tank/* sein, sonst sind die Mountpoints nicht im Backup, shit... - nebst etlichen NFS-Mounts in /mnt.
Mit --one-file-system kümmert sich rsync darum: Es werden nur Daten gesichert aus der Quelle '/' die sich auf sda3 befinden. Das bedeutet:
- kein /proc/, kein /sys/ usw. ABER: die Verzeichnisse /proc und /sys sind (leer) als Mountpoints im Backup, da die Verzeichnis(namen) zum Dateisystem auf sda3 gehören.
- Daten in meinem /home werden ausgeschlossen (ist bei mir sda4), aber ein (leeres) /home ist im Backup. Cool....
- /tank ist ein Verzeichnis was ich im Dateisystem auf sda3 angelegt habe, deswegen ist das im Backup. Der gemountete Inhalt (welcher von sdb1 kommt) ist hingegen ausgeschlossen. Cool....
Deswegen bietet -x/--one-file-system IMHO nur Vorteile, wird aber leider viel zu wenig genutzt. Übrigens kennen auch tar und cp diesen nützlichen Mechanismus. Ebenso das Tool du(diskusage), sehr nützlich z.B. als du -xhs /, was mir die Datenmenge einer Sicherung meines Root-Verzeichnisses auf sda3 anzeigt.
Beim Excluden kann ich mich dann auf wenige Verzeichnisse beschränken für Daten die ich von sda3 nicht gesichert haben will:
- Man kann /var/cache/* komplett ausschließen, ich beschränke mich immer auf /var/cache/pkg/*
- Ich sichere Logfiles aus /var/log i.d.R. mit, wohlwissentlich das es beim journald durchs Restore erstmal zu einem inkosistenten Logfile kommt - Nachteil von Binärlogfiles...
- /var/tmp/* schließe ich aus (ebenso /tmp/* wenn es nicht als tmpfs angelegt ist)
Ansonsten muß man IMHO für die rsync-Sicherung des '/'-Wurzel als Betriebssystem nichts groß beachten in punkto Daten die während des Betriebs auf realem Speicher verändert werden.
- No-Go's sind klar Dienste wie SQL-Server oder Hintergrund-pacman-Syu-Vorgänge. Wer solche Dienste vor einer Sicherung nicht abstellt ist selbst schuld.
- Das blanke System an sich "schreibt" v.a. kontinuierlich in Logfiles und Caches (also /var/{log|cache}) auf reale Dateisysteme. Eine Inkonsistenz dieser Daten kann/muß man dann bei einem Restore in Kauf nehmen, ist aber bei 98,45% der Systeme vernachlässigbar ;-) (Ich hab extra nochmal nachgerechnet...)
Habe ich mein '/' fürs System weiter auf mehrere Partitionen aufgeteilt (z.B. /var und/oder /usr oder /usr/share auf anderen Partitionen), dann muß ich bei --one-file-system natürlich separate Sicherungen ebenfalls dieser Dateisysteme machen und wieder herstellen - am Ende muß ich aus OS-Sicht eben ein "komplettes" System auf der Zielplatform haben. Das gilt auch für /boot wenn es eine eigene Partition ist, bei UEFI ja AFAIK ein Muß.
Es ist also IMHO kein Problem ein laufendes System zu sichern zum Zwecke einer späteren Systemwiederherstellung - wenn man einiges beachtet. Der bessere,sicherere Weg ist natürlich eine Sicherung eines nicht gestarteten Systems, also Sicherung z.B. über den Archlinux-Install-Medium.
NB: Noch was zu deinem Skript, ich habe nur kurz drübergeschaut. Du nutzt ja auch inkrementale Zeitpunkt-Sicherungen, bei denen unveränderte Daten über Hardlinks geregelt werden.
In deinem Skript hast du dafür einen extra cp-Lauf (bei echo "Copy Hardlinks:"). Das kann rsync auch selbst, schau dir mal in der manpage --link-dest an. Wenn für --link-dest das Verzeichnis mit dem letzen Backup angegeben wird, dann werden unveränderte Files daraus ins neue Ziel automatisch hardverlinkt und nur veränderte Files werden real neu gesynct. Kannst ja mal bei Lust und Laune mit rumspielen.
chepaz Vor allem sollte man eines: Das recovern durchspielen und testen bevor man es wirklich braucht.
!!!!!!!!!!!!!
Jep, dieser Schritt im gesamten "Wir-machen-jetzt-Backup-koste-es-was-es-wolle" ist nämlich eigentlich der Wichtigste im gesamten Komplex. Und der am stiefmütterlichst behandelte, leider.
Man kann das in virtuellen Maschinen so gut testen... Und wenigstens einmal sollte man es mit dem realen System gemacht haben, und einen Backup/Restore-Ordner auf Papier anlegen und neben dem Rechner liegen haben...