Anzeige
Linux & Co.Netzwerk

Festplatten unter Linux klonen – auch über das Heimnetz

Ihr wollt ein 1:1-Backup Eures Systems? Oder auf eine größere Festplatte umziehen? Einen zweiten PC mit identischem System aufsetzen? Linux macht es an der Stelle ganz furchbar einfach. Es gibt allerlei Tools mit allerlei schönen Features, aber es läuft doch immer wieder auf den Klassiker hinaus, der an Einfachheit nicht zu überbieten ist.

Anzeige

Tools, Tools, Tools

Wer im Netz nach dem Thema schaut, wird schnell auf Tools wie insbesondere Clonezilla treffen. Der Name verrät es, Clonezilla ist der Klon-/Imaging-Spezialist schlechthin. Man bootet von der Clonezilla-Live-CD und greift von dort über eine recht einfache Textmenüführung auf die Funktionen zu. Das ist super, wenn man etwa ein System nicht hochfahren will oder kann – beispielsweise zwecks Datenrettung/Forensik. Aber der Umweg über die Live-CD ist eben doch ein Umweg.

Auch der bekannte Partitionierer Gparted kann Festplatten klonen, genauer gesagt: Partitionen kopieren. Das funktioniert zwar in einer netten grafischen Nutzeroberfläche, ist aber dennoch recht aufwändig – zumal man über den Aufbau der Linux-Partitionen Bescheid wissen muss.

gparted screenshot
Gparted kann auch klonen – ist aber umständlich.

Wirklich einfach ist der Klassiker: dd liest eine Datei ein und gibt sie 1:1 in eine andere Datei aus. Erfreulicherweise ist unter Linux alles eine Datei! Ja, auch Laufwerke findet Ihr im Dateisystem als Datei und könnt sie entsprechend ansprechen. dd ist also nichts weiter als ein simpler Kopierbefehl.

Klonen mit dd

Bevor jemand meckert: Ja, man kann heute (fast) alles unter Linux auch mit grafischen Werkzeugen erledigen. Aber der Terminal ist manchmal einfach besser. Und besser heißt hier durchaus auch einfacher! Und dd ist auf so ziemlich jedem Linux vorhanden. Und dd kann als CLI-Tool – natürlich – auch über das Netzwerk klonen. Es ist zuverlässig und läuft dezent im Hintergrund, benötigt wenige Ressourcen und so lohnt es sich einfach, es zu kennen.

Anzeige

Die übliche Ausgangssituation: Ihr habt eine alte Systemfestplatte, die standardmäßig die Bezeichnung sda trägt und durch die Datei /dev/sda dargestellt wird. Dann kommt eine zweite neue Platte hinzu, die das System dann als /dev/sdb einhängt. Partitionen heißen dann übrigens sda1, sda2 und so weiter.

Da dd nur Quelle (if für Input File) und Ziel (of für Output File) benötigt ist der Befehl genau so simpel:

sudo dd if=/dev/sda of=/dev/sdb

Da dieser Vorgang länger dauert und dd so keine Statusmeldung ausgibt, solltet Ihr in der Praxis besser

sudo dd if=/dev/sda of=/dev/sdb status=progress

nutzen, um den Fortschritt verfolgen zu können.

terminal screenshot
dd in Aktion.

Nachtrag: Um den Vorgang zu beschleunigen könnt Ihr noch die Blockgröße auf 1 Megabyte hochsetzen, Standard sind winzige 512 Byte:

sudo dd if=/dev/sda of=/dev/sdb status=progress bs=1M

Troubleshooting

Von der erstellten Festplatte könnt Ihr anschließend booten – bekommt aber eventuell Fehlermeldungen und landet in einem Terminal mit dem Hinweis, es würde ein manuelles fsck für die Partition sda1 benötigt. Gebt in dem Fall einfach

fsck /dev/sda1

ein, um den Filesystem-Check (fsck) durchzuführen. Etwaige Fragen beantwortet Ihr mit Ja, und schon sollte die Reparatur durchlaufen. Nach dem ersten Booten solltet Ihr im Terminal einmal

sudo apt-get update
sudo apt-get upgrade

durchlaufen lassen, für alle Fälle. Hier traten zum Beispiel Grub-Fehler auf, die sich dann einfach über ein sudo dpkg –configure -a lösen ließen, ein Hinweis der apt-get-Kommandos ;)

Klonen über das LAN

Und wenn Euch das noch nicht überzeugt, staunet vor der Macht des Terminals: CLI-Tools (Command Line Interface) haben unter anderem einen riesigen Vorteil – sie können zusammenarbeiten. Ihr könnt im Terminal immer die Ausgabe des einen Programms an ein anderes weiterleiten – was sich unter Linux Pipe (Tunnel) nennt. Ein Beispiel: Ihr listet den Inhalt eines Ordners auf (ls) und leitet die Ausgabe per | weiter an grep, um nach dem Wort „foobar“ zu suchen:

ls ~/mein-ordner | grep foobar

Und so lässt sich eben auch der dd-Output über ssh (mehr zur ssh-Nutzung) weiterleiten und auf der Gegenseite wiederum zurück an (das lokale) dd, das den empfangenen Datenstrom wie üblich in eine Datei schreibt:

ssh root@192.168.178.100 "dd if=/dev/sda " | dd of=/home/mirco/mein-klon.img

Als Variante wird hier nicht auf ein Laufwerk geschrieben, sondern eine Image-Datei „mein-klon.img“ erstellt. So simpel im Terminal – und nun versucht mal, sowas mit GUI-Programmen zu erledigen ;)

Voraussetzung für dd über ssh ist, dass auf dem entfernten Rechner entweder SSH-Verbindungen für den Nutzer root erlaubt sind oder die Ausführung von dd ohne Passwort möglich ist. Den Root-Zugriff könnt Ihr zum Beispiel einfach in der Datei /etc/ssh/sshd_config mit folgender Zeile ermöglichen:

PermitRootLogin yes

Danach startet Ihr den SSH-Server über

service sshd restart

neu. Anschließend funktioniert nicht nur der obige Befehl, sondern freilich auch:

dd if=/dev/sda | ssh root@192.168.178.100 dd of=/home/peter/mein-klon.img

Damit schreibt Ihr ein Image Eurer lokalen Festplatte auf dem entfernten Rechner – eine perfekte Backup-Option!

SSH könnt Ihr übrigens auch ohne Passwörter nutzen.

Mirco Lang

Freier Journalist, Exil-Sauerländer, (ziemlich alter) Skateboarder, Dipl.-Inf.-Wirt, Einzelhandelskaufmann, Open-Source-Nerd, Checkmk-Handbuchschreiber. Ex-Saturn'ler, Ex-Data-Becker'ler, Ex-BSI'ler. Computer-Erstkontakt: ca. 1982 - der C64 des großen Bruders eines Freunds. Wenn Ihr hier mehr über Open Source, Linux und Bastelkram lesen und Tutonaut unterstützen möchtet: Über Kaffeesponsoring via Paypal.freue ich mich immer. Schon mal im Voraus: Danke! Nicht verpassen: cli.help

6 Kommentare

  1. Oh Sh**, falsche Taste erwischt. Wollte den Namen ergänzen: Jens_zwo.
    Unglaublich, so oft kommt der Name ja nicht vor.

    Schade, die schöne Formatierung hat es komplett verhagelt. Jetzt ist es kaum noch lesbar.

  2. Denkt an eure Datenmengen, die übertragen werden sollen.

    Ich muss jede Nacht eine Datensicherung über 150km Distanz erstellen. Der Server hat 2TByte Filespace, von dem etwa 500GByte belegt sind. Weiter unten habe ich mal schnell eine Übersicht erstellt wie lang so etwas bei Vollsicherung per dd dauert.

    Pro dd:

    1. Cooles Kommando zum schnellen klonen
    2. Man kann damit Bootplatten einfach klonen

    Contra dd:

    1. Klonen per ssh übers Netz wird schnell zäh bzw. ihr blockiert ggf. das Heimnetz für Stunden!
    2. Es wird jedesmal eine Vollsicherung erstellt.

    Backup -> rsnapshot -> je nach Datensicherungstiefe einfach bis rel einfach eingerichtet

    Link lasse ich weg ( pot. Copyright Probleme), aber wer im Netz nach „Linux rsnapshot“ sucht findet alles was er braucht.
    Für reine Backups besser rsnapshot nehmen, das macht eine erste Vollsicherung, danach wird bei den nächsten Sicherungen nur noch das weggesichert, was sich seit der letzten Änderung geändert hat (Deltas). Ändert sich wenig, ist die Sicherung nachts ratz-fatz durchgelaufen. Man kann dabei stündliche, tägliche, wöchentliche, monatliche Sicherungen rel. simpel einrichten.

    Bestimmung der benötigten Übertragungsdauer

    Bei den Plattengrößen von i.d.R. 2-4TB wird das dann schnell zäh.
    Viele DSL-Zugänge haben zwar einen fetten Download, aber einen kleinen Upload und der ist dann der Flaschenhals.

    Beispiel: Ich sichere über 2 Standorte mit 150km Distanz.

    Standort1:  35MBit/s Download und 5MBit/s Upload (Backupserver)
    Standort2:  25Mbit/s Download und 2MBit/s Upload (Cloud, Fileserver, Backup auf interne, gespiegelte Platten)
    HDD-Größe: 1TB ~ 1.000GByte ~ 1.000.000MByte ~ 8.000.000MBit
    

    Downloadzeit (Test):
    Von Standort2 wird an Standort1 folgende Datei kopiert (wegen der Authentifizierung per scp)

    root@server2[~]#   ls -lh home.tar
    -rw-r--r-- 1 user  group  102M Okt  2 04:29 home.tar
    
    user@server1[~]#   time scp server2:/home/user/home.tar   .
    real 7m6,063s
    user 0m0,072s
    sys 0m0,556s
    

    Der Wert bei „real“ ist die Übertragungsdauer. Gut 7 Min. für 100MByte, also 70 Min. für 1GByte, also 70.000 Min. für 1 TByte. Das wären 1166 Std. oder 48 Tage.
    Bei 100MBit DSL-Upload immer noch 1 Tag.
    Im internen Hausnetz mit GigaBit Ethernet etwa 2,5 Stunden.

    1. Danke für die ausführlichen Ergänzungen! Und ja, für dauerhafte entfernte Backups ist rsync immer die richtige Lösung, egal ob pur oder als Unterbau wie bei rsnapshot (das ich mir mal näher ansehen werde).

      Habe die Formatierung ein wenig angepasst.

      Und hier für alle noch der LInk zu rsnapshot:
      https://rsnapshot.org/

  3. Auf gut Deutsch: Wenn ich mit dd die interne Platte auf eine externe sichere, brauche ich im Katastrophenfall nur die beiden auszutauschen und kann dann – wiederum mit dd – zurückspielen? Und schreibe ich damit ein Script und trage das in Cron ein, kann ich zeitgesteuert regelmäßig eine Sicherung erzeugen?
    Is ja cool, eeh …

  4. Es fehlt nur noch das übliche bs=1M, damit DD nicht in 512byte Blöcken liest und schreibt… macht dass DD unheimlich viel schneller, bes. bei SD Kärtchen und ähnlichem Gedöns!

    Gruß

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Do NOT follow this link or you will be banned from the site!