High availability or good backups?

Every hosting quote I review for a client has one of two problems. Either it sells "99.99 % uptime", failover and multiple data centres to a business whose app could go down for an afternoon without anyone losing a dollar. Or it has no real backup at all, and the owner finds out the day the server dies.

Both come from the same confusion: treating high availability and backups as the same thing. They are two different insurance policies, against two different accidents. And both miss the line that is on no hosting quote: who keeps the thing updated.

Two different problems

High availability (HA) keeps you online when a machine fails. Two or more servers run side by side; when one dies, the other takes over in seconds or minutes. You pay for it every month, whether anything breaks or not.

Backups get your data back after something goes wrong: a deleted table, a bad update, ransomware, a hacked account, a provider that loses a disk. You are offline while you restore, but you do not lose the business.

Here is the part that surprises people: high availability does not protect your data. If someone deletes your customer list, or ransomware encrypts it, the standby copies the damage within a second. The same goes for a poisoned software update. HA protects you from hardware failure. Only a backup protects you from mistakes and attacks.

So every business needs backups. Only some need high availability.

Where does your backup actually go?

Almost every host advertises "automatic backups". Ask where they are stored. Most of the time the answer is: on the same provider, often in the same data centre, managed with the same account. That protects you from a dead disk. It does not protect you from the provider having a fire, locking your account, or an attacker who gets your login and deletes the server and its backups together.

A real backup has a copy somewhere else — another provider, another location — encrypted before it leaves, and at least one version that nobody holding your server's keys can delete. That off-site copy is usually an option on the quote, not the default. Check for it before you compare prices.

The two numbers to decide on

Before comparing offers, write down two answers. Engineers have acronyms for them; you only need the questions:

• How long can you be offline? An hour, a day, a weekend? This is the recovery time objective (RTO).
• How much recent work can you afford to lose? The last day of orders, the last hour, nothing at all? This is the recovery point objective (RPO).

And put the famous percentages in hours. 99.5 % uptime allows about 44 hours offline a year. 99.9 % allows under 9 hours. 99.99 % allows 53 minutes. Each extra nine costs more than the last one, and most customers of a small business never notice the difference between the first two.

What each level costs per month

The same custom business app — your code and its database — on four kinds of managed offer, from a managed server in Canada to a platform with automatic database failover. Public prices of established Canadian and US hosts in September 2026, US prices converted at 1.40 CAD per dollar, with my own offers on the last three lines:

"With upkeep" adds the part none of these hosts do for a custom app: updating your code's dependencies, applying security patches, testing that a restore actually works. I counted two hours a month for A and B, three for C and D, which also need their failover tested — at about $100 an hour for a senior contractor. Your numbers may differ; the order will not.

Who keeps it updated?

"Managed" rarely means what owners think. A managed server means the host patches the operating system and answers when the machine is down. A managed platform means you never see a server at all. In both cases, your application is yours: its libraries, its framework, its database migrations, its security fixes. If nobody does that work, the app slowly becomes the easiest way into your company.

That is why the upkeep column is bigger than most of the hosting column. It is also why high availability is rarely the best place for the next dollar. A platform with automatic failover still replicates a bad migration, still runs an outdated library, and adds a failover of its own to test. Many of the outages I have seen were in setups built to avoid them.

Do the math with your own numbers

The right level is the one where the extra monthly cost stays below what the downtime it prevents would cost you. A rough formula for one hour offline: the margin on the sales you would lose in that hour, plus the wages of the staff who cannot work, plus any penalty in your contracts. Count margin, not revenue — and remember that many customers simply come back later.

A local service company — an accounting firm, a contractor, a clinic — with a client portal or booking app. Four hours offline on a Tuesday means a few clients try again later. The cost is close to zero. A fully managed server with an external backup, kept up to date, is the right answer. Moving to level D would add about $3,500 a year to protect almost nothing.

An online store doing $2 million a year. That is $228 of sales per hour on average, easily twice that at peak. If a single server means ten more hours offline a year than a standby would, that is $2,300 to $4,600 of sales at risk, some of it recoverable. Level C costs about $600 a year more than B: worth it. Level D costs about $3,500 a year more than B for the same few hours: only when every minute of checkout matters.

In both cases, the decision comes from a number you can write on a napkin, not from a vendor's uptime badge.

What to do, whatever level you pick

1. Keep a copy somewhere else. Off the server and off the provider. A backup at the same host goes down with the same account.
2. Encrypt it before it leaves. Your backup holds everything your database holds; it should be unreadable to whoever stores it.
3. Keep one copy the server cannot delete. Versioned or locked storage means ransomware or an attacker with your server's keys cannot erase your way back.
4. Keep your backups even with high availability. A standby protects you from a dead machine, not from ransomware or corruption: it copies them instantly. Only a backup takes you back to before.
5. Test the restore. A backup that has never been restored is a hope, not a backup. Do it on a schedule and time it: that is your real recovery time.
6. Name who updates the app. Dependencies, security patches, migrations: a person, a schedule, a budget. The host will not do it.
7. Watch it. Uptime monitoring and an alert when a backup fails. Many businesses discover their backups stopped months ago on the day they need one.
8. Move up a level only when the math says so. High availability is a business decision, not a technical badge.

How I price it

This is the gap I built my own hosting to close. For apps built with GoatCheese, fully managed hosting starts at $50 CAD a month for up to 25,000 visits: server and runtime patches, monitoring, an encrypted backup stored off-site with versions nobody can delete, scheduled restore tests, and the dependency security patches for your app — the upkeep column, included. Add $50 a month to lose at most an hour of data instead of a day, and $100 more for a standby server that takes over in minutes. Feature work is billed separately. For apps built elsewhere, the upkeep depends on the code, so it is quoted after a look at it.

Whoever you choose, ask the same three questions: where does the backup go, who updates the app, and what does an hour offline cost you. Pay for the need, not the brochure.