Is very important. There are a number of lightning bolts that can strike your website and force you to start over from scratch, and two of them have happened to myself.
The first bolt that hit a site of mine was it got cracked. Fortunately, not too much damage was done, the crackers (I don’t use the word hack here, as hacking can be a “white-hat” activity, but cracking is almost always “black-hat”) did not destroy my data, they just broke into the site and created their own
index.html file with some gibberish about the villain of 9/11. I traced the attack to some people in Turkey who used a script to search websites with the particular combination of CMS and version I was using. They then used a known exploit to get in. All I needed to do was to remove the
index.html and replace the old CMS files with the latest version. There is a lesson here, keep your CMS software up to date. Sometimes updates are for new features, but more often they are to patch security holes. Also, it is probably good practice to remove references to the CMS you use, both visible and invisible, but that is not really a trivial task as there are a number of ways a person can find out what CMS you use.
The second bolt though was more destructive. It was a web-host system failure. Some of my sites were restored by the vendor’s backup, but not all. The one site missed had to be built completely from scratch, that is the materials I had created for that site were gone.
So, how does one back up their site?
You can do so in a number of ways. If you use popular CMS software there is a great chance there is backup functionality built in or easily available. In fact, I viewed a video last evening on using a WordPress plugin to do just that. However, what if you use a different system that does not have built in backups or a plugin to do this?
You can create your own. You have two items you need to backup, the first is your database and the second are your files. The more critical of the two is the database, but files can be critical too especially if you or others are uploading files to view via the site.
The approach I take is to backup the entire database. If you are setup on a Linux Apache MySQL PHP system (aka LAMP) you can create a couple of scripts to perform the backup automatically.
Here is the script I use to backup one of my sites. I present backup.sh
#First - get current date
- FileDate=`date +"%Y%m%d"`
- tar -c -f /home/Archives/$TarFileName /DIRECTORY_WHERE_YOUR_WEBFILES_ARE_AT/public_html
- bzip2 -9f /home/mark/Archives/$TarFileName
- eval "mysqldump -uUSERNAME -p'PASSWORD' DATABASE_NAME > /home/mark/Archives/$SQLFileName"
#Next form filename
#now invoke tar
#Now call bzip2 to compress the file
#Now backup the database
What does this script do?
- Any line starting with a # is a comment
- Line 1 gets the current date in YYYYMMDD format.
- Line 2 creates a filename of the form
WEBSITE_YYYYMMDD.tar, e.g. WEBSITE_20100512.tar
- Line 3 creates another filename of the form
WEBSITE_YYYYMMDD.sql, e.g. WEBSITE_20100512.sql
- Line 4 bundles all the files in and under
/DIRECTORY_WHERE_YOUR_WEBFILES_ARE_AT/public_htmlinto the single file
- Line 5 then uses bzip to compress the file created in line 4. I use bzip, you can also use compress, zip, or gzip.
- Line 6 then performs the database backup. Storing the entire database structure and data from DATABASE_NAME in the file
RUNNING THE SCRIPT
Upload the file to your website. If your site is stored in the following directory
/home/your_name/public_html I then prefer to create a directory called
/home/your_name/Archives, the former to hold the script, the later to hold the backup files. Make sure the permissions on the file are set to 750 (I think 700 will work but not certain) that is
Your next step is to set up a cron job. Logon to your CPanel and select
CronJobs. I prefer to run this script over the nighttime hours. Generally from 1:00 am to 4:00 am, I figure there will be few users on my sites at that time and the backups can run and get a complete snapshot and not slow down end-user access. The Cronjob panel makes it pretty easy to setup. Again, I run the script once/day late at night.
However, you need to actually see the script run before considering this job done. Setup your first cronjob near in the future and wait. After about 10 minutes past the target time view the contents of the
/home/your_name/Archives directory, does it contain two files? If so give both files a quick check by transferring to your workstation and uncompress the backup of your files to see if the files are there, and open the sql file using notepad (or similar, I will use VI for that), does it contain database create, table create, and insert statements? If you answer yes to both questions you are almost done. Reset the cronjob to a time late at night and your are done. Next morning, make one more check to make sure the backup script did its job.
WHAT CAN GO WRONG?
A number of things.
- Make sure the paths you created to store the script and the backup files are writable.
- Make sure the user, password, and database parameters are correct on the
- Make sure the permissions on the script allows cron to run the script.
- Make sure the path definitions are correct.
- Is your web-host running in a different time zone? Your cron jobs need to be scheduled on their time, so you may have to add or subtract some hours to the execution time.
- Maybe your web-host does not run on Linux but on a WAMP (W being Windows) you will have to investigate alternatives based on Windows. My suggestion is to use ZIP and with ZIP you can specify the bundling and compression of multiple directories in one go.
Is the other half of this process and that is a script that transfers the files from your webhost to your home PC and also keeps the number of files on your home PC and webhost reasonable. No real sense in having 100 instances of each file.
If you have suggestions for improvement I will be glad to hear them please leave a comment.