my node_revisions table's size is 0.9GB, scheduled every 24 hours, but items under 'Scheduled Backups' look like:

db-2008-10-27T15-23-52.sql.gz 10/27/2008 03:25 pm 24.74 MB download restore delete
db-2008-10-27T15-23-46.sql.gz 10/27/2008 03:25 pm 24.74 MB download restore delete
db-2008-10-27T15-22-40.sql.gz 10/27/2008 03:24 pm 24.74 MB download restore delete
db-2008-10-27T15-22-36.sql.gz 10/27/2008 03:24 pm 24.74 MB download restore delete
db-2008-10-27T15-22-15.sql.gz 10/27/2008 03:23 pm 24.74 MB download restore delete
db-2008-10-27T15-21-41.sql.gz 10/27/2008 03:22 pm 24.74 MB download restore delete

it seems 24.74MB is the max size, and it does try hard to backup the whole database piece by piece every one minute?

Comments

rickvug’s picture

rickvug commented
Status: Active » Closed (works as designed)

I'm marking this as "by design" as I'm assuming that Backup and Migrate is not made for sites with large databases. For a larger database like yours it is time to script something directly at the command line level. Recently on Drupal Planet there was an excellent blog post and discussion about backing up Drupal databases. See http://www.thingy-ma-jig.co.uk/blog/26-11-2008/backing-drupal-database for other options.

1kenthomas’s picture

1kenthomas commented

Is this just the PHP file transfer limit? Why shouldn't B&M work for "large" db sizes? I'd like ronan's opinion...

ronan’s picture

ronan commented

There are a number of reasons that B&M (or indeed any php solution) doesn't work well for large DBs. The most likely candidate is php timeout, which is 30 seconds by default. Another is memory limit, though Backup and Migrate takes pains not to take up too much memory (by transcribing the db 1 line at a time to disk) so this is less likely.

Both of these things can be changed in your php.ini or .htaccess files if you're familiar and comfortable with changing PHP settings. If you are not (and maybe even if you are) it's probably wiser to look for a non-php solution.

Also, because the backups are failing, the scheduler is attempting to restart them everytime cron is run, which is causing all of those incomplete backups to pile up. You should turn off the scheduler to stop this.

Long term these limitations can be overcome, but the only plan I have is to make a copy of the database (not necessarily a great idea for one that large) and back it up/restore in batches. That's a long way off though.