Does anyone know if this is possible? I am attempting to copy one "master" hard drive to two or more "destination" drives. I hope to use the DD command because the master drive is encrypted and I need to make exact copies to "destination" drives.

I have used dd if=/dev/sda of=/dev/sda and it works for one-to-one operations. I tried dd if=/dev/sda of=/dev/sdb of=/dev/sdc but the command skips the of=/dev/sdb and copies to sdc....I knew that was going to be too easy :-)

Any help would be appreciated. We currently use a hardware disk duplicator to perform the function but they tend to be expensive.

use the parted magic or clonezilla live cd for that

I reviewed the doc's on the two suggested solutions. It doesn't seem like either is capable of taking one disk and making multiple copies at the same time. I may be missing something though.

How about dd if=/dev/sda | tee /dev/sdb | tee /dev/sdc > /dev/sdd

What does it mean tee ?

From the tee man page

Thanks catkin,

I put in a master drive and 2 destination drives and attempted the command dd if=/dev/sda | tee /dev/sdb | tee /dev/sdc > /dev/sdd

The command ran for about 20 minutes and then returned the following error:

tee: standard output: No space left on device

I booted each of the destination drives and found that the securedoc boot loader was copied, but the encrypted part of the disk was not copied. Is it possible that this is because the "tee" option tries to process what is being read and written and, because the disk is encrypted, it is unable?

This definitely brings me closer to my final goal

The encyption should not matter. The info coreutils 'tee invocation' command gives examples of tee usage including processing a .iso file and a tar file. I figure tee is agnostic about what it's copying.

Is it possible that the error message is correct and that one or more of the destinations really wasn't big enough?

How did you determine that "the encrypted part of the disk was not copied"? If you did it by trying to browse the file system it could be that incomplete encrypted data is unusable. How about using dd to copy the securedoc boot loader and a few MB of the encrypted part to a file for both the original and one of the targets and then checking for similarity/difference with md5sum?

In terms of lack of space...My master is an 80GB drive and the two destination drives are 160GB.

I used an external caddy attached to a secure-doc'd computer to check what was copied. I am able, on a successfully copied drive, to read the contents of the disk. When I put in the drive that gave me the tee: error, I see an 80GB partition, but am unable to browse it without getting errors. Also, the dd if=/dev/sda of=/dev/sdb command that works took almost 2 hours to complete, where the more recent command with "tee" only took about 20 minutes.

I will attempt again with all drives exactly the same just to eliminate different drive sizes/geometries.

I have tried copying both encrypted and non-encrypted hard drives using the dd if=/dev/sda | tee /dev/sdb |tee /dev/sdc > /dev/sdd command and nothing gets copied. I believe what was happening before when it looked partially successful is that the destination hard drives had not been wiped and the file table got copied back during the process and it "looked" like the files were copied. I am not even able to copy disk-to-disk using this command....minus the |tee /dev/sdc and replacing > /dev/sdd with > /dev/sdc

I will keep plugging away. Any other suggestions from readers of the forum?

I'm sorry it did not work and can't understand why.

Is there anything I should do to prepare the destination drives? Maybe I am missing something basic.

Not that I can think of; dd simply starts at the first block addressable via the driver and writes to successive blocks until finished; I had hoped that tee would not alter anything except to bifurcate the data stream to successive disks.

It didn't work when attempting a copy of a master usb memory stick to 2 destination memory sticks of same size and manufacture either. I did notice that, even though they looked identical on the outside, they had different geometries. The copy process does work when doing a one-to-one operation.

A quick inspection of the tee source code shows it using read(2) to read from stdin and and fwrite(2) to write to each output file (I did not realise several were possible or would have suggested dd if=/dev/sda | tee /dev/sdb /dev/sdc /dev/sdd). I have some doubt about the O_BINARY on line 144 (what is it's value? Where is it set?) but netsearching it suggests it is ineffective on UNIX and Linux anyway.

Apart from that slight doubt the tee source code supprts my original concept that tee simply copies stdin to its output verbatim ...