fusionpbx restore backup to new server

[agree]

I followed the guide from https://docs.fusionpbx.com/en/latest/getting_started/restore.html and it went smoothly, but after the restore, I wasn't able to access the web GUI. I got an error message that the Postgres password is incorrect, so I manually changed the Postgres password with the password from /etc/fusionpbx /config.php and I was able to access it.

But the problem is that I cannot register any phones to the newly restored server. In sngrep, I can see the phones trying to register but the server is not responding, I took a packet capture and I saw the server responding with ICMP port unreachable but the ports are open in iptables. what I found is Sofia status is empty and when I reload the acl I see the error in the file I attached. when I connect to the DB I see that I"m getting connected as user Postgres (in the old server it was user fusionpbx)


thank you for helping out

 

[roger_roger]

Go to /etc/fusionpbx/config.php on the old server and get the password - look for $db_password.

//pgsql: database connection information
$db_host = 'localhost'; //set the host only if the database is not local
$db_port = '5432';
$db_name = 'fusionpbx';
$db_username = 'fusionpbx';
$db_password = '<my-password>';

Put that password into that file on the new server and you should be good to go.

 

[agree]

when I connect to the database I get:
postgres=# \connect fusionpbx
You are now connected to database "fusionpbx" as user "postgres".

and when I try to access the GUI I get:
error: SQLSTATE[08006] [7] FATAL: password authentication failed for user "fusionpbx" FATAL: password authentication failed for user "fusionpbx"

I have to change $db_username = 'fusionpbx'; to $db_username = 'postgres'; in order to access the GUI
but I cannot register phones as I wrote

looks like some misconfiguration in the DB usernames

 

[roger_roger]

Did you change the /etc/fusionpbx/config.php files as I suggested above?

 

[agree]

both files are identical

 

[roger_roger]

Is the password from the server that you restored from or is it the password that was on the new server?

 

[agree]

password from restored server

 

[roger_roger]

I don't understand your difficulty. The original server has a postgres password of, say, ABC and the new server has a postgres password of XYZ.

When you restore the backup from the original server to the new server, your passwords will be mixed. The remedy is to take the ABC password and put it in the new server, thus removing XYZ and making the new server ABC also. I've done this many times and it works.

 

[agree]

I followed the script mentioned above and one of the lines is:
rsync -avz -e 'ssh -p 22' root@$ssh_server:/etc/fusionpbx /etc
so it copies automatically the config.php file, no?

 

[roger_roger]

I don't use the rsync procedure and you may want to make sure that it worked

 

[agree]

I didn't manually too, and I had the same issue.

what are the steps you use to restore?

 

[roger_roger]

This is my backup script:

#!/bin/sh
now=$(date -d "yesterday" +%Y-%m-%d)
#delete backups older 7 days
find /var/backups/fusionpbx/postgresql/fusionpbx_pgsql* -mtime +7 -exec rm {} \;
find /var/backups/fusionpbx/*.tgz -mtime +7 -exec rm {} \;
#delete freeswitch logs older 7 days
find /usr/local/freeswitch/log/freeswitch.log.* -mtime +7 -exec rm {} \;
#echo "Starting Backup"
#backup the database
#echo "database"
pg_dump -Fc -w -h 127.0.0.1 -U fusionpbx -f /var/backups/fusionpbx/postgresql/fusionpbx_pgsql_$now.sql
#
#backup the files and directories
#echo "fusion"
tar -zvcf /var/backups/fusionpbx/pbx1-backup_$now.tgz /var/backups/fusionpbx/postgresql/fusionpbx_pgsql_$now.sql /var/lib/freeswitch/recordings /var/www/fusionpbx /usr/local/freeswitch/scripts /var/lib/freeswitch /storage /etc/fusionpbx /usr/local/freeswitch/conf /var/scripts

And this is my restore script:

#!/bin/sh
now=$(date +%Y-%m-%d)
#delete freeswitch logs older 7 days
find /usr/local/freeswitch/log/freeswitch.log.* -mtime +7 -exec rm {} \;
#message to the console
echo "Restoring the Backup"
#extract the backup from the tgz file
tar -xvpzf /var/backups/fusionpbx/pbx1-backup_$now.tgz -C /
#remove the old database
psql --host=127.0.0.1 --username=fusionpbx -c 'drop schema public cascade;'
psql --host=127.0.0.1 --username=fusionpbx -c 'create schema public;'
#restore the database
pg_restore -Fc --host=127.0.0.1 --dbname=fusionpbx --username=fusionpbx /var/backups/fusionpbx/postgresql/fusionpbx_pgsql_$now.sql
#backup the files and directories
#echo "Restore Complete";

I have my postgres password saved in /root/.pgpass so I don't have to type the password

Here's the format of that file:
127.0.0.1:5432:fusionpbx:fusionpbx:<password>

make sure you chmod 600 the file or pg_restore won't use it

 

[agree]

thanks, I"ll give it a try

 

[agree]

when executing
pg_restore -Fc --host=127.0.0.1 --dbname=fusionpbx --username=fusionpbx /var/backups/fusionpbx/postgresql/fusionpbx_pgsql_$now.sql
I"m getting the following output

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3; 2615 2200 SCHEMA public postgres
pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" already exists
Command was: CREATE SCHEMA public;

 

[agree]

I think I"m getting this error because new server runs postgres 11.1 and restored server runs version 10.5 and this what's causing all the headaches.
any solution?

 

[roger_roger]

Are you sure you are running the drop schema public command or that it is completing successfully? I use these scripts all the time without incident.I am running postgres 9.x

 

[agree]

I solved it by manually removing the database roles:
DROP ROLE fusionpbx;
DROP ROLE freeswitch;

and than recreating them with the restored database password:
sudo -u postgres psql -c "CREATE ROLE fusionpbx WITH SUPERUSER LOGIN PASSWORD 'restored server password';"
sudo -u postgres psql -c "CREATE ROLE freeswitch WITH SUPERUSER LOGIN PASSWORD 'restored server password';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE fusionpbx to fusionpbx;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE freeswitch to fusionpbx;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE freeswitch to freeswitch;"

and restoring the database:
pg_restore -Fc --host=127.0.0.1 --dbname=fusionpbx --username=fusionpbx /var/backups/fusionpbx/postgresql/fusionpbx_pgsql_$now.sql

thank you

 

[smn]

I know this is an old thread but I am wondering if your default domain is different after restoring. If you are using IP for default domain then it will be different on the new server. So a restore will break that by restoring the original default domain.

Try logging in by referencing the old default domain. So instead of username: superadmin, try username: superadmin@x.x.x.x where x.x.x.x is the old default domain or IP.

 

[ParaCon]

I have installed a new Fusionpbx and restored alle tabels i have not removed database only old tabels imported via adminer.
everything works but if i make changes on fusionpbx interface like
- change destination,
- change ring group,
- change password of the extention,
- delete extention


Next things works wel
- create new extention (if i use a new number not a already used ) and if i remove this new extention also
- create new ring group ect

Extra notes:
if i make changes on fusionpbx web interface i have cheched it change also in fusionpbx database.


does not help things:
Flush cache
restart server
reload mod_sofia
reload xml
i have maked a new fusionpbx restored hole database and changed db password to new db password (also same problem)
domain name renamed
in upgrade --> Schema, Data Types, Data Types, Menu Defaults,Permission Defaults
delete domain add again

it seems that freeswitch have a different database and fusionpbx have a different database.
If i add new things in fusionpbx database it will sync with freeswith database but if i make changes in fusionpbx database it's not sync with freeswitch database.

Can some one help for this

 

[smn]

It's just used for internal freeswitch stuff as far as I know. Sometimes it's nice to be able to see that which is the only reason to put it in postgres. Otherwise you can just not configure it and it will use sqlite by default. I think you can delete all those sqlite files and it will regenerate everything on reboot. I don't think you would ever want to do anything on that DB directly.