seeking HOWTO us 'dd' to clone and copy HDD contents

SaintDanBert · 12-21-2018, 02:13 PM

I want to capture a set of files (probably ISO) that will mostly guarantee that I can "restore" or "recover" an entire HDD -- not only the files and folders, but the partition details, boot record and all.

I know that /dev/sda is the entire HDD and that /cev/sdaN is a partition on that same hdd.

I know that I can use 'dd' to clone and copy HDD content.

Code:

prompt$  sudo --login
**********

prompt#  dd if=/dev/source  of=/dev/target

QUESTION #1:
What do I capture so that I get an image file (ISO) of nothing but the low-level boot parts written by GRUB?

I think that I need the MBR for dos-style drives
I'm not sure what I'd need for a GPT drive
I think that I need the /boot folder tree
(I usually have a separate partition mounted /boot)

For MBR, one article suggested:

Code:

prompt#  ## as super user
prompt#  dd if=/dev/sdX of=/tmp/sda-mbr.bin bs=512 count=1
prompt#  ## ... to restore
prompt#  dd if=sda-mbr.bin of=/dev/target bs=1 count=64 skip=446 seek=446

For GPT, one article suggested:

Code:

prompt#  ## as super user
prompt#  sgdisk --backup=my-mbr.iso  /dev/sda
prompt#  ## ... to restore
prompt#  sgdisk --load-backup=my-mbr.iso  /dev/target

I know how to copy/clone /boot as a folder tree or as a separate partition file system.

QUESTION #2:
Is there a shell command {aka, something I can use in a script} that will tell me (1) this HDD is MBR-based, vs (2) this HDD is GPT-based?

Thanks in advance,
~~~ 0;-Dan

Brains · 12-21-2018, 03:57 PM

Your best bet is to make an image of the drive with dd or dcfldd, I prefer dcfldd as it defaults to block size and is faster-->dcfldd if=/dev/sdx of=/partition large enough for the image/image.dd. Once you have an image of the drive, you make a copy and play with the copy, if you screw it up, ditch it and make another copy to play with till you fix it. There are ways of testing an image of a drive as if it was a physical drive as you attempt to fix it. This is the forensically safe way to work on a non-booting drive and avoid loosing everything, which is the risk involved when working directly on the drive itself.

Once you have an image to play with, run command: fdisk -l image.dd to find if it's GPT or MSDOS based partitioning. Testdisk can be used to attempt to repair automatically, the image file will need to be read/write, documentation available here.

jefro · 12-21-2018, 04:07 PM

You could look at the first parts of a disk in a hex editor to see what type of disk it is usually.

dd is independent of the filesystem and disk type. If the distro booted (generally live for any /boot) and it is able to read the disk you can dd it off.

ondoho · 12-22-2018, 03:19 AM

it's the sort of question that is best answered by finding a good tutorial.

effectively, it's really quite simple:

Code:

dd if=/dev/sda of=/yourchosenoutput

"sda" could also be sdb, sdc etc. it is a complete drive with all partitions, boot record etc.
where and what you output to, is a matter of personal preference.

pan64 · 12-22-2018, 03:30 AM

at first you can try similar threads (see the bottom of this page) and actually there is a very good thread about dd here, at LQ, just unfortunately I cannot find it right now. I hope someone will post it.

tofino_surfer · 01-02-2019, 10:03 PM

Quote:

What do I capture so that I get an image file (ISO) of nothing but the low-level boot parts written by GRUB?

You appear not to understand what an ISO filesystem is. dd just produces a binary dump of data. The ISO 9660 file system was created initially for optical media but can be written to USB drives and other media. It is a complete file system of directories. The dd utility and ISO file systems have nothing to do with each other.

Quote:

I think that I need the MBR for dos-style drives

You would also need the grub2 core.img stored in the "MBR gap".

Quote:

I'm not sure what I'd need for a GPT drive

First of all GPT drive does not necessarily mean EFI firmware. There are BIOS/GPT systems as I have. The type of drive partitioning and the type of firmware a MB has are different things.

For an EFI system you would need the /EFI directory where the actual EFI bootloader grubx64.efi is located.

Quote:

prompt# ## ... to restore
prompt# dd if=sda-mbr.bin of=/dev/target bs=1 count=64 skip=446 seek=446

This would only restore the 64 byte partition table and ignore the first stage bootloader code in the first 446 bytes. This seems to be the opposite of what you want.

Quote:

For GPT, one article suggested:

prompt# ## as super user
prompt# sgdisk --backup=my-mbr.iso /dev/sda

I suggest you find better articles. The use of the .iso extension is very wrong in this case as this is not an iso file system. The .bin extension is more appropriate.

ehartman · 01-03-2019, 04:04 AM

Quote:

Originally Posted by tofino_surfer

You appear not to understand what an ISO filesystem is. dd just produces a binary dump of data. The ISO 9660 file system was created initially for optical media but can be written to USB drives and other media.

And isn't specifically geared to Unix/Linux, there are extensions TO the ISO 9660 standard for that (Rock Ridge Extensions) and for M$-Windows too (Joliet fs).
See also this man page "man 8 mkisofs"/

But you are very right in that the .iso extension should be used only for images OF an ISO 9660 (possibly with extensions) file system.

Brains · 01-03-2019, 05:20 AM

Quote:

Originally Posted by pan64

actually there is a very good thread about dd here, at LQ, just unfortunately I cannot find it right now. I hope someone will post it.

How to do everything with dd by AwesomeMachine.

pan64 · 01-03-2019, 07:17 AM

yes, thats' it. The only thing what was missing there: dcfldd which was an improved dd.

onebuck · 01-03-2019, 07:41 AM

Hi,

I believe the LQ Thread; 'Learn The DD Command Revised' by AwesomeMachine is great to see how to use 'dd'. Loads of feedback!

Hope this helps.
Have fun & enjoy!