Yeah, Carbon Copy Cloner is a great app and it’s free! You might also want to take a look at ChronoSync. Setting up a cron job in Unix is definitely an option, but it’s probably a lot to get your head around if you’re not used to working in the terminal at a lot.

If the second drive is networked, use Chronosync. Carbon Copy Cloner has some issues across networks.

Grant … that may be true for making a bootable clone backup of a startup drive, or for backing up system level files … but I have never had issues using CCC when it comes to copying/moving simple files and folders over a network … CCC has actually been one of the most stable and trustworthy utilities I have ever used.

Yes, that may be true. Though, as the FAQ states for “some Apple File Protocol share points” … but you forgot to mention the title for the entire FAQ article was … “Backing up to/from network volumes and other non-HFS volumes” … I have found using SMB and drives formatted in HFS+ … there is rarely an issue …

As long as you make sure the network connection is not using AFP … there have been few if any issues using CCC in this manner …

The FAQ goes on to state:

“Unmount the sharepoint, then restart the Macintosh or Network Attached Storage device that is hosting the AFP sharepoint. Reconnect to the sharepoint and try the backup task again.

Connect to the sharepoint using SMB instead of AFP. Choose “Connect to server” from the Finder’s Go menu, then specify “smb://servername.local/sharepoint ” to connect to the server using SMB rather than AFP.

Reduce the number of files/folders in your backup set, e.g. split your backup task into multiple tasks.”

I have been using CCC to copy files/folders over my network for years without issue …

Butch,

I may not have found the exact FAQ … I just did a quick google. I spent quite a lot of time trying to make this work for me with CCC. My particular circumstances were that the backup software had to be able to mount the drive itself and CCC/SMB failed to copy some stuff without errors across my network. (SMB is a bit limited on Macs). So, sticking with AFP, I had constant errors with CCC, which were resource fork issues, related as I recall to permissions issues for drives connected to remote Macs on a network. No workaround, worked around. Chronosync talks about the same issues (no doubt because there’s an OS bug) but provides a proprietary workaround, which is all I need. Having made the switch for this one Mac, I’m quite happy to use either app now. Both are excellent pieces of software. There are still some issues with Chronosync copying across networks (permissions) but you can choose to ignore the alerts and the copies, in my case anyway, are just fine.

Ah…AFP… I wish we would get native SFTP support in OS X so I could forget about AFP. So easy, yet so problematic at times.

Butch,

I’ve used CCC for a number of years, but when I switched my backup strategy to an HD attached to a Mini on a wired network, located in a fireproof safe in my basement, I ran into this issue. SMB didn’t work as a solution, but Chronosync works around the bug by using a proprietary system. From CCC’s FAQ :

Resource limitations encountered while backing up resource forks to/from AFP volumes

We have received sporadic reports of a problem that can occur while copying files to or from some Apple File Protocol sharepoints (e.g. a volume shared from another Macintosh using the “File Sharing” feature of the Sharing preference pane). When the problem occurs, the server erroneously maintains open references to hundreds of resource forks. Eventually the file sharing service encounters a system-imposed resource limitation and is unable to continue sharing files until it closes the open resource fork files. Misleading errors are subsequently returned to CCC, reported as “Input/output” errors or “Bad file descriptor” errors. CCC will report that “An error occurred while CCC was getting or setting information about this item on the source/destination”.

This problem is due to a bug in the AppleFileServer application, and affects several different implementations of the AppleFileServer (e.g. on Mac OS X as well as on some other NAS devices). We have identified a few solutions/workarounds to try when encountering this problem:

Unmount the sharepoint, then restart the Macintosh or Network Attached Storage device that is hosting the AFP sharepoint. Reconnect to the sharepoint and try the backup task again.
Connect to the sharepoint using SMB instead of AFP. Choose “Connect to server” from the Finder’s Go menu, then specify “smb://servername.local/sharepoint ” to connect to the server using SMB rather than AFP.
Reduce the number of files/folders in your backup set, e.g. split your backup task into multiple tasks.

You could utilize Unix chron jobs with rsync, but you might want to look at using Carbon Copy Cloner. It’s a fantastic utility that does a whole lot more, but yes, you can schedule the transferring of files from one drive to another.