So here I am on the new server, a dedicated virtual server (dv) from brand new, having launched at the very end of December 2006. Lucky me! My server problems could not have been timed better.

It’s only been a few month since I moved to FutureQuest, so the whole How to Move a Working WordPress Installation procedure was relatively fresh in my mind. It worked out a little differently, so I’m documenting this process again.

Geeky notes follow!

The Basic Idea

Since I have a working installation on davidseah.com, I need to do a few things in this order:

1. Buy new hosting from Media Temple, keeping the old host active so I can move files.
2. Move my email mailboxes over to the new host
3. Move my WordPress files and the MySQL database that powers it
4. Move any other non-wordpress services that might exist on the old site.
5. Change the official name servers for the davidseah.com domain to use the new ones

What is dedicated virtual hosting?

The dedicated virtual server (dv) from Media Temple is different from the usual shared hosting I was working with. For one thing, you don’t share the server with anyone else from your point of view. Technically speaking, you’re actually running a simulated dedicated server (that’s why it’s called “virtual”), on hardware that is shared with other virtual servers. The advantage is that you can make any changes you like to the operating system environment, including having full root access. You also gain the economy that comes from sharing hardware resources, with improved isolation from your neighbors CPU- and memory-hogging hijinx.

On the down side, you need to know something about system administration. The (dv) version 3 package uses an enterprise-level Linux (CentOS) on Virtuozzo, which is controllable to some extent by the Plesk 8.1 control panel. With Plesk, you adminstrate the server and can create clients, domains, and mail users. You can do some limited configuration of common services, but it does assume understanding of how these services work. If words like daemon, mysqld, cron, xinetd, smtp and ssh mean nothing to you, then Plesk might not be all that easy to understand for ya.

The main advantage of Plesk, from my perspective, is that it allows you to manage your domains and hosting clients from within a pretty GUI that works. Plesk also provides a measure of stability on your server because all the software and operating system components have been tested and made to fit together; sort of like having managed hosting without the expense or the expertise. You can purchase additional “snapshots” of your server configuration, which is really really handy if you’re the kind of person to mess around with things and need a way to undo the damage. Especially useful if you have a tweaked configuration.

Where Plesk falls short is lower-level configuration of the services it manages. If you want to change the setting of some internal MySQL or PHP variable, you’ll have to get root level access to the server (which you can, since it’s dedicated to you). Plesk will restart a service (like mail) for you, but that’s about it.

Since the server is dedicated, you can install your own software on it. At Media Temple you need to request to have the developer tools installed first, then you can do things like [install Ruby on Rails] and compile from sources. Note, though, that if you update the “plesk managed” parts of your server, you may not longer be eligble for the automatic updates that MediaTemple will do for you through their Update Option Program.

Getting situated on the new (dv) 3

There was a problem with my order, and I didn’t get my welcome emails that described what I was supposed to do. Normally with shared servers, you would receive an email that tells you the basics of how to move your files and how to set up email. I didn’t get any of that, so I had to figure it out from scratch.

The good news: You use Plesk to set that all up. The bad news: you’re on your own. There is a Plesk User Administration Manual I just found, which is probably worth reading. Until you set up your accounts to allow FTP and ssh into the system, you’re sunk. The quick way to do this:

• Set up your domain through Plesk. Then select the domain and click the SETUP icon, choose Account Preferences and enter the FTP Login name. This create a user that you can use to FTP into the site. You can also optionally allow this user to SSH in, if you assign a shell using the dropdown menu.

• FTP your files using the login name you created. Drop ’em in the httpdocs directory.

• Create email mailboxes by clicking back on the domain you created (in my case, davidseah.com) and then clicking MAIL under the Services heading. This is where you can add your email boxes and configure aliases for each one. It’s actually pretty nice. I used the exact same names and login credentials for my new mailboxes, so theoretically I won’t have to change much in my email program setup.

I’m skipping a lot of strange first-time configuration here…you’ll be forced to set up your domain and a default Client. Every domain (like davidseah.com) is tied to a Client (for me, I chose Dave Seah). I can create more domains and clients under my dedicated IP address (up to 30 with the basic license) and run a mini hosting business through Plesk, which is pretty cool.

Moving Your WordPress Files

I’ve got about 500MB of files on my current host that I got to move, not including the WordPress MySQL database. I could download the files to my computer and re-upload them, but that tends to be slow, so I do a server-to-server FTP transfer. This requires shell access on each host.

1. Login to both your new server and your old server via SSH. For the purposes of this description, the new server will be called newserver.com and the old one oldserver.com.

2. On the old server, use the tar command to compress your wordpress folder. Like tar cvzf wordpress.tar.gz wordpress/*, assuming that you’re at the same directory level of your wordpress folder.

3. On the new server, type ftp oldserver.com into the shell and login to your account. Make sure bin is set, then do a get wordpress.tar.gz. Since your hosts have a lot more bandwidth than your crappy home cable connection, this will be way faster.

4. On the new server, uncompress your archive with tar xvzf wordpress.tar.gz. The entire directory structure will be recreated.

There’s actually more than this that you have to do usually, because there are probably other directories you’ll want to move, including hidden files like the .htaccess file at the root of your installation. Move ’em all! Make sure you have enough disk space on your old server to create the tarfiles…they can get big, even with the compression. If all this talk of tar and command-line FTP makes you ill, you could of course just re-upload your wordpress files from your home computer using FTP or DreamWeaver or whatever you’re using. My cable modem upload speed is about 40K per second, versus the megabyte-per-second bandwidth when talking server-to-server.

Moving your WordPress Database

The database lives in MySQL, the database engine that stores all of the posts and comments in my blog. This isn’t stored as a regular file, so you have to use two command-line tools called mysqldump and mysql.

• If you’re using WP-CACHE, disable it before doing the following steps.

• Shut down your wordpress installation by renaming your wordpress directory or equivalent. You don’t want people hitting your database while you’re trying to dump out a copy of the data.

• Dump the database on oldserver.com into a file called wordpress.sql.gz with the mysqldump command. You can get the values of db_name db_host, db_user, and db_passwd out of your wordpress/wp-config.php file.
  mysqldump db_name -hdb_host -udb_user -pdb_passwd -Q --opt > wordpressdb.sql
gzip wordpressdb.sql

• FTP the wordpressdb.sql.gz file to newserver.com.

• On newserver.com, make sure that you have a database setup with a database user and password. Usually you can find some tool that will do it for you, like PHPMyAdmin or a control panel of some kind.

• There’s a good chance that the new server will have different db_name, db_user, db_host, etc values, so you’ll have to update your wp-config file to use the new values. Do this now!

• Assuming you’ve got the new database set up, it’s time to re-import the database. Using the values you just generated when creating the new database and database user, do the following on the new server:
  gunzip wordpressdb.sql.gz
mysql db_name -hdb_host -udb_user -pdb_passwd < wordpressdb.sql

• If you’re very lucky, everything will import cleanly, and you’ll get no errors. I got a couple, a “syntax error” that resulted because the MySQL 4.0.x installation on my old server didn’t emit quotes properly, as some tables used reserved keywords for their field names (adding the -Q option to mysqldump fixed that). The second error was due to the max_packet_size value being set too small by default on the (dv). It defaults to 1 megabyte, but is usually higher on shared servers. I had to modify the etc/my.cnf file and restart MySQL, which did the trick. You will need root access to edit the configuration file, so make sure you request it immediately when you buy your (dv). It took (mt) 3 days to respond to my request!!!

• You might have import problems too if you are downgrading from one version of MySQL to another, as I did the last time I moved. You might want to read the older post for some hints on how to use mysqldump to get around that.

• Ok, you’ve just moved a copy of your wordpress database to the new server! Unfortunately, you’ve got to do a little surgery on it now, because your new server doesn’t have a domain name yet. WordPress stores the domain name in your database, so you’ll have to use a database tool like PHPMyAdmin to edit the wp-options table, specifically the siteurl entry, to point to my temporary server address. In my case, it’s the numeric IP number of the new server, which is 64.13.223.31. The value of siteurl from my old site is https://davidseah.com/wordpress, so I need to change it to http://64.13.223.31/wordpress so I can test the site.

• At this point, I’m ready to test that WordPress has made it over. Visit http://64.13.223.31 in a web browser and cross your fingers. If you get a blank page, that might mean you have to update the WP Cache symbolic link in your wp-content directory (I always forget this). Check your PHP error logs to see what the problem is. You could be missing files from your transfer, or you might need to change permissions for certain folders. My old FutureQuest environment kicked ass, so I had to re-adjust to some of the restrictions in place on the new server.

• If everything pops up, yay! You now need to change another option in WordPress temporarily. Login as a wordpress administrator, go to OPTIONS->GENERAL and change the Blog Address to match the numeric IP.

• Also, go back and re-enable WP-Cache. You might have to do some additional configuration based on what it complains about.

• There’s an additional checklist I follow, which is available in part 1. I have just finished running through it, so now I’m ready for the last step.

Do the Nameserver Switch

I control my domain name via a third-party registry, so the last step is to tell the world that the new home of davidseah.com is Media Temple. Media Temple’s name servers are responsible for telling the world this now, so I update my domain registration to make them the “name servers of record.” Some notes:

• Some plugins, like ones that depend on the Flickr API, may not work until the domain name change switches over. At least I think that’s what’s going on.

• It takes 24-48 hours for the entire world to see the switch. In the meantime, email will probably be going to both servers, so be sure to use webmail to check both.

• After the new domain servers are stable, I’ll switch the WordPress SiteURL options from the numeric IP address back to davidseah.com.

Here goes nothing…see ya on the flip side!

<

p>Pulling the switch!!!

UPDATE: I have started writing a guide to configuring the (dv) Base for WordPress to optimize performance. They’re quite long, but if you’re having problems running out of memory this might be helpful to you.