Posted by austintnacious on December 22, 2009 at 4:10am
10 followers
Jump to:
| Project: | Backup and Migrate |
| Version: | 6.x-2.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
So, I've been trying to work out why my cron is getting stuck since last night.
Using cron control module I've turned off cron jobs for all module and then on again one at a time.
I narrowed the problem down to Backup Migrate (Files).
I can do manual db backups BUT manual files backups fail and I'm assuming this is the problem.
I recently upgraded to Backup Migrate 6.x-2.2. (after getting caught by the 2.1 mix up)
Backup Migrate Files used to work just fine on my system can anyone give me any ideas what's wrong?
I'm not sure if the problem is with Backup Migrate Files or with Backup Migrate itself, since it is the latter that has recently changed, so I'm going to cross post this in the Backup Migrate issue cue also.
Thanks!
Comments
#1
I would imagine that the problem is older versions of B&M did not include data from a number of tables (cache at least) by default, whereas the new version defaults to including data from all tables. Thus, a gzipped backup of my site on the last version of B&M was about 2-5mb, and now it is 950mb. This could nuke your cron job pretty easily.
#2
As for me scheduled backup fails because new version needs permissions forbidden by my ini.php.
I don't know what to do, besides changing hosting. For now,I reverse in older version of B&M
#3
I have the same issue with my really good hosting provider. They're fast and reliable, but my cron job won't work if I enable this module. When I GZip my database, it takes about 1mb since the site has just been released. What to do and what's the workaround?
@sahuni: what's the newest "older version" (that would support cron) we're talking about?
#4
I reversed to 6.x-1.2
#5
I installed this patch on the latest dev....seemed to work OK. On my first attempt I deleted the video and added a new video in one pass. Upon saving it had unpublished my node and I was unable to publish it. Nothing I did allowed me to publish the node until I deleted the video and saved, at which point I could publish. Then upon trying to add a different video again it once again unpublished the node (I do not use the functionality that publishes the node when the video is done converting), but I was able to publish and it seems to have worked fine.
#6
Cross-reference to the issue at Backup and Migrate Files: http://drupal.org/node/665524
vood002: I think you have the wrong issue queue.
#7
For the problem of the original post, you might have this issue: #832866: After upgrading from 1.3 to 2.2 "every day" schedule becomes "every second"
#8
I can assure you that this issue is still alive and active under B&M 2.4. When B&M is running my cron job WILL get stuck. I can clear it running:
DELETE FROM variable WHERE name="cron_semaphore";DELETE FROM variable WHERE name = "cron_last";
as a mysql query on the database. But cron will jam up again.
However, if I disable the module completely, cron will continue to run correctly.
Things suggested and checked:
• My "every day" schedule was indeed set to "every day" and not "every second"
• My backup is set to ignore the large cache tables like it did in B&M 1.x (I guess it didn't default to this behavior in 2.2)
Here is a hint as to what might be happening: My VPS host alerted me that there are many, many 200+ MB files showing up in my /tmp directory. This directory is outside of my main directory so I don't see it. The database is usually less than 20 MB and is set to drop cache tables. So how does B&M work. Here is my theory:
B&M will ultimately save only the database without the full cache. But first it must do a mysql dump. It saves all tables into a file in the tmp directory with every intention of winnowing it down. But by the time it has mostly saved it, the max execution time is up and it throws a cron error. From her, every time cron runs the module will try and run again and create a full dump of the database, but never get around to actually saving the back-up nor registering that it has backed anything up. So it creates a viscous circle.
Is this behavior different than it was in version 1.x. I notice some people have had success with downgrading and I wonder if that is the right solution for me.
#9
Is anyone in a position to comment if there are any issues with down-grading to the 1.x branch of Backup and Migrate? That version was at least working for me and would not prevent cron from running.
#10
Yes mcfilms, you can downgrade to 613.
You delete your actual b&m directory, get the 613 version instead and run update.php.
No problem
#11
Thanks sahuni. Here is what happened:
B&M 2.4 was already disabled. I uploaded backup_migrate-6.x-1.3 to over-write the newer version. I went into the modules folder and enabled B&M. The banner at the top of the page disappeared. I looked around my site and every_single_graphic was gone. The site was fully functioning, but there were no graphics.
I disabled Backup and Migrate 1.3 and all of the graphics instantly returned.
Anyone have any clue why this would happen. This behavior does not seem like it _should_ be linked to B&M, but clearly it was.
#12
Are you using the private file mode? I seem to recall the 1.x branch having issues with private file systems.
#13
Yes I am. And unfortunately I need that, but thank you. At least the mystery is solved.
I think my database has grown to a size that is just too big for B&M to manage internally. It is 200 MB even after the caches have been cleared.
#14
Yeah, that might be too big to backup with this module. You might be better switching to a command line script for a database that big. Or try using B&M 2 using drush which shouldn't be subject to the same limits as running through apache.
#15
Subscribing. Updating backup & migrate basically killed my client site, and being a cron error it was a complete git to uncover the cause. I increased the memory limit to half a gig to no avail. I'd suggest some kind of notice or fix for this. There are likely to be quite a few people wondering why their crons have given up the ghost and unable to figure out why.
#16
I can confirm that a fresh install of 2.4 crashes cron, and manually invoking just it using supercron results in wsod. Downgrading to 1.3 works, but now I have no scheduled backups because existing scheduled items were set to go to an S3 server.
#17
Another data point I forgot to mention: Backup for download was never affected by this. Just the cron-driven process was failing.
#18
Can any of you guys check your apache error logs for any php fatal errors?
Thanks
#19
Bueller?
#20
I'm seeing this problem, too, with daily and weekly backups.
This is because cron puts a record in the semaphore table to prevent simultaneous cron runs.
So cron runs, sets the semaphore, starts a backup, the backup records the semaphore.
When you restore from this backup, it still has the semaphore, so Drupal doesn't start any more cron runs.
if you do this: DELETE FROM {semaphore} WHERE name='cron'; you fix the problem and cron is happy again.
A work-around would be: Configure Backup & Migrate to ignore the semaphore table
A solution would be: have the restore system remove this record if present.