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

zataragate13’s picture

Issue summary: View changes
ronan’s picture

Status: Active » Postponed (maintainer needs more info)

Not 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?

zataragate13’s picture

thanks 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!

bleen’s picture

I'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?

bleen’s picture

... 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.

catya’s picture

I'm also getting empty files on a brand new backup & migrate scheduled setup, would love help on this.

tommyent’s picture

I too am now seeing this and I don't see anything in the logs and the drupal notification only says it was successful

Beezer75’s picture

I'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.

ann b’s picture

Same 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:

My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs!
The application should be fixed to use /var/tmp.

tsssystems’s picture

Backup 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!

couturier’s picture

Version: 7.x-2.8 » 7.x-3.x-dev

Updating 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

couturier’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Closing after more than two weeks with no activity.

OCTOGONE.dev’s picture

i had that problem to, i disabled the gzip option and now the dowloaded database file is not empty anymore.

couturier’s picture

Status: Closed (outdated) » Active

So this error still exists in the current version, then. I wonder if we need a patch to duplicate the action on Comment #13.

DamienMcKenna’s picture

Assigned: zataragate13 » Unassigned
Issue tags: -Backup and Migrate, -backup files, -scheduled task, -empty backup file +Needs tests

So 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.

joelpittet’s picture

@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?

DamienMcKenna’s picture

@joelpittet: That's an interesting one.. did you examine the output file?

joelpittet’s picture

More digging is finding that /tmp ran out of space (default using tmpfs aka memory), there seems to be no problem with private://

joelpittet’s picture

Moved temporary:// to /var/tmp. So far that's playing nicer because it's disk space and there is more.

liquidcms’s picture

I'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.

DamienMcKenna’s picture

For 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.