It’s a promise we’ve all heard before. Web hosting companies all over are offering “unlimited” hosting for mere dollars per month.

On the surface, it seems like a great deal. For a low monthly price you get to stop worrying about bandwidth and server space caps and focus on running your site. You can host as many domains, get as much traffic and store as many files as you want.

However, unlimited hosting is much more myth than reality. It just means that the host doesn’t place “hard” caps on storage and transfer and instead has replaced it with soft ones that could come back to bite you at almost any time.

Fortunately, it is a relatively avoidable pitfall if one is willing to be realistic about the limitations of such hosting and take precautions to avoid abusing it.

The Pitfall

Though unlimited hosting is a tempting offer for a variety of reasons, it is an offer that we should be able to recognize as somewhat misleading right off the bat. After all, if unlimited hosting truly were unlimited, then Google, Microsoft and other companies could save millions on datacenters and just spend a few dollars per month at a regular host.

The truth about unlimited hosting is that it is indeed very limited. If you read the fine print on any unlimited contract, you’ll find that a variety of restrictions are placed on the account, including, in many cases, bans on providing streaming media, image hosting or other bandwidth/storage-intense activities.

Even if there are no such caps, the host always has a clause in their TOS that allows them to disconnect, temporarily or even permanently, those who use too much resources and cause problems for other accounts on the same server or network.

In short, your use of the server is only “unlimited” as long as it doesn’t cause a problem and, if it does, you may find that your site goes dark.

The Danger

The danger of unlimited hosting is illustrated very well by what recently happened to the Frogpants podcast network. The network, which was hosted on an unlimited account at Bluehost, went dark for a day after Bluehost cut their account for using too much of their resources.

While it was poorly handled by Bluehost, they should have offered warning before cutting the account, it illustrates the problem. The network, which includes several very popular podcasts, simply used up more of the host’s resources than they could afford to provide with the account that they were using and their host shut down the sites.

Frogpants was able to recover quickly, after being offered hosting at a different company and given the chance to recover its files, but it was down for over a day and other sites are not so lucky. Many sites that suffer sudden terminations aren’t given adequate opportunity to move and don’t have another company waiting to scoop them up.

Without adequate backups, this can be a very deadly pitfall for a blog and one that is well worth avoiding.

How to Avoid It

Avoiding this pitfall completely may seem to be fairly simple, but it really isn’t. This is especially true considering that most shared web hosts offer unlimited hosting as their primary account type and most low-end hosting accounts claim to be unlimited.

That being said, there are several things you can do to avoid this problem and having your account disconnected:

1. Avoid “Unlimited Hosting: This one seems simple enough, find a service with a hard cap and stick with it. The limits might be lower than with an unlimited host, but at least you can be sure what the limits are.
2. Read the TOS Carefully: If you do choose or have to use an unlimited host, read the TOS carefully. Most likely, the terms place a limit on what you can and can not do with your account dealing with media streaming, image hosting and FTP access.
3. Don’t Host Media: Media, including both audio and video, are the biggest bandwidth and space hogs on a server. You can use other services, such as YouTube and Talkshoe, to offload your media content and make your site much more lean.
4. Be Realistic: If your site grows beyond what one would expect to be a typical use for that level of a hosting account, upgrade to a larger account. Not only will it prevent a possible termination, but also make your site faster.
5. Warn of Traffic Spikes: If you get warning of a traffic spike, such as a story making its way to the front page of Digg, warn your host so they can prepare. They may be able to move your site to a lower congestion part of the network or a server with smaller load. That way, you won’t create problems and you will be working with them to resolve issues.

To be clear, this is actually a separate issue from the downtime many sites see when they are hit with a traffic spike. Hosts often temporarily disable accounts or individual sites during such spikes as their memory and CPU usage reaches dangerous levels. This is almost unavoidable on shared hosting accounts.

Unfortunately, these steps won’t do much to mitigate against those temporary outages but will go to great lengths to mitigate against the far less common, though far more worrisome, account closures that often happen when an unlimited account is overused.

Bottom Line

In the end, account terminations due to overuse of “unlimited” hosting plans are actually rare. Only a small number of accounts will see any kind of action taken against them and most of the time the response is much more tame than termination.

That being said though, it does happen and it is worth addressing since most of the steps are simply good hosting practices on any account.

In short, if you are smart about your hosting- you should work with a reputable provider and managed data center service, you will most likely find that it will serve you well. Try to get more than your money’s worth out and you will probably be facing an unplanned outage in the near future. Likely an extended one.

Unlike other services of Automattic, VaultPress is geared strictly towards self hosting WordPress blogs (aka WordPress.org) as a data backup service that protects a bloggers data in the even that their hosting company dies, kidnaps their site or (worse case scenario) is attacked by hackers.

Despite being in a limited beta, WordPress is charging brave souls $15 a month per blog (which works out to be $180 a year) to entrust their blog’s entire content to the VaultPress crew.

For those of you wondering if you should give Automattic your cold hard cash or choose an alternative, here is this authors take on VaultPress (both the good as well as the bad).

Everyone knows that you’re supposed to backup your data but how many of us actually do it and, of those who do, how many do it right?

The problem is that far too many bloggers ignore this very crucial security step. Whether it is putting too much trust in their host, not understanding how to backup properly or simply not wanting to put forth the effort, many simply don’t backup their sites and, sadly, often lose months or years worth of work when something goes wrong.

The worst part is that it is a pitfall that can be easily avoided and, thanks to various tools, can be completely mitigated either for free or at very low-cost.

In short, there is no excuse to not backup your site, but there is a lot of reason to worry if you don’t.

The Pitfall

It is far too easy to forget about backups, until we need them. The dirty truth about technology is that things break and bad things happen. Though such occurrences are (usually) blessedly rare, the damage they can do can not be ignored.

Typically, there are three reasons for ignoring or performing inadequate backups of one’s site.

1. Trust in the Host: Most Web hosts tout their backup procedures and many bloggers feel this is adequate.
2. Lack of Understanding: Many simply don’t understand what they need to backup or how to do it, causing them to either skip on making backups or do them incorrectly.
3. Laziness: Backups are work and its work that doesn’t usually pay off until something bad happens. As such, many do not think it to be worthwhile.

Unfortunately for bloggers all of these excuses are poor ones. Host backups are usually for restoring their machines in the face of a disaster and are not aimed at restoring individual accounts. If a hard drive dies they can restore their backups, if your account gets hacked or you break your site, they might not be able to. Also, often times, host backups get hosed at the same time the server does, especially when they are stored at the same physical location. Simply put, Web host backups are never enough by themselves.

Lack of understanding and laziness are not valid excuses either. Though it is easy to see why backing up may be confusing, it’s easier to understand how to backup and restore than it is to try to rebuild a site without one. The techniques and tools are much simpler when a proper backup exists. Likewise, the amount of energy and financial cost it takes to perform good backups pales in comparison to what it takes to rebuild without one.

In short, by not having backups, you aren’t saving time, money or headache, all you are doing is shifting those things to a later date, when you will have to pay it back at a very high rate of interest.

The Danger

This happened to me once. I visited my Web site only to be greeted with a nasty server error. After nearly a day of tortured waiting, I found out that my server was completely hosed and the host’s backups had failed. My only option was to rebuild the server from the ground up.

Fortunately, I was in luck. I had just recently switched to the new host and my old site still had relatively up to date backups. I simply moved everything back to the old server, updated its database and pointed the domain there. Within a few hours, I was back online with minimal data loss.

However, if I hadn’t had that, I might have been in serious trouble. Though I had good database backups, but my backups of the images and other static files were not adequate. I would have been in a very bad place.

If good fortune had not smiled on me, at best I would have been staring at weeks worth of work rebuilding my site and, at worst, I would have lost many weeks, possibly months of data. Others, with even less robust backup plans, could have lost everything.

In my case, that would have included over three years of blogging, all wiped out in seconds by a hard drive failure at my host. I’m not sure my online presence would have ever recovered.

How to Avoid It

The way to avoid this pitfall is extremely simple, have good backups. Specifically, you need to back up two different things:

1. Your Database: Your content, settings and other blog information, for the vast majority of blogs, is stored in your database.
2. Your Files: A lot of content is not in your database including your theme, plugins, images and other media files that are stored as files on your server.

How often you should back up these elements depends on your site. If you have a very active blog, you should probably back it up daily. A less active one can probably be backed up weekly. In all cases you should have several iterations of your blog stored at any time to guard against bad backups or any corruption not being swiftly detected.

As far as how to do it, there are actually many different ways. If you’re more technical and want to do it yourself, Franky wrote an excellent guide on how to make database and file backups using cron jobs last year. However, for those who want an easier way and are willing to use a third-party service, there are two great options.

1. Backupify: Backupify works with both WordPress and Blogger blogs to create daily backups of your site and store them remotely and securely on their servers. Best of all, a basic account is free and you can also backup other services, such as Twitter, Flickr and Gmail accounts. Very simple to use.
2. Site Auto Backup: Created by Hostgator, Site Auto Backup makes it easy and cheap to backup your site. If your host uses CPanel, which many if not most do, SAB will use your built-in backup feature to backup your files and databases. This makes it easy to transfer your site to another host in an emergency. If your host doesn’t use CPanel, you can configure to backup via FTP and MySQL. A 1 GB account, which should be adequate for most blogs, cost $2 per month.

However, no matter what service you use or if you do it yourself, you need to make these backups and keep them in a safe place. Should something happen, you’ll be able to restore your site quickly and easily with a minimal amount of data loss.

It’s a small effort to make to protect all of the hard work you’ve put into your blog.

Bottom Line

In the end, the important thing to remember is that technology is fallible. Hard drives fail, servers die, natural disasters happen and mistakes are made. Your data can be wiped out at any moment and, without a backup, you could find yourself losing a large portion of your work.

You have the choice of either spending a little time and energy on setting up a good backup plan now, or waiting until a disaster happens and spending many times that trying to recover.

You owe it to yourself, your readers and your blog to make sure your backups are solid and ready to roll when needed. Doing anything less is only an invitation for disaster to strike.

I was sure I had a backup.

Most database plugins for WordPress offer the option to weekly backup your database and even email it to you but if you have a popular site, you might want to prefer a more frequent backup routine. Imagine how many posts and comments Gawker would lose if they only kept weekly backups and suffered problems the 6th day after their last backup.

Another problem with all database plugins is that they will not backup your files. With server storage space being really cheap nowadays, you can easily have several backup procedures in place, even if you host many pictures on your blog.

Personally I have three different, totally automated backup routines, using cron jobs:

1. Daily backup
2. Weekly backup
3. Monthly backup

The reason why I also use weekly and monthly backups is because if you have a corrupted database, probably your daily backups will be corrupted and unusable. This can happen on sites you do not use on a daily basis.
Daily backups are overwritten every 7 days, weekly and monthly backups are stored with attached timestamp.

Because most web hosting companies offer cPanel in their package, this tutorial is based on cPanel but the syntax is the same for Plesk and other backends.

What Are Cron Jobs

From Wikipedia:

Cron is driven by a crontab, a configuration file that specifies shell commands to run periodically on a given schedule.

Backing up your database.

In your cPanel (http://yoururl/cpanel) under the header Advanced Tools, you will find a link Cron Jobs. Click this link or click the icon on the right if your cPanel is setup with icons.
On the next page choose Advanced (Unix Style). There is no real difference between both options, the needed attention level is the same and in both simple and advanced you have to fill in the correct command.

The screenshot shows the daily cron jobs I have setup for my own blog (minus sensitive information of course).

The Command Line

The structure of the command line for the cronjob is following

mysqldump -udbusername -pdbpassword db_name | gzip > /home/cpanelusername/yourfolder/mysql_backup.gz

The different switches explained

• mysqldump
  This is the command to backup the database.
• -udbusername
  This is a double switch: the first part -u identifies the user to the database. Replace dbusername with your database username (if you have used Fantastico to setup your blog and don’t know those data, retrieve them from your wp.config file)
• -pdbpassword
  Again a double switch, with -p being the trigger to call the database password. Replace dbpassword with your password (if you have used Fantastico to setup your blog and don’t know those data, retrieve them from your wp.config file).
• db_name
  Here we add the name of the database we want to backup (If you have used Fantastico to setup your blog and don’t know those data, retrieve them from your wp.config file)
• | gzip
  Triggers the compression for the backup. This is not needed. If you don’t want to compress the backup, just skip this switch.
• /home/cpanelusername/yourfolder/mysql_backup.gz
  This is where we will store the backup and how it will be named. If you have opted not to compress the mysql backup, change the extension gz into sql. Of course you can name your backup and folder(s) differently.
  Feel free to be creative. I am boring conservative and save my backups in the folder /home/mycpanelusername/etc/dbase (Do not save your backups in a non-public folder, that is one level higher than your public_html/www/ folder. Use the cPanel File Manager to create this folder, or finally get a decent and free FTP-client). cpanelusername is the nick you use to login into your cPanel.

When do we run the script

Last thing to define is when to run the script. Cron Jobs follow an easy structure for this.

• Minute
  What minute of the time period. Values from 0 to 59
• Hour
  What hour. Values from 0 to 23
• Day
  What day. Values from 0 to 31 (remember the shorter months)
• Month
  Which month, 0 to 12, Gregorian Calendar.
• Weekday
  Guess… 0 to 7, 0 and 7 being Sunday.

Some examples for dates.

• 1 * * * * : Every minute after the hour, daily. * works as wild card, EVERY unit.
• 12 4 * * 3 : 04.12AM every Wednesday.
• 6 22 15 2 * : February, 15th at 10.06PM.
• 1 0 * * 1 : Every Monday at 0.01AM.

As can be seen in last example (every Monday), it is easy to create another job for every day (remember to give your file another name for every day as well: fe. mysql_backup-mon.gz and do this for every day of the week).

There also is an option to date stamp the backups but this might not work on every cPanel install and also is the best way to clutter your web space because probably you’ll forget to delete the old files anyway. This will overwrite your backup every time.

Adding a timestamp to the file name

Now we know how to create a daily backup cron job, it is easy to make a weekly backup and add the time and date to the file name.
In this example we are going to let the procedure run every Sunday at 19.45 server time and the backup will be named: weekly.

mysqldump -udbusername -pdbpassword db_name | gzip > /home/cpanelusername/yourfolder/mysql-$(date +%Y-%m-%d-%H.%M.%S).gz

The needed time values are: 45 19 * * 7. My weekly backup which ran yesterday is named: mysql-2009-12-20-19.45.28.tgz

To run a monthly cron job on the 15th of every month at 06.22, use the same command as for the weekly backup but for time you have to use 22 6 15 * *.

Emailing the backup

It is good procedure to store the backups somewhere else as well. You can easily email backup files. Be aware that daily or weekly backups can quickly take up lots of space in an email account and that there is a limit to file size for most email providers. To email a backup simply precede the command with MAILTO=yourbackupemailaddress (There is a space after your email address).

Backing up your files

Now we know how to use cron to backup your database it actually is very simple to backup files. Probably you do not need a frequent routine for these files and if you do, the only important folder is probably the wp-content folder as this is where your uploads, plugins and themes are stored.

First we are going to create another folder files for this backup. Navigate in your cPanel File Manager or FTP client to your root folder and chose again the folder etc. This is where we also created a folder for our databases. Now create a new folder named files.

To backup our wp-content folder weekly we are going to create a file called file-backup.sh and store this file in our home folder (your root folder).

#/bin/bash
/bin/tar czPf /home/cpanelusername/etc/files/wp-content-weekly.tar.gz /home/cpanelusername/public_html/wp-content/

This file will now create a backup named wp-content-weekly.tar.gz of your wp-content folder in the directory etc/files.

Go back to your Cron Jobs in cPanel now and now we need to call this file weekly. Use the following command to schedule your new cron job: /home/cpanelusername/file-backup.sh. To run this command every Sunday again, at 13.45 this time use 45 13 * * 7 for the time. This will weekly overwrite the backup, to save every week another backup with timestamp add -`date "+%Y%m%d%H%M"` to the filename in the new file we created, eg.

#/bin/bash
/bin/tar czPf /home/cpanelusername/etc/files/wp-content-weekly-`date "+%Y%m%d%H%M"`.tar.gz /home/cpanelusername/public_html/wp-content/

Remember that if you have many large files you could run out of web space after some weeks if you do not regularly back them up on your computer and delete old files.

Photo credit: Daryl Mitchell.

Note: I originally wrote the first part of this tutorial more than 2 years ago on iFranky.

Ok, ’nuff about teeth, backup these days are equally important though. If you’ve been situated where there was “hair pulling” and “table banging” because you failed to backup, here’s a tool that may make you avoid that horrific episode.

The Imation Apollo Pro WX Hard Drive.

It’s a USB wireless hard drive (comes in 250GB to 1TB storage capacity) that you can hide anywhere within 30 feet AND STILL be able to access as if you’ve got your own “data cloud” at home. Comes pre-packed with data security features that ensures you private and sole access to it. No worries about the neighbors trying to peek in and create havoc with your files.

Right now, it works with the Dell Latitude and XPS models AND with Kensington’s four-port Wireless USB Docking Station. Soon enough, I’m sure it will expand its compatibility to a lot of PCs and notebooks.

It will be available Q4 of 2008. No price listed yet.

Basically, what this means is that I pay about 20 – 24$ a year for a safe and reliable backup of about 10 GB of data. Not too shabby, eh? If you’re looking for safe and very cheap backup, I would really recommend Amazon S3. No need to worry about malfunctioning external disk drives, burning backup CDs/DVDs all the time or other issues. Transfer the files to Amazon and you’re safe!

There are also recommendations for various tools you can use to access the S3 service. I, for one, am excited to give the service a try to back up all my personal photos, coding projects and design work. Check out Ryan’s post for more details.