Best way to transfer to a new VPS, a little at a time

[GoWilkes]

I'm transitioning to a new VPS. The old one is running CentOS 6.10 xen hvm and WHM v86.0.32, with PHP 5.6 and MySQL 5.5; the new one is running CentOS 7.9 and WHM v92.0.3, with both PHP 7.4 and 5.6 installed and MariaDB 10.3.

One account (which is mine, and the largest) is roughly 40G in size, and 11G of that is MySQL. The last major rebuild was on PHP 5 and used procedural mysql_ commands throughout, but PHP 7.x requires MySQLi so it's a bit of work to modify the whole thing.

I'm trying to minimize (better yet, prevent entirely) any down time.

So first question... would you suggest that I:

A) move 29G of PHP and images (mostly uploaded by users) to the new VPS on PHP 5.6, modify the DNS to point to the new VPS, and on the new VPS modify the scripts to load MySQL from the old VPS (which would just require a change on one file), then modify each of the scripts for MySQLi? Or

B) move the 11G of MySQL first, then point the scripts on the old VPS to point to the new VPS for MariaDB?


Second question...

What would be the best way to move these items piecemeal like that?

I'm guessing that I would need to manually create an account on the new VPS with the same account name and domain name as the old VPS, but I have 55+ domains parked on the old VPS... would I have to manually park each of them on the new VPS?

Then I'm guessing that I would need to use cPanel to create the emails, MySQL database, and MySQL users with the same names, usernames, and passwords as the old VPS, and THEN use rsync to copy the files over?

That's a lot of opportunity for mistakes so it's far from ideal, but I don't see an option in WHM to select file types or directories to transfer, or to just transfer DNS data or anything.

TIA for any advice you can give!

 

[cPRex]

Hey hey!

So, I have a few thoughts on this.

Instead of your A or B option, what about just moving all the data over to the new server and pointing there with a hosts file while you make adjustments and ensure things are working? That way you don't have two servers with portions of a live site, because, as you mentioned, there's a lot of opportunity for error. Once you know things are working well, you could do a final rsync of /home/username to make sure all data is updated on the Destination machine.

For the "piecemeal" option you mentioned, the Transfer Tool in WHM will let you move part of the account. For example, using the details here:

Transfer Tool | cPanel & WHM Documentation

This interface copies multiple accounts from a remote server to your cPanel & WHM server.

docs.cpanel.net

if you choose not to move the home directory, you'll still get databases, FTP users, email accounts (but not the mail content), and everything necessary to create the account. Then, you could manually rsync /home/username from the Source machine to the Destination to move the data.

Let me know if you like those ideas instead!

 

[GoWilkes]

Instead of your A or B option, what about just moving all the data over to the new server and pointing there with a hosts file while you make adjustments and ensure things are working? That way you don't have two servers with portions of a live site, because, as you mentioned, there's a lot of opportunity for error. Once you know things are working well, you could do a final rsync of /home/username to make sure all data is updated on the Destination machine.

You went just an inch or two over my head, so let me make sure I follow you here...

Step 1, use Transfer Tool to copy everything, but not use Express Transfer so that the DNS on the old VPS doesn't change;

Step 2, modify all of my scripts in a way that I THINK would work, maybe turn off mod_userdir to test with 12.45.67.89/~example;

Step 2a, I think I would still have to change the scripts on the new VPS to point to MySQL on the old one; otherwise, anything submitted by a user while testing would be lost;

Step 3, go to /etc/hosts on the old VPS and add... I'm guessing here:

# new server IP, whitespace or tab, my domain name;
# I know there's a 3rd column for DomainAlias, but I don't understand that and I think it's optional
123.45.67.89 example.com

then if there are problems, just comment that line out so that everything quickly points back to the old VPS.

Am I right so far?

As an addendum, if I do that then could I change one directory at a time so that any undefined directories point to the old VPS? Something like,

# new server IP, whitespace or tab, my domain name
123.45.67.89 example.com/index.php

# if this would work, does it apply to all subdomains, too?
123.45.67.89 example.com/foo
123.45.67.89 example.com/bar

And then, when everything is good...

Step 4, go back to Transfer Tool, use Express Transfer to copy the account on the old VPS to the new one, while leaving "Home" unchecked;

Step 5, use rsync to copy over any new user-uploaded files and MySQL; and

Step 6, finally, modify the scripts on the new VPS to point to MySQL on localhost.

Does that sound about right?

 

[cPRex]

Correct on step 1 and 2, but you lost me after that :D

You want to make sure everything works on the new system, so you wouldn't want to point anything back to the old server. The whole point of doing this type of test is to ensure things work with the MySQL changes, so testing only on the new machine is what you want to happen.

 

[andrew.n]

Why don't you want to use the Express option? that way you wouldn't need to adjust anything manual as it will automatically suspend the accounts on the old server once the migration is completed. By the way we recently had another client to move from lentos 6 to 7 and we discussed the best steps here in details:

Transfer of all accounts CENTOS 6.10 WHM v86.0.32 to CENTOS 7.9 v92.0.3

 

[GoWilkes]

Why don't you want to use the Express option? that way you wouldn't need to adjust anything manual as it will automatically suspend the accounts on the old server once the migration is completed.

I know that the account won't be a seamless transfer, so I'm trying to minimize down time. The current site was built on PHP 5 and uses procedural MySQL, but PHP 7.x deprecated that entirely; now I have to modify the entire site to MySQLi.

And since I'm switching from MySQL 5.5 to MariaDB 10.3, I'm not sure that I won't have errors from that, too.

So right now the plan is to move all of the data over without changing the DNS on the old VPS, modify all of the PHP to use MySQLi and look at the old VPS for MySQL, then maybe use /etc/hosts to temporarily see if it's all good? If it is then I would then use rsync to copy MySQL over, modify the PHP again to look at the new VPS for MySQL / MariaDB, then make sure it's still all good. If it is then I would use rsync again to move over any recent user-uploaded images.


Follow up question:

I understand that when I use cPanel's Express Transfer, it gzips everything up on the old VPS to transfer it. I'm concerned, though, that if I don't have enough room to store the gzipped file then the old VPS will fill up, the transfer will fail, and the site will start throwing errors.

Any guess at how much storage I need to make available?

If there are too many variables to guess, then do you know if I can use Express Transfer and turn OFF the transfer of Home, Databases, and Bandwidth Data, would it still create the account, then copy all of the relevant DNS info, database names (without the data) and database users, and email accounts (without the emails)? If so, I could use rsync to transfer directories a little at a time.

 

[ffeingol]

OK, a couple of things.

You can't rsync MySQL. If you need to sync up the database again you have to dump it (back it up) on the old and then restore it ( import it) on the new. Depending on the size of the DB, you can do that with phpMyAadmin. If it's too big (and you have shell access) command line mysql and mysqldump are pretty easy.

As far as what get's gzipped on a transfer, it's basically the account setup and database backups. They 'tend' to be small. All the sites content will be rsynced along with any mail. The transfer process will check that there is enough room on the destination server before it starts restoring.