Backup and Migrate writing empty files locally

Question

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!

Answer 1

Found out the problem: a file system quota on that particular user on the server. Drush finally gave me this clue when I ran it as the web user:

drush bam-backup files dm-0: write failed, user block limit reached. file_put_contents(): Only 0 of 400 bytes written, possibly out of free disk space files.inc:411 [warning] Public Files Directory backed up successfully to XYZ-2016-12-27T23-28-18 ( bytes) in destination [success] Manual Backups Directory in 12 min 59 sec. Error while sending QUERY packet. PID=19337 database.inc:2227

Of course there was plenty of disk space, just not available to that user, and I never saw that message when running the command as root. There was enough space available to write the database backups, just not the files directory backup (600MB). Of course, BAM sent me emails saying the backup was successful. I still don't know what the error sending the QUERY packet is about, but the earlier problem of mysql crashing noted did not reappear. Also, I discovered that the web user was not the owner of the module - I forgot to change the ownership after having drush 'update all' earlier (as root); that could have caused the other problems, but the main issue was the disk quota.

In any case, drush bam-backup archive finally worked. Hope this helps someone else in the future.