Considering moving my VMin server offsite

Virtualmin
1
SYSTEM INFORMATION
OS type and version RHEL 9
Webmin version 2.303
Virtualmin version 7.30.8
Webserver version Apache

I am thinking of moving my VMin server to a remote hosting service.
Plan A is to use the Domain Transfer feature to do one domain at a time.
What I am curious about, is what happens to transactions - eg email in/out, web pages, database changes etc while the transfer is happening?
A couple of domains may take quite a while to upload.
Any comments, suggestions, etc appreciated.

2

If, say, a backup and restore operation takes 60 minutes and you cannot afford downtime:

  1. prep DNS by reducing TTL
  2. backup and restore (the 60 minute operation)
  3. update DNS, wait for propagation
  4. sqldump the database again (this would take a minute or few), put old server database in read-only mode
  5. imapsync several times, say once an hour, till no email is left behind

It’s tedious work. The simple and easy method is to schedule a bit of downtime and migrate as per the Virtualmin documentation. See

3

Have you read our migration guide?

I’m not sure if it mentions the mail question, but you have a few options for how to handle it. You can do a final rsync of the mail homes at the end, you can use something like imapsync, or you can stop the mail server during the migration. Mail will retry for quite a while before rejecting mail if the destination server isn’t responding (this last one is almost always what I do, I used to setup a temporary hold and forward mail server as a backup so mail was still accepted during the move, but I’ve come to think of that as overkill and a poor use of time). Then, after the migration is done and MX records have been updated (you did remember to shorten your TTL on all records before beginning, right?), you can turn the mail server on the old system back on (for any domains that haven’t been migrated yet).

I like to do one domain at a time, as long as I don’t have a lot to do, as it makes it casual and each can be done faster than all at once and I can confirm everything is working and I remembered all the steps and got everything right, before moving on to the next. Even if you do have a bunch and want it to all happen at once, maybe do two or three individually first to get comfortable with the process (and with using the CLI for a restore), and then use the command line interface to bulk restore the rest all at once.

1 Like
4

Just curious, why not use the domain transfer feature? It has worked well on a couple I have done on the local network.

5

Virtualmin’s domain transfer is perfect for the average sized website which can be transferred in a reasonable length of time and with an acceptable level of downtime / data loss (or loss of transaction data, as you put it). However there are situations in which scheduled downtime is not possible…

6

So if it took an hour for a domain and I was happy to do it late night, then it would work OK?

Possibly then just do backup/restore for the larger ones?

7

The best way forward would be to schedule downtime and use Virtualmin’s migration documentation.

8

Transfer should also work, but I like to control the individual steps and I’m dealing with very active databases and mail, so it just feels better to know when I need those services to be stopped so I know data isn’t being “lost” by being ingested on the old server after the backup.

9

According to me when you do a big migration, you warn your community 1 month in advance about a big 4-5 hours downtime. And thats it. Your members will understand.

Then when the First server is down, you have 5 hours to make the backup and restore it with the new server. Finally you update DNS. And when DNS is propagated it’s done.