cloning an entire hard drive? (including the partitions)

Lawless Flogic · 2014-02-06 20:53:47

I have a dual boot setup with many partitions (arch, osx, and a shared partition with a shared home directory). this is very convient because i can work in linux or osx and then if i need a tool that one system doenst have I can just reboot and continue working with the same files. the only issue is that it is rather complicated and time consuming to set up, and I'm worried about having to do it again if (when) something gets mucked up.

so is there a way to back up an enitire disk? I'm talking about 1 hard disk with 6 partitions where some are formatted ext and some are formatted hfs. It seems like this would be possible but my googling has not returned anything terribly useful so far.

does anybody else use a setup like this? any help would be appreciated!

nagaseiori · 2014-02-06 20:56:03

dd if=/dev/sdX of=/dev/sdY

?

Slithery · 2014-02-06 21:00:36

You could always use dd.

Clonezilla will probably work as well, you'll have to check that it fully supports HFS though.

jasonwryan · 2014-02-06 21:08:43

Not a Sysadmin issue, moving to NC...

ewaller · 2014-02-06 21:50:13

dd would be my choice. But [ewaller drags out his soapbox], be extremely careful when you enter the command. Then stop, put your hands in your lap, and read the command you typed. Then read it again. Verify the source and destination, contemplate why those with experience have dubbed dd to mean "Data Destroyer", read that command again, throw caution to the wind, and press enter. Pray you got it right.[/soapbox mode]

Last edited by ewaller (2014-02-06 21:50:46)

drcouzelis · 2014-02-06 22:19:20

I do just that! I have four operating systems installed and make backups using "dd". You can read about my backup strategy on my blog here: http://archlinux.me/drcouzelis/2012/04/17/backups/

alphaniner · 2014-02-06 23:03:29

Using dd to clone/backup seems awfully inefficent in most cases. If I wanted to duplicate a drive, I'd use dd to clone the beginning of the drive (0 to sector before first partition), then format the partitions and copy the data over.

Of course, that's for linux filesystems. To clone other filesystems, dd is often the safest choice. In the past I used ntfsclone and fsarchiver for Windows partitions, but that was for creating image files rather than cloning. If you want to go that route, partimage and partclone which seem to have some support for HFS.

Lawless Flogic · 2014-02-07 00:07:15

Ok thanks for all the feedback! sorry if this is dead simple, but when I asked a knowlegable person that I know he said he didnt know of anything offhand to do this. but you guys say i can do this with dd? just to clarify, dd will copy all of the partitions, so when i run it on /dev/sda it will copy /dev/sda1, sda2, etc? and they will remain formatted the same?

thiagowfx · 2014-02-07 00:07:32

But does dd only copy the used space?

Usually I use clonezilla too, it is perfect to backup. But I have to confess I've never got any success when I needed that backup, I'd always get a different error.

Never tried it, but there is ddrescue also. It looks better than dd for backups.

frostschutz · 2014-02-07 00:22:01

dd copies everything. the copy dd creates is the same size as the source. the downside of dd is that you can't use it while the filesystems are mounted, as the copy would be inconsistent.

Every few days I make a copy of my SSD by using md. The SSD is actually set up as a RAID 1 with 1 disk. When I want to make a copy (while things are mounted and running), I add another disk (a HDD backed logical volume) to the RAID. That mirrors stuff in the background and once the sync is done, I kick it out of the RAID again. That way you have an image like you would with dd but it's consistent because any changes that were made to filesystems during the sync process were instantly synced too by the raid layer.

script to go with that (/dev/md0 being the SSD, /dev/HDD/ is a HDD backed volume group, /dev/HDD/SSD the Logical Volume for the SSD mirror)

#!/bin/bash

mdadm --grow /dev/md0 --raid-devices=2 --force
mdadm --zero-superblock /dev/HDD/SSD
mdadm --manage /dev/md0 --add --write-mostly /dev/HDD/SSD
mdadm --wait /dev/md0
sync
mdadm /dev/md0 --fail /dev/HDD/SSD
mdadm /dev/md0 --remove /dev/HDD/SSD
mdadm --grow /dev/md0 --raid-devices=1 --force

Of course this is just a quick way to get back on your feet; for a real backup (incremental, keeps around older copies of files, etc.) you should still do rsync/tar/dar/whatever to a backup disk...

Last edited by frostschutz (2014-02-07 00:25:34)

Xyne · 2014-02-07 00:38:25

dd copies the raw disk data: boot sectors, partition tables, file data, empty space... everything. dd does not see the partitions or the file systems. All it sees are raw bytes. A disk is just one huge array of bytes. When you copy a full disk with dd, you end up with a copy of that array of bytes. If you copy the array back to the disk at a later time, you end up with the exact same data as when you created the array from the disk (yes, partition tables, file data, deleted files, etc.). It is not efficient if you want to back up your data because it will recopy unchanged bytes and it will copy all unused bytes. If you have a 1 TB disk then dd will copy 1 TB every time it is run (assuming no errors), even if you only have a 100 GB partition with 20 GB of files on it. Whatever time you may eventually save from not needing to recreate the partition table and file systems will be lost 100 times over through regular backups using dd.

In your case I would create a script to regenerate the partition table and file systems if necessary and then use a tool like rsync to back up and restore data as necessary. It will be much faster.

ddrescue is only better if there are disk errors (e.g. bad sectors that generate read errors). Under normal operation it is neither better nor worse than dd afaik.

Fun fact: paritions copied to files with dd can be mounted as regular disks with the "mount" command. You can use this to create encrypted LUKS partition files as a sort of poor man's TrueCrypt.

WonderWoofy · 2014-02-07 01:07:35

Xyne wrote:

<snip>
In your case I would create a script to regenerate the partition table and file systems if necessary and then use a tool like rsync to back up and restore data as necessary. It will be much faster.
<snip>

I came here to say exactly this. In addition to being faster, it will also rewrite every file sequentially. So if you use a HDD you can enjoy the benefits of a nice defrag as well.

Arch Linux

#1 2014-02-06 20:53:47

cloning an entire hard drive? (including the partitions)

#2 2014-02-06 20:56:03

Re: cloning an entire hard drive? (including the partitions)

#3 2014-02-06 21:00:36

Re: cloning an entire hard drive? (including the partitions)

#4 2014-02-06 21:08:43

Re: cloning an entire hard drive? (including the partitions)

#5 2014-02-06 21:50:13

Re: cloning an entire hard drive? (including the partitions)

#6 2014-02-06 22:19:20

Re: cloning an entire hard drive? (including the partitions)

#7 2014-02-06 23:03:29

Re: cloning an entire hard drive? (including the partitions)

#8 2014-02-07 00:07:15

Re: cloning an entire hard drive? (including the partitions)

#9 2014-02-07 00:07:32

Re: cloning an entire hard drive? (including the partitions)

#10 2014-02-07 00:22:01

Re: cloning an entire hard drive? (including the partitions)

#11 2014-02-07 00:38:25

Re: cloning an entire hard drive? (including the partitions)

#12 2014-02-07 01:07:35

Re: cloning an entire hard drive? (including the partitions)

Board footer