Support

Documentation

Unorthodox: the emergency restoration procedure

[Warning]Warning

THIS IS NOT THE REGULAR RESTORATION PROCEDURE.

I will say it again.

THIS IS ****NOT**** HOW YOU ARE SUPPOSED TO RESTORE BACKUPS!!!!!

You must follow these instructions ONLY if the restoration script which is included inside the backup archive, under the installation directory (Akeeba Backup Installer) is not working on your host and you really, REALLY are in a BIG hurry to get your site up and running.

And I will say it once more.

THIS IS NOT HOW YOU ARE SUPPOSED TO RESTORE BACKUP ARCHIVES UNDER NORMAL CIRCUMSTANCES.

For normal restoration instructions, please take a look in our Quick Start Guide.

[Note]Note

These instructions are meant to be first read before disaster strikes. Therefore, a fair amount of humour has been used throughout. If you try to read it after disaster struck you will naturally find the humorous parts inappropriate, or even offensive. Rest assured that this is because you are under a huge amount of stress. As soon as you'll have finished following the instructions herein, you will be able to re-read this document with a light heart and enjoy the humorous puns as they were intended.

Inevitably, some people will end up with a backup file, a ruined site and a problem in the restoration procedure they can't work out. Almost always, the recipe includes a pressing deadline which requires that the site is on-line... yesterday. If you are in a situation like the one we just described, breathe. Do not panic. We've got you covered, with this concise manual site restoration guide. So, here it goes... it's manual Joomla! Site restoration In 7 steps or even less.

Step 1. Making sure it won't get worse.

Assuming such a situation, it's only human to be in panic and despair. Panic is a bad counsellor. It will give you wrong advice. Despair will only make you careless. So, people, get it together! Make a backup of the only thing separating you from complete disaster: the backup file. Burn it on a CD. Write it on your USB key. Put it on a couple of locations on your file server. Just make sure you'll have an extra copy in case you screw up.

This exercise has been proven to lower the probability of anything going wrong. Furthermore, it's good for your psychology. It gives you a sense of security you didn't have five minutes ago.

Step 2. Extracting the archive.

Now, we have to extract the archive somewhere on your local hard drive.

If the archive is of the JPA type, you'll have to use Akeeba eXtract Wizard, available without charge from our website.

If you have a ZIP package, there are a couple of gotchas. If you are working on a Linux machine, unzip will work just fine. If you're on Windows and under certain configuration circumstances on the server you took the backup on, you might not be able to extract it with WinZIP, WinRAR, 7-Zip or other archiver software. So you'll have to use Akeeba eXtract Wizard available for free from our website. This is a GUI utility which allows direct extraction of backup archives on your Windows™ PC. It is possible to run it under other operating systems, such as Mac OS X™ and Linux™, using DarWINE and WINE respectively. Please refer to the Akeeba eXtract Wizard documentation, available on-line on our site, for more information on using it.

Step 3. Editing your database backup.

Take a look at the directory where you extracted your backup archive. Inside it there is a directory named installation. Inside this, there is a subdirectory named sql. Inside this there is a file, site.sql (older versions: joomla.sql), containing your database data. COPY THIS TO ANOTHER LOCATION NOW! We'll have to edit it, so please, don't tamper with the original, will you?

Open the copy of site.sql (older versions: joomla.sql). Use a text editor (we recommend gedit and Kate on Linux™, Notepad++ on Windows™; do not use Wordpad or Word!). If you were ever familiar with SQL, you'll recognize that each line consists of a single SQL command. But they have a problem: table names are mangled. You'll see that tables are in a form similar to #__banner instead of jos_banner. Ah, nice! We'll have to fix that.

Using your text editors Replace command, do the following changes:

  • search for CREATE TABLE `#__ replace with CREATE TABLE `jos_

  • search for DROP TABLE IF EXISTS `#__ replace with DROP TABLE IF EXISTS `jos_

  • search for INSERT INTO `#__ replace with INSERT INTO `jos_

  • search for CREATE VIEW `#__ replace with CREATE VIEW `jos_

  • search for CREATE PROCEDURE `#__ replace with CREATE PROCEDURE `jos_

  • search for CREATE FUNCTION `#__ replace with CREATE FUNCTION `jos_

  • search for CREATE TRIGGER `#__ replace with CREATE TRIGGER `jos_

The idea is to replace all instances of #__ (note that there are two underscores after the hash sign) with jos_ in the SQL command part (not the data part). DO NOT PERFORM A BLIND SEARCH AND REPLACE OF #__ WITH jos_ AS IT WILL CAUSE SEVERE PROBLEMS WITH SOME COMPONENTS. Easy, wasn't it? NOW SAVE THAT FILE!

Step 4. Restoring the database.

In order to restore the database on the server you'll have to use some appropriate tool. For small to moderately sized database dumps (up to 2Mb), we find that phpMyAdmin does the trick pretty well, plus it's installed on virtually all PHP enabled commercial hosts. For larger dumps, we found that bigdump.php from Alexey Ozerov works wonders. Another useful and very easy (or, should I say, easier) to use tool which also works with PostgreSQL and Microsoft SQL Server is Adminer. Use either of those tools - or any other of your liking - to restore your database.

Step 5. Upload your site's files.

First of all, delete the installation subdirectory from the directory you extracted the backup archive to. We won't be needing this any more. Then, using FTP - or any method you please - upload all of the files to the target server.

If you want to be thorough remember to set the directory and file permissions accordingly. If you just want to get the damn thing on-line ASAP, just skip this permissions thing; it will remind you of itself as soon as you try to do some website administration (like uploading a picture) after the site's back on-line.

Step 6. Edit configuration.php, if necessary.

If you were restoring to the same server location you took the backup on, nothing else is necessary. Your site should be back on-line now. If not, you'll have to edit the configuration.php.

You have Joomla! 1.5.x. Good news! Joomla! 1.5.x doesn't require you to specify some of the hard-to-obtain parameters. Your configuration.php consists of several lines. Each one is in the following form:

var $key = "value";

The key is the name of the configuration variable and value (inside double quotes!) is the value of the variable. Below we provide a list of the configuration variables which have to be modified to get up on-line.

dbtype

is the database driver Joomla! will use. It can be mysql, mysqli (notice the extra i in the end), postgresql, sqlsrv or sqlazure. This depends on the kind of database you are using. If unsure, your best bet is mysqli.

host

is the database host name, usually localhost

user

is the database user name, assigned from your host company

password

is - obviously - the database password, assigned from your host company

db

is the database's name, assigned from your host company

dbprefix

is the database prefix; if you followed our instructions, it is jos_

live_site

Normally this is an empty string. If, however, your Joomla! site's front page looks as if all images and CSS files are not loading, you have to modify it and enter your site's base URL. For example, if the new site is located in http://www.example.com/mysite/, you have to locate the line starting with var $live_site and change it to become:

var $live_site = "http://www.example.com/mysite";

That's all! You're good to go.

Step 7. Enjoy success.

Your mission is accomplished. You are exhausted. Go drink whatever is your favourite drink and enjoy sweet success!