Support

This warning is already scheduled to be removed in the next version as it makes little sense. The disabled functions, if any, are recorded in the log so any failed backup can be traced back to a disabled function being a possible culprit.

Which functions are required for the operation is heavily dependent on which features you have configured and which code paths will be taken based on the server conditions at the time of the backup. Sort of trying to dry run a backup before running a backup you cannot have an accurate list. Of course, that's impractical. Reporting the existence of any possibly used function in the disabled functions list of your server is materially no better than reporting the mere existence of a non-empty disabled functions list. Now you understand why the warning triggers on a non-empty disabled functions list.

However, you need to understand why this exists in the first place, and why it no longer makes sense.

When this was introduced 20 years ago I was seeing failed backups due to disabled functions on an at least weekly basis. The warning made sense because it would alert the user of this possibility, greatly reducing the number of support tickets. Most people would see the warning and the failed backup, put two and two together, check the log file, ask their host to address it, and I wasn't involved in this at all.

Over the years, hosts have gotten better at actually understanding what they need to disable and why. Long gone are the days hosts would disable parse_ini_file thinking it's the same as ini_set, or indeed disabling ini_set instead of adding actual hardening to their server. Moreover, I have also gotten better at working around disabled/missing functions or, when no technically feasible workaround exists, report the issue in an intelligible and actionable user-facing error message. I now have the experience, the tools PHP provides (Throwable which allows me to catch errors like this was only introduced in PHP 7.0 just over 12 years ago), and the PHP memory headroom to be able to afford putting that extra code in. The last ticket with this root cause was filed over five years ago and it did show an error message the user could've acted upon without consulting me.

Therefore, it now makes a lot more sense to remove the warning altogether.

Here's the thing. This warning should've been removed a long time ago. Unfortunately, the way it was done was essentially by relying on a bug which wasn't identified as a bug at the time. That bug was fixed last month, hence the warning coming back. I have now removed the actual detection code for the warning, as it should've been the case  all along.