Clone full disk with multiple OS X Versions installed

Seems to me that dd went off the rails. With signalinfo you can find out how dd is doing.

There is no temp file. It's all in memory.

sudo dd if=/dev/disk1 bs=4096 | gzip | dd of=~/Desktop/disk1img bs=4096

dd if= reads the data sector by sector into memory with a buffer of 4096 bytes this 4096 bytes is forwarded to gzip which compresses then sends to dd of= which writes to disk.

I didn't realize the block size was so small until I reviewed the documentation just now. man dd

I should have written something like:

sudo dd if=/dev/disk1 bs=512m | gzip | dd of=~/Desktop/disk1img bs=512m

This would give you 512 megabytes as the buffer. adjust as needed.

There is a way of getting where the commands are:

sudo kill -s SIGINFO <pid> <pid> ... # get dd info

What you do is to open a second terminal window and enter this command

sudo kill -s siginfo $(pgrep ^dd)

It looks a little scary and you need to be careful.

The -s option of kill turns the command into a signal.

The $(pgrep ^dd) find all instances of dd. In particular, run the pgrep command and search for open process that begin with dd.

siginfo is the type of signal.

Once you enter the command, look on the first terminal window and you will see where you are.

You can see portions of my two terminal windows. Fyi: The up arrow retrieves the last command.

You could check every minute via:

while :; do sudo kill -s siginfo $(pgrep ^dd); sleep 60; done

There is a fifteen minute window for root commands.

you could do

sudo bash

# puts you into a root temrinal. Use exit to exit

while :; do kill -s siginfo $(pgrep ^dd); sleep 60; done

R

There's the unix dd command.

dd if=/dev/disk0s10 bs=4096 | gzip | dd of=~/disk0-s10 bs=4096
dd if=~/disk0-s10 bs=4096 | gunzip | dd of=/dev/disk0s10 bs=4096

You will have to boot off some external hd. You need to figure out the name of the disk. Something like the terminal df or diskutil list commands. Then, unmount the disk from disk utility. The example is for a partition, so the disk would have been "/dev/disk0". The new disk needs to be the same size or I believe larger. I did this in my ppc days but not more recently.

Before I do this, I zero out the free space on the partitions. Thus saving space in the resulting file.

cd x #to the file system on the partiton
dd if=/dev/zero of=zero  bs=1024k  count=101
rm -i zero

If you want to speed up the process and size is not a concern, consider not piping through gzip

(Thanks for testing this. I could never get asr (Apple Software Restore) to work for me (hence my use of CopyCatX), but never thought of using dd as rccharles suggested)

What I do is zero out the unused space. Create a big file of all zeros then delete the file. This makes the compression go faster [ I think. ]. I think a bigger block size does speed things up. I wanted to reduce the size of the resulting archive. I use clonezilla to backup my linux machines across a 100m ethernet link.

It does take a while to copy a disk. It surprised me.

dd if=/dev/zero of=zero bs=1m count=101

create a 101meg file of all zeros.

decompressing seems to go fine.

should be able to see how much processor power is used by compression. You'd think with today's faster processors it would not be as big of issues. I did this on a iMac g3 600. Of course, disks were smaller in the day.

R

SubRosaSoft CopyCatX