I moved two of my own revenue sites and their aliases this morning:
LOSING SERVER: CentOS 7.9, Webmin 1.994, Virtualmin 7.1 Pro
GAINING SERVER: Rocky Linux 8.6, Webmin 1.994, Virtualmin 7.1 Pro
Each server has its own Virtualmin license. They are on different domains and do not share DNS.
Both servers also have non-standard SSH ports, which I think may explain some of the quirks.
Quirk 1:Add Servers > Import Virtual Server created empty sites.
In a nutshell, the /home directories were empty. The virtual servers were created, but nothing was imported. Possibly due to non-standard SSH ports?
Quirk 2: Sending backup from losing server to gaining server failed.
Whether sending to a Webmin server or using SSH, the connection as refused. I suspect this is also because of the non-standard port.
I used rsync to move the backup files, and they restored successfully on the gaining server. They’re both in revenue service now. (I love the speed of a lightly-loaded server.)
However:
Quirk 3: It would be nice if the aliases were packaged with the target virtual server, and an option to restore the aliases given during restoration.
Quirk 4: Manually re-creating the alias virtual servers immediately after creating the target virtual server or another alias fails with a 404 on the preview page of the target server when the “See what will be restored” button is pressed. Opening the dashboard in between creating the parent or previous alias, and the new alias, enables the alias to be created.
The good news is that both sites are now live on the new server and everything is working fine.
It actively refused the connection trying to send the files from the losing server to the gaining server, as well. But when I specified the port in rsync, the files transferred. That’s why I think the port is the problem.
That’s my plan for the next site I move over, more to test my hypothesis than for any other reason. I actually don’t mind using rsync because I can move as many backups as I want in one command.
But if the GUI-based move will fail due to a non-standard port, then it makes sense to have a place in the GUI to specify the port.
It’s a very simple site, but appeared to transfer properly.
Thanks for the advice. I’ll most likely just keep pushing the files with rsync, however, just so I can do them in batches when I have time to point DNS and change the nameservers at the various registrars, which actually takes longer than moving and restoring the backups. The restore function itself has worked flawlessly.
I was surprised that the registrar for two .aero domains I moved over popped up a message that they had to “validate” the new nameservers. Maybe it’s because .aero is a restricted TLD. Or maybe they’re just more thorough than most registrars and want to make sure that the nameservers are properly configured. Given the cost of .aero domains, they certainly can afford to be thorough.
Whatever the reason, the “validation” of the nameservers only took a few minutes. More importantly, however, it also alerted me that one of the nameserver IP addresses was on some obscure blocklist I’d never heard of before. I’ve successfully delisted it.
I’m pretty sure Virtualmin does an “rsync” when it comes to moving the data between servers, but yeah if you want to do a bulk action perhaps it’s a bit easier your way for the moment.
from the losing server moves them all. Once they’re all restored, I empty the directory on both servers until the next batch. Keeps things nice and simple.
You could write a script to execute a backup via CLI API and then have it issue the rsync either after each backup or after all backups are completed. You could also place a cleanup step in there and a verification step as well… Perhaps go as far as triggering a restore as well… Oh my…
