UPDRAFTPLUS_ZIP_EXECUTABLE

/usr/bin/zip will be looked at by default. So presumably there’s some reason it can’t be used. There should be more information in the backup log about the attempt to try it. For example, perhaps it’s blocked by the server’s AppArmor policy.

Do you have php-zip installed? It’s the fall-back if *neither* of those are installed (PclZip) that’s the really slow one.

Edit: yes, you do. (ZipArchive::addFile: Yes).

Hi David, thank you for your answer!

Is there any (measurable) performance difference between php-zip and using zip executable?

I am using VPS with SSD, so it is not shared hosting, however I am backing up 20 GB website to the VPS itself (another folder)

20GB web has a lot of files in media library, so I would like to find fastest option

if you could add experimental option (add files to zip archives but don’t compress files) so that should be fastest possible solution, disk space is not the issue, it is backup speed

or maybe you have some other idea or suggestion?

Thank you for your time and effort!

Normally the zip executable is a bit faster (last time I did some testing, anyway), but you’ll use more memory because it’s a separate process. The difference is nothing like as dramatic as the difference between PclZip and ZipArchive.

if you could add experimental option (add files to zip archives but don’t compress files)

It’s already the case that any files with common extensions indicating that the file is already compressed (images, movies, archives), won’t have any extra attempts to compress them; that code has been there for several years.