Auf Mastodon ansehen
Jeder kennt es aus seinem Bekanntenkreis oder seinem Stammforum. Da gibt es diesen einen Typen, der sagt, er benutze seit über 10 Jahren ein und dieselbe Debian-Installation (oder eine beliebige andere Distribution).
Man weiß dann nie, ob man dieser Person gratulieren, sie bewundern oder sie verächtlich ignorieren soll, weil man selbst zum fünften Mal in diesem Jahr Linux neu aufgesetzt hat.
Fakt ist: Wer seine Installation pflegt und gut behandelt, hat eine hohe Chance, dass man lange ohne Neuinstallation auskommt. Allerdings können Schicksal und Unachtsamkeit der Entwickler auch mal zu einem unschönen Boot nach dem Upgrade führen, siehe Debian 12.3.
Aktuell soll es auch bei Ubuntu 24.04.01 zu erheblichen Problem beim Upgrade kommen, wie die Kollegen von linuxnews.de berichteten.
Als kleiner Erfahrungs-Einschub sei noch erwähnt, dass es für ein Versions- oder Point-Release-Update auch nicht zielführend ist, wenn man sich dazu verleiten lässt, Snap von seinem Ubuntu zu verbannen.
Kein Backup, kein Mitleid
So mancher, den ich kenne, hat in seiner Forum-Signatur diesen Satz stehen. Gelegentlich kommt es auch zu Wortgefechten, weil der Satz in einem Thread zu einem zerschossenen Linux fällt.
Backups sind wichtig, früher wie heute, und leider muss sich jeder selbst darum bemühen. Oft wird Timeshift ins Spiel gebracht, was sich aus meiner persönlichen Erfahrung heraus, gelinde gesagt, als nicht zielführend herausgestellt hat.
DD
|
dd (steht lt. Dokumentation für "convert and copy a file", wird aber im alltäglichen Gebrauch auch gerne als "disk dump" oder "disk destroyer" bezeichnet) kopiert Dateien oder ausgesuchte Teile von Dateien. Dabei kann sowohl eine bit-genaue Übertragung oder auch eine Konvertierung erfolgen. Häufig wird das Programm zum Kopieren von Festplatten oder Partitionen über deren Gerätedateien verwendet. "Bit-genaues" Kopieren bedeutet, dass der Datenträger Bit-für-Bit bzw. Byte-für-Byte ausgelesen und beschrieben wird, unabhängig von dessen Inhalt und Belegung. dd ignoriert Dateisysteme und funktioniert mit allen blockorientierten Datenträgern, also auch mit Daten-CDs/DVDs. |
Auslesen der Laufwerks-Aufteilung
Wichtig: Wie mehrfach in den Kommentaren erwähnt, sollte das Backup natürlich über ein Live-System gemacht werden, um Inkonsistenzen zu vermeiden.
lsblk
Unter Ubuntu kann das etwas ausschweifender ausfallen:
Hier wäre nvme0n1 das zu sichernde Ausgangslaufwerk und sda das Ziel (Die Externe Festplatte).
~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 4K 1 loop /snap/bare/5
#[...]
loop32 7:32 0 402,2M 1 loop /snap/gnome-46-2404/49
sda 8:0 0 111,8G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 513M 0 part
├─sda3 8:3 0 109,3G 0 part /media/timo/97078cb6-47fc-4f60-beba-03597e59e8ab
└─sda4 8:4 0 2G 0 part
nvme0n1 259:0 0 238,5G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 238G 0 part /
Umsetzung
In diesem Beispiel sind das Ausgangsvolumen sda und sdd. Abhängig von der System-Situation werden die Bezeichnungen wahrscheinlich anders sein. Augenmerk sollte darauf gelegt werden, dass hier keine Sub-Volumes (z. B. sda1/2/3 usw.) gewählt werden, sondern die gesamte Platte.
sudo dd if=/dev/sdX of=/dev/sdY bs=64K status=progress
Logik
sudoverschafft erhöhte Rechteif=/dev/sdadefiniert das zu klonende Volumenof=/dev/sdddefiniert das Zielbs=64Ksetzt die Blockgröße auf 64 Kilobyte, was den Kopiervorgang stark beschleunigen kann. (Anmerkung: In meinen Sitzungen hat dies noch nie zu Problemen geführt, falls bei euch schon Fehler aufgetreten sind, könnt ihr das gerne kommentieren.)
Für moderne Speichermedien kannbsauch auf1Mgesetzt werden.status=progresslegt fest, dass grafisch rückgemeldet werden soll, wie weit der Prozess fortgeschritten ist. (Wird nicht automatisch angezeigt.)
Serviervorschlag
Wissens- und beachtenswert ist, dass Ziel-Drive mindestens die Größe des Ausgangs-Drives haben sollte, da sonst logischerweise nicht ausreichend Platz vorhanden ist.
Als Datenträger eignet sich eine externe HDD, die exklusiv für dieses Backup genutzt wird. SSDs hingegen müssen, genau wie USB-Sticks, ab und an mit Strom versorgt werden, da sonst Datenverlust droht.
Eine Möglichkeit wäre, regelmäßig von Hand ein Backup zu machen und so seine gesamte Installation zu sichern.
Meine Herangehensweise ist ähnlich, aber anders. Ich konfiguriere mir ein System nach meinem Gusto und schreibe mit dd das Backup. Eigene Dateien liegen auf einer separaten 1-TB-Festplatte; diese werden über Nextcloud zusätzlich gesichert. Eine einfachere Lösung wäre eine separate Home-Partition.
Rückspielen
Dies kann über ein Live-ISO erfolgen. Ein Notfallstick mit Knoppix oder Gparted-Live sollten zum Bestand jedes PC-Interessierten gehören.
Im Live-Betrieb kann nun eine kaputte Installation ersetzt oder eine leere Platte bespielt werden.
sudo dd if=/dev/sdY of=/dev/sdX bs=64K status=progress
Auch hier können die Laufwerksbezeichnungen abweichen.
dd Man-Page auf Ububuntu Manpages
Auf welche Probleme beziehst Du Dich bei Timeshift?
Als ich noch Mint genutzt habe, hat es schlicht nicht funktioniert. Das ist aber auch schon ein paar Jahre her. Wie geschrieben, ist meine eigene Erfahrung.
Timeshift ist ausdrücklich kein Backup Tool - es dient der Systemwiederherstellung. Ich möchte es nicht missen - hat mir schon gelegentlich den A*** gerettet. Nicht nur auf einem Rechner.
Das hätte ich auch gerne gewußt. Aber ob da noch eine Antwort kommt, heute ist bereits der 11.09....
Danke für den Artikel, hab mich nie so richtig getraut den Befehl einzusetzen. Werde es aber jetzt auch mal probieren. Habe mir auch mal das Tool "Foxclone" angeschaut, ist halt für mich einfacher zu bedienen wegen der grafischen Oberfläche. Gruß Rigo
Mit Backups habe ich mich Privat noch nicht wirklich beschäftigt. Und mit
ddmeine Festplatte zu klonen oder in eine Image Datei zu schreiben würde bei TB einfach zu lange dauern. Bei einer Festplattengröße von 500GB Könnte man es noch in betracht ziehen. ABER ich würde es als Datei sichern sprich:Das zurück spielen wäre genause einfach nur wie gesagt im Artikel - Live System!
sudo dd if=/media/BackupDisk/Backup-DATUM-UHRZEIT.img of=/dev/sdY status=progress conv=sync,noerrorHinweis: DATUM und UHRZEIT sind Platzhalter, die ersetzt werden müssen, weil dort die echten Zeitangaben stehen.Somit könnte man eine große 4 TB Festplatte öfter verwenden - Bei 500 GB wären es 7 Backup Dateien, eigentlich 8, ABER man weiß nie ob Fehlersektoren da sind, darum einmal weniger. Einfach ein vorheriges Backup.img löschen und schon ist Platz für ein neues. Wenn man unbedinkt eine komplette Festplatte klonen möchte.
Mein Backup kommt erst, wenn ich einen neuen Rechner mir zusammenstelle alle mind. 15 Jahre. Ich möchte so lange wie möglich immer mein Rechner bediehnen und nicht den Stand der Technik hinterher gegen und Konsumieren. Anderes Thema.
Dein Artikel war schön zu lesen und an manchen stellen musste ich auch lächeln. Zitat-aus-dem-Artikel:
Man weiß dann nie, ob man dieser Person gratulieren, sie bewundern oder sie verächtlich ignorieren soll, weil man selbst zum fünften Mal in diesem Jahr Linux neu aufgesetzt hat.Mein System ist auch schon einige Jahre im Einsatz seit Ubuntu 16.04 LTS bis jetzt 22.04.4 LTS. Ich bleib gerade bei dieser Version, weil Snap mir nicht geheuer ist und ich noch einen schönen alten CPU nutze. Es wurden wieder Kernel entfernt, deswegen warte ich auf einen guten moment um mir einen neuen Rechner zuzulegen. CPU:i7 4790kRAM:32 GB- Ich habe einige Virtuelle PCs am laufen darunter auch ein paar WindoofsWie kommst du auf die 64 KB Blocksize und warum ermittelst du nicht die bs und den count von z. B. /dev/sda und setzt es in deinen DD-Befehl ein?
Stand im ArchWiki. Lief gut und dann hab ichs nie versucht zu verbessern. https://wiki.archlinux.org/title/Dd
Alles klar - danke. Hast du mal versucht eine DVD mit dd zu sichern? Ich habe das Problem, dass bei mir das Sichern der DVD sehr lange dauert. Hast du damit Erfahrungen?
x mal durchgeführt und funktioniert perfekt. Das gesamte System kann danach von z.B. einer externen SSD geladen werden und läuft wie auf dem Original. Allerdings kann getrost "bs=" auf 1M statt 64K gesetzt werden, dann geht es noch schneller.
Bei mir ließ sich Debian von einer externen SSD nicht starten, bis dass ich den Schalter
--removablebei update-grub fand.Sehr schöner Artikel...
Anmerkungen:
Es wird ja nicht ein Verzeichnis (also auch nicht /root) angewandt, sondern auf das device-File der gewünschten HD/SSD. Da wären dann auch keine Daten aus dem RAM drin.
Spielt absolut keine Rolle. Wenn man ein rw (gemountetes) Dateisystem mit dd sichert ist ist die Chance SEHR gross das man es nicht mehr zurück spielen kann bez. das es korrupt ist! Schon x mal probiert. Manchmal merkt man es zuerst gar nicht. Sobald man aber z.B. Videos oder Bilder öffnet sind diese nicht abspielbar oder werden nicht richtig angezeigt! Das ist echt gefährlich weil man meint man hätte ein Backup, dieses ist jedoch korrupt!!! Ich backupe mit einem bash script das auf rsync basiert.
Genau genommen sollte man dieser Methode besser auch aus einem read-only-System (z.B. über eine Live-System) sichern, es drohen sonst Inkonsistenzen der Dateisysteme, die während des Backups sich verändern können.
Um SSDs zu beschreiben, würde ich das nicht empfehlen. Bei HDDs kein Problem!
Da dd alle Bits kopiert, werden auch alle leeren Bereiche deiner Platte mit kopiert. Und sowas mögen SSDs eher nicht so. Jeder Schreibvorgang in jede Zelle ist einer weniger, für zukünftige Schreibvorgänge. Und diese sind bei SSDs (und auch USB-Sticks) begrenzt...
Jruß
Hast du's schon mal mit BorgBackup versucht? Ich finde das toll, weil es viel Speicherplatz spart.
Aus meiner doch schon längerer Erfahrung als Systemler kann und sollte ich von solchen Lösungen für eine Bare-metal backup/restore abraten da es immer wieder zu inkonsistente backups führen kann.
Für regelmässige Backups empfehle ich den Veeam Agent für Linux (oder auch Windows) der frei verfügbar ist und einfach auf eine ext. Festplatte oder NAS Backupen kann, hat mich bis jetzt noch nie im stich gelassen hat. Das und zusätzlich eine File Backup mit Pika (GUI für BorgBackup) sollte ausreichen…
Dann geb ich auch noch meinen Senf dazu :-)
Erst mal danke für die Einführung ins Cloning mit dd! Der große Vorteil von dd ist, das es überall an Bord ist und eine Kopie damit ein echter No-Brainer ist.
Wenn es um Cloning geht empfehle ich allerdings auch, nicht ein laufendes System zu clonen, sondern das in einer Live-Umgebung zu machen, um Inkonsistenzen wegen geöffneter Dateien zu vermeiden.
dd braucht sehr lange, weil es alle, auch die unbeschriebenen, Bereiche kopiert und das ist ja eigentlich gar nicht notwendig. Bei einer SD-Card o.ä. finde ich das noch ok, aber komplette HDs/SSDs sind heute so groß, das halte ich nicht für praktikabel, jedenfalls bei vielen Systemen. Daher mache ich so etwas mit Clonezilla https://clonezilla.org/. Das hat mich noch im Stich gelassen, kopiert zuverlässig ganze Devices oder einzelne Partitionen und zwar nur die beschriebenen Bereiche, stellt sie aber komplett wieder her. Clonezilla beruht auf partclone, eine Beschreibung dazu gibt es z.B. hier https://blog.doenselmann.com/festplatten-image-mit-partclone-erstellen/ es lässt sich also wie dd fürs direkte cloning verwenden.
Das Problem mit einem solchen Snapshos ist aber eben genau das, es handelt sich um einen Snapshot, d.h. der von letzer Woche ist schon wieder eine Woche alt, das System hat sich seitdem verändert. Ich sichere die Systeme bei uns daher immer mit einem Tool, das inkrementelle Backups auf Dateiebene macht, nämlich rsnapshot. (Das beruht auf rsync mit Hardlinks, es gibt einige Tools und Scripte, die darauf basieren.) Der große Vorteil ist, dass die Backups sich ganz einfach durchsuchen lassen, einzelne Dateien oder Verzeichnisse lassen sich ganz einfach finden.
"Das hat mich noch im Stich gelassen" sollte natürlich heißen "Das hat mich noch nie im Stich gelassen" und "Das Problem mit einem solchen Snapshos" sollte heißen "Das Problem mit einem solchen Snapshot"
Schade dass es hier keine Voransicht für die Kommentare gibt.
Danke für die ausführliche Beschreibung. Ich habe dd nur ein einziges Mal benutzt, und das ist ewig her. Es hat mir schlichtweg zu lange gedauert, und das zurückspielen ging schief. Da ich gerne experimentiere, oder auch diverse Distris ausprobiere, habe ich immer ein Backup in der Hinterhand. Ich nutze seit Jahren REDO Rescue. http://redorescue.com/ Das ist simple gehalten, hat eine grafische Oberfläche, und hat sich als sehr zuverlässig erwiesen. Was will ich wohin speichern, bzw. von wo will ich zurücksichern. Als bootfähige .iso, ein 4GB Stick reicht.
Ich musste gerade schmunzeln, „Laufwerbezeitungen“ ist eine schöne Wortkreation (letzter Satz). 8)
Ich hab das dann mal verbessert :-D
wenn dd, könnte auch erwähnt werden: GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying to rescue the good parts first in case of read errors. + Warum nach über 40 Jahren PC in den Betriebssystemen immer noch kein Image Programm existiert, das im laufenden System ein Image herstellen kann, ist mir schleierhaft. Plus ein Restore-USB-Stick, um ein kaputtes System durch das Image zu ersetzen.
Hi, danke für den "Fachvortrag". Hierüber bin ich gestolpert: "...SSDs hingegen müssen, genau wie USB-Sticks, ab und an mit Strom versorgt werden, da sonst Datenverlust droht...." Wie ist das gemeint? Danke im Voraus, Gruß Kai
Dies habe ich noch vergessen: Warum DD, wenn doch Clonezilla "alles" viel besser kann, u.a. eigenes UI?
Das ist ja, kein Clickbait-Artikel, der sagt nicht: "dd ist das Beste, was es gibt!"
Natürlich gibt es bessere Lösungen, es geht viel mehr um die Umsetzung und das überhaupt sowas gibt. Meine Artikel sollen auch immer dazu einladen, sich selbst weiterzubilden und sich für Themen zu interessieren. Austausch ist auch wichtig.