Trying backup and restore freepbx 13 to 15 for first time

Hi,

How did it go for you? Did you face any issues? Please suggest any tips that you may have.

Also, would you recommend that I just upgrade it to Freepbx 14 instead of using the backup/restore to 15.

Thanks
-D

Hi @dsubs As such Backup & Restore is a good option for upgrading to 15, I would recommend you to please try backup & restore to 15 (to your spare system to avoid touching your live 13 system).

If you face any issue, please do report them to issues.freepbx.org for us to fix.

Best Regards
Kapil

Agreed! The legacy version restoration process in FreePBX v15 is quite stable now. We use a v13 Backup -> Restore to v15 to migrate systems several times a week, if not several times a day.

My advice:

  • Take a Backup from the v13 of only your Full Config and Voicemail, excluding your CDR DB and Recordings initially, and restore just that initial config/VM backup file first.
  • Then you can come back for your CDR and Recordings after the initial restore…or better yet, take this opportunity to archive your Recordings and CDR elsewhere to start with an un-cluttered v15 system!
  • If you are going to restore Recordings and are the type who records most or all of your calls, it would be faster and way less taxing on the PBX if you just used something like SCP to copy the /var/spool/asterisk/monitor/ directory from old to new. Having the Backup/Restore module fight for resources to zip ALL those Recording files can crash/hang older systems with limited resources or unstable hardware.

Observations:

  • Due to all sorts of variations that could exist out there over the years - both official and otherwise, we have encountered some occasional issues restoring CDR from v13 Backups. Mind you, this almost always boils down to random little bits of corruption in CDR data from records that could be from a “billion years ago” (that NO ONE cares about anymore) that have accumulated in the DB over the years. Since there is some conversion/checking taking place with CDR importing during the Restore process, this can hang or crash or otherwise corrupt a Restore process or CDR DB, causing you to have to start over. This is why we suggest doing CDR separately or skipping that restore entirely. If a legacy restore is going to fail, it seems that CDR is where it happens most often.

  • While this is becoming less and less of an issue in recent times due to efforts by the Sangoma team, we still encounter some occasional activation/licensing related restore issues with a couple commercial modules. So, do your first config restore, check things out and test the new PBX. When you are ready for production - assuming you don’t just opt to purchase new licenses on a new Deployment ID, we suggest that you deactivate the Zend registration on the old system, re-activate that Deployment ID on the new system to move your licenses, then do ANOTHER final Restore on the new system with that latest config backup before you swap over to the new system in Production to ensure that every last bit of commercial module data gets restored. (Remember: If you are out of self-service resets for Zend, you’ll have to contact Sangoma Support and request a manual reset to move the Deployment ID to your new PBX.)

  • A Bug that I thought was in the issue tracker already (that I can’t seem to find now, mind you, and may have to write up myself :man_shrugging:) can result in your Intrusion Detection (fail2ban) Whitelist not being restored on the new system. So, you may have to manually copy that from the old to new after the final restore of config, because I’m pretty sure it gets wiped to default 127.0.0.1 on restore, instead of restoring the list from the backup properly.

I think that’s all the notes we have on the process as of today. It sounds like a lot, but I’m just really longwinded. :wink::rofl:

1 Like

Thank you for the detailed tips. I appreciate it.

1 Like

Hi, I just came across this post.
I’m going to try this as we are using FreePBX 13 and have been experiencing some minor bugs associated with the version we are on, so instead of running upgrade scripts, it seems like going to FreePBX 15 and doing the backup and restore is my best bet!

If you have any more suggestions or “whatch out for” things please let me know! I’m excited to try this!
Jeff

I just tried to restore a backup from my FreePBX 13 system on a FreePBX 15 system and got:

This archive cannot be used, because the version is not correct!!!
Freepbx version 15.0.16.75, Archive version 13.0.197.28
The archive must be come from a release like this: 15.0
Restoration canceled.

I suspect this may be due to the Freepbx 15 system not being completely fresh, but not sure. Any help would be appreciated.

What is your backup module versions, on both old and new systems?

fwconsole ma list | grep backup

I suspect that it’s the v13 system that has too old a backup version. Some final updates were put into the v13 backup module to aid in restoring to v15, and that’s likely what the v15 backup module is complaining about. You could ensure just that module (and any necessary dependencies) is up-to-date on the v13 system:

fwconsole ma upgrade backup

Then try the backup and restore again.

It was an issue on the new machine - it apparently had not fully upgraded from 14 to 15.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.