26.2. How to restore PHP-Nuke from backup
We have already seen that PHP-Nuke offers a built-in database backup function in the administration panel (Figure 26-2). phpMyAdmin (Section 3.3) also offers a very good web interface to database backups and you can even use home-made scripts that automate the backup work for you (see Section 27.16). However, we have not yet covered the procedures necessary to restore a backup made with the above procedures.
PHP-Nuke can bee seen as a structure comprising two general elements, the files and the database. The pulsing heart of our dynamic CMS is the database. It is actually there where the we save all usernames, articles, statistics and all the rest. In the files, on the other hand, we have the commands that are necessary for a functioning connection to the database, the fetching and processing of the data and finally their saving back to the database again.
Although the database is experiencing constant modifications (UPDATEs) - practically every time some user is vieweing some page - the files themselves are subject to much slower change, most of the time due to necessary interventions of the administrator. If, for example, we have PHP-Nuke 6.8 installed, then the possible modifications to our installation include:
Installation of a new theme we programmed ourselves, or modification of an existing theme.
Installation of patches that correct errors.
Installation of new modules or of modification of existisng modules in order to get a more personalized site.
As you can see, if we were to lose our PHP-Nuke files, a recuperation would not be something impossible, although painful and annoying. On the other hand, it would be really impossible to recuperate our database data, if lost, due to the fact that they may change automatically, independently of the administrator's will. For example, the update of the statistics, a user's post in the forums, or a user registration, are all events that happen independently of the administrator's will and they all find their way to the database.
Hopefully, the above observations have convinced you of the necessity of database backups. We recommend you to:
Make a backup of your PHP-Nuke at least every time you make a change to them (although a regular backup every N days would be even better).
Make a database backup as often as possible. The backup frequency should be directly proportional to the number of visits that your site attracts per day: the more visits per day , the more new data is stored in our database each day. Also in this case, a regular backup is the recommended way.
 | Don't trust your ISP on making backups of your data! |
|---|---|
Do not, under any circumstances, indulge to the comforting thought that your ISP is doing database backups for you, even if he talks in his marketing brochures about "security", "crash protection" or even "backups"! If you read the Standard Terms and Conditions of your ISP carefully, you will almost certainly discover that he does not assume any responsibility for data loss, unless it was the result of gross negligence (a rare condition that you will have to prove in a court). Even if your ISP does do backups, and runs big ads declaring so, this does not mean that he does them for you! You might discover that you have to pay an “market fair” hourly rate for the ISP's operator's work, if you ask his help on restoring that lost table of yours... Thus, you'd better not rely on your ISP when it comes to backups. Do your homework and you will not regret it. |
Restoring a backup is very simple. All you need to do is delete all tables contained in the PHP-Nuke database and insert the emergecy versions in their place. You can do this through the function “SQL query” of phpMyAdmin (see Section 3.4.2). Enter the full name of the backup file in the field for “textfile” in Figure 26-3, or select “Browse” and then search for it in the dialog that follows.
However, it is important that we are aware of some exceptions or particular cases that may yield themselves the above restore procedure:
How to restore a single table (see Section 26.2.1).
How to restore a large backup (see Section 26.2.2).
We will talk about these cases in the following subsections.
26.2.1. How to restore a single table
Suppose we only need to restore the nuke_users table, leaving all other tables untouched. For this we use phpMyAdmin (Section 3.3) to selectively delete the nuke_users table. We then open our backup file with a decent text editor (see Chapter 11) and copy from it only those parts that are relevant to the
structure and
data
of the nuke_users table. The structure part is normally preceded by a three-line comment like:
# # Table structure for table `nuke_users` # |
The data part, on the other hand, is preceded by a three-line comment like:
# # Dumping data for table `nuke_users` # |
All in all, our structure and data parts for the nuke_users table will look like the following:
# # Table structure for table `nuke_users` # CREATE TABLE nuke_users ( user_id int(11) NOT NULL auto_increment, name varchar(60) NOT NULL default ", username varchar(25) NOT NULL default ", user_email varchar(255) NOT NULL default ", femail varchar(255) NOT NULL default ", ...many other fields of nuke_users follow here # # Dumping data for table `nuke_users` # INSERT INTO nuke_users VALUES (1, ", 'Anonymous', ", ", ", 'blank.gif', 'Nov 10, 2000', ",", ", ", ", 0, 0, ", ", ", ", 10, ", 0, 0, 0, ", 0, ", ", 4096, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 10,NULL, 'english', 'D M d, Y g:i a', 0, 0, 0, NULL, 1, 1, 1, 1, 1, 1, 1, 1, 0, 3, NULL, NULL, NULL); ...many other user data follow here |
In the above example, only a small part of the structure of the nuke_users table is shown for brevity. You will also most probably have more than one user, so that the data part will also be much bigger (we only show the user data for user “Anonymous”).
We can get a partial restore of the single nuke_users table in three ways:
We copy and paste the relevant structure and data parts from our backup file into a separate file that we will call partial_backup.sql. Then we use phpMyAdmin's “SQL query” function (see Section 3.4.2) to import the partial_backup.sql file, just as we do with any other file containing SQL queries. We enter the full path to partial_backup.sql in the “textfile” field of Figure 26-3 and click on “Go”.
We copy and paste the relevant structure and data parts from our backup file into the text area field above the “Browse” button, then click on “Go”.
We don't use phpMyAdmin but use the shell command line instead. From the shell promt, we type:
mysql -h dbhost -u dbuname -p dbname < partial_backup.sql
where dbhost, dbuname and dbname are exactly the same as in your config.php file(Section 3.7).
26.2.2. How to restore a large backup
If your backup file is really large (a few megabytes are enough), PHP will not be able to import it in the usual CPU time limit of 30 sec. that is set by most ISPs. The result will be an error and a corrupted or incomplete table. In this case you can proceed as follows:
If you have access to the shell promt, login to your server with SSH and type the following on the shell prompt:
mysql -h dbhost -u dbuname -p dbname < partial_backup.sql
where dbhost, dbuname and dbname are exactly the same as in your config.php file(Section 3.7).
If you don't have shell access, you can use an interface like MysqlFront (see Section 28.6):
| The PHP CPU time limit may hit you in backups too! |
|---|---|
Just as PHP may time out on a restore, it may timeout on a backup as well!. You are then left with the command line option , or some script solution along the lines of Section 27.16, modified so that it only makes a backup of a piece of your data each time. |