How to copy an os x drive?

I have noticed that CC Cloner can be slow - took a whole weekend to copy 450GB of data between ultra-wide RAIDs! However, it did work completely flawlessly (apparently).

To back up everyone else, CCC works fine.

I have used CCC several times to clone a complete system from one harddrive (or partition) to another. It worked perfectly! So for your (less demanding) job, it should do everything you want. You do need admin-rights, but don't need to login as root.

Both ccc and superduper take a very long time to copy a 100GB HD. I haven't switched drives yet so I'm not sure who gets the points. If someone can tell me how to speed it up to less than 12hrs i'll give them the points plus some bonus points too :)
Thanks people.

Well you can look at taring an zipping large files up, or use stuffit to compress files.

I've just done this, and it reduced the time by about 30%, but that was given that I had a large number of documents I could compress, lots of already compressed files, jpg's dmg's zip files, that sort of thing, and it's not going to be as good.

is the "shared drive" you speak of the same as the boot drive? then, yes, like everybody is saying, run Carbon Copy Cloner or SuperDuper.

if it's all on a different physical disk and you feel like it hook a second disk up and just drag stuff. 100G is a lot though. if the server is staying up and in use while this is going on you might look at running rsync locally... the first run would take a while but then you could keep running it periodically until you were ready to kick everyone off, run rsync one last rime, then bounce the box and pull out the old disk.

I suppose it's a question of which solution (out of CCCloner, SuperDuper and Disk Utility) the guy used in the end.

and wether he zipped it and tarred it.

He suggests that the points should go (with bonus's) to whoever can speed it up, well that would be me, if of course he actually did it.

I'd be happy with a 3 way split.

Yeah, for the sake of resolution I'll go with that. :0)

I seem to have about 40 emails at the moment, all with a 50/50 with someone (mostly weed) where the solution could have been one of two things, and the person hasn't got back, so no one knew who was right.

>>I seem to have about 40 emails at the moment
Yep.. trying to get the old questions closed ..

Oh yes, don't take it the wrong way Venabili, you're doign a great job!

Sorry guys,

I have points for only 3 way split.
The first two comments give alternative solution, the third I selected also...
Sorry... I wish I had 5 more points here...

The only comment I would make is to go back to the posters last comments.

"Both ccc and superduper take a very long time to copy a 100GB HD. I haven't switched drives yet so I'm not sure who gets the points. If someone can tell me how to speed it up to less than 12hrs i'll give them the points plus some bonus points too :)
Thanks people."

The answer to that, is zip and tar.

In that case, I feel I have to reiterate my point that presuming (logically) that the 12hrs is in the context of minimising downtime, zip and tar would not necessarily be the best solution because the data obviously needs to be offline while its being compressed. So unless (time taken to compress files) + (time taken to copy compressed files) is quicker than a straight copy it's no quicker.

Nope, you could compress whilst you're transferring the files to disk.

Something along the lines of.

ls `*` |xargs |compress > /Volumes/newdisk/$1.

As a 3 second example which probably won't work but should show the way.

Okay, my shell experience clearly isn't as extensive as yours but I still would have thought that total time = compression time + transfer time. It's merely occuring file-by-file in this case. I'd be delighted if I was wrong as this is potentially a very useful method.

This is more for fun that to do with the question now, although I guess it's still useful.

Well we're both potentally right.

How?

Well if the transfer medium is slower than the compression time, then I'm right.

If the transfer medium is faster than the compression, then you are correct.

Example

1 MB file, no compression takes 1024 seconds to transmit.                                     Total time 1024 seconds
1MB file, takes 1 second to compress to 100k, which takes 100 seconds to transmit. Total time 0102 seconds.


Saving, 900 seconds.

however.

1 MB file takes 100 seconds to transmit.                                                                      Total time 100 seconds.
1 MB file takes 99 seconds to compress to 100k which takes 10 seconds to transmit    Total time 109 seconds.

Mostly, it's quicker to compress and send.

however, with a slow machine and a fast firewire drive it's going to be close.

Also for the shell you'd probably use find, not list.

If you're really interested I can dig something out for you.

Hehe, nah I think you've indulged me enough, thanks. I see what you mean now and I'm surprised I hadn't considered the difference compression could make - 900 seconds multiplied by 100,000 is a lot of minutes saved.

Obviously though this is based on your example compression ratio of 1:10, so in this instance the question of who's answer is closest would be answered by finding out what sort of data is on the server in question. If it's video or graphics then of course there's not much consideration to be given to  your method.

Cheers!