Möchte man einen genaueren Blick auf den MBR einer Platte werfen bietet sich zunächst ein Dump der ersten 512 Bytes einer Platte an:

> dd if=/dev/sda of=mbr.bin bs=512 count=1

Anschließend kann man sich diese Datei mit dem File-Kommando ausgeben lassen:

> file mbr.bin
mbr.bin: x86 boot sector;
partition 1: ID=0×83, active, starthead 1, startsector 63, 40949622 sectors;
partition 2: ID=0×82, starthead 254, startsector 40949685, 2088450 sectors;
partition 3: ID=0x8e, starthead 254, startsector 43038135, 74172105 sectors, code offset 0×48

Man kann die Datei auch dahernehmen und sie wieder auf eine andere Platte duplizieren aber vorsicht, mit solchen Aktionen lassen sich Platten in NullKommaNix unwiderruflich schraddeln. Die Daten sind zwar faktisch unberührt aber ohne die korrekten Partitionsinformationen nicht mehr zugänglich.
Möchte man nur den boot loader ohne die Primärpartition clonen, kopiert man nur die ersten 446 bytes des MBR anstatt der 512:

> dd if=mbr.bin of=/dev/[DRIVENODE] bs=446 count=1

Wer die Windows Installation einer kompletten physischen Platte samt aller Partitionen auf eine neue kopieren möchte erneuert mit diesem Kommando den boot loader auf der Zielplatte ohne die Partitionstabelle zu überschreiben!
Dies löst Bootprobleme wenn nach der BIOS Sequenz lediglich die Nachricht Loading Operating System erscheint, der Bootprozess dann aber einfach eingestellt wird.

Quellen:
Easy way to read MBR?
Disk Cloning

In manchen Situationen möchte man ein Platte exakt genauso partitionieren wie man es zuvor schon bei einer anderen gemacht hat. Man könnte per fdisk, gdisk, parted, etc. sich jedesmal durch die Menüs hangeln, das kann aber u.U. langwierig sein. Hierfür bietet sich sfdisk an:

~$ sfdisk -d /dev/sdc | sfdisk /dev/sdd
~$ # cloning partition schema

Insbesonders bei RAID Konfiguration bei denen ein Reihe von Geräten gleich partitioniert sein sollten ist das hilfreich und funktioniert analog auch für GPT Partitionierungsschema mit dem sgdisk Kommando. Ggfs. auch hier den Disk Identifier überprüfen. Das Partitionsschema läßt sich auch in eine Datei zwischenspeichern:

~$ sfdisk -d /dev/sdc > partition.sfdisk
~$ ...
~$ sfdisk /dev/sdc < partition.sfdisk

Achtung!
Beim dupliziren von Partitionsdaten orientiert sich der Pipe-Vorgang unter sfdisk in der Reihenfolge Quelle, Ziel. Beim Duplizieren von Partitionsdaten mit sgdisk hingegen wird keine Pipe verwendet sondern eine Argumentübergabe die genau umgekehrt angeordnet ist!

~$ sgdisk -R /dev/sd[Y] /dev/sd[X]
~$ # with Y=Destination & X=Source
~$ sgdisk -G /dev/sd[Y]
~$ # create a new disk GUID!

Den Disk Identifier kann auch mit fdisk für MBR-basierte Partitionsschemata ändern:

~$ fdisk /dev/sd[Y]
Command (m for help): x

Expert command (m for help): i
New disk identifier (current 0x00112233): deadbeef
Expert command (m for help): w

Achtung!
Stellt man fest dass der Disk Identifier sich auch nach dieser Prozedur nicht wirklich verändert hat, liegt das an einem recht alten Bug im fdisk-Kommando. Wenn man nichts weiter ändert als den Disk Identifier so erkennt fdisk dies manchmal nicht als Veränderung der Partitionstabelle an und schreibt einfach gar keine Daten, um das zu umgehen kann z.B. den Partitiontyp irgendeiner Partition auf einen beliebigen Wert setzen und ihn anschließend gleich wieder auf den alten Wert zurücksetzen. Das hat keine wirkliche Änderung der Partition zur Folge sorgt aber dafür das fdisk Änderungen nun auch tatsächlich schreibt.

Quelle:
automated disk partitioning with sfdisk

Unter Linux lassen sich physische Datenträger samt Partitionsinformationen als Bit-by-Bit-Copy leicht klonen:

> dd if=/dev/sd[X] of=/dev/sd[Y]
#X=Source drive, Y=Target drive

Solche Vorgänge dauern je nach Diskgröße länger u.U. die ganze Nacht daher empfiehlt es sich den Kopiervorgang asynchron z.B. per Screen anzustarten. Danach liegt eine exakte Kopie vor, bei der allerdings auch der Disk Identifier geklont wurde, dies bringt die Partitions- bzw. Geräteerkennung des Linux Kernels etwas durcheinander weil nun zwei physische Geräte mit ein und derselben Identifikation vorliegen. Man sollte das ändern wenn man Quell und Zielgerät weiterhin in einem System betreiben möchte.

> fdisk -l /dev/md1
[...]
Disk identifier: 0x000b1799

    Device Boot      Start         End      Blocks   Id  System
/dev/md1p1   *          63  1953520064   976760001    7  HPFS/NTFS/exFAT

> fdisk -l /dev/mapper/vg1-lv1 
[...]
Disk identifier: 0x000b1799

    Device Boot      Start         End      Blocks   Id  System
/dev/md2p1   *          63  1953520064   976760001    7  HPFS/NTFS/exFAT

> ### Huiaa! Two Disks same disk identifier

Unter den Experten Kommandos von fdisk findet man:

> fdisk /dev/md2

Command (m for help): x
Expert command (m for help): m
Command action
   [...]
   i   change the disk identifier
   [...]

Mit x gelangt man in der Expert Mode und mit i kann man einen neuen Disk Identifier angeben. Logischerweise sollte man eine Zahl wählen die bisher im System nicht existiert.

Expert command (m for help): i
New disk identifier (current 0x000b1799): 0xdeadbeef
Expert command (m for help): w

> ### Now let's see
> fdisk /dev/md2

[...]
Disk identifier: 0xdeadbeef

Analog funktioniert das auch mit gdisk statt fdisk wenn eine Partitionierung nach GPT vorliegt mit dem kleinen Unterschied das der Disk Identifier dort vom Typ GUID ist.

Mit dd läßt sich der dump auch in eine Image Datei schreiben anstatt die Kopie direkt auf eine andere Platte zu klonen. Nützlich für BackUps von z.B. Datenlaufwerken mit virtuellen Maschinen.

> dd if=/dev/sda dd of=/media/mySDA.img

Verwendet man irgendwann die Quellplatte andersweitig entsteht schnell der Wunsch die angelegte dd Image-Datei vorübergehend ins System einzubinden um z.B. Dateien auszutauschen.

> mount -t ext4 -o loop /media/mySDA.img /media/sda_image

Quelle:
askubuntu

Möchte man eine physische Disk die Teil eines mdadm RAIDs gewesen ist wieder neu partitionieren und untersucht die Disk mit dem Disks Tool (palimpsest) sieht man eine Partition vom Typ Linux RAID. Neben gewöhnlichen Partitionsmarkierungen befindet sich noch ein sogenannter Superblock der Metainformationen bzw. alle Details des RAID beinhaltet zudem die Festplatte mal gehörte. Ausnullen der ersten 512 bytes per dd um die Partitionsdaten zu zerstören ist hier aber nicht ausreichend da der Superblock für gewöhnlich am Ende des physischen Datenträgers untergebracht ist. Beim Versuch den Superblock zu entfernen kommt es manchmal zu einer nicht besonders hilfreichen Fehlermeldung:

# using sdd as an example:
> mdadm --misc --zero-superblock /dev/sdd
mdadm: Couldn't open /dev/sdd for write - not zeroing

Findet Linux beim Systemstart einen solchen Superblock wird dieser sofort an mdadm weitergereicht worauf dieser den RAID-Verbund im System einbindet also einen Device Node anlegt unter dem das Gerät im System ansprechbar ist auch dann wenn das eigentliche RAID im System gar nicht mehr existiert. Man sollte prüfen ob sich nicht klammheimlich ein neues RAID unter /dev/md127 findet:

> cat /proc/mdstat
[...]

md127 : active raid0 sdd5[0]
907026944 blocks super 1.2 128k chunks

unused devices: <none>

Aha! Hier muß man dieses erstmal per

> mdadm --stop /dev/md127

aus dem System auswerfen. Danach läßt sich auch der Superblock der RAID Partition ohne weiteren Fehler entfernen und man kann anschließend die Disk neu partitionieren.

Quellen:
Re: mdadm problem
Linux Software Raid Couldn’t Open …