This is an excerpt of my guest blog entry on osSupportDesk's blog. There's a link to the full article below.Web site backup comes with its own set of limitations and pitfalls. If you trust your web host for backup you might find your expectations fall short. Most hosts take daily backups – if any at all –on a secondary hard disk on the same server or, even worse, on a secondary partition of the same hard disk. If the server goes down due to a hardware fault, so does your backup. A few enlightened hosts also take backups on remote storage, for example NAS arrays. Even they do so on rather sparse intervals, for example twice per week. This means that on a complete catastrophe you will most assuredly lose a fair amount of data.

The solution is simple in concept. Take your own backups and store them on a cloud storage service, like Amazon S3. Taking your own backups means that you get to decide which data and how often has to be backed up, making sure that the crucial, regularly updated information routinely ends up in a backup archive. Using a cloud storage device adds a strong data safety clause to your procedure, while keeping costs low. Cloud storage is designed to be redundant and reliable, boasting a negligible risk of data corruption or data loss. Combined with its incredibly low cost, it is reasonably attractive to businesses of all sizes: from hobbyists and sole proprietorships up to large corporations and government agencies.

Read the full article on osSupportDesk

We live in a potentially hostile world. Spammers, scammers, hackers and - alas! - script kiddies are after our site, for all we know. It's bad if - like most people - your site is your personal page. It's humiliating if - like many - it's the internet presence of your company. It's devastating if you are one of those people whose site is their business. Having regular, automated full site backups is a good first step, but they're only good at fixing a disaster after it has happened. Putting restrictions and controls (such as firewalls and tough passwords) is essential, but only if they don't fail. As Einstein bluntly put it "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former". An ingenius hacker, or a stupid script kiddie, might stumble upon a way to bypass your security controls and gain unauthorized access to your site. They can even hack you yesterday and eploit their back door today.

So, what can we do? Sit around, act casual until disaster strikes? No, not at all. What we need is a proactive check of our site files. If anything unusual is added, removed or modified the equivalent of a red alert should go off in our head and force us to take measures to contain and fix the problem before it's too late. It all boils down to an easy way to get a difference between the current state of our site and the last (and also known good) state of our site. This is the question I tried to answer with JoomlaPack SiteDiff.