Cron run fails when attempting to create a scheduled backup

I am having this same problem, but using 6.x-2.2 and on a brand new Drupal install with NO nodes (just a bunch of modules, some configuration, and Zen). I increased my max execution time to 180, which seems huge, but cron was still hanging.

I spent the last full day troubleshooting this and finally came across the same issue kionae linked above. Adding the suggested function snippet to report which were being hit and backup_migrate is definitely where it's failing. When I disable it, cron runs. When I don't, cron reports "hit backup_migrate cron", then eventually, "Cron run exceeded the time limit and was aborted." (Or sometimes "cron has been running for more than an hour. It is probably stuck.") Then backup_migrate reports "The operation timed out. Try increasing your PHP max_execution_time setting."

I have another Drupal site running this same version of backup_migrate on my same local WAMP installation with no problems. So I am wondering if there's some other module or something that's creating the conditions that cause backup & migrate to hang cron. Here are the differences I can think of between the two sites:

• The problematic site has some modules the working one does not (mostly i18n stuff, rules, messaging, and site map (which, along with search, had been listed as a culprit in the thread above. But cron works with site map on and backup and migrate off.))
• Problematic site has no content whereas working site has a very small number of nodes.
• I noticed people are having the same problem in #375857: Cron getting stuck after MySQL upgrade, and the OP thought it might be related to a MySQL upgrade. I actually did a MySQL downgrade inbetween creating the working DB and the non-working one: original was created with MySQL 5.1.36 and the problematic one with 5.0.51a
• Problematic site had a Duplicate entry error on the info file of every theme, which I fixed using the patch in #43 from #307756: Backport of #147000: Unify and rewrite module_rebuild_cache() and system_theme_data(). However I had this problem on another site which is now in production, used the same patch, and cron & backup_migrate run fine on that site. (Although the production site is running Drupal 6.14 and b&m 6.x-2.x-dev from 2009/10/27; the two local sites are D6.14 and b&m 6.x-2.2.)
• Problematic site also had a duplicate entry problem with the menu router table which I solved using #15 from #246653: Duplicate entry in menu_router: Different symptoms, same issue
• Both local development sites are having a problem I have not solved yet where Drupal core and certain modules, including admin menu, calendar, date, CCK, imagecache, & views) show us as "No available releases found," whereas others (including token, WYSIWYG, pathauto, advanced help, and backup & migrate) behave properly on the available updates screen.)

Sorry if that is way too much information, but I am not a developer so I don't have any in-depth knowledge of the Drupal back-end yet, so I don't know of which of these things could be related. Perhaps someone reading this list will see something that sets them on the right track, since a number of people have reported this problem, but not enough people are having it to figure out what's causing it.

If anyone has any ideas I'd love to hear them, since I can't afford to keep backup turned off for long. I will report back if I uncover any more information.

if a +1GB database is too big for backup and migrate, can anyone suggest alternate automated backup strategies

just trying to run a back up manually with 'backup and migrate', not using cron, kills mysql. I get the fun...mysql has gone away... error so I'm just running mysqldump through ssh for now but I would feel better if this task was automated. I suppose I don't have enough RAM to run this module on such a large database.

I agree with @kentr if you're looking to backup a large database Mysqldump is the best solution I know about. Schedule the command with a cronjob on your sever for an automated solution.

Automatically closed -- issue fixed for 2 weeks with no activity.

@aburnsni, it's not necessarily a bug with table locking.

Table locking itself is a good thing, when it's done in the right way. If your site is in use, tables (or records, in InnoDB) will need to be locked as usage data is updated (watchdog, session data, cache data, user data, system variables, misc logs...).

So, using a site while doing a backup that requires table locks will problematic. If the backup gets the locks first, the site will have to wait. If the site gets locks first, the backup will have to wait. Whichever one is waiting (if it has to wait too long) will eventually time out and it will look like a "crash".

Point being - while there certainly may be incorrectly managed locks, it's probably not possible to completely eliminate the contention between site usage and backups with locks.

Based on this, my perspective is that the issue you reported is not a bug, just a normal consequence.

See if it's using mysqldump. I suspect mysqldump locks all tables at once and doesn't release the locks until the backup is complete. I get the same unresponsive site effect if I use mysqldump without disabling locking.

An alternative would be to have BAM dump each table in succession and lock the table only at that time.

I backup without locks, though.

Oh, I think I see what you mean about not releasing locks. Yeah, they definitely shouldn't persist for a long time after the dump is finished. Maybe because you're executing the backup from the web interface, the process / connection is persisting and the locks aren't being automatically released with the dump is finished.

Try just throwing an "unlock tables" in the code that executes right after the dump is finished - like maybe just before it logs to watchdog.

I've similar issue.
Backup&Migrate takes forever to take a backup.
Finally ending with 512MB out of memory fatal error generating 8GB xdebug log.
I've version: 6.x-2.4
And I've one scheduled task to make a backup.

There are a couple of threads going on here. Some people are having trouble when using the table locking option, some people have huge dbs that simply cannot be backed up before the php script times out.

If your backups are working fine without locking, then you can continue to use the module with locking turned off, you run the risk of getting a backup with some out of sync tables but that's the risk of backing up a live site. If this is an unacceptable risk then talk to your sysadmin about implementing a more sophisticated backup solution.

If anybody has any insight into why table locking is freezing up sites for that long please let me know. None of my testing has shown this issue but every configuration is different and with enough info we may be able to fix this.

If your database is huge and the backup is timing out you could theoretically up your timeout but you probably shouldn't. For very large databases, doing live-site backup at the application layer is probably a strain on your site that you don't want. If you can use a script and mysqldump then that's a safer option.