I am trying to create a complete backup server from our main server.
I have first cloned the disk (using Clonezilla), I put that disk in another sever with identical hardware. I booted, activated the installation. I even bought another licence of the Sangoma Endpoint module so that the restore has no obvious reason to fail.
The main and backup servers have the same hardware, same IP (I never put both online at the same time).
I ran a backup on the main server and I used that file to run a restore on the backup server. The restore was successful. In the log, I can see that the trunk server is Reachable. However, the incoming calls dont work. They do not seem to reach the server at all.
On the other hand, after I reboot a phone, I can do an outbound call from that phone.
Question: what is the suggested procedure to prepare a backup server ? I dont care if I need to start over using another method but I need to get the backup server working and I need to be able to backup my main server regularly , restore on the backup server and have everything working fine.
You may have already seen this page which has some details about creating automated backup jobs: Backup and Restore FreePBX 15+
But more importantly, itâs probably best to figure out why your restored system isnât working, because it sounds like it should.
Is the trunk server a sip provider? If so, does your pbx register to it for service? And just to make sure the problem is not only at the phones, are inbound calls over the trunk going to an ivr or some other extension that is not a phone? It would help to see what the asterisk cli shows, as well as a sip packet trace if the trunk is sip during a failing test call.
As for the phone that starts working after a reboot, were calls to other internal non-phone extensions, like a directory or voicemail also failing before the reboot? The fact that a reboot fixed it sounds like a re-registering could be one reason why it started working. For this case, it would help to know how often your phones are set to register, and looking at a sip packet trace during the failed call attempts.
It might also be worth trying to do a clean install on the spare system, and then restore a backup as opposed to cloning with Clonezilla. I canât think of any specific issues that would come from that, but if thereâs anything relying on your original systemâs mac address, it could cause problems.
There are some routers like the FritzBox (AVM), which assign internal IPs depending on the MAC address. A Fritzbox remembers a device, and will reserve the IP for this device (MAC address) for some time.
You would have to delete this device in the network tab of the Fritzbox to free the internal address.
Dont know, if this is the problem in your caseâŚ
In the old days Backup&Restore was not reliable, therefore I switched to VirtualboxâŚlong time ago. You can easily backup and restore your freePBX server in mins.
I mentioned it here
I have solved my issue but I consider it to a bug from the restore module. Whenever you restore from a backup, it changes the bind port to 5160 if the port was not defined in the production server.
In my case, I use legacy chan_sip and the port in my prod server was not set (5060 was used). It was working fine.
However, in the backup server, after the restore, the port has been restored to 5160. I would expect that if a system works and I do a backup, the restore system should also work. It is not the case in this scenario. I simply defined explicitly the port 5060 in prod, ran a backup and the restore now works. But it the bind port in prod is left empty, the backup will force 5160 which breaks everything.
I take my share of the blame but backup should reproduce a working system.
Thanks for the detailed followup. I canât say for certain whether thereâs a good reason for the current behavior, but Iâm doubtful there is one, and this is most likely an issue that should be resolved. Please open a ticket for it with the details youâve shared here.
If you came from an old FreePBX where the default chan_sip port was 5060 and chan_pjsip didnât exist to a later FreePBX where chan_pjsip now is a thing and will default to 5060 relegating chan_sip to 5160 (neither a clever choice IMHO) , and you had not defined your current port for pjsip nor sip to override new default state , I would not be surprised. operator error not bug perhaps?
I did come from an old FreePBX. However , does it matter ? I mean:
my prod system was working.
I took a backup
i restored
the restored system was not working.
Isnât the purpose of a backup / restore to recover the functionalities of a system ?
I mean, I dont care if this is seen as a bug or not. I have solved my issue now and I want to help others to not waste time with that. But, IMHO, this is confusing for anybody who does not know the history of ports 5060 and 5160. As a user, I expect a backup restore to work: i.e. not apply some black magic to my settings. Since you know the history , you can make sense of the facts now. However, when I posted my question about my trouble with bakcup/restore, nobody pointed me in this direction. Why ? Because it is not obvious. A backup should do its job. If it decides to apply rules without replicating the system blindly, we loose confidence in it.
When you trade up your car, there is a new âoperator manualâ in the glove box , no black magic that you might now have a bluetooth nav system or whatever. Kinda similar situation here
Apparently the backup did itâs job just fine , you just missed the RTFM bit when restoring to a different âeco systemâ
It is not really the same situation: I have 2 identical systems (same identical versions ).
I backup from one to the other and the second does not work .
As I said, i dont care whether this is a bug or not, my problem is solved now. But this will come again for others later, this is why I posted my finding. A backup system should do its job and it did not in this case.
When I backup pfSense, I know that it will work. With freepbx, I have learned to be careful.
All you need to do is simply define the port you listen on for all the sip transports you use that way there is no possibility of a âdefaultâ port you donât agree with being used on any transport, further I suggested you use neither 5060 or 5160 because they are both horribly compromised.
