Linux Sichern/Wiederherstellen auf anderer Hardware

TheLordix

Ensign
Registriert
Sep. 2010
Beiträge
209
Hallo liebe CBler!

Ich bin gerade dabei mein NAS upzudaten (Hardware & Software, siehe auch https://www.computerbase.de/forum/threads/selbstbau-nas-aufruesten.2122916/). Da Linuxinstallationen zumindest für mich immer sehr aufwändig sind, würde ich gerne im Trockentraining alles in einer VM mal durchspielen bzw. konfigurieren und dann auf die Zielhardware übersiedeln. Gleichzeitig hätte ich damit auch gleich die Backupstrategie ausgetestet :-)

Jetzt ist nur die Frage, wie mache ich das?
Reicht es die /ect/ bzw. /var/ Verzeichnisse zu sichern um alle Konfigurationen und Programme zu übernehmen oder brauche ich mehr? Leider findet sich dazu nichts Vernünftiges im Netz...

Update: hier habe ich noch das Sichern der installierten Programme gefunden:
https://wiki.ubuntuusers.de/Paketverwaltung/Tipps/

Klingt für mich so wie wenn die Programme + /etc/ reichen sollte?

Beispiel wäre mit einer Ubuntu LTS 22.4 Distri.

Danke,
TheLordix
 
Zuletzt bearbeitet:
Veeam Backup and Replication oder einfacher, Clonezilla.
Ergänzung ()

Macht ein komplettes Systemabbild/ISO, welche Du auf ein neues System oder in einer VM installieren kannst.
 
Und das funktioniert auch mit "unterschiedlicher Hardware"? Bei gleicher Hardware hätte ich auch einfach ein Image gemacht...
 
warum nicht vorgegebenes nehmen?
zb bei Mint.
....und Linux installieren ist mittlerweile pipik*ck :)
1672658404724.png
 
@TheLordix Einmal bitte Grundlagen anlesen: https://wiki.ubuntuusers.de/Datensicherung/
Aber Kurzfassung: Es gibt nicht wirklich viele Tools die ein lauffähiges full system inkl. Versionierung sichern und wiederherstellen können. Die meisten Lösungen zielen auf das Szenario "minimale Neuinstallation und dann restore aller Daten bzw. Laufwerke" ab.

_anonymous0815_ schrieb:
Veeam Backup and Replication
Bisschen überdimensionierte Lösung für die Sicherung eines einzelnen Systems, oder? Selbst der Linux Agent von Veeam ist nur noch begrenzt empfehlenswert solange Veeam immer noch Probleme mit halbwegs aktuellen Kerneln uns damit Distributionen hat...

_anonymous0815_ schrieb:
Kann halt nur ganze Systemimages und keine platzsparende Versionierung, weder differenziell noch inkrementell. Wenn das aber keine Anforderung sein sollte, dann ein gutes Tool.

TheLordix schrieb:
Jetzt ist nur die Frage, wie mache ich das?
Siehe mein Link mit diversen Beispielen.

TheLordix schrieb:
Klingt für mich so wie wenn die Programme + /etc/ reichen sollte?

Beispiel wäre mit einer Ubuntu LTS 22.4 Distri.
Jain bzw. es kommt darauf an welche Programme du nutzt. Mysql und MariaDB legen ihre Daten z.B. unter /var ab, Inhalte von Webservern wie apache2 oder nginx beispielsweise lagern die Inhalte unter /var/www bzw. /var/www/html und persönliche Einstellungen deines Nutzers liegen in /home/dein-username.

TheLordix schrieb:
Und das funktioniert auch mit "unterschiedlicher Hardware"?
In der Regel schon solange es keine allzu spezielle Hardware ist und natürlich sofern die Laufwerke (SSDs, HDDs) im neuen Zielsystem mindestens die Größe des Quellsystems haben.
 
Es ist utopisch anzunehmen, dass es ein Backup für dieses Szenario geben kann.

"Warum, man kann doch x y z!!!!111elf"

Ja, kann man, aber Backup bedeutet, dass es einen halbwegs festen Prozess gibt, zudem sowohl die Sicherung der Daten als auch deren Wiederherstellung gehört. Dabei muss es unabhängig sein, in welchem Versionsstand der Inhalt des Backups (hier speziell der Kernel) vorliegt als auch welchen Chipsatz/CPU/GPU/BIOS/UEFI das Zielsystem verwendet. Aber auch der Wiederherstellprozess muss definiert sein.

Im gewünschten Szenario kann es aber nun zu Inkompatibilitäten zwischen Sicherung und Zielhardware kommen (Treiber), die den Boot auf dem wiederhergestellten System ohne weitere Eingriffe unmöglich machen. Auch kann bei einem Linux nicht sichergestellt werden, dass ohne Image-Backup auch wirklich alle Anwendungen und ihre Konfigurationen mitgesichert werden. Manche Anwendungen installieren sich nach /opt, manche nach /bin, andere nach /sbin, wieder welche haben ihre Abhängigkeiten in /lib oder /var/lib.......

Je nach Komplexität empfehle ich /home zu sichern und für alles Andere gut zu dokumentieren, was man wo und mit welchen Einstellungen installiert hat.

Deswegen ist es oft so:
snaxilian schrieb:
Aber Kurzfassung: Es gibt nicht wirklich viele Tools die ein lauffähiges full system inkl. Versionierung sichern und wiederherstellen können. Die meisten Lösungen zielen auf das Szenario "minimale Neuinstallation und dann restore aller Daten bzw. Laufwerke" ab.
Es gibt einfach zuviele Varianten und Abhängigkeiten, als das eine Backup-Software diesen Wunsch erfüllen könnte.
 
snaxilian schrieb:
zielen auf das Szenario "minimale Neuinstallation und dann restore aller Daten bzw. Laufwerke" ab.
Danke an alle für die Diskussion, ich habs verstanden dass es auf diese Variante hinausläuft. Werde ich dann mal probieren. Minimale Neuinstallation ist ja ok, wollte nur nicht alle meine Konfigs/Programminstallationen mühsam neu machen.
 
Ja, minimal Neuinstallation bedeutet: Minimales Linux (je nach Distri). Einstellungen und nicht per Peketmanager installierte Programme bzw. Programme, die Teile ihrer Konfig außerhalb von /home speichern, werden oftmals trotzdem nicht von so einem Backup erfasst.

Grade die Programmeinstellungen würde ich, wenn möglich, händisch backupen. Dann hast du auch direkt eine Liste an Programmen, die du wieder installieren musst bzw. kannst dir direkt ein script schreiben, welches die Installation und Wiederherstellung der Konfig für dich übernimmt.
 
Sofern die genutzte Hardware vom genutzten Kernel unterstützt wird, könnte es durchaus funktionieren einfach ein Image zu machen und es auf der neuen Hardware wiederherzustellen.
 
Wenn Du einen zweiten realen Datenträger hast, kannst Du es ja mit dd von einem Live-System probieren. So habe ich das bis jetzt gemacht und das ging ganz gut. Vorher die Partitionen kleiner als das Ziel machen und gut. Aber immer vorher testen, es kann immer was schief gehen. Ich sichere zB nicht nur den gesamten Datenträger damit, sondern auch einzelne Partitionen. Frisst zwar enorm viel Speicher, aber das ist mir egal, weil jede Live-CD dd hat und ich nicht von einem Programm abhängig bin
 
  • Gefällt mir
Reaktionen: TheHille
Vielleicht klappt auch einfach die SSD vom Alten ins neue System zu stecken.
Treiber sollten alle erkannt werden, evtl. müssen ein paar Anpassungen an den Bezeichnungen von NIC und Laufwerk gemacht werden.

Klone doch einfach mal die Platte und hänge diese in dein neues System.

Über ein Backup bei Linux habe ich mir auch schon länger Gedanken gemacht. Das sinnvollste ist ein TAR mit den entsprechenden Parametern (wie weiter oben von anderen bereits erörtert). DD oder Cloning würde ich nur bei Komplettumzug auf eine neue Platte machen.
 
TheLordix schrieb:
Und das funktioniert auch mit "unterschiedlicher Hardware"? Bei gleicher Hardware hätte ich auch einfach ein Image gemacht...
Treiber, die nicht im Kernel enthalten sind:
  • Nvidia-/AMD-Closed-Source-Treiber für die Grafikkarte.
  • Druckertreiber für CUPS (mittlerweile fast obsolet)
  • Diverse exotische WLAN-Treiber
Der Rest wird im Normalfall automatisch erkannt. D.h. unterschiedliche Hardware sollte kein Problem darstellen.

snaxilian schrieb:
Aber Kurzfassung: Es gibt nicht wirklich viele Tools die ein lauffähiges full system inkl. Versionierung sichern und wiederherstellen können. Die meisten Lösungen zielen auf das Szenario "minimale Neuinstallation und dann restore aller Daten bzw. Laufwerke" ab.
Lassen wir mal die Versionierung außen vor, dann kannst du jeglichen Copy-Befehl verwenden:
cp, mv, tar, cpio, rsync, dd
Brauchst du aber nicht mal, denn:

TheHille schrieb:
Vielleicht klappt auch einfach die SSD vom Alten ins neue System zu stecken.
Die Wahrscheinlichkeit ist sogar sehr hoch, dass das funktioniert.

scooter010 schrieb:
Auch kann bei einem Linux nicht sichergestellt werden, dass ohne Image-Backup auch wirklich alle Anwendungen und ihre Konfigurationen mitgesichert werden. Manche Anwendungen installieren sich nach /opt, manche nach /bin, andere nach /sbin, wieder welche haben ihre Abhängigkeiten in /lib oder /var/lib.......
Gerade bei Linux kann das sogar sehr einfach sichergestellt werden. Du bootest einfach eine Live-CD, mountest die Partition und kopierst das per rsync -av auf ein Zielsystem. Zeitstempel, Berechtigungen, Links werden durch den Archive-Parameter beibehalten.

Meine Empfehlung:
Steck die Platte einfach in den neuen Rechner rein und probier das Ding zu booten!
 
  • Gefällt mir
Reaktionen: TheHille
Pummeluff hat das gut zusammengefasst. Meine Erfahrung zum Umzug: Vom Intelsystem zu AMD hat Ubuntu völlig aus dem Tritt gebracht, während Windows da die Kurve gekriegt hat...endlich ein Vorteil, wenn man alle Treiber standardmäßig mit rumschleppt....

Es kann also sein, dass Du das System neu aufsetzen musst, die Mitnahme der Programmeinstellungen und Systemkonfiguration ist hier aber einfacher als bei Windows
 
Aber was kann denn da schon aus dem Tritt kommen? Treiberseitig ist bei mir 0 nötig einzustellen.

Da ich Manjaro nutze habe ich natürlich aus dem Repo den AMDGPU Treiber installiert und beim aufräumen mal hab ich teils andere Pakete weggeputzt. wenn da bei nem intel system dann erstmal die passenden Treiber fehlen, weil ich die geputzt habe, dann startet das halt erstmal mitm framebuffer um noch nen Bild machen zu können, da installier ich dann halt die Intelpakete oder den Nvidia Treiber - Analog zu Windows musste halt da ja genauso die Passenden Treiber von der Herstellerseite nachschieben, wenn du nicht mit den Standardwindowstreiber weitermachen willst.

Betreffend vorbereiten einer neuen Platte und rüberkopieren der ganzen Daten - den Bootloader muss man nochmal gesondert anfassen dann insofern die Platte noch keinen passenden hatte. Dazu gibts aber auch Anleitungen wie man das von hand macht (archwiki)
 
Ich weiß es nicht, gehe aber mal von den Grundlegenden Treibern für den Prozessor und dem Chipsatz aus. Denn extra Treiber für Grafikkarten hatte ich ja nicht installiert, das lief alles über den Kernel. Normalerweise lässt sich das System ja rudimentär starten, mit einem Sack voll Fehlern, die man dann ausbügelt. Aber das System rannte sofort in den Kernelpanic. Keine Eingabe möglich, also gleich neu installiert
 
TheLordix schrieb:
Und das funktioniert auch mit "unterschiedlicher Hardware"? Bei gleicher Hardware hätte ich auch einfach ein Image gemacht...
Linux hat da wenig Probleme.
Man kopiert oder restored die Daten in die Filesysteme der neuen Platte, passt ggf. die fstab an und schreibt dann einen Bootloader nach dem folgenden Strickmuster: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#Reparatur-mittels-Desktop-CD

Du kannst auch die neue Platte in einer VM zum probieren bespielen/clonen: http://www.stablecoder.ca/2018/03/06/disk-passthrough-kvm-vmm.html und wenn da alles funktioniert bootest du die Platte auf der Physik.
Ergänzung ()

scooter010 schrieb:
Ja, kann man, aber Backup bedeutet, dass es einen halbwegs festen Prozess gibt, zudem sowohl die Sicherung der Daten als auch deren Wiederherstellung gehört. Dabei muss es unabhängig sein, in welchem Versionsstand der Inhalt des Backups (hier speziell der Kernel) vorliegt als auch welchen Chipsatz/CPU/GPU/BIOS/UEFI das Zielsystem verwendet. Aber auch der Wiederherstellprozess muss definiert sein.

Im gewünschten Szenario kann es aber nun zu Inkompatibilitäten zwischen Sicherung und Zielhardware kommen (Treiber), die den Boot auf dem wiederhergestellten System ohne weitere Eingriffe unmöglich machen. Auch kann bei einem Linux nicht sichergestellt werden, dass ohne Image-Backup auch wirklich alle Anwendungen und ihre Konfigurationen mitgesichert werden. Manche Anwendungen installieren sich nach /opt, manche nach /bin, andere nach /sbin, wieder welche haben ihre Abhängigkeiten in /lib oder /var/lib.......

Sorry, aber das ist einfach Unsinn. Allerdings wird ein OS für eine ARM-CPU nicht auf X86-HW laufen oder booten.
Im Regelfall lässt sich ein System aus einem (vollständigen) tarball o.ä. bootfähig wieder herstellen.
 
Zuletzt bearbeitet:
AGB-Leser schrieb:
gehe aber mal von den Grundlegenden Treibern für den Prozessor und dem Chipsatz aus.
Die Treiber werden aber nicht installiert. Die sind im Kernel statisch oder als Modul enthalten. CPU-Treiber dürften noch nicht mal als Modul geladen sondern im statischen Kernelblob verarbeitet werden. Da wird auch nichts statisch auf der Platte abgelegt.

Ein Live-System bootet auch auf x86_64 unabhängig davon, ob da jetzt eine AMD- oder Intel-CPU drin werkelt.

Anders sieht das jetzt z.B. auf meinem Rechner (alter Xeon 5500) aus. Auf dem Ding ist ein Gentoo installiert. Da hab ich das gesamte System mit den entsprechenden CFlags compiliert. Und da hab ich aus der Kernelconfig explizit andere CPU-Architekturen und auch die Chipsatztreiber rausgelassen.

AGB-Leser schrieb:
Normalerweise lässt sich das System ja rudimentär starten, mit einem Sack voll Fehlern, die man dann ausbügelt. Aber das System rannte sofort in den Kernelpanic. Keine Eingabe möglich, also gleich neu installiert.
Nur eine Vermutung:
Wenn die Plattenreihenfolge nicht übereinstimmt und im Bootloader als Rootpartition hdX,X in den Configs festgelegt wird, dann wird die Rootpartition nicht gefunden. Damit können dann die Kernelmodule, die unter /lib/modules liegen nicht gefunden und geladen werden.

Zweite Möglichkeit:
Wenn die Platten und Partitionen über UUIDs angesprochen werden und die Dateien von einer alten auf eine neue Platte kopiert werden, ändern sich die UUIDs. Die müssten dann in der fstab und auch im Grub angepasst werden. Sonst gibt's auch da eine Kernel Panic.

D.h. ich würde die Kernelpanic wohl eher auf eine fehlerhafte Grub-Konfiguration zurückführen. Die genaue Ursache werden wir wohl nicht mehr rausfinden.

foofoobar schrieb:
wenn da alles funktioniert bootest du die Platte auf der Physik.
https://raphaelwimmer.wordpress.com/2008/12/11/physisch-vs-physikalisch/
https://de.wiktionary.org/wiki/Physik
 
Zuletzt bearbeitet:
Ich verstehe das schon, die Platten sind mit uuid verknüpft. Da wurde halt nix kopiert. Beide Systeme mit allen relevanten Partitionen liegen auf der selben NVME-SSD. Da hat sich also nichts geändert. Die SSD wurde nur von Hauptplatine A nach Hauptplatine B gesteckt. Dann im UEFI die passende Reihenfolge ausgewählt und gut. UEFI hat ja alles richtig erkannt. Wenn eine Partition nicht auffindbar ist, sagt mir grub das ja. Soweit ich mich erinnern kann, konnte ich grub normal nutzen. Nur das System halt nicht
 
Zurück
Oben