LinuxQuestions.org
Page 1 of 2 1 2
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   Linux - Newbie (http://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Cloning a drive with dd (http://www.linuxquestions.org/questions/linux-newbie-8/cloning-a-drive-with-dd-4175413213/)

scandalist 06-25-2012 01:14 AM
Cloning a drive with dd
 
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 (Post 4711049)
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 (Post 4711049)
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 (Post 4711212)
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 (Post 4711226)
"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 (Post 4711226)
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 (Post 4711237)
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?


All times are GMT -5. The time now is 02:46 PM.
Page 1 of 2 1 2
Show 50 post(s) from this thread on one page