Image mit dd

[Stefan]

Hallo,

ich habe heute meine Festplatte mit dd gesichert.
Nach dieser Anleitung:

Code: Alles auswählen

Heute zeige ich euch wie ich meine 64 GB SSD Festplatte mit dd Clone und damit eine Sicherung meiner Systemfestplatte erstelle.

Als erstes schauen wir uns an welche Platte wir sichern wollen. das machen wir mit dem Befehl

    fdisk -l

Dort sehe wir unter anderem das:

    Disk /dev/sda: 64.0 GB, 64023257088 bytes
    255 heads, 63 sectors/track, 7783 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0007fd62

Für uns ist interessant was hier steht  /dev/sda

Das ist die Platte die ich sichern möchte.

Ich habe oben mit 16065b die Blockgröße von einem Zylinder gewählt, da der Standardwert von dd nur viel zu kleine 512 Byte beträgt. Dieser verlangsamt das Backup enorm. Der folgende Befehl gibt dir die Blockgröße deiner Festplatte (hier /dev/sda) aus:

    root@debian: lang=C fdisk -l /dev/sda | awk '/^Units/ {print $5}'
    16065

Der Befehl zum sichern lautet dann noch

    root@debian: dd if=/dev/sda bs=16065b of=/mnt/backup/Sicherung_sda-`date -I`.img

wobei ihr /dev/sda und /mnt/backup entsprechend anpassend müsst.

    dd if=/mnt/hdb1/myimage.img of=/dev/hda

Mit dem oberen Befehl kann man das Image zurückschreiben lassen, wobei darauf zu achten ist das neue Platte nicht gemountet ist und das die die gleiche Größe oder größer ist als die gesicherte HDD.

Quelle : http://tinyurl.com/2um3yqb

Meine Frage ist, reicht diese Anleitung aus, bin ich damit auf der sicheren Seite ?
Eine weitere Sache ist das zurück spielen des Image auf eine neue Platte, muss die neue Platte genau die gleiche Größe haben oder kann man auch größere Platten verwenden ? Geht auch ein Image von einer SSD auf eine SATA Platte?

Hoffe ihr könnt meine neugier beantworten

Gruß,
Stefan

[whisper]

Ich behaupte, das ist in Ordnung so.
Die Sache mit der Blocksize ...
Überprüfe die größe der gesicherten Dstei.
Nachteil: Du sicherst auch alle leeren Blöcke mit.

[spiralnebelverdreher]

Diese Anleitung sollte ausreichen.
Du musst dir natürlich sicher sein, welche Platte wie heißt, denn ein UNDO gibts bei dd nicht. Vor dem dd Befehl würde ich persönlich noch eine Prüfung des Dateisystems auf dem Quellmedium mit dem fsck Befehl durchführen, damit sich das mit dem dd auch lohnt.

Da du die gesamte Platte (/dev/sda) und nicht nur eine Partition (z.B. /dev/sda1) kopierst, wird der Master Boot Record (MBR) einschließlich Partitionstabelle mit gesichert. Beim Zurückspielen wird damit dann auch MBR und Partitionstabelle auf dem Zielmedium überschrieben.

Das Zurückspielen auf eine größere Platte ist IMHO kein Problem.

Es gibt übrigens das Paket partimage, dass dies alles auch erledigen kann und dazu auch noch Komprimierung oder Sicherung übers Netzwerk erlaubt und man kann auch noch ne sinnvolle Beschreibung dazu erfassen.

[akku]

Du musst unbedingt auf die korrekte Blocksize achten, ansonsten haste kein lauffähiges Backup.
Mach zur Sicherheit nochmal ein 2tes Image ohne Angabe der Blocksize.
Der Rest ist in Ordnung und sollte passen.

[robi1]

Prinzipell geht es so einfach auch
Allerdings das Arbeiten mit dd auf Platten und Partitionen hat einige Falltüren, da auch einiges kopiert wird, an das man nicht immer gleich denkt. Auch sollte man unbedingt bedenken ( ein solcher Hinweis fehlt im HOWTO oben komplett), wird gleichzeitig noch schreibend auf die Platte/Partition zugegriffen, baut man sich mehr oder weniger große oder kleine Fehler in die Kopie ein, da die Daten mit dd vom Anfang zum Ende linear geschrieben werden und das dauert seine Zeit, das Filesystem aber Datenblöcke und die Verwaltungsdaten des Filesystems in der Zwischenzeit kreuz und quer schreibt wie sie sich gerade ändern und logisch auf der Platte angeordnet sind. Eine während der Laufzeit von dd geänderte Datei könnte also durchaus hinterher in der Kopie auf Datenblöcke verweisen die noch als frei markiert sind - Oder - eine während der Kopieerstellung von dd geänderte Datei zeigt nach dem Wiederherstellen dann einen komplett falschen Inhalt - und ähnliches mehr. Ergebnis könnten kleine Fehler im Filesystem sein, die oftmals erstmal überhaupt nicht auffallen, die aber durchaus auch Wochen später noch zu dicken Problemen führen können. Auch das Filesystemjournal ist davon in aller Regel betroffen, und kann bei einem anschließenden unvollständigen fsck das Problem erstmal durchaus auch noch vergrößern, das es den Inhalt eines komplett falschen Zeitpunktes enthält. Der Filesystemsuperblock ist in der Kopie nicht als "clear" markiert und wird vor dem mounten einen fsck anfordern der genau das Journal mit dem zeitlich falschen Informationen abarbeitet.

Die Blockgröße ist bei Platten , Partitionen oder ähnlichen im Gesamtergebnis relativ Wurst, das Ergebnis ist immer das gleiche egal mit welcher Blockgröße gearbeitet wird. Es wird hier nur festgelegt wie groß die einzelnen Übertragungsblöcke sind, die dd jeweils sequentiell einzeln bearbeiten soll. Wer allerdings irgendwann mal erfunden hat, die Blockgröße ausgerechnet aus der Ausgabe von fdisk herauszulesen, ist mir bis heute schleierhaft. Ist noch niemanden aufgefallen, das diese Werte nicht mal durch 512 teilbar sind?
dd kann auf ein Blockdevice auch nur mit den Treibern des Blockdevices zugreifen, und das sagt schon der Name, dieses arbeitet blockweise muss also immer ganze Blöcke lesen und schreiben, auch wenn dd bei jeder Einzelübertragung intern nur mit einzelnen Byte oder der halben-Blockgröße oder (9*dreiviertel-Blockgröße -7Byte) pro Übertragung arbeitet. Die Geschwindigkeit sowie Cacheeffekte mit der das intern abläuft, sorgen zwar dafür das dabei die Blöcke meist nicht alle mehrfach gelesen/geschrieben werden brauchen wenn man mit "schiefen" Blockgrößen arbeitet, aber optimal ist das nicht.

Ausführliche Informationen, mit Anwendungsbeispielen für tag-tägliche und einige außergewöhliche Aufgaben, mit vielen Warnungen vor den Fallstricken uA. auch mit Hinweise auf die Verwendung einer angebrachten Blockgröße sind übrigens hier zu finden.

robi1

[Stefan]

Hallo zusammen,

erstmals vielen Dank für die Infos.
Ich werde eine weiter Sicherung mittels einer Live CD und CloneZilla erstellen.

Was mir aber fragen aufwirft ist das Appel mit seiner Time Maschine es geschafft hat ein Image vom Laufendem System zu machen.
Also sollte das doch unter Linux auch möglich sein.
Weil das doch bei dd angezweifelt wurde.

Gruß,
Stefan

[TuxPeter]

Hallo,

wenn Du sicherstellen könntest, daß sich das laufende System während des dd-Laufes nicht ändert, könntest Du es auch damit sichern.
Alle Prozesse beenden, die irgendeinen Schreibzugriff haben und Platte umounten ...
geht normalerweise nicht.

Also besser von einem anderen System aus machen! (z.B. Live-CD)

Das Rückkopieren auf eine andere Platte oder Partition hat auch Tücken. Wenn sie größer ist und der Platz genutzt werden soll, muß man anschließen mit parted oder ähnlichem ran, wenn sie kleiner ist, wird das Filesystem nicht OK sein.

Partimage macht sowas ähnliches wie dd + Komprimierung und behandelt (nach Warnungen) auch das Rückkopieren auf eine andere Part. Man kann mit und ohne MBR kopieren und das Prog mit einer Maske oder rein mit Parametern bedienen.

Grüße, TuxPeter

[AxelMD]

Hallo Stephan,

da Du ein SSD verwendest, geht ich davon aus, dass Du auch ext4 als Dateisystem verwendest.
Partimage ist da nicht kompatibel!

Evlt. könnte fsarchiver eine Lösung sein.

http://sourceforge.net/projects/qt4-fsarchiver/

http://wiki.ubuntuusers.de/qt4-fsarchiver

Den Bootsektor der Partitionen müßtest Du mit dd sichern, fsarchiver sichert auf Fileeben und nicht auf Sektorenebene.

MfG

xsid

[gnude]

Je nach System sicher ich mit DD oder auch mit Partimage.
Da ich noch gern JFS als Dateisystem nutze tut es Partimage ganz prima...

Aber eine Sicherung mit DD ist sehr schön exakt weil wirklich alles Sektorweise kopiert wird.
Deshalb ziehe ich DD dem fsarchiver auch vor...