Environment:
WordPress 6.6 freshly updated yesterday
OS: Ubuntu linux 24.04 LTS
Apache 2.4.58-1ubuntu8.3
PHP 8.3.6-0ubuntu0.24.04.1
MySQL 8.4.1-1ubuntu24.04
I have upgraded the entire server OS this week, in stages – linux OS on sunday, wordpress yesterday.
Before the upgrade it was WordPress 6.5.5 on Ubuntu linux 23.10, php 8.2 and MySQL 8.0 – and UpdraftPlus was working to create and restore manual backups.
After the OS/php/SQL upgrade UpdraftPlus is getting stuck and most of the time is refusing to make any backups when creating the plugins.zip.tmp file…
I tried monitoring the filesystem and i see that the plugins.zip.tmp file keeps getting created and deleted in an infinite loop (it keeps showing up with different inodes/timestamps assigned by the filesystem), and during this time a single apache2 thread (the one running the backup) is keeping the cpu load at 100%
After trying multiple things it seems to have produced some sort of backup set… but in the error log is this piece of worrying data:
(and no, the drive space is not full)
0003.885 (0) Binary zip: error (code: 9 - look it up in the Diagnostics section of the zip manual at http://infozip.sourceforge.net/FAQ.html#error-codes for interpretation… and also check that your hosting account quota is not full)
0003.890 (0) The attempt to close the zip file returned an error (*** buffer overflow detected ***: terminated). List of files we were trying to add follows (check their permissions).
0015.211 (0) Error: makezip_addfiles returned false
0015.215 (0) makezip_addfiles(UpdraftPlus_BinZip) apparently failed (file=backup_2024-07-18-1308____my_site_here____-plugins.zip.tmp, type=plugins, size=106773087) - retrying with PclZip
0015.427 (0) backup_2024-07-18-1308____my_site_here____-plugins.zip.tmp: Zip file already exists, with 23384 files
0015.788 (0) Total entities for the zip file: 4815 directories, 24385 files (0 skipped as non-modified), 326.5 MB
0015.793 (0) Only one archive required (UpdraftPlus_PclZip) - will attempt to do in single operation (data: 334309.9 KB, split: 409600 KB)
So.. it seems to have decided to use a different ZIP method after a while… how can i force it to always use this second zip method instead of the buggy zip primary?
How reliable / usable is this backup set if it was made after such errors?