Linux Mint bootbares Backup

Aladin033

Member
Themenstarter
Registriert
20 Sep. 2019
Beiträge
36
Moin zusammen,

ich nutze schon länger Linux mint im alltäglichen Einsatz.
Jetzt wollte ich mich mal mit dem Thema Backup auseinandersetzten.
Jetzt ist es ja so, das es unter Mint einmal Timeshift und dann noch Datensicherungswerkzeug.
Wenn ich das richtig verstehe kann ich mit beiden kein Bootbares Backup erstellen richtig?
Ich stelle mir das so vor, das ich dann meine Festplatte anschließe auf der sich das Backup befindet, davon dann boote und dann darüber halt die SSD lösche und neu aufsetzte.
Gibts da ne Möglichkeit?

Danke
 
Um eine einfache* Linux-Installation auf ein anderes Medium zu übertragen musst du:
1. Auf dem Zielmedium eine Partitiontabelle und POSIX-konforme Dateisysteme (für gewöhnlich ext4) erstellen, welche das Partitionsschema des Quellmediums aufnehmen können (z.B. bei vorhandenen /, /home und swap-Partitionen auf dem Quellmedium entsprechende Partitionen auf dem Zielmedium erstellen).
2. Die Inhalte des Quellmediums unter Beibehaltung der Rechte auf das Zielmedium übertragen (am besten von einem anderen Linux-System aus mit rsync).
3. In /etc/fstab und /boot/grub/grub.cfg die UUIDs des Quellmediums gegen die des Zielmediums austauschen (am einfachsten geht das durch automatisches Ersetzen im Editor).
4. /proc/, /sys/ und /dev/pts/ des Zielmediums in dem System mounten, von dem aus du das Backup ausführst; ins Zielmedium chrooten; und dort ein update-grub sowie ein grub-install ausführen.

Danach kannst du vom Zielmedium booten.
Es mag Tools geben, die diesen Vorgang mehr oder weniger vor dem User verstecken (manch einer würde dazu "vereinfachen" sagen), aber unter der Haube führen sie genau diese Schritte aus, wenn sie schlauer sind als ein stumpfes dd.


*) ohne Verschlüsselung und/oder Soft-RAID.
 
Da wäre es ja fast einfacher, Linux bei bedarf neu zu installieren und dann alles weitere über Timeshift einzuspielen.
Das dürfte ja auch funktionieren.
 
Nein, einfacher geht es nicht. Und es geht weitaus schneller als eine Neuinstallation, weil man seine ganzen persönlichen Anpassungen mitnimmt, wirklich nur das überträgt, was man haben will und nichts aus dem im Vergleich zu lokalen Datenträgern langsamen Netz ziehen muss.
Es sieht nur auf den ersten Blick kompliziert aus, weil man etwas Hintergrundwissen braucht.

Das letzte mal habe ich es vor ca. einem Monat gemacht, als ich meinen HTPC ausgetauscht und dabei die SSD auf eine andere übertragen habe. Dabei habe ich ca. 27GB übertragen, was netto rund 2 Minuten gedauert hat (der Flaschenhals war das USB-3.0-Interface). Inklusive der oben beschriebenen manuellen Schritte hat der ganze Prozess etwa 15 Minuten gedauert, vom Runterfahren des alten HTPC bis zum Booten des Neuen, inklusive Datenträgertausch.
 
Vielleicht klingt es einfacher wenn man sagt den Inhalt der zu sichernde SSD auf eine neue kopieren und dafür sorgen, dass die neue SSD booten kann (grub) und beim Hochfahren eingebunden wird (fstab).

Dieses herumhantieren mit pseudo FS und chroot klingt erst einmal enschüchternd aber man fragt Google und tippt ab.

Jetzt wird in den meisten Fällen via UUID gemounted. Verhindert natürlich so manche Unfälle weil Linux scheinbar die SSDs auswürfelt aber als man stur z.B. /dev/sda1 als / mountete war der Schritt mit fstab Anpassung nicht nötig.

Andererseits, als ich das letzte mal eine Boot SSD wechseln musste habe ich eine größere SSD genommen und mit "dd if=/dev/sda of=/dev/sdb bs=4096" kopiert. Danach war natürlich die Partitionstabelle nicht ganz in Ordnung aber der Rechner lief ohne Probleme weswegen ich mich nie darum gekümmert habe zumal ja SSDs nie voll geschrieben werden soll.
 
Vielleicht klingt es einfacher wenn man sagt den Inhalt der zu sichernde SSD auf eine neue kopieren und dafür sorgen, dass die neue SSD booten kann (grub) und beim Hochfahren eingebunden wird (fstab).
Warum einfach, wenn es auch kompliziert geht? ;)
Du hast natürlich recht. Letztendlich steckt ja hinter meiner Beschreibung das Gleiche. Es klingt nur komplizierter, weil es technisch die auszuführenden Schritte beschreibt.

Andererseits, als ich das letzte mal eine Boot SSD wechseln musste habe ich eine größere SSD genommen und mit "dd if=/dev/sda of=/dev/sdb bs=4096" kopiert.
Dabei kopiert man ja den vollständigen Inhalt der Quell-SSD, selbst wenn sie zum Großteil leer ist. Hätte ich das beim HTPC gemacht, dann hätte ich nicht 27 sondern 240GB übertragen, knapp 90% davon nutzlos. 20 statt 2 Minuten Übertragungszeit hätten mich sicher nicht umgebracht, aber es wäre trotzdem verschwendete Zeit gewesen.
Hinzu kommt, dass man ja Schreiboperationen auf SSDs minimieren soll. Nun wird die einmalige Übertragung der SSD nicht schaden, aber ich finde es konzeptuell unschön, über 200GB Nullen (oder Müll) durch die Gegend zu schieben.

Wenn du bei dd bleiben willst, würde ich übrigens auf "bs=1M" erhöhen. Der Sinn ist ja, den selben Sektor (HDDs) bzw. die selbe Flash-Zelle (SSDs) nicht mehrfach zu beschreiben. Die 4096 Bytes passen zu "neueren" 4k-HDDs. Die Flash-Zellen von SSDs sind meist größer, wobei die genaue Größe aber nur selten dokumentiert ist. Das ist wohl selten genau 1MB, aber soweit ich aufgeschnappt habe, ist das eine sinnvolle Obergrenze und es tippt sich kurz. Und da 1MB auch ein Vielfaches von 4096 ist, passt das ebenfalls für HDDs. Eine schlaue SSD-Firmware sollte ein zu kleines bs eigentlich puffern, aber wetten würde ich darauf nicht. Du kannst ja spaßeshalber bei deiner SSD mal verschiedene Werte für bs testen. Wenn du einen signifikanten Einbruch bei der Übertragungsrate siehst, weißt du, dass der Wert zu klein ist.
Ganz sparen kannst du dir übrigens das Jonglieren mit der Blockgröße, wenn du cat statt dd benutzt. Oder du nimmst pv (falls verfügbar), dann kriegst du auch noch eine nette Fortschrittsanzeige.

Danach war natürlich die Partitionstabelle nicht ganz in Ordnung aber der Rechner lief ohne Probleme weswegen ich mich nie darum gekümmert habe zumal ja SSDs nie voll geschrieben werden soll.
Das Dumme ist halt, dass bei GPT erwartet wird, dass der Secondary Header am Ende des Laufwerks liegt. Geht dir der Primary Header kaputt, dann hast du dank des Secondary immer noch ein lauffähiges System - falls er gefunden wird.
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben