Uptime, and the 99.99% scam

If you have looked at the websites of hosting providers on the web you can’t fail to have seen claims of 99.9%, 99.99% or even 99.999% uptime. The higher the number, the better the deal, right?

The answer is “not necessarily”

It all boils down to the SLA (Service Level Agreement). This is an agreement that the hosting business gives to its customer to keep their site online, or rather it is an agreement that the downtime will not exceed a certain threshold.

So what exactly is 99.9%, or 99.99%?

Availability Downtime per year Downtime per month
99% 3.65 days 7.2 hours
99.9% 8.76 hours 43.8 mins
99.99% 55.5 mins 4.38 mins
99.999% 5.26 mins 25.9 seconds

Looking at the above figures you can see how little time per month a site can be down in order not go over the SLA.

Ask yourself the question, when can they reboot a server, apply security patches etc? In Enterprise environments (Banks, Medical environments etc) there is a LOT of infrastructure in place, failover servers, mirrored storage, even backup data centres! In all but the most expensive hosting solutions you cannot expect this same level of SLA…. yet some places advertise it?

So… what’s the catch? Is it too good to be true?

In a word, yes. Most of these places cannot promise to have uptime to that level. Realistically most months they will probably manage it easily, but when something goes wrong (as it does for all companies, even Microsoft) then there will be downtime and it will be more than 4.38 mins a month!

So how can companies advertise an uptime level they cannot hit? Are they lying?

This is the clever (or sneaky?) part. An SLA is an “agreement”, not a promise. It means that if the agreed level is breached then the business will compensate the customer, be it in service credits or cash refund. The level of this is completely dependent on the business terms and conditions (or contract).

I have seen some hosting companies (no names) state “we will compensate downtime that is in excess of our SLA at our standard rate”. In this case it was a cloud provider that charged by the minute. In effect they were just saying that for every minute your server is offline you will be refunded a minute’s charge. So on that deal they may as well say they have a 100% uptime SLA, it makes no difference.

In Enterprise situations there are vast penalties for exceeding SLA’s, so a lot of thought and planning goes into meeting them, but in your general Internet hosting provider’s case they generally have small print to avoid high penalties, so they can get away will boasting about massive uptime SLA’s in order to bring in new business, without worrying about what happens if things go wrong.

So are we all doomed?

No, not at all. servers are generally quite reliable, and month on month most providers will hopefully give you 100% uptime. The way to judge a good hosting provider is not what uptime SLA they promise, but how they react when things go wrong. Do they react quickly, do they keep you informed, and do they solve the problem and explain why it happened if you ask?

A good web host is worth their weight in gold, just not for the simple reason of a 99.999% SLA.

Backing up your family photos

It’s a while since I have posted about backup strategy but it’s such an important topic I thought it was worth a revisit.

If you are like me you probably have all sorts of data around your house, across multiple computers, phones and devices. While everyone is different, I think most people would agree  that in the event of losing their data “en mass” the most devastating would be the loss of their family photos.

While the risk of losing photos due to water damage, sunlight, or general wear and tear is a lot less, the biggest risk nowadays is hard drive failure. I have seen many examples of people taking their dead hard drive to their designated “techie friend” in the vain hope that it could be recovered. Sometimes it can, sometimes it can’t, and often even if it is possible it involves significant cost.

Companies are pushing bigger and bigger hard drives, NAS devices, USB sticks etc upon us, and it’s great that we  can now store years and years of data on these, but in actual fact the situation (and risk) is getting much worse. Where you used to have your photos stretched over 4, 5 or 6 devices, now you can fit them all on a single hard drive… so why not? The answer is simple, if that device fails you lose EVERYTHING!

Yes it is possible to have 2 hard drives and backup everything twice, but in reality how many people do that?

NAS devices also allow you to configure them in RAID mode, where you can use two disks together and the data will survive if one fails. The problem is you can also configure them where they use the full capacity of the two disks (RAID 0), which looks on paper to be great…. more disk space than you can shake a stick at. The problem is you’re back to losing a lot of data if a disk fails.

The other issue is how often you actually backup your data. Most people find that when they have a failure it’s been “quite a while” since they last backed up.

The best situation is to backup automatically. To have a system where you don’t have to think about it. There are services such as CrashPlan which offer this service if you have a reasonable internet connection. It’s great as it keeps your data safely off-site, so if you has a flood or fire you can always get your data back. CrashPlan also allows you to setup your own servers (or peer to peer with a friend) so you can backup to those instead (or as well!).

The ideal situation is to backup to multiple places, having several copies of data in multiple locations. This is a lot to consider for a lot of people, so that’s why I often recommend CrashPlan, as it is simple to use and doesn’t cost the earth. If you don’t want to go that route then by all means continue to use hard drives, but please consider buying a second one, using that as well, and keep it in a different location to the first one.

If you have any comments or questions please leave a comment.

Why you should not use VMWare snapshots

Snapshots in Virtual Machines are a great idea. They allow you to test out changes safe in the knowledge that you can revert if necessary, without any clutter left behind from an uninstall. They are brilliant for that!

This post comes off the back of seeing many people using VMWare snapshots as some form of backup system. DO NOT DO THAT!

I cannot stress enough that a VMWare snapshot is not a backup at all. The snapshot is kept in the same location as the main storage files, so if you lose the storage that your main VM is kept on you also lose the snapshots.

If you want to use a VMWare specific method of backing up you need to be looking at exporting your VM as a template. You can then farm that off to some safe location and use it to restore if necessary.

Unfortunately this is not explained well by VMWare at all, leading to all sorts of confusion and people using the technology for the wrong purpose.

Added to this, when you have a snapshot VMWare stops using your primary storage file and starts writing the changes to other files (delta files). This results in you using a lot more storage than anticipated and also puts a much higher load on the I/O system.

To conclude, snapshots are great, but use them as intended, for a short term to prove changes in a system. Once you have done that, delete them quickly. The longer you leave it the longer it will take, as VMWare has to merge back in all the delta changes to the main storage file before removing a snapshot and this is SLOW!



HTTPS has always been used to secure websites that contain sensitive information such as Credit Card numbers, but most web site owners tend not to give it much thought outside those requirements.

In 2014 Google announced it was starting to give a slight ranking advantage to HTTPS sites over their HTTP counterparts. This started out as being pretty much a tie-breaker scenario, where two sites were otherwise equal it would rank the HTTPS site first.

Last year Google also started actively looking for HTTPS content ahead of HTTP content. That means if your site supports both protocols Google will automatically look for the HTTPS version.

With the advent of HTTP/2 and it’s current requirement of HTTPS now is a good time to consider switching over to HTTPS. As well as giving your users a more secure experience you also have the added benefit of being in a good place to support HTTP/s if your host supports it.

HTTP/2… why you should care!

HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web”

Now we have that out of the way, there are a few reasons to take notice of this and a few things you may want to do in order to take advantage of it.

What is wrong with normal HTTP?

HTTP is old… in terms of the Internet it is very very old indeed. It was standardised in 1997, when a lot of web developers were still learning learning to walk! It did the job, but as websites became bigger and more complex it was a constant struggle to get the site to display at a reasonable speed, even with modern high-speed connections.

The crux of the issue is the fact that sites are made up of lots of files and the HTTP protocol only allows a certain amount of transfers at the same time. This increased over time but there has always been the situation whereby files sat in a queue waiting to be downloaded by the browser.

What web developers started to do was use techniques such as merging multiple CSS files into a single one, using CSS sprites so icons were downloaded in a single file. All this to get around the queueing system. There was also the problem that if some files got “stuck” then everything else had to wait in line, causing very erratic behaviour at times.

How does HTTP/2 help?

HTTP/2 does away with the queuing system by using something called multiplexing. Without going into the finer details it basically means that browsers can download a lot more content at the same time (if the browser and server both use HTTP/2) and things should perform a lot faster.

Server pushing is also used in order to speed up the rendering experience. In the pre HTTP/2 world the browser downloads the full HTML page first, then starts grabbing the assets it needs such as CSS files and javascript. With HTTP/2 the server is able to send over files it knows the client needs into the cache, so by the time the HTML file is loaded the assets files have also started to arrive. Add in header compression and you have a much more streamlined method of loading pages

So what’s the catch?

While technically there is no requirement for encryption to use HTTP/2, several implementations have said they will only support HTTP/2 over a TLS encrypted connection. There are several reasons for this, which may or may not change over time, but for now you must use an HTTPS connection to take advantage of HTTP/2.

What this means to most users is they must have an SSL certificate for their domain, if not their users will get nasty messages about unsecured connections and/or mixed content.

Should I use HTTP/2?

Google have already stated they are starting to give sites using HTTPS a slight advantage in the ranking mechanism, so now is a good time to at least consider using HTTP/2 for your sites.

That said, HTTP/2 is very new and currently only supported by a hand full of hosts. For now if you convert your site to use HTTPS you will be in good shape to enable HTTP/2 as soon as it is supported on your host, and thus take advantage of a very real boost in performance!