My main concern regarding the running of a MySQL database driven website is that servers to die, and having a backup is essential. However, without an automated backup solution, you are likely to find that when you most need it, your backup is old.

Fortunately a plugin has been written for WordPress which not only allows you to manually backup your database from your site control panel, but also allows you to set up an automated backup that is emailed to a destination of choice. So you could if you desired, back up your database to a gmail account, where it should be safer than a home pc or the same web server that your website is hosted on.

I am still testing WP-DBManager 2.30 now, but have set it to automatically backup my database every 12 hours, then GZip it and email to myself. The auto backup can be set in minutes, hours, days, weeks or months, so depending on how active your site is there should be a backup solution for you. Hopefully testing will prove positive.

In addition to backing up the WordPress MySQL database, WP-DBManager 2.30 also allows you to restore a database, manage existing backups, run SQL queries, repair the database and drop or empty tables. Emptying a table could be useful if you find that you suddenly have thousands of unwanted spam messages. Just empty the whole comments table, and the message will all go. Drastic, but if you have a backup, you could then just import the comments, rather than importing the entire database.

Finally WP-DBManager 2.30 has the function to optimise the database to ensure smooth running and fast responses.

If I find any problems with this plugin I will report it here, but so far it looks like a very useful plugin for any WordPress bloggers.

If you have used the Backup module on Drupal to backup up your site, then inside to the tar.gz file which contains all the web files, there will also be a slq.gz file which is a compressed version of your database.

One way to import this is using phpmyadmin. Simple go to the database you have created, and chose import, speificy the file, and hit “go”. However, there are often problems with phpmyadmin when importing larger files, i.e. it fails. If the import is successful, then it should report something like:

Import has been successfully finished, 630 queries executed.

However it has been known that for some larger files for php to fail. One thing that is often required is to increase the maximum upload file size in the php.ini configuration file. I have set my php upload file size to 26Mb, which is currently enough still; the last database that I uploaded using phpmyadmin was less than 2Mb. However, some popular, older site can have very large databases. For these, it may be better to use the mysql command line to import. I will go further into that later, once I have mastered the process myself.

For now, assuming that you have successfully inported the Drupal database using phpmyadmin, you should now have a copy of your Drupal installation. With this. you can install new modules, test, play, and upgrade, all without risk to harming your live version.

The main reason that I set out to make a copy of my Drupal installation was to then upgrade it, and check everything is working. There have been security warnings regarding older version of Drupal (5.2 is prone to MySQL attacks) and therefore I want to upgrade to 5.7. However, I did this for a new site (I actually built it using an old 5.2 download, then upgraded) but the forums failed to work afterwards. Something to do with MySQL settings / tables. I cannot afford my forums to die on my main Drupal site, so therefore, I need to practice too.

In the meantime, it is nice to know that I have a method to totally renew my Drupal installation incase of hackers bringing the site down. Sometimes once a hacker has got their hands on you database it is not easy, or even impossible, to fix. Often the only option is to drop the database and rebuild from backup., so ensure no other rogue code is hiding, causing havoc.

Today I set up MySQL and managed to transfer a Pligg CMS over from my paid hosting to my home server. Had a few problems to start with, as I was trying to use phpmyadmin (also installed today) to import the .sql file, but this was resulting in errors. I attempting to increase the max timeout, upload file size and some other parameters, but it kept failing. However, a quick call to my pal over Skype got me sorted out. He actually logged on to my server over SSH to take control, and taught me along the way how to do it all from the command line.

He got into the Mysql prompt with:

mysql -u user -p

and then used this to import the database:

mysql -u user -p database < database.sql

I had already copied the exported the database from my paid hosting account using phpmyadmin, and created the .sql file. So the above commands simply allow a use to enter the mysql prompt (password for the relevant database is required) and then imports the .sql file into the database. Worked a treat. Once again, like I mentioned before about installing applications, this process was much quicker with the terminal than using the browser / php tools. In fact, when trying to back up a database using phpmyadmin I would often find that it seems to crash the browser – maybe it runs out of memory, not sure, but I now know the correct way to do it.

I also backup up my .sql database tonight with this command:

mysqldump -u user -p database > databasebackup

Again the -p means that the password is requested before the command is completed. Next step is to work out how to restore a database in the command prompt. That can wait until later though.

I seem to have one problem at the moment that requires fixing. On installing the CMS application on my home server, I did get an error message. It was something about the f_name I think. I notice now that I cannot configure the CMS, although I can post articles and comments etc. So that needs to be looked at. There are a few things not working on my server, but nothing major yet!