We have a 3CX failover set up in place for a customer of ours. The daily backup/restore process is configured to take place nightly and is currently set to perform the default full backup, along with license key information, FQDN, and conference.
We had a situation recently that resulted in us having to pull the primary server offline for a couple of days and let the customer run on the backup PBX. We have since corrected the issue with the primary PBX and put it back into service.
Today we are running into a situation where the customer is looking for call logs and recordings that should reside on the backup PBX since these calls in question took place during the timeframe from when we pulled the primary server offline, but they are unable to locate these calls and recordings even when logging directly into the backup PBX admin console.
I just realized why this is happening..
The primary/secondary PBX configuration is designed to take a backup of the complete config (including the call logs) of the primary PBX and restores it all to the backup PBX every night. There aren't any records of calls between the specific date range in question because that's when the customer was running on the backup PBX, and the config (and call logs) from the primary PBX have since been copied over to the backup PBX since we put the primary PBX back into service, essentially overwriting the call logs from the backup PBX.. if that makes sense.
However, if you pull a detailed Call Report for that date range from the backup PBX, all of the calls and recordings from these dates are there and available.
While this is technically a workable solution, it certainly isn't ideal and makes for a complicated discussion with a non tech savvy customer.
Is there any way to configure a 3CX failover setup to not overwrite the call logs on the backup PBX when the daily backup/restore process takes place?
I'm assuming the answer here is no because then the backup/restore process from the primary to the backup server wouldn't be taking place in the manner designed, but wanted to lay out the entire scenario here and get someone else's take on this and see where we could have done things better in this situation.
Thank you!
We had a situation recently that resulted in us having to pull the primary server offline for a couple of days and let the customer run on the backup PBX. We have since corrected the issue with the primary PBX and put it back into service.
Today we are running into a situation where the customer is looking for call logs and recordings that should reside on the backup PBX since these calls in question took place during the timeframe from when we pulled the primary server offline, but they are unable to locate these calls and recordings even when logging directly into the backup PBX admin console.
I just realized why this is happening..
The primary/secondary PBX configuration is designed to take a backup of the complete config (including the call logs) of the primary PBX and restores it all to the backup PBX every night. There aren't any records of calls between the specific date range in question because that's when the customer was running on the backup PBX, and the config (and call logs) from the primary PBX have since been copied over to the backup PBX since we put the primary PBX back into service, essentially overwriting the call logs from the backup PBX.. if that makes sense.
However, if you pull a detailed Call Report for that date range from the backup PBX, all of the calls and recordings from these dates are there and available.
While this is technically a workable solution, it certainly isn't ideal and makes for a complicated discussion with a non tech savvy customer.
Is there any way to configure a 3CX failover setup to not overwrite the call logs on the backup PBX when the daily backup/restore process takes place?
I'm assuming the answer here is no because then the backup/restore process from the primary to the backup server wouldn't be taking place in the manner designed, but wanted to lay out the entire scenario here and get someone else's take on this and see where we could have done things better in this situation.
Thank you!
Last edited:
