Tut mir leid, das zu hören, ich weiß aus Erfahrung wie ärgerlich das ist – gerade bei System-Platten sind die Fehlerquellen vielfältig … Meist gibt es Probleme mit laufenden Systemen, sicherer ist immer ein Start von einem Live-System. Grundsätzlich ist dd allerdings ein extrem solides Werkzeug, also gib es nicht auf ;)

Hi Mirco, bin immer noch fasziniert von diesen Möglichkeiten! Leider hat es bei mir aber nicht ganz geklappt.

Ich habe mit dem dd-Befehl das alte Setup auf die neu eingebaute SSD übertragen. Dort kam es aber (warum auch immer :-) mehrfach an und hat die gesamte Festplatte (500gb) vollgepackt. Eine komplette Version des Betriebssystems wurde es dennoch nicht, am Ende wurde nicht alles transferiert. Ich habe dann noch gewerkelt, muss am Ende aber alles löschen und hab es heute neu installiert.

Trotzdem danke, beim nächsten Mal versuche ich es wieder!

na, das ist ja was – so einfach kann es gehen? Ich will gerade einen älteren Laptop mit einer SSD aufmöbeln, und wäre natürlich sehr froh, wenn ich die bestehende Installation einfach so mit dd rüberschaufeln kann. Bin gespannt. Danke für Deinen Tip!

Die Frage stell ich mir auch gerade – schade das deine Frage nicht beantwortet wurde. Hast du eine Lösung gefunden?

@Richard Deine Frage zum Kabel: Ja, du brauchst einen USB –> SATA-Adapter. Die Elektronik ist oft im Adapterkabel integriert. Wenn du USB2 verwendest, muss dieser auch noch mit einem externen Netzteil gespeist werden, alternativ einen aktiven Switch dazwischen hängen. Über USB3-Anschluss mit USB3-Adapter hat es bei mir immer ohne externe Spannungsversorgung funktioniert.

@Richard Wenn dein Notebook von der derzeitigen Systemplatte gebootet ist, werden sich einige Dateien im System während des Kopiervorganges verändern, du weißt dann nicht genau, in welchem zustand sich das System auf der neuen Platte befindet. Deshalb ist es besser, das Notebook mit einem „Rettungssystem“ vom USB-Stick zu booten, auf deiner jetzigen Systemplatte ändert sich dann nichts. Ich kann mir nicht vorstellen, dass du nicht wenigstens eine Partition auf deiner Platte hast (obwohl es das gibt). Mit beispielsweise „fdisk -l“ kannst du dir das anzeigen lassen, und weißt auch gleich, welchen Namen die Platten vom System bekommen haben. An der Größe erkennst du, welches die alte und die neue HDD ist. Wahrscheinlich bekommst du Daten über „sda“ und auch „sda1“ angezeigt Dein dd-Befehl wird dann so funktionieren. Beachte aber, dass du danach nicht beide Platten am Notebook hast, wenn du neu startest. Die haben dann beide die gleiche UUID´s, und das führt zu Fehlern. Außerdem wirst du auf der neuen Platte erst einmal nicht mehr Platz haben. Dazu muss entweder die jeweilige Partition vergrößert werden, anschließend auch noch das Dateisystem. Oder, auf dem gewonnenen Platz kann eine weitere Partition angelegt werden. Alternativer Vorschlag: Wenn dein ubuntu schon 8 Jahre alt ist, wäre es vielleicht auch angebracht, mal eine neuere Version zu installieren, einfach ganz neu. Die für dich relevanten Daten kannst du dann besser mit „rsynv -av“ auf das neue System übertragen.

Zur Info HDD ist Jaaa 120GB und die SSD wird 250 bzw. 500 GB werden. Danke im Voraus

.

Wenn Du die Festplatten dann einfach austauschst, brauchst Du ja gar nichts zurückspielen. Wichtig ist, dass nicht beide Festplatten in einem System stecken, da auch die UUID´s der Partitionen identisch sind, und dann das System nicht weiß, welche es einbinden soll. Die Platten müssen nicht gleich groß sein! Die Zielplatte darf auch größer sein, ist dann aber nicht voll ausgenutzt. Mit einem Partitionierungs-Tool kann man aber eine vorhandene kleinere Partition vergößern, oder aber den übrigen Platz für eine weitere neue Partition nutzen. Für die Systemplatte (120GB) habe ich mich für folgenden Weg entschieden: Sicherung in eine Datei (System.img), von dort auf eine zweite Platte. Im Fehlerfall einfach alte Platte raus, neue rein. Da das Image noch vorhanden ist, kann man es auch nochmal auf eine Platte kopieren, und, bei Bedarf, eben auch auf eine größere, welche sofort funktioniert. Die kann man dann, wie gesagt, noch nachbearbeiten.

Zurückspielen geht eben nicht, wenn die Größen der Festplatten unterschiedlich sind.

Abbrechen kannst Du im Terminal immer mit STRG+C.

Ich hab 250Gb. Mit der jetzigen Geschwindigkeit geht das ewig. Kann ich den Vorgang auch abbrechen? Möchte meinen Rechner kein halbes Jahr laufen lassen bis das fertig ist.

Vielen Dank die schnelle Antwort. Mir steht Knoppix 9.1 Live-CD (und -DVD) zur Verfügung. Leider ist mir Linux sehr ´un-handlich´, nach-dem Windows gewohnt, besonders die Befehlszeilen-Anweisungen. Ohne die gesamte Festplatte – Sektor-für-Sektor – kopieren müssen, nur die (tatsächlichen) Daten der beiden Partitionen EINER Festplatte, in eine Datei, ist wohl etwas aufwendiger, die Anweisung dafür, als ein direktes Image von Laufwerk (Festplatte) zu Laufwerk (Festplatte). Und das Recovery braucht dann nochmals (eine) die korrekte Anweisung.

(In meinem Fall handelt es sich um ca. 14 GB Daten, die gesamte Festplatte je um 110, 500 GB.) Zusätzliche Hürde: ich muß mal zu 110 GB HD und aber auch wieder zurück. Bedeutet: Bei 14 GB Daten, plus zusätzlich vorbereiterter HD mit passenden Partitions-Größen (passend zur benötigten Größe der zu kopierenden Dateien) macht ein Kopieren des MBR, für die Partitions-Größen (des Ziel-Laufwerks) zwei-mal überflüssig, bzw. (1 mal) unbrauchbar. ABER: der Rest des MBR muß wohl kopiert werden können müssen. (Heißt: ich muß auch auf (Ziel-)Festplatte kleiner als Quell-Laufwerk mal kopieren können.)

Ich muß leider noch immer zweifeln, daß mir das eine kosten-freie Möglichkeit überhaupt leisten kann, Entschuldigung, bitte.

dd kann auch in eine Datei schreiben – wie oben in „Klonen über das LAN“ beschrieben, da landen die Daten in einer Datei „mein-klon.img“.

Auch das Kopieren von Festplatten mit mehreren Partitionen ist möglich, ebenso das Booten davon.

dd erstellt schlicht 1:1-Kopien, von daher unterscheiden sich Original und Kopie/Backup nicht voneinander. Wobei es natürlich immer auch Problemchen und Ausahmen und kleine Details zum Beachten gibt – mehr dazu gibt es beispielsweise bei ubuntuusers.de

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/

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

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.

Danke für die Ergänzung, hatte ich ganz vergessen – nu‘ ist es aber nachgetragen.

Gruß