Backup procedure prior to upgrade server OS

Virtualmin
1
SYSTEM INFORMATION
OS type and version Centos 7.9.2009
Webmin version 2.021
Virtualmin version 7.5 GPL
Related packages AlmaLinux 9.1

I plan to upgrade a CentOS 7.9 server with Virtualmin GPL to AlmaLinux 9 re-using the same server.
I know most people spin up a new server but I figure the extra time to install the new OS is only half an hour in a migration process that will probably take me 2-3 hours if all goes well.

I do plan to take a snapshot of the old server that can be used if the migration is not successful.

I have read several guides to upgrading Centos to Alma and the Virtualmin backup restore process reportedly works very well. I will look out for slave DNS issues in previous versions and some workarounds to resolve sync issues.

Whether or not I re-use the server, I need to know the state of my backup. Most of the server is static/quiet and is not frequently changing, but email may arrive at any time.

I’m thinking that I should stop postfix before (a) taking the snapshot, and (b) making the Virtualmin backup, but nobody has mentioned this before. Is it the correct thing to do?
I am presuming that with postfix stopped, potential incoming email will be queued by the sending MTA and will be delivered later when I have restored the backup on the new server OS, at which time I can start postfix.

I would welcome any advice on this procedure to make sure no email is lost in the upgrade process,
Thanks, Peter

2

That would minimize any mail loss, yes.

As for the rest, I haven’t tried an in-place upgrade with Virtualmin installed, so I have no experience there. Good luck.

Richard

3

Make VM backup, shutdown VPS, then make snapshot.

4

Thank you @RJM_Web_Design and @stefan1959.
The revised sequence makes sense. The snapshot is then absolutely the latest working state. I would still stop postfix before the VM backup.

It’s not going to be an in-place upgrade but rather a fresh install of Alma on the old server instance.
Thanks again

5

I don’t understand your meaning.

Either way you have to install the new OS, but if you do it on a new VM then you can do the OS install while the old server is still working.

Then use the excellent domain transfer of Virtualmin and the only downtime is while each domain is transferred.

Versus the down time for all services for all domains while you do backups of every thing, then do the fresh OS install, then restore all of the domains, then finally switch Postfix back on.

You also can’t as easily go back if there are any hiccups.

What is the advantage that I am missing?

6

@randomz It’s a good question and I think there are pros and cons with each approach and the optimal solution (if there is one) will depend on the volume of backup data to transfer and the skills of the admin. I don’t have much of either of those!

My main convern is my ability to manage DNS, and keeping the same IP address requires many fewer changes.

I would, of course, reduce the TTL to something short (e.g. 5 minutes) so that changes would replicate quickly.
I also need to consider the TTL of the GLUE record which is going to change to the new server.
I have the required 2 or more name servers on different servers. If one goes offline it’s not a problem - the other one serves.
But there are many things that I’m uncertain about. For example would I set up a master/slave BIND between the old and new servers? Which would be master? Would the VM restore change slave to master ready for service?
if they serve up different responses as the domains are transferred, that is a problem.

I foresee spending more time trying to resolve DNS problems than I would installing the replacement OS.

Time: My server backup, for all domains, is not large (3-5GB) which transfers to my home backup disk in 30-60 minutes. I imagine it will transfer in less than half that time on a VPS to VPS transfer.

Installation of the new OS and Virtualmin I estimate at 30 minutes and you’re right that this is extra downtime compared to having and old and new server. But It’s straightforward so I don’t anticipate problems and I have had some trial runs.
I have, already on CentOS 7.9, switched from FCGI to FPM, and all apps run on recent PHP (>=8.0).

Domain transfer. AFAIK there is no direct transfer command in Virtualmin, but it is done by backup on old server and restore on the new one. Manual effort is required to click the menu items (at least for me), and doing all domains at once should be quicker than individually. Although I may do them individually to avoid confusion if there is a failure.

My fallback if there are problems is to restore the server with the snapshot, and take time to consider the issues before repeating the process.

And fundamentally I still believe I’d need to stop postfix during the migration. There’s no mail sync available after the backup is done so I have to stop mail being delivered to the old server.

I’m not claiming my logic is correct. It’s just my opinion at the moment. I’m still open to having my mind changed :slight_smile:

7

I use this screen to do it

image
image1510Ă—575 51.3 KB

if you can not see it use the search box in virtualmin to find it

8

@jimr1 Thank you! I had missed that.
If I can get more confident with DNS I might reconsider my migration method.

9

If virtualmin is the dns server on both servers I don’t think you need to worry too much as it does what it says on the tin … but you could do a test by transferring one virtual server across and check the results. On the 3 or 4 times I have used this function I have never had to edit anything on the new server that I remember

10

Ah, okay. I’ve done a few of those, mainly to preserve clean IP addresses. I do them in the middle of the night when traffic is slow.

Richard

11

Not always. Transferring to another disk is reading from one disk and writing to another, versus reading and writing to the same disk - more work,

On my ESXi system I would have to delete the entire server in order to create a new one to install a new OS, this would include losing all snapshots.
The only way that could work is if you still have a snapshot from when the VM was created but before you installed the original OS. Having snapshots going back that far isn’t recommended as more snapshots increases the potential unreliability of the snapshot system and also has a performance penalty.

12

I would never, ever, under any circumstance do an in place upgrade. There’s just too much that can go wrong.

At the very least, I would migrate your current 7.2009 configuration to another server and get it running. Then activate that server as a temp and upgrade the main to Alma.

That way, if lightning strikes and disaster hits, you still have an up and running server.

1 Like
13

Thank you all for your helpful advice and suggestions.
FYI with Vultr I can “Change OS” from the Settings tab of the instance in the Vultr control panel. There I can choose one of their standard OS installations or choose my own ISO (which I can preload without charge).

I will now have a long hard think about how I proceed.
Thanks again

14

You know that destroys everything.

15

$5 to have a new server for a month and then delete the old one.

Having 2 servers for a while is a lot better than having 0 and crossed fingers.

1 Like
16

I hear you !
Just to clarify the snapshot lifespan at Vultr, I asked support and they replied
“Your snapshot is stored separately from your server so even if your server is deleted it will remain. You can keep a snapshot as long as you need.”

17

It still means that you can’t have them running side by side in case you want to check stuff.

Keep in mind that you can probably switch the old IP over to the new server too - though I don’t use Vultr and don’t know what they offer.

18

Yes you can, you can rebuild a server on a snapshot with a different IP

19

He’s not contemplating an in-place upgrade. He’s contemplating an in=place fresh install.

It’s good to have a spare server in any case, however, even if only as a place to stash the backups.

Richard

20

One thing to consider is the sizes and number of sites, which affects the restore time.

I’ve done a few reinstalls to the same hardware with no problems other than downtime. But I always had a spare server to which I could restore if something went sour with the one I was reusing.

The only problems I had were some minor ones when migrating very old cPanel sites because they changed their file structure multiple times over the years. They were easy enough to fix once I figured out what had happened. That, of course, wouldn’t apply here.

Richard