Conversion Service from 1.818.210.58-1 to FreePBX 15?

Hopefully this is acceptable to post.
I have been through a few of these, but don’t have the time, and maybe not the patience, is there anyone that has used a service that will take your data, convert it, and give back a FreePBX backup?

Not sure if PM would be appropriate.

Thanks

That is a very early FreePBX Distro version based on FreePBX 2.10. I would expect backups taken from such a system to be restorable to a new 15 install.

I tried the standard upgrade to 64 bit, then all the upgrades to current, but too many loose ends, so it was a little ugly.
I never tried a straight up legacy restore.
I will give that a try, never hurts.

Thank you!

1 Like

Hello,

I installed and updated the current FreePBX ISO, and uploaded the 1.818.210.58-1 backup and then ran the legacy restore, no errors but in the end ONLY the CDR was available.
I ran a fresh new backup job on the old system, tried the restore again, and once again, no errors or messages, but the same results.
Any suggestions?

Thanks

Can you confirm that the Asterisk and FreePBX DB and the necessary conf files are in the backup?

Hello,

Yes, I can see the configuration files in /etc/asterisk, I see voicemails in /var/spool/asterisk/voicemail/default and I also see custom recordings for IVR.

Should I have restored to an older version and not the latest?

Do you see sql files in the tarball, and if so, what are they called?

The only .sql file I found was mysql-3.sql

If the backup was configured correctly, there should be 2 sql files, one for freepbx settings and one for cdr records. You are missing the freepbx settings sql file.

I don’t see the file, however the CDR’s are the only thing that restored.

On the old server, I cleaned up old voicemail and such, bringing the backup file to under 1GB, went to restore that file, this is the screen after the backup file upload.

I created a temp folder and un-tarred that file, this one shows both SQL files.
mysql-3.sql
mysql-4.sql
I realized that the file I checked earlier, was a 3rd attempt without the CDR because the CDR table is 1.9GB.

I run “Run Restore & Legacy CDR” and the result is below, as you can see a syntax error at the end.
At that point it thinks it’s done, apply changes, no data except CDR.

Running with: /usr/sbin/fwconsole backup --restore=‘/var/spool/asterisk/backup/uploads/20201124-104226-1606232546-2032888516.tgz’ --restorelegacycdr --transaction=‘1e40a712-cebf-4396-b9d6-e9d610b86aeb’
Determining backup file type…type is legacy
Legacy CDR Restore Option: 1
Starting restore job with file: /var/spool/asterisk/backup/uploads/20201124-104226-1606232546-2032888516.tgz
Extracting backup…
Loading manifest to memory
Loading astdb to memory
Parsing out SQL tables. This may take a moment depending on backup size.
Found 2 database files in the backup.
Legacy CDR Restore Opted. we are processing , It may take long time to process /tmp/backup/1e40a712-cebf-4396-b9d6-e9d610b86aeb/mysql-4.sql
Starting legacy cdr sql restore process
Please note that, legacy cdr sql restoration process may take a long time depends on cdr sql file size
Restore of legacy cdr sql process done…
Installing cdr
Adding index to did field…Adding index to did field in the cdr table
Done
Adding index to recordingfile field…Adding index to recordingfile field in the cdr table
Done
Checking if field cnum is present in cdr table…OK!
Checking if field cnam is present in cdr table…OK!
Checking if field outbound_cnum is present in cdr table…OK!
Checking if field outbound_cnam is present in cdr table…OK!
Checking if field dst_cnam is present in cdr table…OK!
Checking if field linkedid is present in cdr table…Adding!
Checking if field peeraccount is present in cdr table…Adding!
Checking if field sequence is present in cdr table…Adding!
OK!
Generating CSS…Done
Restored module cdr [FreePBX\modules\Backup\RestoreBase]
Installing cel
Creating cel if needed…OK
checking for extra field…not found
Checking for userfield field to remove…found
Checking for src field to remove…found
Checking for dst field to remove…found
Checking for channel field to remove…found
Checking for dstchannel field to remove…found
Checking for context index…found
Removing outdated fields (this might take a long time)Removed
Generating CSS…Done
Restored module cel [FreePBX\modules\Backup\RestoreBase]
File named: /tmp/backup/1e40a712-cebf-4396-b9d6-e9d610b86aeb/mysql-3.sql
Detected file /tmp/backup/1e40a712-cebf-4396-b9d6-e9d610b86aeb/mysql-3.sql as the PBX (Asterisk) database. Attempting restore
Loading supplied database file mysql-3
INSERT INTO bmh_names VALUES (9306,200318,‘BURGOS,JUAN CARLOS’,‘’,‘415-254-1594’,‘’,‘’,‘415-554-1514’,‘8970 W ST APT # 204’,‘’,‘Charlston\’‘,‘FL’,‘43174’,’‘,’',‘5FNYF4H48BB045255’,2011,‘Z’,‘Y’,NULL,NULL,‘12/10/2012 0:00’,NULL);SQLSTATE[HY000]: General error: 1 near “FL”: syntax error

I don’t recognize that table, it may be from an old legacy or third party module. Whatever it is, it’s interfering with the restore. If you can generate a backup without that data, it may work, otherwise I think you’ll need to create a bug ticket and provide access to the tarball when requested so engineering can take a look. issues.freepbx.org

The only 3rd party module is OSS EPM.
Looking in mysql-3.sql I can see those entries, maybe I can remove bmh_ entries put it back into the tar and try again.
I’ll update shortly.

Thank you!

@lgaetz You figured it out!
So those tables which I have no idea where they come from, and stopped progress were probably why every conversion attempt as well as backup/restore failed.
Once I pulled that out of the SQL file, I see tons of additional processing on the backup.

I wouldn’t call it a bug, but considering that a 3rd party plugin may exist, I would consider saying the restore routing should simply ignore any tables it doesn’t know and NOT hard fail.

Thanks for your help!

Perhaps not, but it is an edge case, and we’ve been mole-whacking edge cases for 2 years now. I recommend opening a ticket anyway, unless you know for sure that table only exists only your system.

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