The awkwardly named “Here’s what’s been happening” Audit Update from Defender doesn’t note backup failures.
I consider backup failures to be a security issue – the site is not “secure” when there are problems with the backup.
In order to implement proper reporting, a backup plugin would need to provide Defender with its backup schedule and then notify Defender when backups succeed and when they fail. With this data, Defender can check for when a backup should have been performed, see if there was a successful backup around that time, and report if there was no backup at that time, or if a failure was logged.
Note that the absence of a success or failure log from a backup mechanism indicates the backup wasn’t even attempted. This could indicate the plugin/mechanism has been disabled, perhaps corrupted or compromised.
All of this can be implemented with hooks:
– ‘defender_backup_save_schedule’ : When a plugin changes its schedule it can save the day+time here.
– ‘defender_backup_success’ : Plugin indicates a backup has completed.
– ‘defender_backup_failed’ : Plugin confirms failure.
On generation of the Audit Update, Defender can check for success messages, compare them with the saved schedule, and report discrepancies.
It would certainly be ideal if Snapshot integrated with this. Whether it does or not, with the hook API, other plugins (and even OS-level tools) can easily integrate with it.
Here’s another approach that might already be available to us : Rather than creating specific hooks for backups, how about hooks as follows? :
– ‘defender_save_event’ : Allows any process to record any event for Defender.
– ‘defender_audit_log’ : Allows any process to add a line item into the Audit Log report.
With that interface, Defender doesn’t need to check backup timing. It reports anything that was logged by a process. It also does a final check to see if any other processes have something to add to the report. A custom plugin/function can do the housekeeping for backup tracking – Defender just needs to report whatever summary is returned by that process.
This last implementation gives us the ability to use the existing logging and email notification/report to advise us of any site condition that we want – with nearly zero development by WPMU DEV. Just add the hooks … Or document hooks that already exist!?!
Thanks.
