Major Migration Questions
 

About a year ago I acquired a Dell 410T with 128G of RAM and multiple CPUs and I installed CentOS 7 on it and using KVM I built 6 virtual machines for different functions.

Based upon what I've read CentOS is going away come November so based upon what I've heard Rocky Linux is the best way for me to migrate.

But, I'm running BIND, PostgreSQL, and Oracle DB on this CentOS machine - Can and how do I migrate those plus the virtual machines I'm running??? And how do I do all of this without formatting my LVM volumes?????

Gene Poole

Centos 7 EOL is 30 June 2024.

There is a migrate process called elevate project I've not tried using it so I can't help much but there are guides. You might have problems if you use EPEL.

https://wiki.almalinux.org/elevate/

A request for clarification:

When you say "migrate," are you referring to moving to a new machine (the usual meaning of "migrate"0, or recreating the site with a new OS on the same machine (what would usually be referred to as "backup and restore," or,perhaps more properly, "backup and recreate")? Your remarks about your LVM partitions would lead me to suspect it's the latter.

It's been a long time since I've migrated a web site, but I have a few thoughts.

The first step would be to back up your /home (where I would expect the VM's and all the crucial data files to reside to external media; given the complexity of this situation, you may want to make two backups. You should also back up any dot-config files in /etc that you have modified. It would probably also be a good idea to export the Oracle database to an *.sql file (I believe that's the format Oracle uses).

If you do not have a separate /home partition, I doubt that there is a way you can install a new OS without reformatting.

If you do have a separate /home partition, you should be able to install the new OS to /root without touching /home, then install whatever additional programs you need. If all goes well and there are no program-version issues, the dot-configuration and data files in /home may still be valid.

A web search for "backup and restore KVM" will turn up many articles that should help.

My approach would be to get the new install working with all the tools functioning properly, then restore the necessary data files, just as, when migrating a website, you get Apache working, then restore the website or, with a database, you get the database engine working, then import the database.

Just my two cents.

I suppose you want to upgrade the OS?

If yes, my 2 cents for the approach:
- clone one VM
- as per Michaelk, suggest follow that link
- of course you need to decide whether Alma or Rocky
- then test whether all applications will work fine, or you need to tweak or do some configuration change
- if everything works, then roll-out to production
- make sure you document your testing, or else you need to re-think again

Good luck!

OK, Does it really matter if I say migrate or elevate?"

The information I read in one of my Linux magazines was EOL was November 2024.

Besides all of that, I read several tutorials on 'elevate' AlmaLinux and 'migrate' Rocky Linux - what I saw was that the servers were not doing any real work so upgrading was no issue. But, nowhere does anyone say anything about a working server. I've got 4 - tablets running windows and android; 3 - desktops running windows 7 amd 10; 5 - desktops running several distributions of link - ALL of them point to BIND (DNS) running of this server.

I'll not talk about Oracle or PostdreSQL - if bind is not working nothing else will run.

Gene

Honestly, I'm not sure what the issue is. By running these things on a server you tacitly acknowledge some truths about your situation:

• Your system will get old
• Your system will eventually die
• Your software will age and be unsupported
• Your hardware will eventually become obsolete

Given all that, that's why backups are taken. Personally, I never 'migrate' or 'elevate' a server...I do a fresh installation of a new OS. And 'migrating' the servers can also be written as, "I have a new server and need to *INSTALL* these services". Backup your configurations for the various services; copy them to new server. And if the service hasn't ALSO been upgraded and needs a new config. Either way you have one choice: MOVE FORWARD. Configure the service using the new format and the service is now back up as it was before.

Install fresh, restore your data from backups. You're now "migrated".

The warning in the guide was that you should test the process on a separate server from the main production server. Depending on how the test server migration works (or not) you can plan accordingly for the production server. I would assume that part of the process will take the system offline at some point. And make sure you have a good backup.

Agreed. And when I'm in a corner and have one server (and a limited time-window), I will typically buy new hard drives, and pull the old ones. Sit them aside, do a load/restore/test. If everything works, great...if not, I can recover the old system in minutes by plugging in the old hard drives.

Good strategy to keep the hard drives, but not if the RAID Controller or the motherboard goes south.

Right, but the chances of that happening in the hour or so of a rebuild are fairly slim. And you face that no matter WHAT you're doing, since the motherboard or controller can go bad at any given moment.