I've just tried to run the cron manually in the browser and it announced that the automated backups had been delayed.
The cron.php *hung* in the browser (although it was trying very hard to continue loading).
During this I ran the 'top' command and recieved some alarming CPU stats from mysqld and httpd (the latter even maxed - 100% briefly before resuming to a more casual 98%!).
I send zipped course backups to a dedicated folder using cron.
I have also used the default settings that zip the course to it's own backupdata folder.
There's little difference in the results.
Only the courses themselves differ (It would appear that this part is actually pretty random).
Fedora Core 6
PHP Version 5.1.6
Maybe by now you have got some help elsewhere or given up? Either way it might be useful to look at the computer's loading (with top) when the cron job is not running.
If that shows no other problematic services or applications then maybe you need to consider what hardware spec you are using? If you still have problems then come back and talk again.
I had a similar problem with spiking which I traced to the Gismo block when the update is run as a cron job. Occasionally, as soon as the cron job started running, the load rapidly shot up to something like 14!
I have now disabled this and am waiting to see if I have any more occurences.