Systembackup leicht erstellen und wieder einspielen

[snowy]

in einem anderen Thread wurde der richtige Hinweis gegeben

wenn er wirklich volle Systembackups hat und die leicht einspielbar sind, dann sollte er genau das auf dem neuen System machen

da bin ich immer noch auf der Suche nach einer Software, die so etwas leicht erstellt und auch leicht wieder einspielen läßt.
Unter Windows hatte ich so etwas, aber für Linux bin ich noch nicht fündig geworden

Für Tipps, Links und Tricks bin ich dankbar

[TomL]

in einem anderen Thread wurde der richtige Hinweis gegeben

wenn er wirklich volle Systembackups hat und die leicht einspielbar sind, dann sollte er genau das auf dem neuen System machen

da bin ich immer noch auf der Suche nach einer Software, die so etwas leicht erstellt und auch leicht wieder einspielen läßt.
Unter Windows hatte ich so etwas, aber für Linux bin ich noch nicht fündig geworden Für Tipps, Links und Tricks bin ich dankbar

Wenn es Dich interessiert und Du keine Angst vor langen Texten hast, kann ich Dir nen Link senden, in dem ich mal meine Gedanken zu Backups notiert habe... Betrachtungen zu den Fragen "Was muss, was muss nicht, was ist imho Blödsinn". Auf der Seite befindet sich dann auch der Link zur Programmbeschreibung meiner Backup-Lösung, die stabil läuft und abgesichert "gute" Backups erzeugt. Die Prämissen zur Entwicklung dieser Lösung waren "leicht, effektiv, zuverlässig und mannlos."

[NAB]

Das könnte ein langer Thread werden

Prinzipiell hast du die Wahl zwischen dateibasiertem und partitionsbasiertem Backup.
Das dateibasierte Backup wurde hier vor kurzem durchgekaut:
viewtopic.php?f=27&t=168825
(beachte den Beitrag/Thread von heisenberg)
Dabei stehst du immer vor der Frage, welche Dateien kopiert werden sollten. Eine Kopie von /dev/* ist zum Beispiel sinnlos. Und Dateien, in die gerade geschrieben wird, könnten in einem inkonsistenten Zustand sein. Und was mir an diesen Lösungen immer fehlt ist eine "einfache" Methode, das Backup zurückzuspielen.

Partitionsbasierte Backups machst du am besten über ein temporäres Raid1/Mirror, auf eine Methode dazu hatte ich dich hier schon aufmerksam gemacht:
viewtopic.php?f=13&t=169222#p1170196
Die lassen sich einfacher und konsistent zurückspielen, mit etwas Geschick ist sogar die gesamte Backup-Platte bootbar. Dafür verbraten sie (erheblich) mehr Speicherplatz.

[snowy]

Partitionsbasierte Backups machst du am besten über ein temporäres Raid1/Mirror, auf eine Methode dazu hatte ich dich hier schon aufmerksam gemacht:
viewtopic.php?f=13&t=169222#p1170196
Die lassen sich einfacher und konsistent zurückspielen, mit etwas Geschick ist sogar die gesamte Backup-Platte bootbar. Dafür verbraten sie (erheblich) mehr Speicherplatz.

wie ich in dem o.g. Link schon zu erkennen gegeben habe, bin ich ein ehemaliger Windoof-User
Da gab es Software-Lösungen, die einerseits "Images" von Partitionen erstellt habe, aber auch die Formatierung erkannten und leeren Platz nicht mitgesichert haben.
Und idealerweise konnte ich die verschlüsselten Partition im entschlüsselten Zustand sichern lassen, damit die Backup-Software auch den leeren Platz erkennen kann
z.B. 320GB sichern, obwohl nur 10% belegt sind, macht irgendwie auch kein Sinn, von der Sicherungsdauer mal ganz abgesehen

aber bisher habe ich zu (fast) jedem Windows-Programm immer eine gute Alternative unter Linux gefunden , nur beim Backup sieht bisher gefundenes alles so nach Bastellösung aus

Das könnte ein langer Thread werden

gerne

[NAB]

wie ich in dem o.g. Link schon zu erkennen gegeben habe, bin ich ein ehemaliger Windoof-User
Da gab es Software-Lösungen, die einerseits "Images" von Partitionen erstellt habe, aber auch die Formatierung erkannten und leeren Platz nicht mitgesichert haben.

Das lässt sich auch mit Bordmitteln zurechttricksen, indem man den leeren Platz auf der Partition vorher mit Nullen vollschreibt, der komprimiert sich dann zu fast Null. So richtig schön ist das aber nicht.

Mit den entsprechenden Windows-Programmen habe ich eher unschöne Erfahrungen gesammelt. Da ließ sich dann das mit Version 3 erstellte Backup mit Version 5 nicht wieder einspielen oder das Spezial-Bootmedium startete auf dem neuen PC nicht oder ähnliche Scherze. Darum schaue ich, dass ich Backups mit Bordmitteln hinbekomme. Ich bin aber gespannt, welche Alternativen hier im Thread noch genannt werden.

Und idealerweise konnte ich die verschlüsselten Partition im entschlüsselten Zustand sichern lassen, damit die Backup-Software auch den leeren Platz erkennen kann

Noch so ein Punkt ... soll das Backup verschlüsselt sein oder nicht? Wenn du unverschlüsselte Backups willst, wäre das LVM der richtige Ansatzpunkt, das liegt bei dir ja innerhalb des Crypt-Containers.

[snowy]

Noch so ein Punkt ... soll das Backup verschlüsselt sein oder nicht?

mein bisherige Windows-Lösung hat mir automatisch auch eine Verschlüsselung des Backups angeboten
ich verschlüssele die Festplatte in den Laptops und dann liegen die Backups unverschlüsselt auf externen Festplatten? Irgendwie auch nicht sinnvoll

Wenn es Dich interessiert und Du keine Angst vor langen Texten hast, kann ich Dir nen Link senden, in dem ich mal meine Gedanken zu Backups notiert habe... Betrachtungen zu den Fragen "Was muss, was muss nicht, was ist imho Blödsinn". Auf der Seite befindet sich dann auch der Link zur Programmbeschreibung meiner Backup-Lösung, die stabil läuft und abgesichert "gute" Backups erzeugt. Die Prämissen zur Entwicklung dieser Lösung waren "leicht, effektiv, zuverlässig und mannlos."

Klingt interessant, macht mich neugierig

[NAB]

mein bisherige Windows-Lösung hat mir automatisch auch eine Verschlüsselung des Backups angeboten
ich verschlüssele die Festplatte in den Laptops und dann liegen die Backups unverschlüsselt auf externen Festplatten? Irgendwie auch nicht sinnvoll

Stimmt. Dagegen kann man natürlich auch wieder was tun ... entweder die Datei verschlüsseln oder die gesamte externe Festplatte verschlüsseln. Aber das läuft dann immer wieder auf "Bastellösungen" hinaus. Der Vorteil dieser Bastellösungen ist aus meiner Sicht, dass ich jeden einzelnen Schritt verstehe. Das ist auch gleichzeitig ihr Nachteil ... man muss sie verstehen. Oder sollte es zumindest, falls dieses "Script aus dem Internet" dann doch mal versagt. Aber wirklich "leicht" ist das halt nicht ...

[debianoli]

Wozu willst du dein Backup verschlüsseln? Wenn du dein Backup auf einer USB Festplatte speicherst, genügt es doch, wenn die USB Festplatte verschlüsselt ist.

Dazu musst du zwischen einem Backup deiner User-Daten, also des User-Home, und dem des Betriebssystems unterscheiden. Das ist ja das Schöne an Linux: Betriebssystem und User-Daten sind sauber getrennt.

[uname]

Ich finde es sehr wichtig, dass man weiß was das Backup-Programm macht und dass man sich darauf verlassen kann, dass das Backup am Ende auch vollständig bzw. einsetzbar ist. Für den letzten Punkt bleibt einem am Ende nichts anderes übrig als von Zeit das Backup am besten auf einen weiteren System zu testen. Ist also das Backup überhaupt geeignet das System bei einen Hardwareschaden wiederherzustellen? Ist das Backup neu genug? ...

Für ein "dateibasiertes Backup" habe ich mal vor einiger Zeit eine kleine Alternative zu rsnapshot programmiert:
https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC
Das Script ist vielleicht nicht schön und für dich nicht wirklich interessant. Aber man kann den Quellcode lesen und somit verstehen, wie ein in diesen Fall inkrementelles Backup überhaupt funktioniert. Eine Black Box wie bei Windows ist immer mit der Gefahr verbunden, dass man zwar am Ende ein Backup, aber evtl. nicht von den benötigten Daten hat

Vielleicht noch soviel:
- Unterscheidung zwischen Systemdaten (vor allen Konfigurationen /etc), globale und root-Dateien (/usr/local, /opt/, root) und Benutzerdaten (/home)
- Sicherung der aktuellen Paketliste anstatt Sicherung von /usr, /usr/bin, /bin, /sbin, /usr/share, ...

Bei mir ist die Basis einer Neuinstallation immer ein Minimalsystem, Nachziehen der zuvor installierten Pakete und dann manuelles Rückkopieren von /etc, /root und /home . Fertig.

[schwedenmann]

Hallo

@uname

Bei mir ist die Basis einer Neuinstallation immer ein Minimalsystem, Nachziehen der zuvor installierten Pakete und dann manuelles Rückkopieren von /etc, /root und /home . Fertig.

Das geht (ich meine ein erfolgreiches Restore) natürlich nur bei einem Debian, das der reinen Debianlehre folgt. Also keine Fremdquellen in der sources.list oder gar per dpkg eingespielte Pakete aus diversen "dubiosen" Quellen.

Aber wie schon so oft in diversen backup-Threads, jeder hat sop sein Plaisierchen , SW-Vorlieben fürs Backup. Jeder rät zu was anderem.
Alles hängt aber auch von der Größenordnung ab.
Ich sichere aus sentimentalen Gründen mein System 1x pro Monat komplett immer noch per dar (kann übrigens verschlüsseln), höchste Kompression und Aufteilung in slices zu 4GB, das Ganze dauert auf meinem 8kerner für / (29GB belegt von 54GB) incl. einer Paritätserfassung per par2 rund 1Std, die Sicherung wird dann per luckybacku (rsync gui) auf eine lokale Sicherungsplatte geschoben und dann am WE per rsyncscript auf demnächst einen FreeBSD-Serever mit ZFS geschoben.Das /home und 3 weitrere Ordner mit userdaten wird so alle 2 Tage per rsync auf die lokale Backuppltatte geschoben. Zusätzlich sichere ich ähnlich wie @uname nioch /etc und die Paketliste täglich mit einem cronjob, um im Falle eines Falles mein System, auch per netinstall, /etc /home und der Paketliste zu 95% widerherstellen kann.

Aber wie gesagt, ich bin wohl der Einzigste hier im DF,., der dar einsetzt.

mfg
schwedenmann

P.S.
Da ich keine sensiblen Daten auf meinem verschlüsselten LVM-System habe, ist das backup auch nicht verschüsselt, den Aufwand und das Risiko im Falle eines benötigten Restores, ist mir zu groß.

[uname]

Ich sichere aus sentimentalen Gründen mein System 1x pro Monat komplett immer noch per dar

Kann man machen. Ich denke aber mehr als 5 GB deiner 29 GB an Daten sicherst du unnötig, da es sich dabei um Dateien und Programme aus extrahierten Debianpaketen handet. Natürlich kann man diese Dateien sichern, da man befürchtet evtl. was beim Backup zu vergessen. Aber sollte doch mal eine Datei korrupt sein, gelöscht werden oder die Rechte verbogen bleibt im Normalfall sowieso nur die Reinstallation des zugehörigen Debian-Paketes bzw. eine Neuinstallation.

Ich weiß nicht ob es eine gute Idee wäre bei einen versehentlichen "rm /usr/bin/x*" (Buchstabe x vergessen) per rsync einfach wieder /usr/bin geradezubiegen. Und wenn doch sollte man mindestens debsums drüberlaufen lassen (obwohl eigentlich nicht nötig). Bei deinem Backup hätte ich weniger ein ungutes Gefühl ... beim Restore von Systemdateien jedoch umso mehr.

Wobei: Bei den heutigen Datenmengen sind ca. 5 GB für Systemdateien gar nicht so viel und können ignoriert werden.

[ThorstenS]

Ich habe zuletzt 2011 mit dar/dar_static gearbeitet, war damit auch recht zufrieden, hatte ich auch jedem Host laufen
Worauf man allerdings achten muß ist, dass der catalogue unter /root im Laufe der Zeit ordentlich wächst und dir im schlimmsten Fall dein rootfs vollschreibt.
Mittlerweile benutze ich aus Bequemlichkeit auch privat die kostenlose Version von veeam (sichert auf den NFS-Server): https://www.veeam.com/de/linux-backup-free.html

[snowy]

- Unterscheidung zwischen Systemdaten (vor allen Konfigurationen /etc), globale und root-Dateien (/usr/local, /opt/, root) und Benutzerdaten (/home)
- Sicherung der aktuellen Paketliste anstatt Sicherung von /usr, /usr/bin, /bin, /sbin, /usr/share, ...

Bei mir ist die Basis einer Neuinstallation immer ein Minimalsystem, Nachziehen der zuvor installierten Pakete und dann manuelles Rückkopieren von /etc, /root und /home . Fertig.

diesen Ansatz hatte ich auch schon einmal, aber mangels noch nicht vorhandenen Kenntnissen (was muß ich sichern, was darf ich niemals zurück spielen, etc), bisher nie umgesetzt

Wie kann ich denn automatisch die Paketliste (per cronjob) immer sichern?
Und wie spiele ich dann diese Liste notfalls wieder ein?
In Synaptic habe ich zwar nun eine (vermeintliche) GUI-Lösung gesehen, aber dies ist mir zu unsicher. Die manuell angestoßene Listen-Erstellung ist mit Sicherheit nie auf dem aktuellen Stand.

[schwedenmann]

Hallo

Wie kann ich denn automatisch die Paketliste (per cronjob) immer sichern?

z.B. so paketliste + /etc

sudo dpkg --get-selections >/shared/nathan64pakete$(date +_%d_%b_%Y-%R).txt | sudo tar -czvf /shared/etc$(date +_%d_%b_%Y-%
R).tar.gz /etc/

nach /etc/daily kopiert

außerdem die sudoers bearbeitet, wegen su + PW bei dpkg

neben cron noch anacron installiert und das Script sichert daily

mfg
schwedenmann

[debianoli]

Ein weiterer, sehr einfacher Weg zum Sichern des gesamten Systems ohne User-Home ist tar. Das tar-Archiv kann man dann später wieder dort entpacken, wo man will, und mit wenigen Änderungen an 1 bis 2 Dateien wieder zum Laufen bekommen.

Man erstellt eine Datei EXCLUDE mit folgendem Inhalt:

Code: Alles auswählen

/proc/*
/sys/*
/home/*
/dev/*
/run/*

Dann sichert man per tar und das am Besten im Verzeichnis /home, damit man in keine Schleife kommt und die Sicherung selber immer wieder in sich sichern will:

Code: Alles auswählen

tar -cvz --exclude-from=EXCLUDE -f sicherung.tgz /*

Entpacken kann man es dann per

Code: Alles auswählen

tar -xvzf sicherung.tgz

Dann passt man evtl. noch die /etc/fstab und /etc/crypttab an. Per chroot führt man dann noch ein update-grub durch und es sollte alles wieder laufen.

[breakthewall]

Man erstellt eine Datei EXCLUDE mit folgendem Inhalt:

Code: Alles auswählen

/proc/*
/sys/*
/home/*
/dev/*
/run/*

Hier ist alles bis auf /home überflüssig, zumal tar standardmäßig keine virtuellen Dateisysteme verarbeitet. Mal davon abgesehen, dass vieles unter /sys und /proc, nicht mal mit Rootrechten ausgelesen werden kann.

Dann sichert man per tar und das am Besten im Verzeichnis /home, damit man in keine Schleife kommt und die Sicherung selber immer wieder in sich sichern will:

Code: Alles auswählen

tar -cvz --exclude-from=EXCLUDE -f sicherung.tgz /*

Entpacken kann man es dann per

Code: Alles auswählen

tar -xvzf sicherung.tgz

Warum am besten nach /home sichern, und nicht auf ein unabhängiges Volume? Des weiteren folgt --exclude bei tar festen Regeln, womit insbesondere die Reihenfolge in der Kommandozeile stimmen muss, sonst ist das unwirksam. Daher sollte --exclude immer das erste Argument sein. Beim Entpacken sind insbesondere die Parameter --unlink-first und --recursive-unlink praktisch, weil damit nur noch im Dateisystem verbleibt was auch Teil des Backups war. Alles andere wird restlos entfernt, womit ein Dateisystem recht schnell von unerwünschten Inhalten befreit werden kann, ohne danach suchen zu müssen. Auch ein Restore im laufenden Betrieb ist möglich, nachdem lediglich nur noch neu gestartet werden muss.

[debianoli]

Hier ist alles bis auf /home überflüssig, zumal tar standardmäßig keine virtuellen Dateisysteme verarbeitet. Mal davon abgesehen, dass vieles unter /sys und /proc, nicht mal mit Rootrechten ausgelesen werden kann.

Nein, das macht schon Sinn, da tar zB /sys auslesen will und es dabei zu Fehlern inklusive Abbruch der Operation kommt. So werden die Verzeichnisse ohne Inhalt angelegt.

[guennid]

Systembackup leicht erstellen und wieder einspielen

Um Meillo zu zitieren: Es gibt Dinge, die sind eben nicht einfach, auch wenn bestimmte Werbefuzzis es wider besseres Wissen immer und immer wieder behaupten.

Ein System-Backup gehört meiner Meinung nach dazu.

[breakthewall]

So werden die Verzeichnisse ohne Inhalt angelegt.

Und das dient welchem Zweck? Diese Verzeichnisse werden ohnehin bei jedem Neustart frisch generiert.

[debianoli]

Und das dient welchem Zweck? Diese Verzeichnisse werden ohnehin bei jedem Neustart frisch generiert.

/dev wird bei jedem Neustart neu angelegt? Bist du sicher?

[breakthewall]

/dev wird bei jedem Neustart neu angelegt? Bist du sicher?

Absolut sicher. In diesem Verzeichnis ist nichts persistent, und wird bei modernen Linux-Distributionen beim Neustart via udev generiert.

[KP97]

Über "Windoof" kann hier keiner so recht lachen, falls das lustig sein sollte.
Nenne das Betriebssystem aus Redmond doch so, wie es auch heißt.

Zum Thema:
1. fsarchiver - Konsolenprogramm Repo
2. partclone - Konsolenprogramm Repo
3. clonezilla - Konsolenprogramm Repo
4. rsync - Konsolenprogramm Repo
5. grsync - grafische Oberfläche Repo
6. luckybackup - grafische Oberfläche Repo
7. qt5-fsarchiver - grafische Oberfläche https://sourceforge.net/projects/qt4-fs ... =directory

Das ist nur eine kleine Auswahl, im Wiki gibt es zu diesem Thema weitere Infos.
Hätte man auch mit etwas Suche hier im Forum bzw. in Synaptic finden können.
Synaptic hast Du ja sicher installiert.

[NAB]

Hat jemand aktuelle Erfahrungen mit Clonezilla? Das kommt so einem rundum Windows-Backup-Programm, wie snowy es sucht, mMn noch am nächsten. Ich habe es mal verwendet, aber als ich damals auf LUKS Verschlüsselung umgestiegen bin, konnte die Clonezilla Live CD damit noch nichts anfangen, bei einem späteren Versuch konnte es noch nicht per UEFI booten ... es scheint dem aktuellen Debian (Stable) immer hinterherzuhinken. Da dachte ich mir mal wieder, dd (bzw. partclone) und gzip kann ich auch einfacher haben.

[TomL]

Um Meillo zu zitieren: Es gibt Dinge, die sind eben nicht einfach, auch wenn bestimmte Werbefuzzis es wider besseres Wissen immer und immer wieder behaupten.

Ein System-Backup gehört meiner Meinung nach dazu.

Ich bin mit meiner Meinung eigentlich völlig bei uname. Ein wirklich gutes, aktuelles und sicher verwendbares System-Backup ist primär nur deshalb so kompliziert, weil man dabei auf etwas besteht, was man unter Linux für ein Enduser-System m.M.n. eigentlich nicht braucht. Welchen Sinn hat es tatsächlich, 250.000 Dateien auf einem Enduser-Desktop zu sichern, wenn bei einem neuen Setup mit regulären Installer und anschließend manuell hinzugefügten Deb-Paketen mindestens 249.500 Dateien ganz automatisch wieder auf die Platte geschrieben werden? Ich sehe den jedenfalls nicht.

Unter Windows wäre das für mich keine Frage... da ist das so diffus, man kann sich auf nix verlassen, also sichert man am besten alles. Aber das trifft auf Debian imho überhaupt nicht zu. Debian ist so eindeutig strukturiert, dass man völlig gefahrlos ausschließĺich selektiv nur die wirklich wichtigen Sachen zu sichern braucht. Ich kenne alle meine Maschinen, egal ob Server oder Client, ich habe für alle Änderungen an zentraler Stelle entsprechende Doku's hinterlegt. Ich weiss an welchen Confs ich was verändert habe oder wo ich generell vom Standard abgewichen bin, und nix anderes als genau das sichere ich. Für Server und die Clients sind die jeweiligen Backups für das Betriebssystem immer pro Machine kleiner als 100 kb. Das ist so effektiv, so schnell passiert und so klein, dass ich das fast täglich machen könnte und dabei meine Backups sogar versionieren könnte.... was mir hinsichtlich meiner Confs dann gleich auch wieder den Rollback ermöglicht.

Allerdings... das gehört zur Erklärung.... die Speicherorte von Nutzerdaten und Betriebssystem sind rigoros physisch voneinander getrennt. Kein User kann irgendwas auf den OS-Partitionen machen, nicht mal ich selber mit meiner eigenen UID. Und natürlich werden die Nutzerdaten nach anderen Regeln gesichert, mit noch größerer Sorgfalt.... aber ich betrachte das als unterschiedliche Prozesse, als 2 verschiedene Prozesse. Jeder für sich ist aber eindeutig und auch einfach im Handling.

Meine Vorgehensweise bei unseren Systembackups ist eindeutig ausgerichtet: Ich will nach einem Crash keinesfalls den Restore eines alten Systems, sondern immer nur den Restore der alten Funktionalität... und das dann mit einer neuen und sauberen Installation.

j.m.2.c.

[scientific]

Ich kann dem Konzept von @TomL viel abgewinnen.
Setze selber jedoch auf BTRFS und nutze dessen Snapshots und Subvolumes weidlich aus.

Und weil rekusive Snapshotverschachtelungen nur sehr schwer zu sichern sind, und keines der Tools das bis vor 3 Jahren angeboten hat, hab ich mir selbst ein Python-Skript geschrieben, was das kann..

Lokale Snapshots brauche ich für Unfallwiederherstellung (z. B. Gestern, als mir ein irregewordenes Skript Homeverzeichnisse gelöscht hat... Einfach snapshot vom Backup, und innerhalb 1s ist das Home wieder hergestellt)... Und sonst liegen Backups auf einer externen Platte.