Upgrade Drupal Core and Restore from Mysql Backup

For too long the admin pages in my http://drupal.org site have been bugging me to upgrade from 6.12 core to the latest, which recently for to 6.19. I have been putting it off after reading the upgrade.txt which describes how to do it as it sounding a little lengthy and I just never had the time to do it.

I tried once but it didn't work. I went 'more or less' through the process described in upgrade.txt, which accompanies the download, but after doing it the admin pages still said it was out of date, as if I hadn't done anything, which was odd as I had deleted almost everything and replaced it with the new version.

Anyway, I came back to it recently and decided to sort it out. I downloaded the latest core and followed the instructions to the letter. But once again, my admin pages still showed me at 6.12, as if I had just done nothing!

This was obviously a bit annoying as I had very carefully followed the documentation. So I put my problem out in the #drupal-support IRC room on irc.freenode.net and started getting some helpful hints to start tracking down the problem.

The very best bit of information I got was a suggestion to use drush. drush is a command line program that you run in a terminal on the web server, within the site root. It is a simple little program that can perform such functions as checking the current status of the site, check for updates of modules, install those modules, clear cache, run update.php etc. The beauty is the feedback it gives you, highlighting any problems with error messages to help track down problems.

The first problem I came across when trying to update all modules was a duplication error, where one 'piece of code' was conflicting with another of the same name. This was preventing modules from updating. So after tracking down and removing the duplicate files, all modules (except core) updated seamlessly.

Now every time I ran the command drush pm-update or drush up drupal to try and get the core module, drupal, to update from 6.12 to 6.19, it would run through the apparent process with successful messages, but then if I ran them again, it would keep saying it was at 6.12 and needed updating. So the update was failing.

Trouble was that drush wasn't reporting any error messages and even drush core-status would confusingly say it was at 6.19, but everything else said 6.12.

I tried to track down any duplications in my site's directory but there was nothing. So I finally decided to start afresh and wipe everything out and install 6.19 as new.

To ensure I would not loose all my site content, including nodes, images, modules, theme, functionality I needed to ensure I backed up everything I could possibly need.

I made a complete copy of my site's root directory, in this case /var/www/. I also made an up to date dump of the mysql database, very important as this is where everything is contained.

To make a backup of the mysql database:
mysqldump drupal > drupal_dump.sql

Obviously ensure you back up the right database. In this case my database was called 'drupal', but it could have been called anything. If you need to add certain user and password options, add -u username -p password after mysqldump. This will create a text file containing the whole database. I wasn't sure how I would use it yet, but I just knew backing it up was the thing to do if I stood any chance of putting all my data back into the new site.

Next was to make the bold move and empty var/www. I then dropped the database in mysql.

To drop a database, enter the mysql environment with 'mysql' with admin privileges, then simply enter the command DROP DATABASE drupal;. I then re-created the database so it was new and empty, but using the same name: CREATE DATABASE drupal;

I then, perhaps niavely, believe that I have to use a unique user for each mysql database I have so I issue the following command to grant privileges to my chosen user on the drupal database:
GRANT ALL PRIVILEGES ON drupal.* TO myuser@localhost IDENTIFIED BY 'password';

Next I downloaded and unpacked the latest drupal core:

cd /var/www/
wget http://ftp.drupal.org/files/projects/drupal-6.19.tar.gz
untar xvf drupal-6.19.tar.gz


I then went to my root page in a web browser and ran the standard install script to get a new, empty up to date drupal installation.

Next was to get all my existing data back into my site for the mysql backup to try and make it appear as if everything is just as it was before.

The key to getting all content and settings back is to write the mysql dump back into mysql into the newly created, albeit same named, drupal database. But before this will work, you have to put all the modules that were present in the installation when the mysqldump was performed back in place so that the database doesn't get confused thinking it has modules installed that are not present.

To find out which modules were installed I created a temporary database in mysql and wrote the backup into that just so I could examine it. To write a mysqdump into a new database:

mysql drupal_tempdb < drupal_dump.sql

I then wanted to view what modules were installed in this database backup. To do this I viewed what tables were in the database in the mysql environment:

USE drupal;
SELECT * FROM system WHERE TYPE = 'module';


This showed me all the entries in the system table containing the modules. I could then examine this list to see what modules were installed and also, importantly, which versions of each module. This is though where the backup of /var/www/ comes in handy, as all the modules that were installed are contained in here. So using the list in mysql, which also tells me the location of each module. So I just copied each module back from the backup into the right location in the new installation.

Once I was happy that I had replaced all the existing modules, I wrote my drupal database dump in to the new database and ran update.php............... and it was mostly back!

All my themes were back (after copying the theme dir from backup), all my nodes and views were working. There were just some files missing, such as uploaded images, but again copying these back in from the back up solved this.