Output
You're redirecting output to log files - that's fine - but those logs may become bloated over time or full of warnings and errors that you have no intention of looking at. At minimum configure these files with a standard .log extension in /var/log/ and configure a logrotate job to compress them after some time.
However, I don't redirect output at all. The reason is that any output during a cron job will be logged to the /var/log/cron file. In addition, crontab can be configured, per user, to email the output. There are some Magento modules that return their own model during the cron process and thus Magento logs the name of the model - storing it in the cron log database table. This is undesirable for me, and useless output.
You can get a visual overview of logs run using a fantastic plugin from the folks at Aoe and @fbrnc - Aoe_Scheduler. Its location is here on Github: https://github.com/fbrnc/Aoe_Scheduler
Sudoer
There should be no reason to execute PHP as sudoer, as the PHP scripts in question will only reach out and touch the DB. They should only need to have read access.
indexer.php
Reindexing every hour is also unnecessary. I would schedule the indexer to run overnight, possibly, or during your off-peak hours.
cron.php
Cleaning the cron logs is something that I would do every 30-60 days, not hourly. You will still need to configure a job that doesn't explicitly clean the cron, but rather calls the cron.php on its own. This should be set up to run every 5 to 10 minutes. Magento schedules jobs 15 minutes in advance, but only runs them as often as your cron is running. Personally, I configure cron.php to run every 5 minutes.
There is some debate over whether to run cron as a PHP process or a shell script. From my understanding if you run it as PHP, it will not block the next scheduler request from running if the previous instance is still running from the last cron execution, which may be desirable. If you use the bash script, it will block. How you want this to operate is up to you, if you prefer not to have jobs run concurrently.
log.php
This is a good one to run nightly before or after your indexer completes. If you have a large db, I recommend spacing this out by 2-3 hours, because your Indexes may take several hours to complete, especially if you have flat catalog enabled.
If you've never run this, or run it quite infrequently, you may want to run log.php clean on its own the first time with no other scheduled jobs, and you may want to enable the maintenance message on your store. The reason being is that in my experience any locking to the log tables cause significant visible issues to customers in your store.
Because the log tables are stored in the DB, writes get queued up behind your deletes, and, well, it can be apocalyptic (I had a client with 100MM records in their visitor log table - we just had to archive offline, truncate and start over; no delete job would complete during a maintenance window).
I hope this helps. Best of luck.
Answer 1. I just tried doing the backup and restore feature from the Magento Admin Panel.
Magento is putting the store into maintenance mode using the maintenance.flag method. This involves creating a blank file in the sites root directory called "maintenance.flag" once the backup or restore is complete this file will need to be deleted.
Answer 2. In the 1.9 RWD Dev Guide they say that RWD was not implemented for captcha, I'm not sure why.
It has been disabled by the use of a blank captcha.xml file in the following directery:
/app/design/frontend/rwd/default/layout
If you delete this file it will revert to the one in base/default theme. I can't see a reason why leaving captcha on would cause any problems.
Best Answer
To make sure cronjobs are executed, start off by installing the excellent AOE Scheduler: http://www.magentocommerce.com/magento-connect/aoe-scheduler.html
After installing this you'll know whether cronjobs are running, which ones are and at what time.
If they aren't working please write in details what you have done so far to get cronjobs running. (what hosting are you on and what cronjob settings did you use).
Or:
An easier way to check if cronjobs are working is to edit /cron.php and add:
This will add 'cron excecuted at: 20:43:30' to the system.log file in /var/log/ every time the cronjob runs.