Difference between revisions of "Backup" From Online Manual

Jump to: navigation, search
(→‎Restoring your forum files: Add General Notes on file restore)
 
(30 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
{{TOCright}}
 
{{TOCright}}
Whatever anybody else might tell you, backing-up is the most important thing you can ever do with SMF or any website. If something goes wrong, yes, you may well be able to fix it. If you can not, maybe somebody else can. But what happens if nobody CAN help you? Databases, especially, can extremely difficult to repair.
+
It is essential to back up your forum. If your database gets corrupted you will lose everything. Having a backup means that you have a previous version of your database to fall back on should your forum be hacked, or should you make changes to it which you subsequently wish to revert.
  
Bye-bye forum. Bye-bye members. Bye-bye posts.
+
SMF's Admin section has a built-in database backup function. '''Do not use it'''!  It does work in some cases, but not in others, so it should not be used, unless you have no other way to acquire the backup of the database.
  
Now, you REALLY do not want that to happen, do you? Of course not. So, what to do?
+
==Backing up your Database==
 +
When you bought your domain, your host will have given you details on how to access your site's cPanel®, or something similar. You can access this to back up your database.  Alternatively, you can also back up your database using ''phpMyAdmin''.
  
You may have noticed that there's a facility in SMF's "Forum Maintenance" section, to backup your database. Sadly, it's not terribly good. So, we'll ignore that. Also, though, what about your actual site? What about restoring the backups?
+
===Backing up your Database with cPanel®===
 +
#Look for the section labelled "Files" and click on "Backups".
 +
#On the new page that opens, you will see "Download a MySQL Database Backup".
 +
#Under that, click on the name of your database and a requester will open, which will allow you to choose where that backup will be downloaded to.
  
Firstly, let's deal with the database.
+
===Backing up your Database with phpMyAdmin===
==Backing up your database==
+
Again, you will need to access your site's cPanel.
When you bought your domain, your host will have given you details on how to access your site's cPanel®, or something similar.
 
<br>There, you'll be able to access something called "phpmyadmin".
 
<br>Now, of course, different hosts will have different ways of accessing that. For the sake of this article, I'm going to give the means of accessing it via cPanel. Other hosts may be different. But, they'll be pretty similar.
 
  
===Backing up your database with cPanel®===
+
#Look for the section labelled "Databases".
 +
#Under that heading, you will find "phpMyAdmin".
 +
#Click on this, and then follow the steps below. '''Warning: Do not click on any options other than those outlined below, unless you really know what you are doing!'''
 +
#Look at the left-hand pane and you will see the name(s) of your databases.
 +
#Click on one of them and you will see some tabs along the top.
 +
#Click ''Export''.
 +
#On the next page, find "View dump (schema) of database", and you will see "Export".
 +
#Just below that, click "Select all".
 +
#At the bottom of the page, ensure that "Save as file" is checked.
 +
#Finally, click "Go".
 +
 
 +
===General Notes===
 +
Once you have your backup, you should verify whether it works. The best way is to restore it to a second '''empty''' database. '''This is an important step'''. If for any reason the backup fails you can repeat the procedure immediately to ensure that have a working database in case you need it. If after repeating the procedure you still are not able to obtain a working backup, please contact your host in order to identify and solve the problem causing the backup to fail.
  
#Firstly, look for the section labelled "Files" and click on (You guessed it) "Backups".
+
If you cannot restore the database, you should verify that the ''.sql'' file you have obtained has proper SQL syntax and commands inside it (to <code>CREATE</code> your '''tables''' and <code>INSERT</code> data into them, it may also <code>DROP</code> old tables before creating new ones). Make sure it it ''looks complete'' (<code>CREATE</code> and <code>INSERT</code> for all your SMF tables), before assuming that it is a good backup. Spot check a few tables to see if all their data is in the backup (note that the order of records may differ between the database "browse" display and what is in the backup file).  
#In the new page that opens, you'll see "Download a MySQL Database Backup".
 
#Under that, click on the name of your database and a requester will open, so that you can choose where that backup should be downloaded to.
 
  
It really is as simple as that!
+
If you used phpMyAdmin it may end with:
<br>So, there really is no excuse for not backing up, OK?
+
<code>/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;
 +
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;
 +
/*!40101 SET [email protected]_COLLATION_CONNECTION */;</code>
  
The second way, is to use phpMyAdmin.
+
Save a copy of the backup some place safe. Your web host server '''is not''' a safe place.
  
===Backing up your database with phpMyAdmin===
+
You do not have to go over your backup with a fine-toothed comb ''every'' time, but you should do so the first time, whenever you make a change to your backup method, and just once in a while.
Again, you'll need your site's cPanel.
 
  
#Look for the section labeled "Databases".
+
==Restoring your database==
#Under that heading, you'll find "phpMyAdmin".
+
 
#If you click that, you'll see a page that might, at first, seem somewhat scary.
+
===Restoring your Database with phpMyAdmin===
#It IS. Be careful what you do, there, because you can SERIOUSLY break things.
+
To restore your backed-up database, you do exactly the same as to back up, except that instead of clicking "Export", you click "Import". You then navigate to your backup file by clicking  "Choose" under "Location of the text file".
#Look at the left-hand pane and you'll see the name(s) of your databases.
 
#Click on one of them and you'll taken to another scary page.
 
#On there, you'll see some tabs, along the top. The one you want is labeled "Export".
 
#When you click on that, you'll get yet another page.
 
#Under "View dump (schema) of database", you'll see "Export".
 
#Just below that, click "Select all".
 
#At the bottom of the page, ensure that "Save as file" is checked.
 
#Then, click "Go".
 
  
The rest, I think you'll be familiar with.
+
Please be aware that if you have large databases, it may be not possible to back up using phpMyAdmin, as phpMyAdmin has some file size limits.
  
 
===General Notes===
 
===General Notes===
#SMF's Admin section has a built-in database backup function. It is broken, so '''do not use it'''. It will work in ''some'' cases, but don't count on it. Try to avoid using it unless you're desperate and have no other means of backing up your database.
+
SMF does not include any utility for reloading (restoring) the database.
#Most hosts have some sort of process time limit, that may prevent any backup utility from running to completion. Always check (at least, periodically), that you're getting complete backups. If it's timing out, talk to your host about how to suspend this limit, or investigate utilities that do the backup job in small chunks rather than all at once.
 
#You should end up with an .sql file (possibly compressed, zipped, or gzipped). It should have commands inside it to CREATE your TABLEs and INSERT data into them (it may also DROP old tables before creating new ones). Make sure it has both, and looks complete (CREATE and INSERT for all your SMF tables), before assuming that it's a good backup. Spot check a few tables to see if all their data is in the backup (note that the order of records may differ between the database "browse" display and what's in the backup file.
 
#There are so many tragic tales of site owners who needed to restore a backup and then found it was no good (even their host's server backups were no good). Once you have your first backup, try restoring it to a second, ''scratch'' database to see if it's good. You want to learn how to do it ''ahead of time'' so you won't be in a panic when the real need arises.
 
#Save a copy of the backup someplace safe, other than on your web host server.
 
#You don't have to go over your backup with a fine-toothed comb ''every'' time, but you should do so the first time, whenever you make a change to your backup method, and just once in a while (for good measure).
 
  
==Restoring your database==
+
Learn how to do a database restore ''ahead of time'', and practice it at least once with a ''scratch'' copy of the database.
 +
 
 +
Know how to browse through the original and restored databases in phpMyAdmin to check that everything is there (all records in all tables). Note that there is no guarantee that records will appear in the same order in the original database, the backup, and the new database.
 +
 
 +
Some hosts have process time limits that may prevent you from running your restore via phpMyAdmin to completion. Your host may be able to tell you how to suspend or increase the process time limit. There are utilities out there to split up the restore task into smaller pieces, so that you will not exceed time limits.
  
===Restoring your database with phpMyAdmin===
+
Depending on your host's configuration, MySQL default collation may differ from the one you need. Be sure to change the newly-created database to the appropriate collation, for example, UTF-8, before starting an import (restore).
To restore your backed-up database, you do exactly the same as to backup, except that instead of clicking "Export", you need the "Import" tab and you navigate to your backup file, by clicking on "Choose", under "Location of the text file".
 
  
Please, be aware, though, that if you have large databases, it may be not possible to backup using phpMyAdmin, as phpMyAdmin has some file size limits.
+
phpMyAdmin needs to be told the type of encoding the .sql file(s) uses when you do the import. If your backup is, for example, UTF-8, you need to tell phpMyAdmin that, or it will assume the file is Latin-1 and will translate all the text from Latin-1 to whatever encoding your new database is in. This will make an horrendous mess of your database.
  
===General Notes===
+
If you need to rerun part of an import, be careful not to import the same data twice. If you are lucky, the process will die with a duplicate key error. This is why it is generally a good idea to '''drop''' and '''create''' the tables so that they are guaranteed to be empty at the start.
#SMF does not include any utility for reloading (restoring) the database, though it probably should.
 
#Learn how to do a database restore ''ahead of time'', and practice it at least once (with a ''scratch'' copy of the database), so you won't be in a blind panic when you have to do it for real.
 
#Know how to browse through the original and restored databases (in phpMyAdmin) to eyeball them and get a comfortable feeling that everything is there (all records in all tables). Note that there is no guarantee that records will appear in the same order in the original database, the backup, and the new database.
 
#Some hosts have process time limits that may prevent you from running your restore (via phpMyAdmin) to completion. Not to panic. You may be able to find out from your host how to suspend or increase the process time limit. There are utilities out there to split up the restore (import) task into smaller pieces so you won't exceed time limits. Worst case, you can use an ordinary text editor (''not'' a word processor) to split up the .sql file into smaller pieces, and import them separately. Do the DROP TABLE/CREATE TABLE commands first in one .sql file, and then do maybe 500 or 1000 complete INSERT commands at a time in additional imported .sql files.
 
#MySQL defaults to Latin-1 (ISO-8859-1) encoding with "Swedish" collation (for sorting purposes). Why Swedish? MySQL was originally developed in Sweden. Anyway, if your database is not going to be the default Latin-1 encoding, be sure to change the newly-created database to the appropriate encoding (e.g., UTF-8) before starting an import (restore). The encoding is critical; the collation typically doesn't matter all that much.
 
#phpMyAdmin needs to be told what '''encoding''' the .sql file(s) are in when you do the import. If your backup is, say, UTF-8, you need to tell phpMyAdmin that, or it will assume the file is Latin-1 and will translate all the text from Latin-1 to whatever encoding your new database is in (say, UTF-8). This will make a horrendous mess of your database.
 
#Especially if you need to rerun part of an import, be careful not to import the same data twice. If you're lucky, the process will die with a duplicate key error. This is why it's generally good to DROP and CREATE the tables so that they're guaranteed empty at the start.
 
  
 
==Backing up your forum files==
 
==Backing up your forum files==
 +
There are two common ways of doing this:
 +
 +
You can open your FTP client and use it to download everything to your hard disk, or you can use your site's cPanel (or whatever your host uses).
 +
 +
#Go to cPanel, look for the section labelled "Files" and click "Backups".
 +
#In the new page that opens, you will see "Download a Home Directory Backup".
 +
#Just below that, click the "Home Directory" button.
 +
#You will get a requester which allows you to choose where the backup is saved.
 +
 +
This will save your whole site, so this can be a long process, especially if you have a lot of files on your site.
 +
 +
===General Notes===
 +
Your control panel may have an option to pack and compress all of your files into one file (.tar.gz; .tgz; .zip,). Consider using this, as it can greatly reduce file transfer time and leave you with only one large file to worry about.
  
There are two common ways of doing this.
+
The larger the file, the greater the risk corrupted data, such as transmission errors, will be present. If your site contains a lot of attachments this, therefore, may not be the best choice. If you are only going to keep the file for backup, rather than to work with its individual files on your PC, this can be a good choice. If you plan to look at or edit files on your PC, however, you may want to transfer them as individual files.
  
Firstly, you can open your FTP client and use it to download everything to your hard disk.
+
Most FTP clients can transfer an arbitrary collection of files and directories in one operation, such as the entire site at once. There is no need to transfer one file at a time. Some control panel file managers can do this too.
  
The other way is to use your site's cPanel (Or whatever your host uses).
+
For very large databases compression (.zip) may be wise, clearing all logs prior to backing-up, as well as splitting up the tables you are saving to file. When you are opting tables within phpmyadmin it is possible to highlight specific ones for each file. For example, the messages table is usually the largest, therefore, you can create two compressed database files where one contains the messages table and the other contains all remaining tables. When restoring these tables simply import the multiple files one at a time to the same database.
  
#Go to cPanel, look for the section labeled "Files" and click on "Backups".
+
If you do not know how to use an FTP client, please see [[FTP_-_How_do_I_use_FTP]] for further information.
#In the new page that opens, you'll see "Download a Home Directory Backup".
 
#Just below that, click on the "Home Directory" button.
 
#You'll get a requester, so that you can choose where the backup's saved to and you're away!
 
  
This will save your whole site. So, be aware, of course, that this can take a LONG time to do, especially if you have a lot of files on your site.
+
As with the database backup, do a test restore the first time you back up, and once in a while after that.
  
===General Notes===
+
Store a copy of your backup somewhere other than your hosting server. This is because even backups offered by your host may prove unreliable.
#Your control panel may have an option to pack (and compress) all your files into one file (.tar.Z, .tgz, .zip, etc.). Consider using this, as it can greatly reduce file transfer time and leave you with only one (large) file to worry about. If you're only going to hold on to the file for backup, and not work with its individual files on your PC, this can be a good choice. On the other hand, if you plan to look at or edit files on your PC, you may want to transfer them as individual files.
 
#Most FTP clients can transfer an arbitrary collection of files and directories (folders) in one operation (such as the entire site at once). There is no need to transfer one file at a time. Some control panel File Managers can do this too, but some can only handle one file at a time, and some can only ''up''load files.
 
#Be aware that the FileZilla FTP program and SMF each have a very stupid design decision that leads to corrupted data. SMF chooses to store all of its '''attachments''' and '''avatars''' with hashed names and ''no extension (filetype)''.  It should have put .doc or some other arbitrary "binary" extension on the files. FileZilla decided that any file without an extension should be transferred as text ("ASCII" mode) when in "automatic mode selection". The result is that any image or attached binary document ''will'' be corrupted if you bulk transfer in FileZilla with "automatic" mode selection. Always force '''binary''' mode. The only downside will be that you will need a "real" editor (Notepad++, ViM, etc.) to browse or edit your files on your PC, if your server is Linux (i.e., the files will be in Linux file format, which Notepad etc. can't handle).
 
#As with the database backup, do a test restore the first time you back up, and once in a while after that. You want to know that you're doing it right and can do a restore when (not if) it comes time to do it for real.
 
#Store a copy of your backup somewhere other than your hosting server. Even the best hosts have been known to discover that their own server backups are no good!
 
  
 
==Restoring your forum files==
 
==Restoring your forum files==
 +
This can be done by using FTP to transfer the backed-up files from your hard disk to your site or by going to the same place in your site's cPanel (or whatever your host uses) that you use to back up.
  
Again, this can be done by using FTP to transfer the backed-up files from your hard disk to your site.
+
#Go to cPanel, look for the section labelled "Files" and click "Backups".
 +
#In the new page that opens, you will see "Restore a Home Directory Backup".
 +
#Click "Choose" to navigate to your backup, then "Upload" to start the restoration.
  
The other way is to go to the same place in your site's cPanel (Or whatever your host uses) that you use to backup.
+
===General Notes===
 +
As with database backup, practice in advance how to do a file restore to a scratch copy of the site on your server.
  
#Go to cPanel, look for the section labeled "Files" and click on "Backups".
+
Be careful if using FileZilla to transfer with automatic mode selection. It will corrupt all attachment and avatar images unless you specify '''binary''' mode, [[FTP_-_How_do_I_use_FTP#What_FTP_clients_are_available.3F|read this note for more details]].
#In the new page that opens, you'll see "Restore a Home Directory Backup". Click "Choose" to navigate to your backup, then "Upload" to start the restoration.
 
  
===General Notes===
+
Spot check your restored files, especially attachments and avatars, to ensure that they have survived, especially if you use [[FTP_-_How_do_I_use_FTP#What_FTP_clients_are_available.3F|FileZilla]].
#As with database backup, practice in advance how to do a file restore (to a scratch copy of the site on your server). A panic situation is not a good time to be learning such things.
+
 
#Be careful if using FileZilla to bulk transfer with automatic mode selection. It will corrupt all attachment and avatar images unless you specify '''binary''' mode both ways.
+
[[Category:Installing and Upgrading]]
#Spot check your restored files, especially attachments and avatars, that they survived the round trip, especially if you use FileZilla. It's not fun to transfer your site to a new host and tell your old host to take a hike, only to discover later that all the binary attachments were corrupted and you no longer have access to your old site.
+
[[Category:FAQ]]
[[Category:Installing SMF]]
 

Latest revision as of 12:29, 18 September 2014

It is essential to back up your forum. If your database gets corrupted you will lose everything. Having a backup means that you have a previous version of your database to fall back on should your forum be hacked, or should you make changes to it which you subsequently wish to revert.

SMF's Admin section has a built-in database backup function. Do not use it! It does work in some cases, but not in others, so it should not be used, unless you have no other way to acquire the backup of the database.

Backing up your Database

When you bought your domain, your host will have given you details on how to access your site's cPanel®, or something similar. You can access this to back up your database. Alternatively, you can also back up your database using phpMyAdmin.

Backing up your Database with cPanel®

  1. Look for the section labelled "Files" and click on "Backups".
  2. On the new page that opens, you will see "Download a MySQL Database Backup".
  3. Under that, click on the name of your database and a requester will open, which will allow you to choose where that backup will be downloaded to.

Backing up your Database with phpMyAdmin

Again, you will need to access your site's cPanel.

  1. Look for the section labelled "Databases".
  2. Under that heading, you will find "phpMyAdmin".
  3. Click on this, and then follow the steps below. Warning: Do not click on any options other than those outlined below, unless you really know what you are doing!
  4. Look at the left-hand pane and you will see the name(s) of your databases.
  5. Click on one of them and you will see some tabs along the top.
  6. Click Export.
  7. On the next page, find "View dump (schema) of database", and you will see "Export".
  8. Just below that, click "Select all".
  9. At the bottom of the page, ensure that "Save as file" is checked.
  10. Finally, click "Go".

General Notes

Once you have your backup, you should verify whether it works. The best way is to restore it to a second empty database. This is an important step. If for any reason the backup fails you can repeat the procedure immediately to ensure that have a working database in case you need it. If after repeating the procedure you still are not able to obtain a working backup, please contact your host in order to identify and solve the problem causing the backup to fail.

If you cannot restore the database, you should verify that the .sql file you have obtained has proper SQL syntax and commands inside it (to CREATE your tables and INSERT data into them, it may also DROP old tables before creating new ones). Make sure it it looks complete (CREATE and INSERT for all your SMF tables), before assuming that it is a good backup. Spot check a few tables to see if all their data is in the backup (note that the order of records may differ between the database "browse" display and what is in the backup file).

If you used phpMyAdmin it may end with: /*!40101 SET [email protected]_CHARACTER_SET_CLIENT */; /*!40101 SET [email protected]_CHARACTER_SET_RESULTS */; /*!40101 SET [email protected]_COLLATION_CONNECTION */;

Save a copy of the backup some place safe. Your web host server is not a safe place.

You do not have to go over your backup with a fine-toothed comb every time, but you should do so the first time, whenever you make a change to your backup method, and just once in a while.

Restoring your database

Restoring your Database with phpMyAdmin

To restore your backed-up database, you do exactly the same as to back up, except that instead of clicking "Export", you click "Import". You then navigate to your backup file by clicking "Choose" under "Location of the text file".

Please be aware that if you have large databases, it may be not possible to back up using phpMyAdmin, as phpMyAdmin has some file size limits.

General Notes

SMF does not include any utility for reloading (restoring) the database.

Learn how to do a database restore ahead of time, and practice it at least once with a scratch copy of the database.

Know how to browse through the original and restored databases in phpMyAdmin to check that everything is there (all records in all tables). Note that there is no guarantee that records will appear in the same order in the original database, the backup, and the new database.

Some hosts have process time limits that may prevent you from running your restore via phpMyAdmin to completion. Your host may be able to tell you how to suspend or increase the process time limit. There are utilities out there to split up the restore task into smaller pieces, so that you will not exceed time limits.

Depending on your host's configuration, MySQL default collation may differ from the one you need. Be sure to change the newly-created database to the appropriate collation, for example, UTF-8, before starting an import (restore).

phpMyAdmin needs to be told the type of encoding the .sql file(s) uses when you do the import. If your backup is, for example, UTF-8, you need to tell phpMyAdmin that, or it will assume the file is Latin-1 and will translate all the text from Latin-1 to whatever encoding your new database is in. This will make an horrendous mess of your database.

If you need to rerun part of an import, be careful not to import the same data twice. If you are lucky, the process will die with a duplicate key error. This is why it is generally a good idea to drop and create the tables so that they are guaranteed to be empty at the start.

Backing up your forum files

There are two common ways of doing this:

You can open your FTP client and use it to download everything to your hard disk, or you can use your site's cPanel (or whatever your host uses).

  1. Go to cPanel, look for the section labelled "Files" and click "Backups".
  2. In the new page that opens, you will see "Download a Home Directory Backup".
  3. Just below that, click the "Home Directory" button.
  4. You will get a requester which allows you to choose where the backup is saved.

This will save your whole site, so this can be a long process, especially if you have a lot of files on your site.

General Notes

Your control panel may have an option to pack and compress all of your files into one file (.tar.gz; .tgz; .zip,). Consider using this, as it can greatly reduce file transfer time and leave you with only one large file to worry about.

The larger the file, the greater the risk corrupted data, such as transmission errors, will be present. If your site contains a lot of attachments this, therefore, may not be the best choice. If you are only going to keep the file for backup, rather than to work with its individual files on your PC, this can be a good choice. If you plan to look at or edit files on your PC, however, you may want to transfer them as individual files.

Most FTP clients can transfer an arbitrary collection of files and directories in one operation, such as the entire site at once. There is no need to transfer one file at a time. Some control panel file managers can do this too.

For very large databases compression (.zip) may be wise, clearing all logs prior to backing-up, as well as splitting up the tables you are saving to file. When you are opting tables within phpmyadmin it is possible to highlight specific ones for each file. For example, the messages table is usually the largest, therefore, you can create two compressed database files where one contains the messages table and the other contains all remaining tables. When restoring these tables simply import the multiple files one at a time to the same database.

If you do not know how to use an FTP client, please see FTP_-_How_do_I_use_FTP for further information.

As with the database backup, do a test restore the first time you back up, and once in a while after that.

Store a copy of your backup somewhere other than your hosting server. This is because even backups offered by your host may prove unreliable.

Restoring your forum files

This can be done by using FTP to transfer the backed-up files from your hard disk to your site or by going to the same place in your site's cPanel (or whatever your host uses) that you use to back up.

  1. Go to cPanel, look for the section labelled "Files" and click "Backups".
  2. In the new page that opens, you will see "Restore a Home Directory Backup".
  3. Click "Choose" to navigate to your backup, then "Upload" to start the restoration.

General Notes

As with database backup, practice in advance how to do a file restore to a scratch copy of the site on your server.

Be careful if using FileZilla to transfer with automatic mode selection. It will corrupt all attachment and avatar images unless you specify binary mode, read this note for more details.

Spot check your restored files, especially attachments and avatars, to ensure that they have survived, especially if you use FileZilla.