Virtualmin Restore Issues (DB / NGinx)

SYSTEM INFORMATION
OS type and version Ubuntu 20.04
Webmin version 2.001
Virtualmin version 7.2-1 Pro
Related packages Virtualmin Restore

This has been happening consistently for last 4 restores I had in last 12 months. I somehow fixed the issue and moved on. This time I am determined to find out the facts and see it resolved once and for all. I would like to see server migration with virtualmin full backup and restore work flawlessly.

Virtualmin was installed with --bundle LEMP for NGinx support. And virtualmin restoration involves migration of everything related NGinx including my websites, one per virtual server.

Here are the issues.

I have been following instructions on this page Migrating To a New Server – Virtualmin

Backup of Virtualmin settings as well as virtual servers work just fine. No errors seen each time. Everything is either “done” or “none to backup” with “0 had errors”

Then when it comes to two commands of restoration in that user guide, first command of virtualmin settings restoration works just fine without any errors.

But second restoration command to restore virtual servers fully, I get following errors every time.

  1. Right after extracting backup archive files … … done I get this Access denied error as below,
    Re-creating virtual server example.com
    /usr/bin/mysqlshow: Access denied for user ‘root’@‘localhost’ (using password: NO)

Since MySQL → root password was set I thought it is trying without password (null password) and throwing this error. So I set MySQL → root password to null (e.g. ‘’), removed virtual servers and tried to restore again, then I got following error now,

/usr/bin/mysqlshow: Access denied for user ‘root’@‘localhost’ (using password: YES)

How to avoid this issue while restoring virtual servers / domains?

  1. Setting up scheduled Webalizer reporting …
    … Webalizer reporting failed! : Webalizer config file /etc/webalizer/webalizer.conf does not exist!

What do I have to do to avoid this error at restoration?

  1. Creating MariaDB login …
    … MariaDB database failed! : mysql::execute_sql_logged failed : DBI connect failed : Access denied for user ‘root’@‘localhost’ (using password: NO)

What do I need to do to avoid this error at restoration?

  1. Applying Nginx configuration ..
    
    … configuration is invalid : nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: [emerg] bind() to X.X.X.X:443 failed (99: Cannot assign requested address)
    nginx: configuration file /etc/nginx/nginx.conf test failed

How to avoid this error?

  1. Yet to double check, but in all previous restorations none of the actual mails got transferred during migration. I also had a separate ticket of how to just migrate emails from one server to another due to this disaster in past. I think email accounts are created

How to have all the emails

Previously when I only had Apache / PHP websites, I don’t think I had faced these errors during virtualmin restoration.

Appreciate your help resolving these issues.

For 5) about emails post migration, this time emails were migrated. Just incoming emails were not working. Found out that one of the settings in webmin → postfix somewhere that was mapping to user@hostname.com or something like that. It should have been just user. So I switched that setting to NO from YES. Although restoration from virtualmin backup led to that unnecessarily.

@jiteshsg
For 1) and 3) IMHO you shouldn’t clear the mysql root user password, perhaps
you kill a bunch of other processes/functions this way. Set it back to what it was, or maybe use the Re-Run install wizard in Virtualmin → system settings, may be this works.

You can proof the correct connection between Webmin/Virtualmin and your MySql- (i.e. MariaDB-) server, within WebGui via: Webmin → Servers → MariaDB Database Server.
There, you should see all the databases, but no error message.

Then, I’d suggest to try the following using ssh / terminal on your server
as user root (or via sudo):

  • try if a simple mysql mysql opens the mysql console
  • if not: Edit or create the file /root/.my.cnf containing something like:
[client]
user=root
password=(your mysql root user password here)
  • then, starting mysql mysql should succeed, or - there is something really wrong with your server