We're trying to migrate ou Trixbox 2.2 system (based on Asterisk 1.2) to a newer version, maybe the Elastix 1.5 distro with the latest version of FreePbx (2.5.1).
I first started by upgrading FreePbx on our Trixbox system to FreePbx 2.5, which went flawlessly. I then proceeded to do a backup using the FreePbx 2.5 backup module. I tested on another machine with the same configuration that I could do the restore with no problems.
I then installed Elastix 1.5 (under VMware, i'm only testing right now), and upgrade FreePbx modules. When I try to do my restore, it takes forever and seems to stall. The PHP process is taking 99% of the CPU on the machine, so I think something is going bad. I can restore only the call detail and system recordings, but I'm unable to restore the system configuration.
Am I doing something unsupported, or should this work since the FreePbx backup was done? Do I have to reconfigure my system manually if I want to update to Asterisk 1.4/FreePbx 2.5? Any way I can diagnose what PHP is doing and why its spinning like this?
I'm going to take a stab at this, but I may be wrong - if so I hope someone will correct me, because I'd also like to know what the situation really is.
First, know that you are not alone, and probably not doing anything wrong. The thing to remember about the backup module is that it's not intended for system migration - instead it's intended to create a backup of your current system that you can use to get things working again in case of database corruption or (maybe) hard drive failure. If ANYTHING fundamental to the system changes between the time of the backup and the time of the restore - and changing distributions would be a pretty fundamental change - it's far less likely to work the way you hope.
The most likely reason you are having problems is because the backup module backed up something from the Trixbox system that should not be restored to the new Elastix system (believe me, we had the EXACT same issue). I've always hoped that someone would come out with a module that lets you selectively backup and restore various parts of the configuration. You can use the third party Bulk Extensions module to back up and restore your extensions, and the Bulk DID's module to backup and restore your Inbound Routes, but there is nothing similar that lets you selectively backup and restore Outbound Routes, Trunks, IVR's, etc. With the FreePBX backup module it's all or nothing, and all is just too much, apparently.
One thing that you could possibly do, although I've never done it and could not tell you how, is to use something like phpMyAdmin and backup each database individually. Then, before importing it to the new system, you could check to see if the data structure was the same (manually create an entry in each module you use if necessary, to get MySQL to create the data structure). If the data structure is different, you know you have to re-enter that data by hand (or maybe not, but at least you can make sure the structure isn't changed after you attempt to re-import the data). I've never tried that and don't know if it would work, but then I don't know that much about databases in general and MySQL in particular.
Of course you'd also want to backup any files you may have manually edited on the old system, such as extensions_custom.conf, but I wouldn't just copy them over - instead I'd do a side-by-side comparison (there are text editors that will let you do this easily, or you can use a tool like diff) and just take the parts you changed and copy them into the new file.
What we did was prior to migration, we used a Firefox extension (ScreenGrab) to actually take a "picture" of each configuration page, and if a page contained a text box with more than a line or two we cut and pasted that to a text file (same with any data that was too long to be completely visible in a text box). Then we also did a "Save As" and saved a HTML copy of the page. That way, we had two copies of each configuration page (the image and the HTML copy) and could refer back to either or both when recreating the pages on the new system. Since then I've read somewhere that there's a way you can actually get the new system to process those saved HTML pages (you make some change to it in a text editor, then load it back in to Firefox and click the Submit button) but I don't recall the actual instructions for doing that, unfortunately.
Thank you for your reply. So in conclusion it appears we won't be able to do a migration. Due to the small size of our implementation, I'll simply redo the configuration.
I already have a copy of our Trixbox machine running under VMware so it'll be easy for me to redo the configuration.
This topic is now closed. New replies are no longer allowed.