My first successful restore - and what is broken in the Backup!

[GSnover]

Ok - I am filing this under Endpoint Manager, because it’s what is causing the problem.

I have been struggling to use the Backup/Restore function on FreePBX 15 because I have about 30 machines to move from our own Hosting to Vultr - I finally got a machine to restore properly (with a little help - that is what needs fixing!).

Procedure I am using is the same every time:

On the old machine:
yum update -y
fwconsole ma upgradeall
Apply
fwconsole restart
Backup

On the new machine:
fwconsole sysadmin activate ID
yum update -y
fwconsole ma upgradeall
asterisk-version-switch (the .ISO on Vultr is out of date - we are running 18 on everything)
Apply
fwconsole restart
fwconsole backup --restore backup

So that is what I did on this machine - but once again, Endpoint threw and error (and didn’t restore correctly - it was empty) - Here is the error:

SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘asterisk.endpoint_basefiles_211’ doesn’t exist on line 246 of file /var/www/html/admin/libraries/BMO/Database.class.php

Bummer - run the restore again just to make sure it wasn’t a fluke - same thing.

So, from my spelunking here: After restore to new home, can't install Zulu or Sangoma Connect - Commercial Modules / Sangoma Connect - FreePBX Community Forums I went and looked in the Asterisk database on MySQL on the Old machine and on the new - table exists on the Old machine, but not on the new!

mysqldump asterisk endpoint_basefiles_211 > endpoint_basefiles_211.sql

on the old machine and then

mysqldump asterisk < endpoint_basefiles_211.sql on the new machine and then try the restore again.

Progress - New error this time:

SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘asterisk.endpoint_buttons_211’ doesn’t exist on line 246 of file /var/www/html/admin/libraries/BMO/Database.class.php

Alright - look again in MySQL and the table is present on the old, but not the new, so export/import again and then execute the restore one last time - Bingo!

Everything is restored and happy and where it should be!!!

I don’t know exactly why this is failing on almost all my machines, but I would guess that it relates to the following:

1. Almost all of my machines have been in service for at least 3 years + - many of them, even more than that - which means a lot of them were FreePBX 13 (or earlier) and then upgraded multiple times.

2. I am guessing that the old Endpoint Manager stored it’s info in tables that the new EPM is not looking for/creating/maintaining and that’s why it’s borking out.

What I don’t understand is why it is crashing on the restore when it correctly backed it up? I thought 15 Backup was supposed to be smarter than that!

Oh well - On to moving my machines now that I CAN use Backup and Restore (with a little help from the CLI)

[sorvani (Jared Busch)]

This really sounds like you don’t have all the appropriate commercial modules installed on the target machine prior to restore.

As a reminder, installed != activated.

[GSnover]

Endpoint absolutely was activated - it’s that .211 Table - I am certain it’s because this is an OLD machine that has been upgraded many times, and the backup is just not looking for that table to be restored - so it’s not restoring the table, and then when the module tries to restore, it’s trying to restore into a table that is not there.

I am doing another one here in a minute - I will post the results from it - it’s a fresh-load from this year (a new convert) - I am betting it won’t be a problem because that table will not be present in the Backup.

[GSnover]

Ok - Just backed up and restored another machine - this was a fresh-load about 4 months ago, and it had no problems restoring Endpoint.

It also had Sangoma Connect and it restored that too.

But watching the CLI, there were a couple of errors I saw that make me wonder:

[npm-cache] [INFO] [npm] running [npm install]…
audited 404 packages in 2.448s
found 85 vulnerabilities (19 low, 6 moderate, 58 high, 2 critical)
_ run npm audit fix to fix them, or npm audit for details_

Variations on this come up many times - is this just “Life with Node.JS” or should we be worried about it? Lots of deprecated and no longer supported Node packages are installed in the process of restoring. Should I be worried?

Next message was in bright-red, but I have left it plain for eyestrain:

There were errors during the restore process
_ Provisioning protocol ‘sslhpro’ associated with template[ ‘internal’ ] is not enabled._
Please enable ‘sslhpro’ in the System Administration module or change the protocol being used in the template
Please re-ensure that the selected provisioning protocol is highlighted in the template. If not please select the protocol and re-save the template. on line 2990 of file /var/www/html/admin/modules/endpoint/functions.inc/functions_common.php
_ The command “fwconsole reload” failed._

Exit Code: 2(Misuse of shell builtins)

Working directory: /usr/src

Output:
================
Reload Started

Error Output:
================

In Reload.class.php line 712:

_ chgrp(): Operation not permitted_

reload [–json] [–dry-run] [–skip-registry-checks] [–dont-reload-asterisk]

_ on line 239 of file /var/www/html/admin/libraries/Composer/vendor/symfony/process/Process.php_

EPM worked just fine, so it wasn’t a show-stopper, but still.

Finally, after everything was restored, IP’s and Hostnames and Time Zones were set and the machine rebooted, it said everything was fine except for Fail2Ban - wouldn’t start.

journalctl -xe had this:

– Unit fail2ban.service has begun starting up.
Jun 26 16:25:33 pbx-aha.dyndns.org fail2ban-client[12494]: ERROR Found no accessible config files for ‘filter.d/zulu’ under /etc/fail2ban
Jun 26 16:25:33 pbx-aha.dyndns.org fail2ban-client[12494]: ERROR Unable to read the filter
Jun 26 16:25:33 pbx-aha.dyndns.org fail2ban-client[12494]: ERROR Errors in jail ‘zulu’. Skipping…
Jun 26 16:25:33 pbx-aha.dyndns.org systemd[1]: fail2ban.service: control process exited, code=exited status=255

So again - stare-and-compare with a working machine - working machine had a file zulu.conf, with the following contents:

[INCLUDES]
[Definition]
#_daemon = zulu
failregex = Authentication failure from
ignoreregex =

So I created the file and then systemctl start fail2ban.service and it was fine.

So MUCH less hassle with this one, and I think I am on the right track when I say that the problems with restoring Endpoint come from OLD machines and the restore module not making allowances for previous setups.

On to the next one.

[GSnover]

Ok - Just restored to another - had to do the zulu.conf again, but other than that, perfect.