Jump to:
| Project: | Backup and Migrate |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
For about two weeks now, cron has been failing to run on my site (watchdog shows the message "Cron run exceeded the time limit and was aborted."). I finally managed to track down where it was failing using the suggestion in this post:
http://drupal.org/node/123269#comment-644012
As it turned out, cron.php was getting stuck when it hit the scheduled backups in Backup and Migrate, and timing out. I disabled the module and cron now runs normally. I have a feeling that the problem is the sheer size of my database (30,000+ nodes, 1.6 GB total size, and still nearly a gig even after excluding some of the less important tables) and the amount of time it takes to dump it all.
I've tried increasing PHP's max execution time, with no luck. Is there anything I can do to get Backup and Migrate to work with such a large setup? I'd really like to continue using it.
Comments
#1
I'm not really sure there's any more you can do other than upping your max execution time. That's a big db and is probably beyond what you can reasonably expect to be able to backup using a php based solution. I should maybe add some code to the module to check for timeouts so other people don't have to go to all that trouble to figure out why their cron is failing.
#2
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:
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.
#3
Please do let me know if you find out what's going on.
#4
if a +1GB database is too big for backup and migrate, can anyone suggest alternate automated backup strategies
#5
Have you tried using the Elysia Cron module as a possible solution? It allows the scheduling of each contrib module's cron hooks independently.
#6
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.
#7
@jday
If you have shell access and can run cron jobs, use mysqldump.
#8
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.
#9
It's quite possibly not your ram. Could be lock contention causing long delays, or something else like simple timeouts.
If you're open to experimenting and prefer to find a solution with backup_migrate, try tweaking max_execution_time AND / OR the various mysql timeout settings.
But, this should be less of an issue if you're executing cron (or backup_migrate directly) through drush / CLI. The only advantage I can think of for using backup_migrate instead of mysqldump is the profile / scheduling system, but you can jerry rig that with the right cron commands, too.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.
#11
I have come accross the same problem. If "Lock tables during backup" is switched on the site crashes, if I switch off locking the backups run (in 7021.94ms). Could there be an issue with the table locking (well there is - but I've no idea where to start looking)?
drupal 6.19
#12
@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.
#13
I understand locking. The problem is that BAM is not unlocking.
With locking on the backup file is created in /tmp (although not gziped or transfered) and the site is completly unresponsive - for at least 15mins - remember without locking backup is complete in <10secs. The site/s do not get a lot of traffic so it should not have to wait that long for a lock.
#14
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.
#15
I've had the same issue when using elysia_cron (see Cron channel has been running for more than an 3600 secs and is most likely stuck. Last job executed: backup_migrate_cron).
My scheduling is straightforward -- one a day (retain 7) and once a week (retain 1). What appears to be happening is that cron triggers the scheduled backup, backup completes, but doesn't get the signal back correctly from backup_migrate that the process is completed.
FWIW, in my case, it appears related to compression of the backup. The default backup_migrate schedule profile calls for gzip compression; overriding these settings for no compression resolves the majority of conflicts with elysia_cron and perhaps other cron handlers as well.
#16
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.