According to our rules the customers are fully responsible for backing up their websites and databases. However, that doesn’t mean that we don’t run any backups at all. We run backups for the entire server and in case of any emergency we’ll try to restore them as quickly as possible.

For the ones who are familiar with computer technology we’d like to show how an average backup should be handled. The information below applies if you have a dedicated server and several websites on it with MySQL being the back-end.

Backup stages

We divide backup process into several stages:

  1. Backup of website files
  2. Backup of databases
  3. Regular backup of everything

Backup of website files

To backup files we should know where they are located and then we run this backup command for every website we have:

tar -czf website_name.tar.gz /home/website/

Backup of databases

Let’s assume that we know login details to the database of the website we backed up above:

mysqldump -u username -ppassword database_name > database.sql

To save disk space it would be good to zip that MySQL dump with the gzip command.

mysqldump -u username -ppassword database_name | gzip > database.sql.gz

Regular backup of everything

To automate the backup process it’s better run it periodically with a special script. The cron will help us with it! The cron is a clock utility for Linux that executes commands at specified dates and times, but first of all we need to create our special script (hmm.. let’s call it “backup.sh”) and save it. Then, add it to the cron job schedule:

The backup script:

#!/bin/bash
tar -czf website_name.tar.gz /home/website/;
mysqldump -u username -ppassword database_name | gzip > database.sql.gz;

Ok, guys it’s time to add to the cron job. Run cronjob command with the -e (edit) option:

crontab -e

As a result we should see something like that:

0 1 * * 1 /usr/bin/errclear -m
0 1 * * 2 /usr/bin/errclear -w

It doesn’t really matter what the lines, starting from “/usr…” do. These lines are just the absolute paths to the scripts and programs that will be executed. But it’s matter what the numbers and stars before them means. These 5 columns telling the cron what date and time the script/program should run:

  1. Minutes. 00-59
  2. Hours 00-23
  3. Day in a month 01-31
  4. Month in a year 01-12
  5. Day of the week 0-6, where the Sunday is 6

Let’s assume that our script is located on /backup/backup.sh and we want to run it every Friday at 22:37 forever. In that case we should add the line like this:

37 22 * * * /backup/backup.sh

So in the cron job schedule edit mode we would see:

0 1 * * 1 /usr/bin/errclear -m
0 1 * * 2 /usr/bin/errclear -w
37 22 * * 4 /backup/backup.sh

Save the cron job schedule and exit it. Now our backup will run every Friday at 22:37

Increasing the chances of survival of site backup

Now we have backups of the database and website files, but we have a little issue with the reliability. They are all located on the same server with our websites. This is a not good practice to leave them there, so we need to regularly download backup files to another server or local PC/Mac.