Cloning a drive with dd

scandalist · 06-25-2012, 01:14 AM

I read on lifehacker that cloning a drive with Linux is easy as running this command.

Code:

dd if=/dev/sda of=/dev/sdb

Is this true? Apparently it is a bit for bit copy but I just can't imagine the process being this simple. Has anyone successfully cloned a drive with this method? I don't want to brick my data by using unsafe methods.

EDDY1 · 06-25-2012, 01:39 AM

I myself use clonezilla-live & haven't had a problem
http://en.wikipedia.org/wiki/Clonezilla
http://clonezilla.org/

descendant_command · 06-25-2012, 02:32 AM

Quote:

Originally Posted by scandalist

I read on lifehacker that cloning a drive with Linux is easy as running this command.

Code:

dd if=/dev/sda of=/dev/sdb

Is this true? Apparently it is a bit for bit copy but I just can't imagine the process being this simple. Has anyone successfully cloned a drive with this method? I don't want to brick my data by using unsafe methods.

It certainly can be that easy.
That command gets EVERYTHING, MBR, partition layout and all.

There may be snags with different drive geometry, size etc. but you can try the clone before deleting the original ...

pixellany · 06-25-2012, 05:50 AM

Quote:

Originally Posted by scandalist

I read on lifehacker that cloning a drive with Linux is easy as running this command.

Code:

dd if=/dev/sda of=/dev/sdb

Is this true? Apparently it is a bit for bit copy but I just can't imagine the process being this simple. Has anyone successfully cloned a drive with this method? I don't want to brick my data by using unsafe methods.

Yes, it is that simple.......BUT

You have to be absolutely sure that you have the correct device designations---there is no "undo".

You may want to set the block size for best speed. You can run trials like so:

Code:

dd if=/dev/sda of=/dev/sdb bs=M count=N

Start with M=2048 and keep the product of M*N the same---let's say ~ 100MBytes. As you change the block size, look at how long the operation takes. I don't remember the results the last time I tried this----it is useful to experiment a bit to see how it works and whether the block size makes any difference.

AND---the target drive has to be the same size as the source--or larger.

There is a megathread here somewhere--started by member "Awesome machine"----more than you ever wanted to know about "dd".

pixellany · 06-25-2012, 06:39 AM

Curiousity got to me---on this machine (Lenovo laptop, 4G RAM), there is a dramatic increase in speed when the block size is larger than ~1K---I have no idea why.....

Code:

[root@herring-lap mherring]# dd if=/dev/sda7 of=/dev/sdb1 bs=256 count=128K
33554432 bytes (34 MB) copied, 23.7808 s, 1.4 MB/s
[root@herring-lap mherring]# dd if=/dev/sda7 of=/dev/sdb1 bs=512 count=64K
33554432 bytes (34 MB) copied, 23.241 s, 1.4 MB/s
[root@herring-lap mherring]# dd if=/dev/sda7 of=/dev/sdb1 bs=1024 count=32K
33554432 bytes (34 MB) copied, 6.2106 s, 5.4 MB/s
[root@herring-lap mherring]# dd if=/dev/sda7 of=/dev/sdb1 bs=2048 count=16K
33554432 bytes (34 MB) copied, 6.19044 s, 5.4 MB/s
[root@herring-lap mherring]# dd if=/dev/sda7 of=/dev/sdb1 bs=4096 count=8K
33554432 bytes (34 MB) copied, 6.11977 s, 5.5 MB/s

I have noticed that many people suggest a block size of 8192---seems like a good choice based on this quickie test.

syg00 · 06-25-2012, 06:44 AM

Hmmmm - such (small) tests are meaningless unless in-storage buffers are purged.
drop-caches is useful these days, but I still prefer to reboot between any disk tests.

As for "dd", IMHO it should be avoided at all costs for non-forensic backups. Period.

TobiSGD · 06-25-2012, 06:56 AM

I have had the best results with block sizes between 8M and 32M.

Quote:

Originally Posted by syg00

As for "dd", IMHO it should be avoided at all costs for non-forensic backups. Period.

I am really curious for an explanation, like to share your wisdom?

pixellany · 06-25-2012, 06:59 AM

Quote:

Originally Posted by syg00

Hmmmm - such (small) tests are meaningless unless in-storage buffers are purged.
drop-caches is useful these days, but I still prefer to reboot between any disk tests.

As for "dd", IMHO it should be avoided at all costs for non-forensic backups. Period.

Well Hmmmmmm to you too......

<<begin dumb questions>>
What is an in-storage buffer?....drop-cache?
<<resume normal mode>>

What exactly is wrong with dd for backup? Beside---OP did not ask about backup---the question was about cloning a drive......dd do dat dandy....

syg00 · 06-25-2012, 07:08 AM

Sorry - should have been "drop_caches" (underscore).

Disk read are buffered in page cache ("cached" in the free command et al). Subsequent reads to the same data may (will) be resolved from those buffers (in RAM), negating any disk read effects.
See drop_caches in "man proc" for how this can (now) be ameliorated.

"dd" copies everything blindly - including errors in the underlying filesystem. Makes backups (including clones) suspect at best.

TobiSGD · 06-25-2012, 07:30 AM

Quote:

Originally Posted by syg00

"dd" copies everything blindly - including errors in the underlying filesystem. Makes backups (including clones) suspect at best.

OK, that makes sense. So the solution to this would be to fsck all filesystems first, before you clone the disk using dd.

pixellany · 06-25-2012, 07:41 AM

Quote:

Originally Posted by syg00

Sorry - should have been "drop_caches" (underscore).

Disk read are buffered in page cache ("cached" in the free command et al). Subsequent reads to the same data may (will) be resolved from those buffers (in RAM), negating any disk read effects.
See drop_caches in "man proc" for how this can (now) be ameliorated.

Thank You!!

syg00 · 06-25-2012, 08:00 AM

Quote:

Originally Posted by TobiSGD

So the solution to this would be to fsck all filesystems first, before you clone the disk using dd.

Maybe. (or in my opinion "no").

fsck validates the filesystem, not the files/data within. That's why you can wind up with lots of "bit and pieces" of files in lost+found.
So, if the fsck is followed by remedial action on damaged files, then "dd" is fine. But a script that just fsck's then dd, uh-uh; still too risky.

TobiSGD · 06-25-2012, 08:39 AM

Wait, not one application I know of can deal with the data in the filesystem, I can't even imagine how that should be possible. So in your opinion even a simple backup scheme using cp isn't trustworthy, because the data may already be corrupted before the transfer?

jefro · 06-25-2012, 11:57 AM

"I don't want to brick my data by using unsafe methods."

Well, I can say that if you ask then don't do it. dd had been known to bite most of us at one time or another.

EDDY1 posted an alternative to using a file based copy. As with dd and almost every other program there are many issues.

Issue tends to be size, geometry and then second is how the system boots. The geometry is sometimes difficult to fix while the boot naming tends to be more fixable.

I don't know of any fool proof way to copy a drive. I have used dd hundreds of times both directly and using G4U disks.

Like Porky says, When hunting for rabbits, you have to be vwery vwery cawful, hahahaha.

pixellany · 06-25-2012, 01:33 PM

Perhaps this field is already well-plowed,but:

If I have a drive with the essential data readable, and I then clone it for backup, it seems I have not lost anything----I still have a better backup than if I had done nothing.

---right?