Moving all sites - multiple nameservers
Hi there,
I am about to move all websites from my current hosting server to an upgraded server. There are some differences on the new server MariaDB, CloudLinux etc, so I want to have a little bit of time to test before going live.
I also have a situation where I have my own clients using my nameservers. I also have resellers, and some of them have their own nameservers. What I plan to do is move everything over to the new server, update the Nameserver glue records, and that will flick the "switch" and set the new server live. It also means my resellers can do the same, just update the IPs that their name servers point to, and they will be live. I have set the TTL value to 600 to encourage a fast propagation.
I have very little experience with the transfer tool. I did a quick trial with a testing domain to see how it would perform. I used the default settings, and it was messy. The source server wanted to proxy most of its services to the new server. Even email was being re-routed to the new server via /etc/manualmx
Is unchecking "Live Transfer" in the import selection the best way to acheive this? I do want the DNS zones to be updated on the destination server to replect the new IP, but I really dont want anything to change on the source server. It may need to stay live for half days whilst I debug and address issues. I can then use the transfer tool to overwrite accounts that have changed (perhaps not).
Is there a best practice for doing what I am trying to do? I want to use the same name servers on both servers, so it is key that only the source server remains alive until the glue records are updated to reflect the IPs on the new box.
Thank you very much in advance for your assistance!
-
Hi Alistair,
We'll provide you the best practice and step by step instructions of migration process.
We can divide the whole process into 2 phases.
The first phase includes initial transfer and testing
- Transfer all accounts with "Live Transfer" disabled
- Manually update DNS zone records on the new server to point to the new server's IP
- Test thoroughly on the new server using /etc/hosts file by adding the DNS testing like below
1.2.3.4 domain.com www.domain.com
- If you found any issues, fix it before DNS switch. Test it until it corrects.
The second phase includes final sync.
- Lower TTLs further (you've already set to 600 - good!)
- Update glue records for your nameservers
- Do a final sync - this time you can use "Live Transfer" for accounts that changed
- Monitor propagation using online tools or commands like dig
Regarding Resellers, communicate the migration schedule precisely and provide them with the new server IP addresses in advance.Regarding Email issue, transfer the email accounts but don't point MX records until final sync. Also, please do note that, there will be slight email downtime window.
Please write to us if you need anymore clarifications.
Regards,
TechAmigo Support0 -
Yes - if you disable the Live Transfer function that will stop the immediate proxy between the two systems and it will turn into a more traditional migration.
You can use the same nameservers as you just need to update the glue records at the registrar when you are ready to make the switch. This type of migration results in no downtime as a user visiting a website will get directed to either the old or the new machine during the short propagation time.
0 -
Thank you both for your detailed responses. This validates what I was thinking, so I am now confident to proceed.
I did, however, run into another gotcha. One of the websites I had previously imported to the new server for testing... I later reverted to the old server, restored the DNS on the old server and terminated the account on the new server.
I am now trying to import it back into the new server, but I get the following error...
Error: You have selected 1 account that cannot transfer properly because its username conflicts with a username on the local server.
- The remote account “usernamehere” cannot transfer because an account with the same username exists on the local server.
I have 2 options: overwrite or deselect. If I choose overwrite, the transfer fails because the account doesnt exist.
I suspect WHM/cPanel is holding a piece of the old account. Is there a way to purge this from the system?
Thank you again!
0 -
Can you run this command to see if there is anything left of that account in the userdata/
grep -Ri username /var/cpanel/userdata
Just replace "username" with the actual cPanel username you're working with.
0 -
Update:
I was able to address this issue by manually creating the account using the exact same username in WHM, then deleting the account. I was then able to import the account from the other server.
I guess something got hung up when I removed the account previously.
Cheers!
0 -
It looks like we were typing at the same time :)
I'm glad to hear that worked, even though I don't have a good explanation for exactly what may have happened.
0 -
Yea very close timing...
I did check the location you mentioned, and there was nothing referencing the user account. I also looked in MySQL just in case there was a database left behind (username issue) nothing there either.
Error logs also appeared to be free of related errors. It's a mystery!
Thanks again.
1 -
You will be getting fed up with me and this awkward transfer :-)
New problem...
When I select all accounts (deselect the few that I have already brought over for a test), then uncheck "live transfer" apply that to all accounts and hit "copy" accounts are failing...
Streaming home directory from source server …
receiving incremental file list
rsync: opendir "/home/usernamehere/.HttpRequest" failed: Permission denied (13)The process hands for a long time. I then abort and retry with that account skipped, the same applies for other accounts.
The dot file .HttpRequest does not exist. Is this something that resulted from my previous live transfer that was aborted?
0 -
Hello Alistair,
This type of permission error is common and can happen due to several reasons.
- Fix ownership and permissions of the specific file on source server
chown -R username:username /home/username/.HttpRequest
chmod 755 /home/username/.HttpRequest- Check and fix parent directory ownership and permission
chown username:username /home/username/
chmod 751 /home/username/- Temporarily disable SELinux and retry
sudo setenforce 0.
This change is temporary and will only last until the next system reboot.
- Temporarily disable the user from cagefs via WHM or cli
#check if CageFS is enabled
cagefsctl --list username
#If CageFS is enabled, temporarily update the user
cagefsctl --update username
Retry the transfer, if the issue still occurs disable it.
# Disable CageFS for migration (temporarily)
cagefsctl --disable username# After migration, re-enable it
cagefsctl --enable usernameLet us know if any of these works.
Regards,
TechAmigo Support0 -
I may have a rough theory as to why that happened. The hostname for the destination server is a subdomain (srv2.example.com) of a domain hosted on the source server. It seems the DNS did get altered even though live transfer was disabled. I also appear the destination server became unreachable during the transaction.
This time, website DNS zones were not affected, but SSO (WHMCS to cPanel) stopped working...
I was able to correct this by running...
/scripts/restartsrv_cpsrvd
/scripts/upcp --forceWhy am I getting all the strange, unexpected errors lol :-)
Alistair.
1 -
When I transfer accounts I always whitelist the source server's IP in the destination server's firewall, and the destination server's IP in the source server's firewall. If I don't do that I will have problems, especially if I use Live Transfer.
1 -
HI again everyone, and thank you very much for your valuable input. I started fresh and finally got a block of sites moved over. The biggest issue was CloudLinux. When it creates an account, it starts restricting right away. My default install set the IO limit at 1mbps :-) I assumed it was a connection/data issue, but once I set that to "0" (no limit), things improved. Another possible reason for the move being a little slow was my choice to go RAID 1 in my main NVME drives. This will be lightning fast for serving pages, but writes, especially sequential writes, need to be done twice..
The .HttpRequest dot folders.. I believe they are an artefact from a cPanel process. The problem is they are created as root (or a sudo user) the permissions are set in such a way then they can't be read or moved by other users. That's why rsync was failing. I removed these folders, they only appeared to be placed in resellers' apex accounts?
Feeling happy now, I am finally getting somewhere. I should have spent a few weeks getting more acquainted with CloudLinux, instead of just seeing it at my provider and impulsively hitting "add to cart" lol
Again, thank you for all the help and support, any further issues and I will need to annoy you again lol :-)
0
Please sign in to leave a comment.
Comments
12 comments