I recently moved my most complicated Drupal site (a Bulgarian dialectology project with six inter-connected content types and thousands of nodes) from Bluehost to a dedicated Ubuntu 10.04 server; some of the views were exhausting the memory provided by a shared commercial hosting setup. The process reminded me that a skilled, patient sysadmin is worth their weight in antimatter ("gold" would be a serious undervaluation), but in stumbling through it on my own I discovered a few tricks that might save someone else the same frustration.
Some of these are downright embarrassing if you know much at all about Linux servers, but I'm setting aside pride for the moment because I'm sure I'm not the only intrepid but clueless humanist who's Googled themselves into these stupid situations.
Lesson 1: Be careful with scp when moving over whole multisite installs
Since I was 9, I've been using (S)FTP to move files around. The speed of my current wireless setup over the holidays was proving a serious bottleneck to migrating the filesystem from one server to another. So I decided to try the smarter, but unfamiliar, approach of using scp.
So, on my Bluehost account (where I learned how to setup a multisite install) I tried something like this:
scp -rpC public_html/* [new server login name]@[new server]:/var/www/drupal
It worked! But it was taking forever. Four hours later, I grew suspicious and tried to review the text that was quickly scrolling through my terminal window. Buried in all those successful transfers was a warning about "too many symlinks". Indeed, what the system had been doing for those four hours was following my first symlink, and looping back through itself to copy the same files again, nested one level down, until it encountered the symlink again, and once again looped back through itself.
Solution: use rsync instead, or scp over everything except the symlinks in your main folder.
Lesson 2: How to move your database over
This site had a rather large database, and the easy phpMyAdmin export feature I'm accustomed to doesn't work for databases over 50 MB on Bluehost (I discovered after a few failed attempts). It only exports the first few tables. Doing it via the command line works, though.
- On your new server, use your favorite method to create an empty database. Remember: if you give it a different name than the database name in your old hosting setup, and/or if you have a different user for the database, and/or if you're switching from some other host to localhost (e.g. Dreamhost-hosted Drupal sites don't use localhost) you'll have to update the settings.php for your site accordingly.
- On your old server:
mysqldump -u [username] -p [old site database name] > dbname.sql
- On your old server:
scp dbname.sql [new server login name]@[new server]:/home/[new server login name]; you can also put it somewhere else, but I figured my home directory would be convenient
- On your new server: if you're in the same directory where you put your database dump,
mysql -p -u [MySQL login name] [new database name] < dbname.sql
Lesson 3: What to do when only the front page works and you get 404 Not Found errors for anything else
My joy at seeing the front page looking good dissipated when none of the links worked, giving me a 404 Not Found for every single one. Unsurprisingly, going from a shared hosting cPanel setup to a dedicated server meant having to fiddle with settings.php. Maybe a bit more surprising, I also needed to make some changes to an Apache configuration file.
Solution: When all your files are in a directory like /var/www/drupal instead of a public_html directory in a shared hosting setup, edit the
$base_url line of settings.php to
$base_url = 'http://[new site]/drupal';.
If things still aren't working, it's time to poke around in your Apache config file. This tutorial put me on the right path, but it's written for Fedora, and Ubuntu keeps its config files elsewhere. Try
cd /etc/apache2/sites-available and then type
ls. You should see a file called default. Type
sudo nano default. Towards the top of what shows up will be this section:
<Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory>
Change those two AllowOverride None to AllowOverride All, type Ctrl + X, and save your changes.
Then restart Apache by typing
sudo /etc/init.d/apache2 restart.
Lesson 4: When modules misbehave (or, the WSOD)
Having fixed those 404 Not Found errors, I was able to view non-access-restricted pages (of which the site has precious few), but I was getting the dreaded Drupal White Screen of Death (WSOD) on the login page. I tried some of the things on this WSOD page, to no avail. I tried emptying all my tables and reimporting the database dump from the old site. I tried deleting and recreating the database, then reimporting the database dump. I tried making a new database dump and importing that. Nothing.
Then I got to thinking about an error message I'd seen sporadically on those few pages that I was able to access: warning: Parameter 2 to automenu_node_automenuapi() expected to be a reference, value given in /var/www/drupal/includes/module.inc on line 461. Lacking any better ideas, I logged into the version of the site still up and running on the old server, disabled the AutoMenu module, did a new database dump and imported it onto the new server.
Presto! Thinking maybe the trouble was just with the site migration, I logged into the site hosted on the new server and re-enabled the module. Bad move-- WSOD on the modules page that clearing the cache couldn't fix. It's not a critical module for the site, and perhaps updating the module and/or Drupal core will address the problem, so I just re-imported the database dump (with the disabled AutoMenu) and everything worked again.
Solution: Any number of things cause the WSOD. I had one site where, after a server migration, everything worked fine... except I got the WSOD on the path for a page display for one important View. Changing the page's path made it show up fine, deleting the view entirely and re-creating it anew with a page with that same problematic path name still gave the WSOD. No amount of cache clearing fixed it. I ultimately decided to keep it on the old hosting setup, where I had SSH access and, more importantly, everything worked fine.
That said, if you see any sort of error message-- however cryptic-- it might be a valuable clue.
Lesson 5: When you can't connect to your database (or, another cause of the WSOD)
While working on migrating a different site (Drupal 7) over to a new server, I'd followed all the usual procedures (copy filesystem, create database on server, import database dump, change settings.php and, in Drupal 7, dbconfig.php with information for new database) but kept getting the WSOD when I went to the site. Since the favicon was't even showing up, I suspected that something had gone wrong with the connection to the database.
Solution: I deleted the settings.php and dbconfig.php that I'd brought over from the old server, downloaded and unzipped a fresh Drupal filesystem on my local machine, and uploaded a fresh settings.php from a default.settings.php in the fresh Drupal filesystem. I dropped all the tables I'd imported, and used that same database to go through the standard Drupal installation process, and got a brand new Drupal installation up and running on the server. I then went into PHPMyAdmin and dropped all the tables that had been created as part of the site installation, and re-imported the database dump from the old server. When I went back to the site, Drupal was still able to connect to its database, which now contained everything I wanted.