I noticed that when the Backup/Restore module runs a backup job, it’s no longer placing the backup files in the backup job’s directory on remote file servers.
I have these backup jobs…
When those jobs complete in v14 to the FTP server, the structure AUTOMATICALLY looks like this:
What is the value of this? You actually know what’s in a backup file. Why segregate the different elements into different jobs? Because maybe config changes are more important than voicemails (thus, backed up nightly, instead of weekly for voicemails). MOH, even less important, so backed up quarterly. CDR, backed up monthly…
So, With FPBX 15, I noticed that it is maintaining that backup job name folder structure on the local server, when it first generates the files for uploading…
But, then it uploads it to the FTP server and does this:
You’ll note, they’re all tossed into the root of the backup location instead of where they belong (in the backup job name’s corresponding folders). So, you have no idea what each backup is until you attempt to restore it and then look at the pre-restore summary.
So, naturally, I opened this bug report:
Which was closed telling me this is the new normal in 15, due to the shift of backup responsibility to the individual modules.
As you can see, I pushed back on that because that didn’t really seem to make sense to the actual issue. But, since the bug report was so swiftly closed/rejected, I’m not sure the post-closure response was even going to get any visibility.
So, I submit to the group… Obviously this is a bug, as the folder/job name structure remains intact on the local server itself prior to uploading, and only fails to maintain that when uploaded to the remote server. Furthermore, I attest that a complete lack of knowing what a backup file contains (either within it’s file name, or nested in it’s appropriate folder), is not at all desired behavior.
Hopefully this will gain some traction to get fixed.