Backing up your website

Not long ago, I interviewed approximately twenty website administrators who were in charge of the management and administration of at least two websites. One of the questions I raised was how often they backup their website.

The results:

  • Daily — 1
  • Weekly — 3
  • When I am reminded to do so — 10
  • Never — 6

Hopefully, the results are not representative of the web development community because, oh boy, are we gonna be in trouble :)

Why backup

Backup is something we website administrators take for granted — maybe because we are blessed with reliable web hosting companies, or maybe because the content is not updated regularly that it seems like a waste of time.

But there are reasons why you should keep your own separate backup:

  • A lot of webhosting companies do not restore backups for free. One of my web hosting accounts actually charged $25 when we requested a backup restoration.
  • Mistakes and accidents happen. Even if your web hosting company perform daily backups, there is still a possibility that they won’t back it up at least once. And, depending on your luck, it may happen at the same time that you accidentally delete a file.
  • One word: Hacking. You are particularly susceptible if you are using very popular open-source scripts, particularly bulletin board systems.
  • If your site has a forum or has a lot of user-submitted content, your website data actually becomes more crucial. Not only because your website has a greater amount of content, it also has a greater amount of server load.
  • If you have a full backup of the site in handy, it is very convenient to give a copy to your client when they need it.
  • Some hosting companies, despite their claims, actually do not have a regular backup system in place.
  • Web hosting companies do close down. And when they do, so do any other means of getting in touch with them.

When to backup

How often you should perform a backup will depend on a number of factors:

  • Availability of the resources you need in order to perform the backup operation;
  • Frequency of content updates in your website;
  • Amount of updates; and
  • Importance of the website to the organization.

What to backup up

For most cases, there are two things that need to be backed up:

  1. Database. If you are using one of the popular open source content management systems (CMS) to maintain your website, there is a great possibility that your content is saved on a database.
  2. Web files. These are the files accessed by your users (PHP, HTM, images, etc.), and are usually saved in a directory called public_html or www. Note: If your website writes or reads files in another directory, whether remote or above the public_html directory, then these should be backed up too.

Backing it up

In a nutshell: The easiest way to backup your site is by compressing all your HTML/PHP/etc. files, and then downloading the compressed files. Here’s how to do it:

Step 1: Get shell access to your account. If you don’t have one, ask your web hosting provider nicely :) For security reasons, this is usually disabled by default.

A shell allows you to access your server thru a command-line interface (think DOS). With shell access, you can FTP, debug CGI scripts, set permissions, and even read your email.

If your web hosting provider refuses to grant you an SSH/Telnet access, you have no choice but to download each of your file via FTP, which is a time-consuming process.

Step 2: Get a Telnet/SSH client. I personally use PuTTY, a free telnet/SSH client.

Step 3: Login to your account. Open PuTTY (or your favorite SSH/Telnet client). Under Host Name, enter your domain name or IP address. Under Protocol, it is highly recommended that you select SSH instead of Telnet. Click the Open button at the bottom of the window to connect to your server.

You will be asked to enter your account’s username and password. If your login is successful, you will be taken to the prompt, which is typically represented by a dollar sign ($)

Step 4: Backup your database. Enter the following commands:


mysqldump --opt -Q -u USERNAME -pPASSWORD DATABASENAME > BACKUPNAME.sql

Replace USERNAME with the username of your database, replace PASSWORD with the password of your database, replace DATABASENAME with the name of your database, and replace BACKUPNAME with the desired filename of your backup.

When completed, you will be taken back to the prompt. Verify that the BACKUPNAME.sql is in the path you specified. You can compress this file by following similar commands at the next step.

Step 5: Backup your web files.

Go to the directory that you want to backup.

To view the contents of a directoty, enter the following commands:

ls

To change directories, just enter the following:

cd DIRECTORYNAME

Replace DIRECTORYNAME with the desired directory name, For example:

cd public_html

And finally, to compress/archive all the files and subdirectories in that directory, enter the following commands:

tar -cvzf FILENAME.tar.gz *

Replace FILENAME with the desired filename of your backup. Verify that the backup was successfully created. You can do an ls, or view your directory using your FTP client.

Step 5: Download the backup files. Use your favorite download manager. I personally use ReGet and GetRight.

Pretty nifty, huh? Hope this helps.

12 thoughts on “Backing up your website”

  1. If you have ssh access to your webhost, you could do it faster and save bandwith by transferring only the part of the changed files using rsync(http://rsync.samba.org)

    [QUOTE]rsync is a replacement for scp/rcp that has many more features.

    rsync uses the \”rsync algorithm\” which provides a very fast method for
    bringing remote files into sync. It does this by sending just the
    differences in the files across the link, without requiring that both
    sets of files are present at one of the ends of the link beforehand. [/QUOTE]

    [URL=http://hacks.oreilly.com/pub/h/38]Using rsync over ssh[/URL]
    Keep large directory structures in sync quickly with rsync

    there is a win32 binaries which includes ssh clients at [URL=http://www.itefix.no/cwrsync/]http://www.itefix.no/cwrsync/[/URL]

  2. Hrmm that was odd, my first post didn’t work. No matter, I had to tell you that it’s nice to see that somebody else also mentioned this as it was difficult finding the same info elsewhere. This was the first place that shed some light on this subject for me. Thanks.

  3. Good day, I think you’ve got a good weblog and it is comparable to my niche and I’d like to exchange links with you. Are you interested in doing so? Gives thanks

Leave a Reply to Burton Haynes Cancel reply

Your email address will not be published. Required fields are marked *