Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This just started happening over the past two months. Backups no longer work through the web interface, but they do work through Drush (drush-bam). I tried changing options, double-checking the file locations (usually use download), changed file compression options, checked / unchecked "lock file tables" and anything else I could think of. The process runs for several minutes, but nothing happens. There are no log entries created, the process simply ends. I had been using this module for many years and this is the first time I've seen this behavior. Compressed backup is 4.46 mb.
Comments
Comment #1
muranod CreditAttribution: muranod commentedComment #2
muranod CreditAttribution: muranod commentedComment #3
muranod CreditAttribution: muranod commentedI was trying again this morning and after running Backup and Migrate through the web interface, it didn't seem to work again, but I looked in Drupal's tmp folder and found this file: backup_migrate_nN4JfD.com-2015-01-31T09-54-32.mysql . the size is 105,065,139 .
So, it looks like the backup is being created, but the download is simply not being initiated.
Changing the parameter to "backup on server" and it did the same thing. It performed the backup, but then left it, uncompressed, in the tmp folder.
Then I used Drush (Drush bam-backup) and the process went all the way through and put the gzipped backup in the manual backups folder for the BAM module.
Don't know what is causing the last couple of steps from completing when using the web interface.
Comment #4
serundeputy CreditAttribution: serundeputy commentedHi @muranod .
Sounds to me like php timeouts.
Look at 'admin/reports/status/php'
what are the values of:
max_execution_time
memory_limit
if those are being exceeded the request can timeout. You might try increasing those usually in /etc/php.ini the location of the php config file will be towards the top of the page 'admin/reports/status/php'
If you change anything in php.ini you will need to restart apache for the changes to take effect or restart the php service if you are using nginx or fpm.
See if that helps.
cheers,
~Geoff
Comment #5
couturier CreditAttribution: couturier as a volunteer commentedI think this issue has been resolved by the newer releases up through 7.x-3.2.