The importance of running a thorough, regularly scheduled back up cannot be overstressed regardless of whether your site is just starting out or has hundreds of viewers per day. Backing up your important files goes a long way towards preventing or easily repairing many headaches that may come along with broken installations or updates, hacking attempts or if you simply want to move to another domain or hosting provider. After all, an ounce of prevention is worth a pound of cure. In this post, I will show you a basic script you can use as part of your scheduled back up. It will copy your website to a backup folder, zip the contents of the folder and optionally keep a working mirror of your website–automagically!

Why backup?

The problem with backing files up is that most people just don’t see the need to do so until something has happened. Unfortunately, by then it’s usually too late to fix the problem. In reality, if you do not have your website scheduled for a regular daily backup, you are playing a dangerous game Russian roulette with your information. Once a routine backup plan is put into effect, it will give you the peace of mind that comes along with knowing that if problems should occur, you will have… a back up!

Most hosting providers do back up everything on their servers, but that doesn’t necessarily mean they do it often. They may backup the operating system and important information to keep the server running on a daily basis, but most don’t run daily backups of the websites they are hosting. To be honest, it’s just not worth the disk space for them–there could literally be hundreds, even a thousand websites being hosting on a shared server. Of those that do run backups, many charge for restoring the back up they have on copy and it may be weeks or a month old at best. To be honest, they maintain back ups for themselves. It’s your responsibility to back up your own information.

Paid versus shell scripts

There are many back up solutions that rely on the software you have installed on your site. A quick search will bring up a plethora of paid and free plugins available for OsCommerce, Wordpress, CRE Loaded, Joomla, etc. There is a problem with these plugins, though: most rely on your installation to work or be somewhat functional and they run the risk of breaking if you update the plugin or the software. While they are generally much easier to use, they are not the most effective way to back up your site and some only back up the specific software installation, not any other files you may be hosting.

So, how do you get around this? The answer is very simple: good, old reliable shell scripts. Shell scripts have been around forever and they are without a doubt the most reliable way of backing up your information. They aren’t as user friendly as web site plugins, but they are free, fast, have a proven track record and there is a wealth of information available about how to use them. They do not rely on anything to be installed except, of course, the operating system your host is running, but that’s assumed. Since they run locally where your information is stored, they are faster than downloading and backing up your site via FTP. It is nice to have a copy of your site downloaded via FTP on hand in case of a major disaster and I do recommend this as well, but that’s for another topic.

Getting started

Before you do anything, though, you need to make sure you have: SSH (shell access) and the ability to run CRON jobs. Godaddy, for example, requires you to activate SSH by phone before you can run CRON jobs, and since you need both, you should go ahead and get it activated before continuing to read. The back up I will show you has been tested on Godaddy via SSH and their CRON job manager, but should work just as well on any other hosting provider that runs Linux with little or no modification necessary. The first script is designed for Wordpress and selectively backs up only Wordpress and any files in the immediate root directory. It assumes that you have installed Wordpress in the root directory. For example: http://www.yourblog.com NOT http://www.yourblog.com/wordpress. The second script can be used for backing up your entire web site–it merely backs up everything in the public html directory. Again, you can easily modify these scripts to suit your needs. You need only to change the directory or directories that you wish to back up in the scripts.

Plan of action

1. Create a directory in your root called ‘backups’
2. Create another directory inside backups called ‘dailyback.’
3. Protect backups with a user name and password using .htaccess and .htpasswd.
4. Create an empty file inside backups with a plain text editor (no Microsoft Word et al–Notepad or gedit are good enough!) call it backup.sh since this is a shell script we’re creating.
5. Into the contents of this file, copy and paste the following script:

#!/bin/bash
#Compliments of www.fortasse.com
#Displays a greeting and backs up files
#Begin Script
TERM=linux
export TERM
NOWDATE=`date +%m%d%y` # Sets the date variable format for zipped file: MMddyy
clear # clears terminal window
echo
echo "Hi, $USER!"
echo
echo "Beginning backup of files @ `date`"
echo "Backing up wp-content..."
#Copy wp-content
cp -r $HOME/html/wp-content $HOME/html/backups/dailyback
echo "Done!"
echo
#Copy wp-admin
echo "Backing up wp-admin..."
cp -r $HOME/html/wp-admin $HOME/html/backups/dailyback
echo "Done!"
echo
echo "Backing up wp-includes..."
#Copy wp-includes
cp -r $HOME/html/wp-includes $HOME/html/backups/dailyback
echo "Done!"
echo
echo "Backing up files in Wordpress the root folder /html/ ..."
#Copy miscellaneous files in /html/ only
cp $HOME/html/*.* $HOME/html/backups/dailyback
echo "Done!"
echo
echo "Zipping directory structure..."
tar -cvzf $HOME/html/backups/$NOWDATE.tar.gz $HOME/html/backups/dailyback/*
echo "Backup complete!"
#Uncomment the following lines if you DO NOT want to keep a mirror of your site:
#echo "Cleansing backup folder..."
#rm -r $HOME/html/admin/dailyback/*


You will need to do a couple of things before you can run this. If you’re on Godaddy, you shouldn’t need to make any changes to the script. If you’re not on Godaddy, you might need to change the /html/ folder to /public_html/ or whatever it is that your host uses. Make any other changes you need to the directory structure and uncomment the last two lines if you don’t want to keep a working mirror of your Wordpress blog. Upload it to your web site and test it out by opening an SSH connection and going to the directory you uploaded it to and type:
cd ~/html/backups
sh backup.sh

Technically, you don’t need to do all of that copying. You could simply remove almost everything but the last line and tell the script what directory you want to backup. However, I prefer to keep both a working copy (aka mirror) and a zip at all times. It’s a lot faster to simply copy the mirror back over if something broke than to have to unzip and restore the archive. Let’s look at an example of a barebones script that simply zips everything in the public html folder:

#!/bin/bash
#Compliments of www.fortasse.com
#Displays a greeting and backs up files
#Begin Script
TERM=linux
export TERM
NOWDATE=`date +%m%d%y` # Sets the date variable format for zipped file: MMddyy
clear # clears terminal window
echo
echo "Hi, $USER!"
echo
echo "Beginning backup of files @ `date`"
echo
echo "Zipping directory structure..."
#Remove the v in -cvzf below if you don't want to see the output
tar -cvzf $HOME/html/backups/$NOWDATE.tar.gz $HOME/html/*
echo "Backup complete!"


In this case, everything in the public html folder was zipped and the corresponding zip file placed in the ~/html/backups/ directory. This is really effective if you don’t want to selectively back up certain files or directories. I run several backups on my server, at different rates and times and for specific files or directories. Not every web site hosted on my account will necessarily go down at the same time. Therefore, making individual back ups of different installations and/or web sites allows me to have a much finer degree of control over my backups. If I zipped the entire site in one file, I would have to worry about over-writing new content on other unaffected web sites contained in the same root when I expand the zip file. That would be another nightmare altogether!

Backing up your database with MySQLDump

Backing up your database is also very important. If your database goes, in most cases you’ll having nothing. Zilch. Zero. No posts, no users, no links, no tags. You get the point. Thankfully, this is fairly easy to do using a shell script.

Do it!

1. Create a directory called ‘database’ inside the the /html/backups directory.
2. Copy and paste the following code into the bottom of the backup.sh script.

echo "Backing up Wordpress database"
mysqldump -h YOUR.DBSERVER.COM -uUSERNAME -pPASSWORD DATABASENAME > $HOME/html/backups/database/$NOWDATE.sql
gzip -9 $HOME/html/backups/database/$NOWDATE.sql
echo
echo "Job finished!"

Replace YOUR.DBSERVER.COM with wherever your database is stored. It might be locally stored on the machine, or it could be located on a remote server in the case of Godaddy. Replace USERNAME with your username, PASSWORD with your actual password and DATABASENAME with the name of the database you want to backup. Keep the spaces, all dashes and everything else you see intact. -p and PASSWORD are supposed to be connected. Do not make a space between them, or it may not work. Like the file back up script, this will back up the database, zip it and put it in an archive with a time stamped file name.

Final steps

You will need to set this script to run through your hosts CRON Job manager. In Godaddy, this is a very simple task. You need to upload the file, open up your Hosting Control Center, go to Cron Jobs and select the file and time you wish to run the shell script. NOTE: You may get a ‘Permission Denied Error!’ In this case, try setting the permissions of the backup.sh file to 755. For other hosting companies, you may or may not have to use CRON Tab or some other CRON job manager. The commands are simple, but call your hosting company if you have any questions. In either case, you should set up the job to send you an e-mail upon completion. At least for the first few days, to make sure the script is working properly. Caveat: If you left to verbose (-v option) on for tar, you may get a very large e-mail.

Summary

So to briefly summarize everything, the first script copies specific directories, creates a mirror and zips the mirrored backup and places it in a backup directory. The file name is the time stamp of the backup date. The second script backs up everything in your public html file (all websites, subdomains, and anything else) and zips it up and does not create a mirror image of your site. The third will backup your SQL database and zip it in a nice little file using gzip. Simple enough, huh?

If all went as planned, you should have a working back up script for your website. I recommend using the script at least daily for the best protection. Enjoy!

Related posts

• Godaddy, Wordpress & broken permalinks (1)
• Optimize your site with .htaccess (1)
• Your Friendly Guide To Photo Shop Tutorials (0)
• Working With Files in Linux: Kludges and Solutions (0)
• Wordpress Video Tutorial: Why You Need a Wordpress Tutorial (0)

Fortasse.com website 1/12/2010

So you’re designing a really cool website, want to know how it will look on different operating systems and browsers? While most pages will show up fine from one browser to another, there are always certain codes that just won’t work the same from one browser to another. Sometimes it’s more complicated than that: maybe you want to know if it shows up the same way in Firefox for Ubuntu Karmic Koala as it does for Windows XP. What’s a web designer to do? You could ask your friends to check out your site for you on their operating system / browser combinations whilst you test the site on yours. You could also install every conceivable operating system inside your current OS via Virtual Box. Or, you could drop by BrowserShots, type in your URL and wait a few minutes for it to parse your request.

Once you’re at the page, there are a plethora of options to choose from. You can select the screen size, color depth, and whether you want, Java, Javascript and Flash enabled.

Simple, fast, effective. After plugging in my URL, I had 53 browser / OS combinations in about 25 minutes. You don’t have to wait 25 minutes to start seeing them, though. The screen shots will be gradually uploaded one by one, so you can view them as they come in. The site literally directs a computer to view your site, takes a snap shot and uploads it. So you are, in effect, seeing exactly how it would look if someone loaded it up in the selected browser and operating system. Once the process is completed, you can save the pictures if you want. You can continue to view them for a while, but they will expire eventually.

So there you have it: next time you need to find out if there are any problems viewing your page on another browser or operating system, head on over to BrowserShots and take a peek for yourself!

Related posts

• Your Friendly Guide To Photo Shop Tutorials (0)
• Why Are Online Web Tutorials So Popular? (0)
• Where To Find Photoshop Cs Tutorials (0)
• Where To Find CS2 Photoshop Tutorials (0)
• What You Should Learn From CS2 Photo Shop Tutorials (0)

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

While this may indeed be sufficient for some needs, it hardly adds enough juice to sites that are beginning to generate traffic. But, before we get started on this tutorial, I highly suggest you download Google’s Page Speed plugin for Firefox (it requires the Firebug plugin, so go ahead and install it first). Now, make sure all the plugins are enabled by going to the menu in Firefox and clicking Tools > Add-ons. After you’ve done that, point your browser to the URL of your site. In the Tools menu, click Firebug > Open Firebug (you can also push F12 to load the plugin via the keyboard shortcut).

Once the window has loaded, make sure Firebug is opened to the Page Speed tab. If it is, push Analyze Performance and wait for the status bar to come to completion. This usually take 10-25 seconds to finish. Now what shows up? If you have a run-of-the-mill install, there’s likely plenty of problems showing up in the Performance summary. No need to worry, most of the errors are easily fixable.

First, let’s go to the .htaccess file in the root of your blog or other page. Don’t know where it is? Fire up your favorite FTP client and point it at your sites FTP location (e.g. ftp.mywebsite.com). [Note: I personally use the FireFTP plugin for Firefox, you can find it easily by going to Tools > Add-ons. Click Get Add-ons and search for FireFTP].  Login with the username and password assigned to you by your hosting provider and you’re good to go. If you’re using FireFTP, you’ll need to open it up by clicking the icon in the Firefox menu bar or going to Tools > FireFTP.

The .htaccess file is hidden by default, as well it should be. Do NOT try to un-hide it. Simply allow your FTP client to view hidden files. If you’re using Nautilus for Gnome or a similar built-in FTP client for Linux, you can easily do this by pushing Ctrl + H, or in FireFTP click Tools, Options and make sure Show hidden files is checked. If you’re not using Nautilus or FireFTP, you’ll have to search around in your FTP client’s options or preferences dialogs. For example:

Now that we’ve taken care of that, browse to the install folder of your site, such as ftp://ftp.mysite.com/mysitefolder. Once there, you should be able to view the .htaccess file. Great! At this point I should mention that the Nautilus FTP client has one feature that can be very great and very bad. Instead of having to download the file, then modify it and upload it back to the site, you can simply right click the file and open it with your favorite viewer, such as gedit. Once you’re done, you simply push Save and it will automatically save the modified copy to your website. This is great for streamlining the upload process, but PLEASE, always back up ANY files you are modifying. Make a copy of the original file on your computer and, to be sure, make another copy on the website, but name it .htaccessback.

So now that we got all of that out of the way, let’s edit the darned thing already! As I said earlier, you will often find the .htaccess file will be pretty sparse. This is one of the reasons you may have generated so many errors with the Page Speed plugin. The primary error we’re looking for right now is Leverage browser caching. Utilizing browser caching will force the browser being used by anyone viewing your site to cache files locally on their computer for a given amount of time, thus reducing the load on your server. This is a fairly simply modification, and without getting too technical, simply paste the following code below any existing blocks of code in the file:

#Begin Cache
<IfModule mod_headers.c>

#CACHE YEARLY
<FilesMatch ".(ico|gif|jpg|jpeg|png|flv|pdf)$">
Header set Cache-Control "max-age=29030400"
</FilesMatch>

#CACHE MONTHLY
<FilesMatch ".(js)$">
Header set Cache-Control "max-age=2419200"
</FilesMatch>

#CACHE WEEKLY
<FilesMatch ".(js|css|swf)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>

#CACHE EVERY 45 MIN
<FilesMatch ".(html|htm|txt|php)$">
Header set Cache-Control "max-age=2700"
</FilesMatch>

You probably noticed there are file extensions located inside parenthesis separated by bars under each section. These specify how each file type will be handled. While the code above is good for most applications, you might want to adjust which files are under each section to suit your site. The max-age setting determines how long the file types should be cached locally on the browser. The time is measured in seconds and should not be set above 29030400, which is approximately one year [Tip: you can go to Google and type something along the lines of 6 months to seconds, and it will do the conversion for you quickly; use only whole numbers].

At this point, go ahead and save the .htaccess file, upload it to your site and make sure everything works. If you get a page that says HTTP Error 500 Internal Server Error, you’ve done something wrong and should replace the .htaccess file with the copy you should have backed up earlier. This is why you should only make a single change, save, and then check the site. If, for example, you paste in 100 lines of code that do 10 different things, you will have to hunt around to figure out which block or line of code is giving you problems. The .htaccess file is very, very picky. Trust me on this one.

If everything worked as expected, open the file back up and place the following block of code below the block you just added:

<IfModule mod_gzip.c>
mod_gzip_on       Yes
mod_gzip_dechunk  Yes
mod_gzip_item_include file      .(html?|txt|css|js|php|pl|jpg|png|gif)$
mod_gzip_item_include handler   ^cgi-script$
mod_gzip_item_include mime      ^text/.*
mod_gzip_item_include mime      ^application/x-javascript.*
mod_gzip_item_exclude mime      ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

If your hosting provider supports it (it should if your hosting service supports PHP), the above code will enable all of the specified files to be compressed. Obviously, when files are compressed they are smaller and this leads to less strain on the host and thus faster pages loads. Now say it with me: Save, upload and check. If your page isn’t working, you need to go back and see what went wrong. Luckily you backed up, right?

Now that that’s all done, go ahead and close your browser then open it up and navigate back to your site. Run the Page Speed analyzer again and see how you do. Progress? Woohoo! Don’t worry if your site doesn’t come out with high scores in every category, caching and compression are just two of many ways in which you can speed up your site. Be sure to check back to learn how to compress and optimize your images and scripts. Once you’ve applied all the tricks, you’ll be pleasantly surprised at how well your site will start to perform.

Related posts

• Tutorial: Backup script (4)
• Godaddy, Wordpress & broken permalinks (1)
• Your Friendly Guide To Photo Shop Tutorials (0)
• Wordpress Video Tutorial: Why You Need a Wordpress Tutorial (0)
• Why Are Online Web Tutorials So Popular? (0)