In short and in plain language
This article is about backing up your website. A site is often lost through a mistake. An attack is rarely the reason.
Back up every part. That means files, database, settings and mailboxes. If one part is missing, the site will not be the same after a restore.
A backup only helps if it really comes back. So test the restore on a regular basis.
Keep a copy in a different place. A backup on the same server is lost with that server. Data protection law also asks that data can be restored quickly.
We build your website and then take care of the backups.
A trade business rarely loses its website to an attack. It usually loses it to an update that went wrong, to a directory deleted by accident, or to a change of provider where nobody asked about the data. 94 percent of trade businesses run a website of their own (Bitkom), and in most cases it sits in exactly one place: on the storage of a hosting contract. If that one place fails, the question is not whether a backup exists, but what it contains, how old it is and who is allowed to restore it. 71 percent of the businesses surveyed say IT security matters a great deal to them, yet only 15 percent have clearly defined procedures for an emergency (Bitkom). This article describes what belongs in a backup, how often it should run, where it has to live and how you can tell that it will actually come back.
Key takeaways
- A website is made of four parts that have to be backed up separately: files, database, configuration and mailboxes. If one of them is missing, the site comes back after a restore, but not the way it was.
- A backup and a restore are two different things. The German Federal Office for Information Security notes that backing up data regularly does not automatically ensure that the data can also be restored without problems (BSI).
- The restore test is part of the procedure: it must be tested regularly whether backed-up data can be restored correctly and within a reasonable time (BSI, CON.3.A15). Without that test, a business can only assume its backup works.
- Data protection law requires the ability to restore the availability of personal data quickly after a physical or technical incident, and a process for regularly reviewing the effectiveness of those measures (Article 32(1)(c) and (d) GDPR).
- Backup media has to be kept physically separate from the systems it protects (BSI, CON.3.A12): one copy with the hosting contract, a second one somewhere else. A backup on the same server disappears together with the server.
What a backup actually has to contain
Anyone who wants to back up a website has to know what it is made of. The visible part is the files: the content management system itself, the extensions, the template carrying the company colours, the fonts and, above all, the uploaded images. In a trade business the image library is often the most valuable part of the site, because it exists nowhere else in full: the shots of the finished bathroom, the newly covered roof, the site in the rain. These files sit in the storage of the hosting contract and are delivered from there. If the directory is deleted, the images are gone, even if the database is still standing.
The invisible part is the database. It holds the texts, the page structure, the menu, the settings, the user accounts and, depending on the system, the enquiries from the form as well. The database is a separate service with its own files; a copy of the file directory does not contain it. This is where the most common half-loss happens: the images are there, the pages are empty. So when you order a backup, do not ask whether backups are made, ask what is being saved.
Two further parts tend to be overlooked. The first is the configuration: the web server settings, the redirects for old addresses, the records that keep mail delivery working, the credentials used to send form messages. The second is the mailboxes. Email usually sits on the same contract as the website, but it is backed up separately, or not at all. A business that writes its quotes by mail loses more with the mailbox than with the homepage.
| Part of the website | What it holds | What is missing without it |
|---|---|---|
| Files | Content management system, extensions, template, fonts, uploaded images and brochures | The page loads but shows empty image frames and lost data sheets |
| Database | Texts, page structure, menu, settings, user accounts, form enquiries | The images are there, the pages are empty and the login fails |
| Configuration | Server settings, redirects for old addresses, records for mail delivery | Old addresses lead nowhere and form mails no longer arrive |
| Mailboxes | Received and sent messages, folders, address book | The correspondence on current jobs is missing, even once the website is back |
| Access list | Who logs in where: domain, hosting, content management system, mailbox | The backup exists, but nobody is allowed to load it back in |
These five rows are the core of every backup question. They also show why a backup without the matching logins is worth little: whoever holds the data but cannot get into the contract has nowhere to put it. Who should own domain, hosting and logins is set out in detail in the article on domain and hosting in a trade business. The backup is the second half of the same question.
A backup is not yet a restore
Almost every hosting contract now includes some form of backup. The contract summary then carries a line such as: daily backup, seven days retention. That sounds like a settled matter, and in many businesses it is the only answer to the question of data backup. Only that line answers a different question from the one that gets asked in an emergency. It says that something is being written. It does not say that a working website can be rebuilt from it.
If data is backed up regularly, this does not automatically ensure that it can also be restored without problems.
The sentence comes from the IT-Grundschutz Compendium of the German Federal Office for Information Security, and it describes exactly the gap that shows up when damage occurs. A backup can be incomplete because the database is missing. It can be unreadable because the job aborted after twelve minutes every night and nobody read the message. It can be complete and readable and still not help, because it already contains the fault it is meant to repair: if damage is only noticed after ten days while retention covers seven, every version on hand is already damaged.
That is why the restore test belongs to the procedure and not to the category of good intentions. The compendium puts it as a requirement: it must be tested regularly whether the backups work as intended, above all whether backed-up data can be restored correctly and within a reasonable time (BSI, CON.3.A15). For a trade business that does not mean somebody spends an afternoon on it every month. It means the test has happened once, that its date is written down and that it is known how long it took.
The question that makes the difference
How often to back up and how far back
Two numbers decide how well a backup carries in an emergency. The first is the interval between two backups: it says how much work is lost in the worst case. If the site is saved daily at three in the morning and fails at five in the afternoon, a working day is gone. The second number is retention: it says how far back you can reach. Seven versions cover a mistake that is noticed the same day. They do not cover a mistake that goes unnoticed for three weeks.
For most trade businesses a daily backup with fourteen to thirty retained versions is a workable arrangement, because the site rarely changes several times a day. The picture is different on days when somebody deliberately intervenes: a new service page, an updated price list, a rebuilt homepage. Before such work an additional version belongs in storage, created before the change starts, not afterwards.
A separate question is how long records have to be kept at all. There is no statutory retention period for the website itself. For the commercial records created in the business there certainly is: the records listed in subsection 1 number 1 are to be kept for ten years, those listed in subsection 1 number 4 for eight years and the other records listed in subsection 1 for six years (section 257(4) of the German Commercial Code). Anyone who handles quotes and invoices through the website mailbox should therefore not keep those records in the mailbox alone.
- Daily: files and database of the website, automatically, with a message to an address that is actually read in the business.
- Before every intervention: an additional version, created before the update or the content change begins.
- Weekly: a copy in a second location, separate from the server the website runs on.
- Monthly: a look at the messages. Did a confirmation arrive every night, or are single days missing?
- Once a quarter: a restore test into a test environment, with date and duration in the record.
- When changing contracts: a complete version as a file in the hands of the business, before the old contract ends.
This rhythm costs little in day-to-day work, because four of the six points run automatically. Effort only arises where a person has to look. In our experience those are exactly the points that go missing, and for good reason they appear in the collection of common mistakes on trade websites: a backup whose error message goes to a mailbox nobody opens is not a backup, it is a noise.
Where the backup has to live
A backup that sits on the same server as the website protects against exactly one case: accidental deletion. It does not protect against a failed disk, a fire in the data centre, an account that was cancelled and then cleared, or an attacker who gains access to the server and deletes the backup folders along with everything else.
The compendium puts this as a requirement: the storage media for backups must be kept physically separate from the systems that have been backed up (BSI, CON.3.A12). For a trade business that does not mean a second server room, it means a second location: a storage target with another provider, an encrypted copy on a disk in the office, a data carrier in the tax adviser's cabinet. One detail stated explicitly in the compendium matters here: if the backup is encrypted and the key is lost together with the data, the backup is useless. That could be the case if nobody thought of keeping the key separately (BSI). So the key does not belong in the same place as the backup.
- First location: with the hosting contract itself, created automatically, quickly at hand for the everyday mistake.
- Second location: a storage target outside that contract, still reachable if the contract has been cancelled or suspended.
- Encryption: sensible as soon as personal data is involved, so at the latest with form enquiries and mailboxes.
- Key storage: separate from the backup, recorded in writing, known to at least two people in the business.
- Access rights: the business itself has to reach both locations, not only the service provider looking after the site.
The second location is the one that counts
What data protection law requires
As soon as the website carries a form, personal data is processed, and Article 32 of the General Data Protection Regulation applies. Among other things it requires the ability to restore the availability of the personal data and access to it quickly in the event of a physical or technical incident (Article 32(1)(c) GDPR), and in addition a process for regularly reviewing, assessing and evaluating the effectiveness of the technical and organisational measures (Article 32(1)(d) GDPR). The backup is therefore not a voluntary precaution, and the restore test is precisely the review that point (d) has in mind.
Under data protection law, losing data does not weigh less than data leaking out. A personal data breach is a breach of security leading, whether accidentally or unlawfully, to the destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data (Article 4(12) GDPR). A deleted mailbox holding customer enquiries falls under that, even if nobody outside the business ever saw anything.
| Requirement | Where it comes from | What the business does about it |
|---|---|---|
| Restore availability quickly | Article 32(1)(c) GDPR | Daily backup of files, database and mailbox, stored in two locations |
| Review effectiveness regularly | Article 32(1)(d) GDPR | Restore test with date and duration, at least once a quarter |
| Keep backups separately | BSI IT-Grundschutz, CON.3.A12 | Second storage location outside the hosting contract, key kept separately |
| Report within 72 hours | Article 33(1) GDPR | A named responsibility in the business and a note on who to call in that case |
| Retain commercial records | Section 257(4) German Commercial Code | Do not keep quotes and invoices in the mailbox alone, file them separately |
The table shows that backups and legal texts belong together. If your privacy notice says that the data from the form is protected, you should also be able to say how long it stays in the mailbox and where a copy of it lives. Which details have to appear on the site itself is covered in the article on the legal notice and privacy page for trade sites.
When a data loss has to be reported
A backup plan on a single page
A backup policy for a trade business fits on one page. It does not have to be pretty, it has to be answerable: what is saved, how often, how long it is kept, where the second version lives, who receives the message, who may restore, when that was last tested. Seven questions, seven lines. Anyone who cannot answer them does not have a plan, they have a hope.
The plan belongs somewhere it will be found in an emergency, and that is not the computer that has just failed. A printout in the folder, a copy with the tax adviser or a file on the owner's phone all serve the same purpose. The structure below has proved itself as a note, because it fits into any handover record and can be read out in a single breath.
{
"domain": "musterbetrieb-dach.invalid",
"saved": ["files", "database", "configuration", "mailboxes"],
"interval": "daily 03:15",
"retention": "30 versions",
"firstLocation": "hosting contract, automatic",
"secondLocation": "storage target outside the contract",
"encrypted": true,
"keyHeldBy": "owner, in writing in the contracts folder",
"alertOnFailure": "buero@musterbetrieb-dach.invalid",
"restoreAllowedBy": ["owner", "service provider"],
"lastRestoreTest": "still to be filled in",
"durationOfLastTest": "still to be filled in"
}This note is also the template for the conversation with the service provider. Anyone planning to have a trade website built should put the seven questions before placing the order and have the answers written into the quote. After acceptance the negotiating position is weaker, and the answers then cost time instead of one sentence in the contract.
What is saved
Files, database, configuration and mailboxes as four separate items, each named individually. An item that is not on the list is, as a rule, not saved either.
How often and how long
Interval and retention belong together: the interval sets the possible data loss, the retention sets how late a mistake may still be noticed.
Where the second version lives
Physically separate from the system it protects, with the key kept elsewhere and an access route the business owns rather than has to ask for.
When it was last tested
A date, a duration, a name. Without those three details the backup has not been tested, it has merely been set up.
These four cards are the test for any offer to look after a website. We list them in the same order in our service description, because they are worked through in that order: first the scope, then the rhythm, then the location, then the test. Which building blocks belong to it is set out in the overview of our services for trade businesses.
Three cases in which a restore happens
The first case is the harmless and by far the most frequent one: somebody changes something and it looks wrong. An image breaks the line, a text has disappeared, an update has shifted the template. Here the most recent version is enough, the restore takes minutes, and the damage is a lost morning. For this case the backup inside the hosting contract is sufficient, provided somebody is able and allowed to operate it.
The second case is technical failure: a disk, the database service, a server update the site does not survive. Here what counts is how quickly the provider reacts and whether the version is complete. The third case is the unpleasant one: someone else gaining access to the content management system, altered pages, injected content. Here the most recent version is often already damaged, and retention is what counts. With thirty versions you can go back to the day before the access. With seven you usually cannot.
- Case 1, wrong change: most recent version, restore in minutes, then repeat the change cleanly.
- Case 2, technical failure: complete version of files and database, mind the order, then check the form and the mailbox.
- Case 3, outside access: first determine the point in time, then pick a version before it, replace all credentials, and only then open the site again.
- In all three cases: before restoring, additionally save the current, damaged state. It is the only evidence of what happened.
The last point is often skipped because it seems contradictory: why save a damaged state? Because it is the only trace. Without it neither the cause can be established later nor the moment the damage began. The same caution applies to planned work: anyone rebuilding a site backs it up first and records the old addresses, as described in the article on a relaunch without losing visibility.
What the business can check itself
Most of these checks need no technician's appointment. The first step is the question about the date of the last restore test. The second is a look into the mailbox the backup messages go to: does a message arrive there every day, and if so, since when has anybody been reading it? The third is the question of whether the business itself can reach the second version without calling anyone. 81 percent of the businesses surveyed have not yet established structured emergency management (Bitkom); these three questions are the smallest possible start on changing that.
The three questions separate the businesses that have a backup from those that have a line in a contract. 71 percent of the companies surveyed say IT security matters a great deal to them, yet only 15 percent have clearly defined procedures for the case of an attack (Bitkom). The gap between those two figures is exactly the space in which a backup plan works. Whether the site comes from a website builder or from an agency changes little about that; it only changes who you ask, as the comparison in website builder or agency shows.
- Date of the last successful restore test, with duration and the name of the person who carried it out.
- Recipient of the backup message: an address that is read in the business, not the provider's address alone.
- Scope: is the mailbox on the list, or only files and database?
- Second storage location with its own access for the business, independent of the hosting contract.
- Retention in versions and in days, so it is clear how late a mistake may still be noticed.
- The encryption key: where is it, who knows it, is it stored separately from the backup?
Once these six points exist in writing, they rarely need touching. They change when the provider changes, when the site is rebuilt, or when somebody with a login leaves the business. Before a trade website relaunch they belong on the table anyway, because a move needs both versions: the old one for comparison and the new one to carry on with.
Pick a version
Determine the moment when the site was last in order and fetch the matching version from storage. After outside access, deliberately go back further than seems necessary, because the moment of access is rarely the moment of discovery.
Load it into a test setup
Do not put the version straight over the running site, build it up separately first. That keeps the current state available in case the version turns out to be incomplete.
Visual and functional check
Walk through the homepage, two service pages, images, menu and the enquiry form. Send a test enquiry and check that it arrives in the mailbox. Only then does the version count as usable.
Switch over and record it
Take the checked version live, replace credentials if outside access was the cause, and write down date, duration and scope of the operation.
Determine the moment when the site was last in order and fetch the matching version from storage. After outside access, deliberately go back further than seems necessary, because the moment of access is rarely the moment of discovery.
Do not put the version straight over the running site, build it up separately first. That keeps the current state available in case the version turns out to be incomplete.
Walk through the homepage, two service pages, images, menu and the enquiry form. Send a test enquiry and check that it arrives in the mailbox. Only then does the version count as usable.
Take the checked version live, replace credentials if outside access was the cause, and write down date, duration and scope of the operation.
What the business decides in daily work
Three decisions stay with the business, because they have nothing to do with technology. First: who is responsible? A backup without a named person is a procedure without an addressee. Second: how much work may be lost in the worst case? A day is bearable for most businesses, a week is not. Third: how quickly does the site have to be back? A business with an emergency service answers that differently from a joinery working on projects. These three answers belong in every conversation about a website for trade businesses, because they set the scope of the support.
From those three answers the rest almost follows by itself. If one day of loss is bearable, a daily backup will do. If the site has to be back within a few hours, you need a second storage location with its own access and a rehearsed sequence. Anyone who answers neither question gets, in our experience, whatever the contract happens to say, and learns its limits on the day of the outage.
- Responsibility: one person in the business who reads the messages, and a deputy for holidays.
- Loss tolerance: the span of time whose work would have to be redone in the worst case.
- Recovery time: the deadline by which the site should be reachable again, stated separately for website and mailbox.
- Approval: who decides that a restore happens, and who picks the right version.
- Evidence: a place where the date and duration of the tests are written down, readable without the computer that failed.
These five lines are not an administrative act, they are the difference between an outage of two hours and one of two weeks. They cost half an hour, once. What the ongoing care of a website costs, with these points included, is stated openly in our pricing overview.
Sources for this article
Related Articles
Selling maintenance contracts: the service page for trades
How trade businesses offer maintenance contracts on a dedicated service page: scope, interval, price, term, cancellation and an enquiry with equipment details.
Who maintains the website once the project ends
What falls due after handover: updates, backups, availability, legal texts, content. What the business can do and who owns the domain, content and logins.
One website for several trades: structure and legal notice
Electrical, plumbing and painting firms on one site: a page per trade, requests routed to the right firm, the legal notice under § 5 DDG and GDPR roles.