Infrastructure: where your data lives, and how long it takes to leave

Infrastructure is where your data lives: a server in a room, space rented from somebody else, a storage box and its copies. It is the only family in this pillar that produces nothing you can show a visitor.

It is also the one where a mistake is paid for longest. A bad computer gets replaced in a day; a bad hosting decision is dragged along for years, because the data was written in a format belonging to whoever hosts it.

The comparison we are asked to make is almost always the wrong one: local or cloud, this price against that price. The question that actually decides sits elsewhere, and this article has one purpose — to put it in the other one’s place.

It fits in a sentence: how many days would it take to leave, and whose agreement would be needed? The three pages below this one — hosting, the server, storage and its copies — rank correctly the moment that question comes before price.

The local-versus-hosted debate is a comparison of invoices, and it never resolves because it sets against each other two things that are not paid at the same moment: a purchase against a rent.

Replace it with one question and it resolves immediately: if you decided tomorrow to change supplier, how many days would it take, who would have to agree, and in what format would you get back what is yours?

That question has the merit of being answerable today, at no cost, and of producing a number. Three days, three weeks, or "nobody knows" — and "nobody knows" is an answer in itself, the commonest and the most expensive.

It also ranks the three pages below this one without argument. A server you own has a short exit delay and a high upkeep cost; a rented service has the reverse; local storage with copies elsewhere is the compromise we recommend most often because it keeps both exits open.

One thing cannot be recovered from: a proprietary data format. The day your ten years of invoicing exist only inside the database of a publisher who refuses to export, the exit delay is no longer long, it is infinite, and no sum shortens it.

One rule survives every fashion in this family, and it predates computing: what exists in only one place does not reliably exist. The rest is a question of implementation.

Elsewhere means another building, not another cupboard. A theft, a fire and a flood take the whole room, and the copy sitting beside the server has exactly the same address as the original. We see that arrangement everywhere and it is presented as a backup.

The local case deserves saying plainly: when the outbound connection is narrow, sending a full copy every night is not realistic. The answer is not to give up, it is to separate — what changes daily goes over the line, what is bulky and stable goes onto a disk somebody carries away.

That carried disk is infrastructure, even though it does not look like a product. It needs a written routine, encryption, a place where it sleeps, and a named person. Without those four things it becomes, within three months, a disk nobody knows the contents of.

Verification, as everywhere in this pillar, is a test: ask to restore a file from six weeks ago, today, with no warning. What you learn in ten minutes is worth more than anything this section can write.

In much documentation, power supply is a building subject. Here it is an infrastructure subject, because the outage is the only event that reaches the server, the storage box, the switch and the connection at the same time.

What an outage breaks is not the hardware, it is the write in progress. A database interrupted mid-write can come back inconsistent, and an inconsistency is a fault discovered days later, once the faulty copies have already replaced the good ones.

So the power protector is not there to let you work through the cut. It is there to give the machine time to shut down cleanly, which takes two minutes rather than two hours. A properly configured unit shuts the server down on its own; an unconfigured one is an expensive extension lead.

Three checks that cost nothing and that almost nobody has run: is the machine actually plugged into the protected outlet, does the unit have a data cable running to it, and has the battery been tested since installation? A battery lasts a few years and dies without signalling anything.

And the same logic applies to what is not the server: an unprotected switch cuts the network while the server itself runs perfectly. Protecting the machine and leaving the network layer on the mains produces exactly the same lost day.

What we will refuse: running a migration whose exit has not been tested, and delivering a backup whose restore has not been performed in front of you. Those two refusals remove this family’s two easiest sales from our catalogue.

We will also refuse to create your hosting, domain or licence accounts under our own name, even when it is quicker and even when you ask us to. That convenience is what produces, four years later, the shut door described in section 6.

We will refuse to quote availability as a percentage. We can tell you how long we take to get you running again, because that is something we can do in front of you; a percentage is a clause and we do not sell clauses.

What we do: the recovery delay measured once on your real data; the second copy in another building, with an older state kept; the six accounts in your name with a recovery method that belongs to you; clean shutdown on an outage verified rather than promised; and an export opened in front of you before any signature.

And what you can do this week without us: take a file at random, deleted or modified six weeks ago, and ask to get it back today. The time that takes is your real infrastructure. Everything else on this page only comments on that number.