Systembackup leicht erstellen und wieder einspielen
Re: Systembackup leicht erstellen und wieder einspielen
Im Grundprinzip kann ich @TomL ebenfalls zustimmen
Und wenn er selbst diszipliniert und korrekt alles dokumentiert, dann ist dies ein guter Weg. Respekt
User-Daten und System sind auch bei meinem und von mir "betreuten" Systemen immer getrennt. Das mehrfache Backup der Daten ein absolutes Muß.
Allerdings bin ich (leider) nicht so konsequent beim System wie @TomL
Es gibt immer wieder Situationen, wo an einem Gerät der User ein Problem mit dem System-Verhalten hat (persönliche Vorlieben, spezifische Hardware, ....)
Meist ist das Problem schnell gefunden, mit einer Einstellung behoben, aber über die Zeit entstehen dadurch "individuelle" System.
Ich befürchte im Falle eines Ausfalles (z.B. Plattencrash) das System nicht ohne weiteres wieder in den identischen Zustand bringen zu können, zumindest nicht ohne großen Zeitaufwand, der in aller Regel dann aber nicht vorhanden ist. Der User möchte sein System möglichst umgehend wieder einsetzen können.
Und wenn er selbst diszipliniert und korrekt alles dokumentiert, dann ist dies ein guter Weg. Respekt
User-Daten und System sind auch bei meinem und von mir "betreuten" Systemen immer getrennt. Das mehrfache Backup der Daten ein absolutes Muß.
Allerdings bin ich (leider) nicht so konsequent beim System wie @TomL
Es gibt immer wieder Situationen, wo an einem Gerät der User ein Problem mit dem System-Verhalten hat (persönliche Vorlieben, spezifische Hardware, ....)
Meist ist das Problem schnell gefunden, mit einer Einstellung behoben, aber über die Zeit entstehen dadurch "individuelle" System.
Ich befürchte im Falle eines Ausfalles (z.B. Plattencrash) das System nicht ohne weiteres wieder in den identischen Zustand bringen zu können, zumindest nicht ohne großen Zeitaufwand, der in aller Regel dann aber nicht vorhanden ist. Der User möchte sein System möglichst umgehend wieder einsetzen können.
Re: Systembackup leicht erstellen und wieder einspielen
Ich wollte eigentlich unter meinen letzten Beitrag noch eine Empfehlung für unames Tipp setzen, dessen Überlegungen auch ich für ziemlich sinnvoll halte. Ich hab's dann gelassen, weil man schließlich durchdenken muss, inwieweit man seine Setzungen teilt oder nicht teilt, was dann letztlich doch wieder darauf hinausläuft, dass es ein Systembackup nicht "leicht" ist, vor allem nicht in dem Sinne, dass man da lediglich ein bestimmtes Programm laufen lassen könnte. Ich würde es wohl ähnlich wie uname machen - nur für "leicht" halte ich das nicht. Wenn Thomas all seine individuellen Anpassungen so klar im Kopf hat, dass er sein backup sozusagen aus dem Ärmel schütteln kann, Respekt! Ich hätte das nicht, ich müsste mir da Verschiedenes "aufschreiben", überlegen, was und wie ich's "aufschreibe", und das halte ich eben nicht für "leicht".
"Leicht" steht in der Titelfrage, an der orientiere ich mich und behaupte, es ist nicht leicht.snowy hat geschrieben:wenn er selbst diszipliniert und korrekt alles dokumentiert
Re: Systembackup leicht erstellen und wieder einspielen
Mir fällt mal wieder auf, dass ausführlich diskutiert wird, was, wie und wieviel (oder eher wie wenig) an Daten gesichert werden muss ... aber beim Wiederherstellen wird's dann sehr dünn.
Neuinstallation und dann die alte Paketliste wieder einspielen? Würd bei mir scheitern, ich müsste erst die alte sources.list wieder einspielen. Ach nee ... würd auch nicht funktionieren ... ich müsste erst deb-multimedia wieder einkommentieren. Vielleicht. Müsste ich erst prüfen, je nach System. Mist, geht auch nicht, der blöde Keyring. Hoffentlich gibt's die alten Pakete noch ...
Dann /etc wieder einspielen? Zack, hätte ich mir das neue System mit den alten UUIDs geschrottet. Aber egal, die Kiste bootet eh nicht, weil er mir zwischendurch grub-efi durch grub-pc ersetzt hat und grub-install nur nen Fehler schmeißt.
Nee, "leicht" ist das nicht. Konsistent ist es auch nicht. Aber man spart ca. 10 GB an Backupvolumen (unkomprimiert). Das sind immerhin 40 Cent auf einer HDD! Also ... mal grob für Neuinstallation und Gefrickel gerechnet ... bei einem Stundenlohn unter 40 Cent ist man da eindeutig auf der Gewinnerseite!
Neuinstallation und dann die alte Paketliste wieder einspielen? Würd bei mir scheitern, ich müsste erst die alte sources.list wieder einspielen. Ach nee ... würd auch nicht funktionieren ... ich müsste erst deb-multimedia wieder einkommentieren. Vielleicht. Müsste ich erst prüfen, je nach System. Mist, geht auch nicht, der blöde Keyring. Hoffentlich gibt's die alten Pakete noch ...
Dann /etc wieder einspielen? Zack, hätte ich mir das neue System mit den alten UUIDs geschrottet. Aber egal, die Kiste bootet eh nicht, weil er mir zwischendurch grub-efi durch grub-pc ersetzt hat und grub-install nur nen Fehler schmeißt.
Nee, "leicht" ist das nicht. Konsistent ist es auch nicht. Aber man spart ca. 10 GB an Backupvolumen (unkomprimiert). Das sind immerhin 40 Cent auf einer HDD! Also ... mal grob für Neuinstallation und Gefrickel gerechnet ... bei einem Stundenlohn unter 40 Cent ist man da eindeutig auf der Gewinnerseite!
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Systembackup leicht erstellen und wieder einspielen
@NAB hat so rechtNAB hat geschrieben:06.04.2018 05:09:46Mir fällt mal wieder auf, dass ausführlich diskutiert wird, was, wie und wieviel (oder eher wie wenig) an Daten gesichert werden muss ... aber beim Wiederherstellen wird's dann sehr dünn.
<<....>>
Nee, "leicht" ist das nicht.
<<..>>
Re: Systembackup leicht erstellen und wieder einspielen
Ja, deshalb schließe ich den Inhalt ja aus. Aber das Verzeichnis muss vorhanden sein, deshalb das /dev/* in der EXCLUDE-Datei. Wenn man das nicht macht, muss man hinterher die Verzeichnisse händisch anlegen. Also braucht man die Einträge wie /sys/* und /proc/* in der EXCLUDE-Datei von tar eben doch.breakthewall hat geschrieben:05.04.2018 15:24:48Absolut sicher. In diesem Verzeichnis ist nichts persistent, und wird bei modernen Linux-Distributionen beim Neustart via udev generiert.
-
- Beiträge: 5631
- Registriert: 30.12.2004 15:31:07
- Wohnort: Wegberg
Re: Systembackup leicht erstellen und wieder einspielen
Hallo
@NAB
@NAB
mfg
schwedenmann
P.S.
Ansonsten, wenn das zuviel Gefrickel ist, muß es halt ein image werden, per dd, clonezill, g4l oder g4u
@NAB
Dann solltest du die Dateisysteme mit derselben UUID wie bei dem alten System erstellen, dann sparst du dir den murkshätte ich mir das neue System mit den alten UUIDs geschrottet.
@NAB
Völlig richtig, was nützt ein backup, wenn das restore scheitert.. aber beim Wiederherstellen wird's dann sehr dünn.
mfg
schwedenmann
P.S.
Ansonsten, wenn das zuviel Gefrickel ist, muß es halt ein image werden, per dd, clonezill, g4l oder g4u
Zuletzt geändert von schwedenmann am 06.04.2018 09:48:35, insgesamt 1-mal geändert.
Re: Systembackup leicht erstellen und wieder einspielen
Ach was, Günther, sowas kann ich doch auch nicht. Ich habe allerdings mittlerweile eine sehr umfangreiche und thematisch gut strukturierte Knowledgebase, mit deren Hilfe ich alle meine Fragen zu all meinem Setups beantworten kann.guennid hat geschrieben:06.04.2018 00:28:59Wenn Thomas all seine individuellen Anpassungen so klar im Kopf hat, dass er sein backup sozusagen aus dem Ärmel schütteln kann,
Und mein spezielles Backup-Tool macht mir die Selektion ebenfalls sehr einfach. Wenn ich eine Conf verändere oder Änderungen in einem speziellen Verzeichnis vornehme, wie z.B. /etc/apt, dann trage ich immer sofort die Conf oder das Verzeichnis direkt in die Liste des Backup-Programm ein. Das mache ich nur einmalig, aber immer unmittelbar. Ab dann wird das immer automatisch mitgespeichert. Wenn ich ein bestimmtes Programm ausser Betrieb nehme , entferne ich den Eintrag sofort und pack die letzte laufende Konfiguration in ein Archivdir zum späteren Nachsehen, von wo sie auch im langfristigen Backup gesichert wird. Das ist also alles viel mehr Konzept und Disziplin, und eher wenig ad hoc präsentes Wissen und Erinnern. Das ist imho auch alles viel zu umfangreich , um das alles immer im Kopf parat zu haben. Ich weiß nur wenig von Linux, aber ich weiß wo alles steht.
Beim Restore im einem neuen Setup werden bei mir also nur ganz genau diese alten Änderungen durch einfaches Kopieren übernommen, alles andere bleibt vom neuen Setup. Und weil die Backups keinen Müll enthalten, muss ich auch nicht mühsam suchen - alles was im Backup enthalten ist, kann zurückgespielt werden. Das macht es mir jedenfalls total einfach, alte Funktionalität in einem neuen Setup wieder herzustellen.
Re: Systembackup leicht erstellen und wieder einspielen
Ich denke, man sollte den TE nicht zu sehr verwirren. Denn zu viele Wege führen nach Rom...
Nach meiner Meinung ist es wichtig, sich für ein Backup-System zu entscheiden. Ich gehe dabei immer nach folgendem Schema bei einem TOTAL-Backup vor:
Nach meiner Meinung ist es wichtig, sich für ein Backup-System zu entscheiden. Ich gehe dabei immer nach folgendem Schema bei einem TOTAL-Backup vor:
- Prüfen, wie die Partitionierung meines Rechners ist: MBR oder GPT? Dann sichert man den MBR bzw. die GPT in eine Datei.
- Kommt EFI zum Einsatz oder erfolgte der Boot-Prozess noch nach der alten MBR-Methode (BIOS)? Bei MBR sichert man den MBR ( dd if=/dev/Festplatte of=MBR.img bs=512 count=1 ), bei UEFI die /boot und /boot/efi Partitionen
- Dann sichert man jede Partition, am Einfachsten mit einem Tool wie partclone. So kann man bei Wiederherstellen der Installation ganz einfach durch Rückspielen der Sicherung in die entsprechende Partition den Ursprungszustand wiederherstellen. Das müsste auch bei einem LVM klappen, kann ich aber nicht sicher sagen.
Re: Systembackup leicht erstellen und wieder einspielen
Und bis du soweit warst, hast du dafür eine ganze Menge Hirnschmalz und Zeit aufgewendet, behaupte ich mal. Und um das klarzustellen: Respekt, nach wie vor! Ich sag' ja nicht, dass man sich die Mühe nicht machen soll - aber es bleibt Mühe und der muss sich der TE unterziehen, wenn er es denn will - vielleicht fällt ihm ja dann "sein" backup irgendwann genauso "leicht" wie dir das deine.TomL hat geschrieben: Ich habe allerdings mittlerweile eine sehr umfangreiche und thematisch gut strukturierte Knowledgebase, mit deren Hilfe ich alle meine Fragen zu all meinem Setups beantworten kann.
Re: Systembackup leicht erstellen und wieder einspielen
Interessant ist auch die Frage, welche Backup Lösungen das System im laufenden Betrieb sichern. Mit tar geht das.
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Systembackup leicht erstellen und wieder einspielen
Das ist ebenso auch mittels cp oder dd möglich. Ersteres wäre gut dafür geeignet, ein System an einem anderen Ort zu spiegeln, und würde auch Delta-Backups ermöglichen, damit nur noch gesichert wird was sich verändert hat. Und letzteres macht bekanntlich ein RAW-Image des Datenträgers, dass sofern keine Festplattenverschlüsselung genutzt wurde, auch komprimiert werden kann. Muss eben jeder für sich selbst entscheiden, was alles gesichert werden soll. Ich sichere grundsätzlich alles, schon aufgrund meines komplexen Setups, und weil wenig Lust besteht ein System mehr als einmal neu zu installieren. Warum auch dieser Aufwand, wenn man ein laufend aktualisiertes System-Image zurückspielen kann, was alles fix und fertig wiederherstellt? Mit einer Neuinstallation hätte ich letztendlich auch nichts anderes auf der Festplatte. Und gegen mögliche Kompromittierungen, helfen wie immer redundante Backups.
Re: Systembackup leicht erstellen und wieder einspielen
dd ist als Backup eines im Betrieb befindlichen Systems ungeeignet. Wenn sich der Inhalt des Quelldatenträgers während des Backups ändert, weil jamand neue Dateien erzeugt, ist deine dd-Kopie am Ende inkonsistent, das Dateisystem kann sogar so beschädigt sein, daß es nicht mehr repariert werden kann.
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Systembackup leicht erstellen und wieder einspielen
Hat man dieses potenzielle Problem nicht bei allen Backup-Varianten im Betrieb? Dieses Problem kam mir zwar noch nie unter, aber einen extrem ungünstigen Zeitpunkt während eines Backups, kann es natürlich geben. Zumindest könnte man mittels tar und Co., Bereiche des Dateisystems ausklammern, die stetigen Veränderungen unterworfen und für Backups mitunter wenig relevant sind. Alternativ könnte man das eigene System auch generell in mehrere Volumes aufteilen, und relevante Volumes read-only mounten, bevor man dd für irgendwelche Backups nutzt.MSfree hat geschrieben:06.04.2018 15:09:32dd ist als Backup eines im Betrieb befindlichen Systems ungeeignet. Wenn sich der Inhalt des Quelldatenträgers während des Backups ändert, weil jamand neue Dateien erzeugt, ist deine dd-Kopie am Ende inkonsistent, das Dateisystem kann sogar so beschädigt sein, daß es nicht mehr repariert werden kann.
Re: Systembackup leicht erstellen und wieder einspielen
Nein. Backups, die auf Dateiebene kopieren, wie cp, rsync, rsnapshot etc. produzieren schlimmstenfalls defekte Dateien, wenn z.B. der erste Teil einer Datei noch kopiert, während sie der zweite Teil der Datei noch ändert. Dann passen Teil 1 und Teil 2 der Kopie nicht zusammen. Aber selbst das kann man theoretisch abfangen, indem man das Last-Modification-Date der Quelldatei vor und nach der Kopie vergleicht und ggfls. erneut kopiert.breakthewall hat geschrieben:06.04.2018 15:40:25Hat man dieses potenzielle Problem nicht bei allen Backup-Varianten im Betrieb?
dd hingegen kopiert ja überlicherweise vom Raw-Device. Da kann es passieren, daß du Verzeichniseinträge kopierst, in denen auch Offsetpointer zu Dateien gespeichert sind, die anschließend gar nicht mehr existieren oder an einer andere Stelle sitzen. Die Dateisystemstruktur der Kopie ist dann nachhaltig zerstört. Im schlimmsten Fall läßt sich das nichtmal mit einem fsck wieder in Ordnung bringen. Wenn du von so einem "Backup" sinnvolle Daten rekonstruieren willst, braucht du mächtigere Werkzeuge.
dd-Kopien sollte man also nur von ungemounteten bzw. Read-Only gemounteten Datenträgern ziehen.
Re: Systembackup leicht erstellen und wieder einspielen
Prima Idee! Wie mache ich das mit dem Debian Installer?schwedenmann hat geschrieben:06.04.2018 09:43:30Dann solltest du die Dateisysteme mit derselben UUID wie bei dem alten System erstellen, dann sparst du dir den murks
Woher weiß tar denn, welche Datei gerade schreibend geöffnet ist und somit in einem inkonsistenten Zustand sein könnte? Das beträfe nicht nur unwichtige Log-Dateien sondern auch meine VM, meine SQL Datenbank und meine Firefox Lesezeichen. Ist tar da schlauer als dd?debianoli hat geschrieben:06.04.2018 13:30:04Interessant ist auch die Frage, welche Backup Lösungen das System im laufenden Betrieb sichern. Mit tar geht das.
Wie eingangs beschrieben, mit einem Raid1 kriegst du eine konsistente Kopie im laufenden Betrieb hin. Nur abstöpseln musst du das Backup dann während eines Reboots.breakthewall hat geschrieben:06.04.2018 15:40:25Hat man dieses potenzielle Problem nicht bei allen Backup-Varianten im Betrieb?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Systembackup leicht erstellen und wieder einspielen
Berechtigter Einwand. Ich sichere immer per tar das System ohne /home, mache währenddessen aber nichts anderes mit dem Rechner. Deshalb hatte ich damit noch nie Probleme. So spare ich mir das Booten per Live-System nur für die Sicherung.NAB hat geschrieben:06.04.2018 16:54:38Woher weiß tar denn, welche Datei gerade schreibend geöffnet ist und somit in einem inkonsistenten Zustand sein könnte? Das beträfe nicht nur unwichtige Log-Dateien sondern auch meine VM, meine SQL Datenbank und meine Firefox Lesezeichen. Ist tar da schlauer als dd?
-
- Beiträge: 3022
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Systembackup leicht erstellen und wieder einspielen
Wenn ich mir das Konzept von TomL so durchdenke... ich beschäftige mich momentan grad mit openshift, und auch hier ist Backup ein Thema - sehe ich im Konzept von TomL eine Mischform aus Haustierhaltung und Massentierhaltung.
Jedes Haustier hat einen Namen und will umsorgt und gepflegt sein, und wenns krank ist, sitz ich mit ihm beim Tierarzt.
Wenn 300 von 300.000 Hendeln krank sind, entsorge ich die (ist grausam...)
Wenn ich, so wie TomL einfach mit der Paketliste den Rechner neu installiere, ein paar Modifikationen von Hand oder per Skript anpasse, dann hat das was von Massentierhaltung. So mach ich das mit Containern oder Rechnern im Rechenzentrum, nicht aber für Arbeitsplatzrechner, wo jeder individuell werden wird...
Ich denke, dass btrfs-Snapshots eine wunderbare Lösung sind. Besonders wenn es darum geht, den ganzen Rechner wiederherzustellen.
Mir schwebt grad eine Desaster-Recovery-Möglichkeit ein... Und zwar ala FAI... Darüber muss ich jetzt direkt mal nachdenken...
Jedes Haustier hat einen Namen und will umsorgt und gepflegt sein, und wenns krank ist, sitz ich mit ihm beim Tierarzt.
Wenn 300 von 300.000 Hendeln krank sind, entsorge ich die (ist grausam...)
Wenn ich, so wie TomL einfach mit der Paketliste den Rechner neu installiere, ein paar Modifikationen von Hand oder per Skript anpasse, dann hat das was von Massentierhaltung. So mach ich das mit Containern oder Rechnern im Rechenzentrum, nicht aber für Arbeitsplatzrechner, wo jeder individuell werden wird...
Ich denke, dass btrfs-Snapshots eine wunderbare Lösung sind. Besonders wenn es darum geht, den ganzen Rechner wiederherzustellen.
Mir schwebt grad eine Desaster-Recovery-Möglichkeit ein... Und zwar ala FAI... Darüber muss ich jetzt direkt mal nachdenken...
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Systembackup leicht erstellen und wieder einspielen
Ist das nicht immer so? Braucht nicht jedes Hühnchen seine eigene IP-Adresse, hostname, SSH Key? 32-Bit Hühnchen sterben ja langsam aus, dafür sind ARM-Hühnchen im Kommen ...scientific hat geschrieben:06.04.2018 17:47:26sehe ich im Konzept von TomL eine Mischform aus Haustierhaltung und Massentierhaltung.
Stimmt, wenn man das Konzept von TomL weiterentwickelt, dann landet man bei Automatisierung statt Dokumentation (ich würd da eher Richtung Ansible statt FAI schielen). Nur ... "leicht"?
Du meinst btrfs send? Da scheint mehr zu gehen als ich vorher wusste:scientific hat geschrieben:06.04.2018 17:47:26Ich denke, dass btrfs-Snapshots eine wunderbare Lösung sind. Besonders wenn es darum geht, den ganzen Rechner wiederherzustellen.
https://btrfs.wiki.kernel.org/index.php ... tal_Backup
Gar nicht schlecht. Wenn ich nur nicht immer wieder von der Bugliste von btrfs so beeindruckt wäre ...
Und immerhin schreibt er mal groß drüber, dass ein Snapshot im laufenden Betrieb einem Stromausfall entspricht.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Systembackup leicht erstellen und wieder einspielen
Tja Günther, ich habe von Leuten wie Dir (und einigen anderen) hier in diesem Forum gelernt... wenn man selber keine Ahnung hat, einfach nur aufmerksam zuhören, wenn die Fachleute reden und mitschreiben... dann kommt der Rest von ganz alleine.guennid hat geschrieben:06.04.2018 10:38:38Und bis du soweit warst, hast du dafür eine ganze Menge Hirnschmalz und Zeit aufgewendet, behaupte ich mal.
Ich glaube nicht, dass es das ist. Weil ich mich von allen Standard-Desktops verabschiedet habe, habe ich einfach nur ein Standard-Vorgehen für ein neues Setup eines beliebigen Rechners. Bei allen ist es die gleiche Basis, wie es auch die gleiche Basis wäre, würde ich bei allen LXDE installieren... nur ist eben meine eigene Basis.scientific hat geschrieben:06.04.2018 17:47:26sehe ich im Konzept von TomL eine Mischform aus Haustierhaltung und Massentierhaltung.
Was macht diese Individualität denn aus? Das ich gpsprune installiert habe und die Chefin nicht? Oder das ich gimp nutze und die Chefin nicht? Die Unterschiede sind doch alles nur Variationen von "apt install" beim Setup des Rechners. Ich verwende bei allen Systemen die gleiche Liste mit "apt install's"... und weil ich die Chefin seit über 40 Jahren kenne, und natürlich den Rest auch (nur nicht so lange), entferne ich bei dem einen oder anderen nach dem Copy-Paste des apt-install-strings die Teile aus dem String, die nicht gebraucht werden. Für mich ist das pillepalle.... und wirklich kein Faktor, wo ich von großer Individualität reden würde. Im übertragenen Sinnen haben einfach alle den gleichen Desktop installiert... nur eben kein LXDE, XFCE, Cinnamon, Mate, oder sonst was, sondern meinen eigenen. Ist aber für mich dassselbe, als hätten alle Cinnamon installiert.... oder alle W10. Ich brauche hier auch systemüberschreitend einen gewissen Wiedererkennungsfaktor... also schliesst das eine wirklich gravierende Variabilität sowieso aus.nicht aber für Arbeitsplatzrechner, wo jeder individuell werden wird...
Aber auch das ist doch imho eine absolut vermeidbare Situation. Wie kanns überhaupt sein, dass sich wegen aktiver Customizing-Arbeiten der ganze Rechner himmelt? Das ist eine Situation, die ich hier komplett ausschließen kann. Ich fummel NIEMALS an produktiven Systemen mit unsicheren oder neuen Parametern oder Programmen rum.... niemals. Ich habe einen PI als Hardware-Testsystem und ich habe eine systemd-spawnd-VM als tar gesichert. Die "saubere" VM entpacke ich in den RAM, mach nen Dist-Upgrade, sichere diesen Stand sofort zurück zum TAR-File und richte danach meine komplette Testumgebung ein. Erst wenn die Tests erwiesen haben, dass sie tun, was ich erwarte, werden die Änderungen auf das produktive System transportiert. Die VM lösche ich dann einfach, für den nächsten Test habe ich ja mein sauberes TAR-Backup. Diese Vorgehensweise kenne ich die ganze Zeit meines Berufslebens durch unseren IT-Dienstleister... und ich habe das einfach übernommen, weil ich glaube, dass es so richtig ist.Ich denke, dass btrfs-Snapshots eine wunderbare Lösung sind. Besonders wenn es darum geht, den ganzen Rechner wiederherzustellen.
Ich finde diese Diskussion über die Gefahren des Backups eines laufenden Systems sehr irritierend, weil anscheinend einige echte Unsicherheitsfaktoren dabei bestehen. Ich habe den Eindruck, dass es also immer auch ein wenig ein Glückspiel ist , ob man ein solches Backup wirklich 100% erfolgreich zurückspielen kann, weil man nie weiss oder prüfen kann, ob es an hinter-unter-linkster Stelle nicht doch ein Problem beim Schreiben des BAKS gegeben hat. Ich kenne solche Unsicherheiten nicht... weils diese Gefahr mit meinem Konzept gar nicht gibt. Ich empfinde es für meine Anforderungen auch irritierend, ein fremdes Backup-System zu verwenden, das vielleicht ein eigenes Backup-Format anlegt.. keine Ahnung, was da alles möglich ist...eigenes Kompressions-Format, Container, Verschlüsselt, das es sich meiner Kontrolle bis hin zur Detail-Bestätigung der Qualität entzieht. Ich habe mich entschieden, jederzeit mit willkürlichen Stichproben bestätigen zu können, dass mein Backup wirklich 100% verwendbar ist.... als ganzes, oder auch selektiv. Das geht aber nur, wenn ich nicht alle 380.000 Files meines Desktops sichern muss. Da mal eben reinzuschauen, ob die /usr/share/polkit-1/actions/LocalExtPermissions.policy wirklich die richtige und auch lesbar ist, scheint mir einigermaßen kompliziert. Und so oft, wie bei mir die Backups seit Monaten völlig mannlos laufen, würde das mit System-Backups sowieso nicht gehen. Das wäre ja völlig inkompatibel mit meinem Anspruch an "mannlos".
Re: Systembackup leicht erstellen und wieder einspielen
Eigentlich ist in diesem Thread schon alles gesagt, aber das von NAB formulierte Problem haben sicherlich einige. Daher beschreibe ich auch meinen Weg vollständiger, als ich das weiter oben getan habe.
Das Archiv kann dann auf einer frischen Installation das System schnell wiederherstellen.
Die Grundinstallation erledigt bei mir fai-quickstart. Einfacher kann man keine Platten Partitionierung beschreiben als mit fais setup-storage².
Mein /etc ist dank etckeeper und git gut gesichert, ein post-commit-hook schiebt das Archiv ins Gitlab.
Darüberhinaus habe ich eine bootbare externe Festplatte mit einem clonezilla. Die grub/syslinux Konfiguration davon ist soweit vollständig unattended eingestellt, dass ich mit zweimaligem Return-drücken ein image des Rechners speichere. (Eigentlich mal für Windowsrechner erstellt, funktioniert aber wunderbar ebenso mit Linux¹).
Und zusätzlich läuft das schon oben erwähnte kostenlose veeam, was einen phantastischen Job bei der Kompression macht. Außerdem kann ich mit dem einfach bedienbaren ncurses-veeam-tool ein altes Backup ro-mounten und einzeln Dateien/Ordner widerherstellen.
Ich sag immer Ich brauch kein Backup - ich brauch ein restore. Und mit meinen (redundanten) Backupverfahren habe ich schon mehrfach die Installation zurückspielen können. Sowohl auf PCs, als auch auf meinen Laptops.
Von den beiden bootbaren Clonezilla Platten liegt übrigens eine im Bankschließfach - für den Fall der Fälle.
Meine knowledgebase möchte ich sowohl von privaten als auch beruflichen Rechnern im Zugriff haben. Daher liegt die unter gitlab.com in einem privaten repo.
[1] bei clonezilla ist autoproductname sehr hilfreich, siehe http://clonezilla.org/advanced/reserved-word-ocs-sr.php
zum Sichern:
ocs_live_run="ocs-sr -q2 -c -j2 -z1 -i 4096 -sfsck -scs -senc -p choose savedisk autoproductname all"
zum Rückspielen:
ocs_live_run="ocs-sr -g auto -e1 auto -e2 -c -r -j2 -k -p choose restoredisk autoproductname all"
[2] fai hat setup-storage zum Erstellen von durchaus komplexen Partitionierungsideen.
https://fai-project.org/doc/man/setup-storage.html
Bei mir läuft jede Nacht cron-apt zusammen mit dpkg-repack, damit Pakete, die in den sources.lis* nicht mehr vorhanden sind auch zur Verfügung stehen: (dpkg-repack erzeugt wieder debs aus installierten Paketen - inkl. der vorgenommenen Einstellungen!)NAB hat geschrieben:06.04.2018 05:09:46Neuinstallation und dann die alte Paketliste wieder einspielen? Würd bei mir scheitern, ich müsste erst die alte sources.list wieder einspielen. Ach nee ... würd auch nicht funktionieren ... ich müsste erst deb-multimedia wieder einkommentieren. Vielleicht. Müsste ich erst prüfen, je nach System. Mist, geht auch nicht, der blöde Keyring. Hoffentlich gibt's die alten Pakete noch ...
Dann /etc wieder einspielen? Zack, hätte ich mir das neue System mit den alten UUIDs geschrottet. Aber egal, die Kiste bootet eh nicht, weil er mir zwischendurch grub-efi durch grub-pc ersetzt hat und grub-install nur nen Fehler schmeißt.
Code: Alles auswählen
$ apt install apt-clone dpkg-repack
$ cat /etc/cron.daily/apt-cron
#!/bin/bash
set -e
if [ -x /usr/bin/apt-clone ] ; then
/usr/bin/apt-clone clone --with-dpkg-repack /var/backups &>/dev/null
fi
Code: Alles auswählen
apt-clone restore apt-clone-state-$(hostname).tar.gz
Mein /etc ist dank etckeeper und git gut gesichert, ein post-commit-hook schiebt das Archiv ins Gitlab.
Darüberhinaus habe ich eine bootbare externe Festplatte mit einem clonezilla. Die grub/syslinux Konfiguration davon ist soweit vollständig unattended eingestellt, dass ich mit zweimaligem Return-drücken ein image des Rechners speichere. (Eigentlich mal für Windowsrechner erstellt, funktioniert aber wunderbar ebenso mit Linux¹).
Und zusätzlich läuft das schon oben erwähnte kostenlose veeam, was einen phantastischen Job bei der Kompression macht. Außerdem kann ich mit dem einfach bedienbaren ncurses-veeam-tool ein altes Backup ro-mounten und einzeln Dateien/Ordner widerherstellen.
Ich sag immer Ich brauch kein Backup - ich brauch ein restore. Und mit meinen (redundanten) Backupverfahren habe ich schon mehrfach die Installation zurückspielen können. Sowohl auf PCs, als auch auf meinen Laptops.
Von den beiden bootbaren Clonezilla Platten liegt übrigens eine im Bankschließfach - für den Fall der Fälle.
Meine knowledgebase möchte ich sowohl von privaten als auch beruflichen Rechnern im Zugriff haben. Daher liegt die unter gitlab.com in einem privaten repo.
[1] bei clonezilla ist autoproductname sehr hilfreich, siehe http://clonezilla.org/advanced/reserved-word-ocs-sr.php
zum Sichern:
ocs_live_run="ocs-sr -q2 -c -j2 -z1 -i 4096 -sfsck -scs -senc -p choose savedisk autoproductname all"
zum Rückspielen:
ocs_live_run="ocs-sr -g auto -e1 auto -e2 -c -r -j2 -k -p choose restoredisk autoproductname all"
[2] fai hat setup-storage zum Erstellen von durchaus komplexen Partitionierungsideen.
https://fai-project.org/doc/man/setup-storage.html