A website rarely disappears with advance notice. An update goes wrong, an account is taken over, a delete command hits the wrong directory, or an encryption attack freezes the very machine that still held the last usable version. What happens next decides between hours and weeks, and it decides almost entirely on things settled beforehand: how old the last backup is, where it sits, who can reach it, and whether anyone has ever tried restoring it. This article describes the way back for a business without an in-house IT department. It sorts four questions: what scope belongs in a backup, how long each state is retained, how a restore drill runs, and what belongs on a sheet of paper that stays readable when no computer starts up any more.
What is actually missing in an emergency
The sentence heard most often after an outage is: but we do have a backup. The second sentence is: we just do not know how old it is. In small businesses that order describes the normal case rather accurately.
A backup exists, it has not been restored so far, and its scope is unclear because the website grew over years and nobody keeps an inventory. What is missing, then, is rarely the backup itself. What is missing is the chain behind it: a known scope, a known age, a known storage location and a person who can reach it without having to call somebody first.
The threat figures are clear enough to justify the effort. Almost every second company was hit by a ransomware attack within twelve months, namely 45 percent (Bitkom); 25 percent suffered damage as a result (Bitkom). And the attacks are far from aimed at large corporations alone: around 80 percent of reported attacks were directed at small and medium-sized companies (BSI). In its status report, the Federal Office for Information Security lists the cost of restoring IT systems as a separate item alongside the revenue lost during the standstill (BSI).
The second finding is the more uncomfortable one. Asked why an attack led to damage at all, 59 percent of the companies that suffered damage name inadequate detection of security incidents as the main reason (Bitkom). Whoever notices an incident late keeps backing up the damaged state in the meantime. That is why availability checks and outage alerts and backups belong together: one measure determines how early you notice that something is wrong, the other how far back you have to jump to reach an undamaged state.
A backup and a restore are two different things
Two numbers that set the effort
Before technology matters, two business decisions are due. First: how much work may be lost?
The BSI carries this figure in module CON.3 of its IT-Grundschutz compendium as the maximum tolerable data loss, the recovery point objective, and states that it should be taken into account in the backup concept (BSI, IT-Grundschutz). Second: how long may the website be gone before it gets expensive? Neither answer is a technical value; both are statements about the business. A trades business with a contact form works with different numbers than one selling courses or booking appointments through its site.
- Tolerable data loss. Back up once a day and you lose a working day in the worst case: new posts, changed prices, uploaded images, incoming form submissions.
- Tolerable downtime. It covers not only the restore, but noticing, deciding and obtaining credentials. Experience shows the technical part is the shortest one.
- Order of return. First a reachable page with a way to make contact, then secondary functions. Module CON.3 requires exactly this to be set per system in the backup plan (BSI, IT-Grundschutz).
- A named person. One person in charge, one deputy. Without a deputy, a holiday is already the outage.
- Evidence. A short log per run, so that nobody later has to guess which state was complete.
These four or five lines do not replace a formal concept, but they answer the questions asked first in an emergency. What matters is that the numbers are written down rather than kept in someone's head. A single sheet that fits in the folder is enough. Only then does it make sense to talk about storage locations, retention periods and tools, because those decisions follow from the numbers and not the other way round. Anyone who has already reduced the attack surface of their own website holds the second half of the same calculation: the less exposed day-to-day operations are, the less often the way back is needed.
Website: www.example.invalid
Tolerable loss: 24 hours (daily backup, overnight)
Tolerable outage: 4 hours (working day, 08:00 to 18:00)
Order of return:
1. Home page, contact page, imprint (reachability)
2. Service pages, blog (content)
3. Form intake, appointment booking (functions)
In charge: owner
Deputy: office manager
Access to the backup: both, stored separately
Log: folder "Website/Backup", one sheet per quarterScroll table sideways
| Case | What breaks | What it is restored from |
|---|---|---|
| Faulty text change | One page, visible at once | Previous version of the same page |
| Failed update | Layout or function of the whole site | Last state before the update |
| Account takeover | Content and possibly the credentials themselves | An older state verified as undamaged |
| System encrypted | Everything in one location, often the backup too | Copy at a second location, not overwritable |
| Provider outage | Reachability, not the data | Own copy delivered by another route |
| Accidental deletion | Individual files or a database | Daily state, as recent as possible |
The case that defeats most concepts
What counts as the website and has to be included
The most common gap is not technical but a question of scope. What gets backed up is what somebody understands as the website, and that is usually less than what is needed to operate it.
If a single part is missing later, the rest helps little: the pages are there but the domain points elsewhere; the content is there but form intake is missing; everything is there but nobody can reach the provider account because it lived in a mailbox that went down with it.
So it pays to write a complete inventory once. It is not a large document, but a list with one line per component and a note on where that component sits and who may change it. Anyone who has already sorted out roles and permissions in website maintenance can derive this list from it. It is also the basis for the handover value of a website in a business succession, because the same inventory answers the question of what is actually being handed over.
- Page content and structure. Copy, headings, section order, menu structure, redirects from old addresses.
- Images and files. At the resolution they were uploaded in, not only in the delivered version.
- Settings. Colours, fonts, consent dialogue, form recipients, language versions.
- Legal pages. Imprint and privacy policy including their date, because they are part of the site's provable state.
- Domain and name resolution. Registrar, expiry date, records for web and email. Without these, the restored site points nowhere.
- Credentials. Provider account, domain account, mailbox for system notices, access to the backup itself.
- Form submissions. Incoming enquiries are business records and usually not part of the site files.
- Evidence. Logs of the backup runs and the date of the last verified restore.
How old the last backup may be
A single daily copy that is overwritten every night is the most common arrangement and at the same time the weakest. It helps against mistakes noticed the same day, and it fails at everything noticed later.
That is precisely the normal case: an account takeover often only shows up once the damage becomes visible, and by then the recent copies already carry the damaged state. The way out is not a bigger disk but staggered retention.
Staggered means several rows with their own window, running side by side. Daily for the recent past, weekly for the middle range, monthly for the long view. Storage demand grows far more slowly than the number of return points, because the coarse rows hold few states. The only requirements are that the three rows do not overwrite each other, and that mirroring is not counted as a backup: mirroring via RAID systems is not understood as a backup, because the mirrored data is changed simultaneously (BSI, IT-Grundschutz).
Daily, 14 days
Covers mistakes and failed changes. This row is the only one that limits the loss to hours.
Weekly, 12 weeks
Covers damage noticed only after days. Twelve states are enough for a quarter of hindsight.
Monthly, 12 months
Covers gradual changes and later questions, such as the wording of a legal page on a given day.
Before each change
A state taken right before a larger intervention. It costs nothing and, in case of doubt, replaces any of the three rows.
Two locations
One on the premises, one outside. The separation is the requirement, not the technology behind it.
Not overwritable
The running system must not be able to delete older states. Otherwise an account takeover carries off the backup as well.
Keys kept apart
If the backup is encrypted, the key belongs somewhere other than the backup.
A log per run
Date, scope, result. A run without output carries no signal that would reveal a persistent fault.
The drill that turns a backup into a restore
A backup nobody has restored is an assumption with a timestamp.
The BSI puts the requirement in module CON.3 unambiguously: backups are to be tested regularly to see whether they work as intended and, above all, whether backed-up data can be restored properly and within an appropriate time (BSI, IT-Grundschutz). The clause about appropriate time is the part businesses overlook most often. A backup whose restore takes two days does not meet a four-hour downtime commitment, even if the data is complete.
The drill has to be small, otherwise it does not happen. One morning per quarter is enough if it follows a fixed sequence and if the elapsed time is recorded. The drill runs against a copy, not against the live site. And it is run by the person who would have to do it in an emergency, not by the person who set the system up, because that difference is exactly what determines the time needed later.
Scroll table sideways
| Step in the drill | What is measured | Where it typically fails |
|---|---|---|
| Locate the backup | Location, access, age of the newest state | Access rests with a person who cannot be reached |
| Open the state | Completeness, readability | Key missing or kept in the same place as the backup |
| Restore the content | Time to a visible page | One component is missing, such as settings or images |
| Switch the address | Time to reachability under the domain | Domain access unknown, expiry date overlooked |
| Check the functions | Form, redirects, legal pages | Form recipient points to a mailbox that no longer exists |
| Record the result | Total duration, open points | Nothing is noted, the next drill starts from zero |
The drill has a second benefit that is often larger than the first: it produces an honest number for downtime. Whoever knows that number can decide whether it fits the business. If it does not, there are two levers: reduce the scope by keeping content and structure versioned, or arrange the credentials so that waiting time disappears. In small businesses the second lever is usually the more effective one, because waiting for credentials accounts for the largest share of the total duration.
What the drill says about preparedness
Credentials, keys and the second location
A restore rarely fails on files and often on permissions.
Whoever has to reach the backup in an emergency needs access to the storage location, to the provider account and to the domain account, and needs it independently of the system that has just failed. In module CON.3 the BSI also points to documentation: if the information required for restoring exists only in digital form, there is a risk that it is lost as well in a major incident such as ransomware, and the restore is then at risk (BSI, IT-Grundschutz).
- Keep backup access separate. Its own account, allowed to read and write only what it must, and not tied to the day-to-day sign-in route.
- Do not keep the key next to the door. If the backup is encrypted and the key is affected by the same data loss, the data cannot be restored (BSI, IT-Grundschutz).
- A second person with access. A deputy who knows the route and has walked it once. A stored list without a drill only counts half.
- A mailbox for system notices outside. Notices about expiring domains or failed runs must not sit in the very system that fails.
- Think about switching providers. Anyone who keeps credentials in order is in the same position when moving to another provider as in an emergency, only without time pressure.
It must be tested regularly whether backups work as intended, and above all whether backed-up data can be restored properly and within an appropriate time.
The emergency sheet that works without power
The emergency sheet is the cheapest measure in this whole article and the one missing most often.
It is a single sheet in a folder kept on the premises, and it answers the questions of the first hour: whom do I call, where is the backup, what is the provider called, what order applies, what do I tell customers. It contains no passwords, only the route to them, and once a quarter somebody checks whether the names and numbers still hold.
The sheet also carries one sentence for the outside world. To customers an outage is first of all a closed door, and a short, honest message on another channel prevents enquiries that cost time in an emergency. If personal data is affected as well, notification duties with their own deadline apply on top. The procedure for that is in the article on a data breach and the 72-hour notification, and it belongs on the same sheet, because otherwise nobody thinks of it.
AS OF: 2026-09-15 next review: 2026-12-15
1 CHECK REACHABILITY
Open the site from outside, mobile data instead of office network.
Is only the site down, or email as well?
2 MAKE THE CALLS
In charge: owner Deputy: office manager
Provider: customer number in the folder, tab 3
Domain: registrar, customer number in the folder, tab 4
3 BACKUP
Location 1: network drive "Backup" daily, 14 states
Location 2: separate storage outside weekly + monthly
Key: envelope in the safe, not in digital form
4 ORDER OF RETURN
Home + contact -> service pages -> forms
5 OUTWARD COMMUNICATION
Short note to existing customers, change the voicemail message.
Personal data affected? Then check the notification route.
6 KEEP NOTES
Time per step. Afterwards this sheet is the evidence.Why a versioned website shortens the way back
How long a restore takes depends on how many moving parts a website has.
A site assembled at request time from a database, a set of extensions and a bundle of settings has to be brought back in all of those parts, and each part can fail on its own. If structure, content and settings instead exist as a versioned configuration from which a statically delivered site is produced, the way back is a different procedure altogether: you pick an earlier state and publish again. How that route runs, from description to published page, is shown in how it works.
- Every publication is a return point. The way back does not stop at last night, it stops at the last change.
- The scope is known. Content, structure, colours, legal pages and form targets sit in one place rather than scattered.
- Fewer moving parts. What is delivered are finished files; database and extensions drop out as a source of failure during delivery.
- The way back is the way forward. Anyone who can publish a change can publish an old state. No new procedure has to be learned under time pressure.
- Separation is built in. The place where the site is built is not the place from which it is delivered. That follows the same idea as the rule to keep backups separate from the systems they secure (BSI, IT-Grundschutz).
The first steps this week
Getting started takes less effort than the threat figures suggest. One afternoon is enough for the inventory, a second for the first drill.
Anyone who does nothing beyond that has already shifted the largest part of the risk, because the expensive cases arise from not knowing one's own inventory rather than from missing technology. The following order has proven useful because each step is worth something on its own.
- Write the inventory. One line per component, with location and the person in charge. Include the components whose location is unclear.
- Establish the age of the newest backup. Do not look at the setting, look at the state that exists: date, scope, size.
- Set up a second location. Separate storage, its own credentials, older states not overwritable.
- Fix the staggering. Daily 14, weekly 12, monthly 12. These values are a starting point and can be adjusted after the first drill.
- Print the emergency sheet. Into the folder, not into a directory on the same machine.
- Run the first drill. Against a copy, with a clock, performed by the deputy. Put the result on the same sheet.
- Set a date for the next drill. One quarter later, with a name attached. Without a date the drill tends not to happen.
If a point stays open at the end, it belongs on the sheet rather than into oblivion. The same order helps outside an emergency, by the way: knowing which components a website has and where they sit also makes it easier to extend it cleanly, for instance with one page per service, and to check a business name and domain against trade marks before a rename, without first having to work out who actually holds the name. How such a setup comes about here is shown by the features and the demos.
Sources and studies