DB Backup fails if uploads/backup-guard folder is symlinked

Initial issue was that a WordPress server node was running out of disk space and the backup size has now exceeded the available free space so is unable to complete.

Easiest solution seemed to be simply to attach a 2nd volume to the linux node and symlink the wp-content/uploads/backup-guard folder to the new volume so it can backup successfully… which it seemed to. Now trying to migrate the whole site to a larger node I’m having issues.

The backup appears to work for the files and the backup job tells me that it is successful every day with a green tick… but it is actually failing to grab the DB behind the scenes silently.

Eg. Checking the backup logs:

2018-05-31 17:01:00: Backup files: wp-content,ckup-guard/Backup_opt(full)_20180531170106.sql
2018-05-31 17:01:00: Warning: Path is not readable (skipping):

It seems to be clipping off the beginning of the path… strange.
So lets compare to a node that has not had the folder symlinked:

2018-05-31 20:59:00: Backup files: wp-content/uploads/backup-guard/Backup_opt(db)_20180531205933/Backupp_opt(db)_20180531205933.sql
2018-05-31 20:59:00: Number of files to backup: 1

If you check the plugin settings page on both servers –
Backup destination path: /mnt/backup/backup-guard
Backup destination path: wp-content/uploads/backup-guard

You can see that it detects the actual path where the symlink is pointing to, rather than just using the full symlinked path.

The bigger issue here is the fact the backup job tells the end user SUCCESS, yet in reality the plugin can’t figure out how to handle the path and simply skips the entire DB backup… which is ridiculous, the backup is incomplete and cannot be restored. If it can’t grab the file it should report FAILURE.