Backups you can actually restore when something fails

Almost every organization has backups. A task runs, a schedule sits in a control panel, and now and then an email comes in that nobody reads. The question that is rarely asked is a different one: when did someone last try to get something back out of it? Usually the answer turns out to be never, and you only find out on the morning a server no longer boots or an employee has emptied a folder.

A backup that has never been restored is an assumption

A green check mark means a task finished without an error message. It does not mean the database was written consistently, that the files are complete, or that you still know which password goes with the storage. We run into all three, usually in the same week they turn out to be needed.

That is why this work starts with a restore for us, not with a schedule. We fetch an existing backup, restore it to a test environment, and look at what actually comes out. You know right away what is missing, at a moment when it costs nothing. If something does not work, we tell you directly instead of burying it in a report.

How much work may you lose, and how long may you stand still

These are the two questions everything hangs on, and they differ per system. Accounting that is written away once a night is fine; for an order system that people work in all day, losing a night of entries is a problem. The other way around, an internal wiki can be down for two days without anyone noticing.

So we go through your systems one by one and put two numbers next to each: how much work you may lose at most, and how long you can go without that system. Those numbers decide the rest. They decide how often we copy, where the copy sits, and whether with Managed databases we work with snapshots of the transaction logs instead of a nightly dump. It is not a technical discussion; it is a conversation about how your business runs.

Copies in several places, including outside your own environment

A backup that sits on the same machine as the data protects you against a deleted file and against nothing else. Fire, a failed storage controller, or ransomware with admin rights simply take the copy with them. So we always make sure there is at least one copy outside the environment it protects, with its own credentials that are not stored on the server itself.

Those copies sit in our managed environments, in a different place from the systems they protect. Data stays within the EU and you stay the owner: if you switch providers, the backups go with you. If your environment runs on Dedicated servers, we connect the backup traffic to the same internal network, so a full restore does not have to go over the public connection. If you have to keep working during an outage instead of recovering, High availability and failover belongs with that; a backup is a safety net, not a second working environment.

The recovery plan you have practiced once

On the day itself there is no time to figure out who has access to what and in which order the systems have to come back. So we record it in advance: what comes first, who calls whom, where the credentials are, and what your customers hear in the meantime. Two pages, not a binder nobody opens.

We practice that plan periodically, and afterward we adjust it to what went wrong in practice. Meanwhile our systems monitor the backup tasks, and a failed task goes to a person through an agreed escalation. So you know where you stand before things go wrong.