1.) Call waiting is disabled on all extensions on PBX B for some reason, but enabled on PBX A… Any idea why call waiting is being disabled on PBX B if it’s pulling all settings and configurations from PBX A where call waiting is enabled on all extensions?
2.) My call recording storage is located on a separate disk that is mounted on PBX A. PBX B is hosted by another cloud provider that doesn’t support block storage, so I have a script in place called in the “Post Restore Hooks” field of the backup and restore module to remove the custom call recording location in “Override Call Recording Location” in Settings > Advanced Settings
That script is below, and works fine when I run it manually, it removes the custom call recording location in Settings > Advanced Settings but this isn’t happening during the restore process of PBX A to PBX B on a nightly basis.
Well, I thought it was fixed but it appears not to be. The asterisk user has execute permissions on the script… if I run the restore job from the backup & restore module of the warm spare server manually, it completes and the override call recording location in advanced settings is blank on the warm spare, which is what it should be.
However, when the warm spare restore job performs on its own during its daily scheduled time, I attempt to log into the server to see if the override call recording location field was still blank under advanced settings and unfortunately, it still has the path specified on the primary server again…
So… the script works when I manually run the restore job from the FreePBX GUI, but not when it runs at its scheduled time.
The first issue is still persistent and pretty annoying, where extensions on the warm spare have call waiting disabled (when call waiting is enabled on the primary), and instead findme/follow me is enabled on various extensions of the warm spare when it isnt enabled on the primary box.
If it is reproducible and you can document the problem, then it could be. Note that something like that would be probably have been reported by a couple other people that use the Warm Spare script a lot, so it’s also a possibility that it’s something in the way you’ve set it up.
Submit an issues ticket with the steps to produce and reproduce the error, the submit an Issues ticket and see what the ‘backend’ folks have to say. If it is, in fact, a bug, they’ll squash it. If it turns out to be something specific to your implementation, that will point us in a direction that says something in the procedure or documentation needs to be adjusted. Either way, I’m pretty sure it can’t hurt the system.