Backup/Migrate generating corrupt gzip files, some backup migrate pages return "The website encountered an unexpected error"

Some more details:
PHP 7.4.33
Drupal 7.91
Hosting: Siteground

I updated token and then was able to change the backup compression to zip instead of gzip. Gzip is still corrupted I'm not sure why, but at least we can be reasonably sure we have backups that are available.

You can close this request, thanks!

There are two issues here, please open a separate bug report for the _token_token_tree_format_row() but and we'll focus this one on the corrupt backups.

I'm seeing this since upgrading from php 7.4 to 8.2. The tar.gz files on the server are all 0b, but this module shows them as 5GB (which is what they should be) in the list of saved backups. Executing the public files backup manually resulted in a WSOD after about 5 min with no errors in the log.

I cannot reproduce this (Apache on Windows 10 Home, destination Manual Backup).

What is the operating system (name and version) you are running?

What is the backup destination?

I think it ended up partially being a server capacity issue. We increased our storage and it's no longer happening so I'm unable to test it now. My theory is that the temp file was getting too close to the storage limit and causing the backup to fail. The concerning part is that the module didn't know it was failing. It was recording the backups as successful with file sizes that matched what was expected. But looking directly at the backup files via SFTP, they were ~1KB. The failed backups tar.gz files also remained in the temp folder with the larger sizes, but were corrupted and could not be unzipped.

LAMP stack with CentOS7. Multisite install with the backup files saving to /www/drupal-7/sites/{site-folder}/files/private/backup_migrate/scheduled (or /manual for manually executed). Probably not all that helpful since everything is working fine again after increasing the server capacity.

Thanks for the feedback. This is certainly useful. Regardless of what causes the corruption, you would expect the B&M module to not report the wrong file sizes if it can avoid doing so.

Plato1123 and Jvogt, if you look at the corrupted files with a text editor, do you see anything out of the ordinary? A file size of around 1 KB could mean something has written a plain text error message to the file. It might be useful to know that message.

-------

Some notes for whoever picks up this issue:

backup_migrate.module:backup_migrate_ui_saved_backups() (1453) is the callback for the menu hook for the Saved Backups tab.

includes/destinations.inc:_backup_migrate_ui_destination_display_file_list() (310) calls theme() to create the table on the Saved Backups tab.

includes/destinations.inc:backup_migrate_destination::load_files_info() (925) retrieves file size info from the accompanying .info file if it exists. This includes a field 'filesize'.

It seems this .info file is created upon back-up file creation. The PHP function filesize() is ultimately the source of its wisdom.

This suggests to me that even if, over time, the .info file and reality have gotten out of sync, there must have been a time where the back-up file actually had that size.

Perhaps also useful to know, https://www.php.net/manual/en/function.filesize.php suggests that:

- "[this function] may return unexpected results for files which are larger than 2GB"

- "The results of this function are cached."

And the comments add that:

- "If you recently appended something to file, and closed it then this method will not show appended data. You should insert a call to clearstatcache() before calling filesize()."