Failed upgrade to FreePBX

Regardless of how you update FreePBX(TM) (command line or GUI), you must follow the procedure listed in the HAAst maintenance guide – or the shortcut above.

By ignoring the instructions you have synced new database contents to old FreePBX code. FreePBX on the standby will be confused and refuse to start. The only solution is to bring the FreePBX code and database back into alignment.

I really hope you heeded our warning to BACKUP YOUR SYSTEM before applying any FreePBX’s updates, enabling modules, etc. The quickest solution is to unplug the standby and restore from the backup. After that resume at step 2 in the link you posted, and apply the same updates/changes you made to your active peer.

We see this problem a couple of times per year when a user doesn’t follow the upgrade instructions. The solution is simple: just restore your system level backup and resume at step 2 in the link you posted above.

Some users have described the FreePBX PHP code as ‘a tangled and fragile mess’. And we have seen FreePBX systems implode because of a (FreePBX) module changing the schema and other modules (or core FreePBX) didn’t like it. You must be very careful with FreePBX changes/updates. (This does not apply to other configuration generators or Asterisk itself).

If FreePBX is not too badly damaged (i.e. it has not messed up its own settings) you may be able to recover by just copying the full database with schema from the working node to the defective node. This assume you have followed all of the other advice in the installation guide regarding FreePBX modules/versions/etc.

If not, the Telium support team has tools to attempt to realign the two FreePBX installations. These tools move files/directories/databases/links etc to attempt to make FreePBX identical on both peers. Because of the potential to really make of mess of the peers, Telium does not offer these tools to the public. Instead you would need to purchase 2 hours of service (from the Buy tab) and grant direct SSH access to each peer. That’s usually the quickest route to recovery, but doesn’t always guarantee success (depending how badly the second peer is damaged).

If you want to recover the systems on your own, the next quickest way to recover your cluster is to mirror the primary PBX disk to the secondary PBX disk, and then adjust settings on the secondary to turn it into a unique peer. (Network settings, host name, and HAAst settings). Using ‘dd’ (or Ghost4Linux) is the easiest way to mirror the disk. Keep the secondary PBX unplugged from the network throughout this recovery, and resume at step 2 of the link you posted above.

After that your cluster will be up and running again!

In the future, I suggest you follow the HAAst Maintenance Guide before you apply any updates, or enable any FreePBX modules. Fortunately this problem is appears to be unique to FreePBX, as all other Asterisk based PBX’s we have encountered which use MySQL databases seem to detect any code-database mismatches and allow the user to simply UPDATE the configuration generator to recover.

Treat the FreePBX program as very fragile – so follow the upgrade instructions. As well, be sure to disable Automatic Updates in FreePBX as this too can cause problems.