Backup/Restore to new server, CDR not working

Used the High Availability SSH method to backup an existing, in-use FreePBX server and restore to a new server (full backup/full restore). They are running the same versions of Asterisk, FreePBX, and CentOS, all from the FreePBX distro. Modules up to date on both.

After the restore, all the recorded greetings were gone. They show in the GUI, but don’t work. Calls to the IVR went to dead air. I rerecorded the IVR greeting and set the new recording as the destination. That now works.

However, CDR is not working and that’s a problem.

Executing cdr mysql status at the Asterisk CLI returns:

“Not currently connected to a MySQL server.”

The system seems to be working; calls are going in/out. But I need CDR to work and I’m wondering now what else might be broken.

The password in the cdr_mysql.conf is probably not the same on both boxes so access to the cdr database will fail.

Hmm, I presumed that a “Full Restore” would cover things like this. Can you point me to a fix?

Both machines were setup from the FreePBX distro and patched to the same level. Whatever password is on the DB is what was set by the distro. To be clear, the OLD records, up to the time of the restore, show up. It’s just not collecting new data. I’m not clear about how it could have restored the old data with a bad password, but now can’t write new data.

Regardless, a pointer to an article on how to fix this would be helpful and appreciated, if there is such a thing.

It cant cover things like that if your MySQL password is different on the 2 machines.

When the system is installed a random password is generated for the CDR database. The install is being done as the root uses so access to change the database is allowed. This password is put into the cdr_mysql.conf file.

When you copy over the config from the primary system to the backup system the cdr-mysql.conf is copied over from the primary system to the backup system. Unfortunately the passwords do not match so you have this problem.

The solution is to change the passwords of the CDR database to match on both systems. I don’t recall how to do that right now but I can try to look it up later.

Looks like there’s conflicting info out there about how to change this.

I can see the password its trying to use in cdr_mysql.conf:

hostname = localhost
password = xxxxxxx (altered)
user = freepbxuser

However, it’s not clear from the links above exactly where else it needs to change, if anywhere, or exactly how to change it for the CDR DB only. I don’t want to make a mess.

The password for freepbxuser in freepbx.conf does not match the password for that user in cdr_mysql.conf:

$amp_conf[‘AMPDBUSER’] = ‘freepbxuser’;
$amp_conf[‘AMPDBPASS’] = ‘xxxxxxxx’;
$amp_conf[‘AMPDBHOST’] = ‘localhost’;
$amp_conf[‘AMPDBNAME’] = ‘asterisk’;
$amp_conf[‘AMPDBENGINE’] = ‘mysql’;
$amp_conf[‘datasource’] = ‘’; //for sqlite3

It’s not clear if these two files would both need to be edited if I have to change the password, or if, since the system is working except for CDR, if I can just alter the password in cdr_mysql.conf to match what’s in freepbx.conf.

Okay, I changed the password in cdr_mysql.conf to match what was in freepbx.conf, then rebooted. Now cdr mysql status returns:

Connected to asteriskcdrdb on socket file default using table cdr for 2 minutes, 17 seconds.
Wrote 0 records since last restart.

And CDR is working.

This would be a nice add to the restore script since both conf files are plain text, especially since it affects the high availability system.

mysql> GRANT ALL PRIVILEGES ON asteriskcdrdb.* TO [email protected] IDENTIFIED BY ‘amp109’;

Replace amp109 with your password. The password in MySQL, /etc/freepbx.conf and the cdr_mysql.conf must match.

It was my case too. I built a fresh install than decided to put raid so have to reinstall, and when I did backup restore the cdr report showed the old calls no the new ones.
Thank you for this thread that resolve my problem

Okay, I changed the password in cdr_mysql.conf to match what was in freepbx.conf, then rebooted. "
this resolved the issue.
and I think that should be added to backup restore script like FreerPBXer said