Server migratie met DirectAdmin
Hoewel het niet erg veel specifiek met VPS te maken heeft, plaats ik deze HOWTO ook maar eens hier. De doelgroep van deze website is toch redelijk gelijk aan de doelgroep die deze HOWTO aanspreekt. Hij is in het Engels, maar dat lijkt me geen probleem!
We, as a company, migrate DA servers on a very regular basis. Sometimes because a server is past its expiration date, sometimes because clients move to our services. Anyway, because we feel we’ve conquered this quite nicely so far, I decided to share our knowledge and maybe start a discussion on how to improve this technique.
It’s just a basic checklist based on many other howto’s and knowledgebase items, but I’ll try to make it a comprehensive set of “tools” making sure you minimize your downtime.
We start four to six hours before our server is at its quietest by lowering the TTL. As DA support has a guide for this, I decided not to go too deep into this. Don’t lower it to 100 though, lower it to 301. Some access providers tend to overrule a TTL lower than or equal to 300, 301 has the best results, although I must add to that that these experiences are with Dutch APs.
These four hours give us plenty of time to setup the new server. Of course, you have experience with setting up a server and you will want to do it your way, I respect that. Basically, what we do is we install our OS (CentOS 5), do a custombuild DA install and proceed from there. Add all the IPs you need to the server in advance. Then you could look into using ELS as your basis for securing the server. After that I would advise on securing Exim with ClamAV, SpamAssassin and SpamBlocker (an obsolete version is currently provided with DA, look here for the current stable version (v2) or the latest beta (v3)). Guides can be found on the forums. But again, this is just one of many ways. Of course, install the packages you need, you’ll know better what you want.
Fine, then you’ll have some spare time left, get a nice cup of coffee, start testing whether everything is setup properly. Make a test reseller account and try giving it two nameservers and one user (with a domain) on those nameservers. Check whether they are functioning normally using your favorite nameserver checking service (Google will find it for you). We’ve had some problems with bind/named in the past, so I always advise to do so. If everything works, remove the reseller and the user(s).
At least four hours should have passed and it should be an off-peak time by now. If not, get another cup of coffee and go do something useful.
Right before your start backup up, there’s a very important decision to make: whether to shutdown httpd/mysql/exim/dovecot etc. on the old server or not. Basically, that’s a choice between downtime and information loss. And it’s your choice. I always stop all services just before I make the backup, inform all clients on it two days in advance and depend on my mail relay service for relaying e-mail. But again, it’s your choice. It should all be offline for no longer than 30 - 40 minutes.
Now, we’ll start by backing up all accounts on the old server. I don’t know how your server is setup, but I always advise not to transfer the admin account along with the other accounts. If you’re experienced with DA, you’ll know not to use the admin account too much and use a reseller account for all the rest, but if you didn’t, well, you’ll have to backup the admin account as well. Use the admin backup/transfer tool. System backup is nice to use for redundancy, but it’s very hard to restore a system backup, so this way is better imho. You can have DA send the backup to the new server using FTP, but you could also have DA just focus on the backing up process and throw each individual backup to the other server as soon as it’s done. The last way is probably faster as DA doesn’t backup and transfer at the same time (thanks to jlasman for pointing that out!).
Login to the new server and wait until the old server’s DA tells you the backups have been successful.
After the backup’s done, start restoring the backups on the new server. Make sure you check that the new IP is being used for restoring. If certain users have their own IPs, restore them individually or change it later on. DA will have it done quite fast in my experience, but it could take a while longer or fail. If it fails, make sure to restore the failed accounts again.
Then, as fast as you can, fire up an SSH session to the old server and change the IPs in the DNS configurations. This is to make sure that all traffic is now going to the new server, even if an AP overrided the new TTL. To do that, use the following steps:
# cd /var/named
# perl -pi -e 's/1.2.3.4/4.3.2.1/' *.db
# service named restart1.2.3.4 is your old IP, 4.3.2.1 is the new one. Make sure you execute the perl command for every IP that needs to be changed, so also for the nameserver IPs and dedicated IPs.
Just to be sure, stop all processes on the old server except for DA, named and SSH. To speed up the process, you could change the IP for the domain that has the nameservers at your registrar’s. After you have made sure everything resolves fine, you can do with the old server whatever you want.
After making sure everyting works like it should, you’re done. Great stuff, give yourself a nice pat on the back!