[gelöst] Backup und Restore mit dd

[Duff]

Hallo,

habe eine Verständnis-frage.

Ich mache auf einem hw Raid 1, bestehend aus zwei Festplatten, ein Backup der einzelnen partitionen mit Hilfe von dd und zusätzlich vom mbr mit

Code: Alles auswählen

dd if=/dev/sda of=/mnt/mbr.img bs=512 count=1

.

Ändere ich nichts an den Festplatten (kein löschen der vorhandenen Partitionen oder ein neues aufsetzen des hw-Raid), so kann ich per dd die einzelnen Backup's der Partitionen wieder problemlos einspielen.


Setze ich das HW-Raid jedoch neu auf, z.B. mit zwei neuen Festplatten, so kann ich zwar alle Partitionen per dd zurückspielen mit (zuvor Backup mit sfdisk -d /dev/sda > sda_partititions) sfdisk /dev/sda < sda_partitions, jedoch kann ich dann aufgrund des fehlenden mbr's nicht booten. Diesen spiele ich zwar mit

Code: Alles auswählen

dd if=/mnt/mbr.img of=/dev/sda bs=512 count=1

ein, aber leider will der Rechner noch immer nicht booten.

Meine Frage lautet nun, ob die Vorgehensweise an sich richtig ist.
Ich meine schon.


Danke.

[Alternativende]

hmh ein hardware RAID synchronisiert sich doch von selbst nach einem Ausfall. Ist ein wenig überflüssig oder nicht?

[schwedenmann]

Hallo

Und die Quellpartitionen sind nur Read-only gemounted ? oder besser gar nicht.

mfg
schwedenmann

[Duff]

Falls beide Festplatten des HW-Raids ausfallen sollten und durch neue ersetzt werden müssen, möchte ich quasi das Backup wieder einspielen können.

Bevor das Backup erstellt wird, wird der Spiegel des HW-Raids getrennt, so dass eine Festplatte nicht benutzt wird.

[rendegast]

Der MBR allein reicht nicht aus.
Der MBR besteht aus Bootcode + Partitionstabelle,
danach kommt noch Grub-Code.

Die Partitonstabelle der alten Platten paßt in den meisten Fällen wohl nicht zur neuen Platte.
Ich würde nach dem Partitonieren der Platten und Einspielen der dd-Images
den Zwischenschritt mit einem externen generischen Bootloader (raid-fähig, zBsp von einer Live-CD) machen.
Damit das System starten (-> den Zustand des Raid prüfen),
und aus dem gestarteten System den grub neu installieren.

Den Grub nicht nur auf die erste Platte, sondern auch auf die zweite Platte installieren.
Kontrollieren, ob die zweite Platte auch als erste/allein starten kann (im Falle des Plattenausfalls).

[Duff]

Zum Restore wird ein Live-Image verwendet und die Plattengröße ist identisch mit den vorherigen.

Mit dd kann ich doch nach dem Partitionieren mit sdfisk /dev/sda < sda_partitions, diese wieder einspielen.

Mir ist jedoch noch nicht klar, wie ich das OS wieder bootfähig bzw. startklar durch den mbr machen kann bzw. muss.

[rendegast]

Zum Restore wird ein Live-Image verwendet und die Plattengröße ist identisch mit den vorherigen.

Trotzdem kann linux die Parameter des Plattenbios zwei gleichgroßer Platten unterschiedlich interpretieren.
Recht sicher wäre ich mir nur bei zwei identischen Platten, wobei auch dabei chargen-Unterschiede auftreten könnten.

Mit dd kann ich doch nach dem Partitionieren mit sdfisk /dev/sda < sda_partitions, diese wieder einspielen.

So habe ich auch geschrieben:

Ich würde nach dem Partitonieren der Platten und Einspielen der dd-Images

Mir ist jedoch noch nicht klar, wie ich das OS wieder bootfähig bzw. startklar durch den mbr machen kann bzw. muss.

ZBsp. mithilfe eines Live-Linux, chroot in das System und grub neu installieren.
(Probleme dabei gibt es meist bei Verwendung eines Systems vom USB-Stick,
da dieser dann meist die Platte hd0 / sda (0x80) bekommt.
Live-linux von CD sind da einfacher.)
Vor der Umschaufelung könntest Du auch aus dem laufenden System heraus eine grub-CD oder -Floppy erstellen.
Aber auch mit einem generischen grub würde ein direktes Starten des Systems möglich sein,
hilfreich beim Erstellen der entsprechenden Anweisungen in der grub-shell ist dabei deren Command/Pfad-Completion.

[Duff]

Ok, danke.

Ich verwende allerdings, aufgrund eines fehlenden CD/DVD-Laufwerks, einen Live USB-Stick.

Wie könnte ich so denn grub auf die Platten installieren?
Wie sieht die richtige Reihenfolge aus?

1. sfdisk /dev/sda < sda_partitions
2. Mit dd alle Partitionen zurück spielen
3. Grub installieren?

[rendegast]

Noch
2a. Raid-Status prüfen

[schwedenmann]

Hallo

Ev. den MBR ohne Partitionstabelle sichern und zurückspielen.

mfg
schwedenmann

[rendegast]

Ev. den MBR ohne Partitionstabelle sichern und zurückspielen.

Der ist aber recht nutzlos ohne den grub-Code ab Sektor 1, ca. 26kB.
Und der könnte wiederum auf anderer Hardware nicht mehr funktionieren.

Da lob ich mir eine chainloadfähige boot-Partition, ohne raid-Schnickschnack.

[Duff]

Wie kann ich dies mit dem grub oder der chainloadfähigen boot-Partition machen?

[rendegast]

grml booten, md-device kontrollieren (ready?) + mounten, chroot dahin,
'grub-mkdevicemap', /boot/grub/device.map kontrollieren + anpassen (eventuell wegen des USB-Stick),
'grub-install' zum passenden MBR.
Testen.

[Duff]

Danke.

Nachdem ich die Backup's mit dd in die einzelnen Partitionen eingespielt habe (und ggf. vorher noch ein sfdisk /dev/sda < sda_partitions ausgeführt habe), kann ich den grub über die LIVE-Distribution von einem USB-Stick wie folgt mit Hilfe eines kleinen Shell-Skriptes erstellen.

Code: Alles auswählen

MP=`mktemp -d`

# mount root-partition
mount /dev/sda5 ${MP}
# mount boot-partition
mount /dev/sda1 ${MP}/boot

mount -o bind /dev ${MP}/dev
mount -o bind /sys ${MP}/sys
mount -t proc /proc ${MP}/proc

cp /proc/mounts /etc/mtab
chroot ${MP} grub-install /dev/sda
chroot ${MP} update-grub

umount ${MP}/proc
umount ${MP}/sys
umount ${MP}/dev
umount ${MP}/boot
umount ${MP}

rm -rf ${MP}

[ThorstenS]

Code: Alles auswählen

umount ${MP}

rm -rf ${MP}

Böse Falle! Wenn die Partition nicht ausgehangen werden kann, weil du dich da evtl. noch drin befindest, wird dir der rm alles grillen!
Also machs lieber so: umount ${MP} && rmdir ${MP}

Ansonsten kann ich dir grml sehr empfehlen. Da gibt es grml-chroot, welches dir das mounten und umounten von /proc &Co. abnimmt...

[Duff]

Danke. Aber das Ganze geschieht automatisiert per Skript und die Variable MP wird eh unterhalb von /tmp mit mktemp -d angelegt.

Deshalb sehe ich dort keine Bedenken.

[Stefan]

Hallo,

ich habe für meinen blog einmal so einen Bericht geschrieben.
Vielleicht hilft der dir ja auch weiter

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.

[ThorstenS]

Hallo,

ich habe für meinen blog einmal so einen Bericht geschrieben.

...
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:
...

Es freut mich, dass du meinen Wikiartikel teilweise wort-wörtlich dafür verwendet hast:
http://wiki.debianforum.de/Vollst%C3%A4 ... zen_Platte

[Stefan]

Hallo Thorsten,

schon vergessen, das ich bzw wir das Thema schon vor einem ca halbe Jahr hatten ?
Wir hatten glaube ich auch über PN die Sache Besprochen, daraufhin wurde diese Sache mit Verweis auf die Wiki im Blog Veröffentlicht !
Also kein Grund zur Panik

Gruß,
Stefan

[ThorstenS]

Ich sehe das leidenschaftslos, wir betreiben das Wiki ja alle zusammen für jedermann. Und wenn die Beiträge dort helfen, finde ich das grandios.
Einen Link zu deinem Blog oder dem Wikibeitrag hätte ich persönlich schöner gefunden, deswegen mein Beitrag vorhin.