Hi all,
I use the Backup and Migrate module in order to backup my website everyday.
Two weeks ago I created a schedule for every day and I selected to keep the last 7 files in the repository (one week of backups).
The first week everything worked fine and I received a successful email notification that the backup created in XXX seconds etc.
The first day of the second week also worked fine. It replaced the first backup file from the first week (because as I said I want to keep only 7-one week's files) but after the second day and so on it returns empty backup files (it is in the repository but the size of the file is 0 bytes the same with the nfo file). Also the emails I received those days were also successful but the file each day was still empty.
Any ideas about this issue? The only modification that I made all these days was in CRON, I changed the automatic run of CRON to every 12hours from 3hours
Thanks a lot!
Comments
Comment #1
zataragate13 CreditAttribution: zataragate13 commentedComment #2
ronan CreditAttribution: ronan commentedNot sure what might have happened here. Can you increase the number of backup files to keep (to say, 100) and tell me if backups start working again?
Comment #3
zataragate13 CreditAttribution: zataragate13 commentedthanks ronan! I changed some configuration in cron runs and now it seems that work ok ( as before)
I would like to ask you something else! the size of the backup file is around 14mb but when I download manually a dumb version of the database through phpmyadmin is 400mb .. is this normal? the file of 14mb from backup and migrate is ok?
thanks in advance!
Comment #4
bleen CreditAttribution: bleen commentedI'm also seeing empty backup files ... this is happening for all my scheduled backups as well as when I run manually. In the manual case I see this: http://goo.gl/tgBgJ6 ... so it is taking a decent amount of time to come up with an empty file. This particular site has a fairly large DB in terms of number of tables (~400) but Ive had sites with larger.
Thoughts?
Comment #5
bleen CreditAttribution: bleen commented... same problem when I run drush bam-backup, but on further inspection of the output there I'm getting this message:
file_put_contents(): Only 0 of 309 bytes written, possibly out of free disk space files.inc:304
I have TBs of free space so I dont think that is the issue.
Comment #6
catya CreditAttribution: catya commentedI'm also getting empty files on a brand new backup & migrate scheduled setup, would love help on this.
Comment #7
tommyent CreditAttribution: tommyent commentedI too am now seeing this and I don't see anything in the logs and the drupal notification only says it was successful
Comment #8
Beezer75 CreditAttribution: Beezer75 commentedI'm having the same issue. I'm on a shared host with Bluehost, and I used their install feature. Not sure if any of that has anything to do with it.
UPDATE: It turns out BlueHost's automatic set-up feature was adding a database prefix to the site, since I was actually trying to set up a new installation to populate with the database it appeared as though nothing was happening. In fact it was, but I had duplicate tables for everything in the new site and it wasn't reading anything with the other database prefix. My solution was to reset my new installation to wipe the extra database tables, open the Backup Migrate database download, search and replace the database prefix, save and upload. All seems to have worked fine. Just thought I'd share in case it helps anyone.
Comment #9
ann b CreditAttribution: ann b commentedSame as #5. I used devel generate to create a large # of nodes on an old PC I use for development, and after that my backup files were empty. I changed the drupal temporary directory from /tmp to /var/tmp, and this fixed the problem for me. I think what's going on is the backup file is created on /tmp and then moved to destination directory. The file was too big for my /tmp directory, and according to the Fedora FAQ documentation on this subject:
Comment #10
tsssystems CreditAttribution: tsssystems commentedBackup and Migrate writing empty files locally in Drupal 7.53...
When I do either a scheduled or a manual backup, that's all I get. When I also write to NodeSquirrel, the NodeSquirrel backups are fine.
The problem started when I moved the private file folder to a level below the Drupal user "home" directory (it's a CentOS/cPanel server), to avoid these backups getting added to the overall server backup files - or so I originally thought (see below).
I've since figured out that I can exclude the files from the backup via a script. I pointed the private files directory back the original directory (one level below the web root), but I'm still getting empty files, even though Backup and Migrate sends me messages that the backup completed successfully.
I've checked permissions; I can manually write to that directory as the Drupal user (via nano). Anyone else experienced this?
Update:
Now when I back up the database ONLY, it works as expected. I actually get a compressed .sql file that looks like what I'd expect. But when I try to back up the public files directory, it reports "Public Files Directory backed up successfully to XYZ-2016-12-20T22-20-22 (444.61 MB) in destination Manual Backups Directory in 7 min 42 sec." However, this is what's in the directory:
-rw-r--r-- 1 dUser dUser 0 Dec 20 22:28 XYZ-2016-12-20T22-20-22.tar.gz
-rw-rw-r-- 1 dUser dUser 0 Dec 20 22:28 XYZ-2016-12-20T22-20-22.tar.gz.info
Have altered max_execution time in php.ini, and tried changing dir permissions to 775 and ownership to dUser:webserverUser to no avail.
Next tried drush bam-backup files. First time I got "Unable to create or write to the save directory 'private://backup_migrate/manual'." (!!!) And drush was operating under root! So I changed permissions to 777 on the whole directory structure and the drush back up was successful, but why? It did kick out an error, though: "Error while sending QUERY packet. PID=7537 database.inc:2227".
So now I'm quite confused. Was it one of the updates I did to Drupal core? I don't believe the backup_migrate module had an update in that time frame.
TIA for any insights or advice!
Comment #11
couturier CreditAttribution: couturier as a volunteer commentedUpdating the version since this bug may or may not exist in the 7.x-3.x branch. The 2.x branch will be deprecated soon. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported
Comment #12
couturier CreditAttribution: couturier as a volunteer commentedClosing after more than two weeks with no activity.
Comment #13
OCTOGONE.dev CreditAttribution: OCTOGONE.dev commentedi had that problem to, i disabled the gzip option and now the dowloaded database file is not empty anymore.
Comment #14
couturier CreditAttribution: couturier as a volunteer commentedSo this error still exists in the current version, then. I wonder if we need a patch to duplicate the action on Comment #13.
Comment #15
DamienMcKennaSo I suggest we add some test coverage to make sure that the compression works correctly, then we could maybe work out what problems could cause it to not work correctly and either fix them or use hook_requirements to identify potential problems.
Comment #16
joelpittet@DamienMcKenna, so I ran into this (possibly by chance) when upgrading to PHP 7.2 from PHP 5.3. For small data (the database only) the file saved with tar.gz, but with the public files it saved as 0 bytes and when I turned off the gzip it saved with 3.82 GB
The database is only 1.17 MB tar file and 200.84 KB mysql.gz
Could be tricky to test coverage large sets of data?
Comment #17
DamienMcKenna@joelpittet: That's an interesting one.. did you examine the output file?
Comment #18
joelpittetMore digging is finding that
/tmp
ran out of space (default using tmpfs aka memory), there seems to be no problem withprivate://
Comment #19
joelpittetMoved
temporary://
to/var/tmp
. So far that's playing nicer because it's disk space and there is more.Comment #20
liquidcms CreditAttribution: liquidcms commentedI'll throw in another test point.
I have numerous Drupal sites on this server. All use BM. All have been working for years and continue to work. Recently added a new D7 site and BM is only creating 0kb files. I have tried PHP 5.4 and PHP 7.1. I have tried latest 2.x-dev and latest 3.x-dev. None of these fixes the issue.
When running from drush, the db backup file gets created correctly.
A watchdog log is created when run from drush stating success. No errors anywhere when run from gui when 0kb db backup is created.
Comment #21
DamienMcKennaFor what it's worth, the 7.x-2.x branch is no longer supported, I plan to mark it unsupported after 7.x-3.7 is released.