Backups and Data Retention
What we back up, how long we keep it, how to get it restored, and the honest limits.
Last updated 23 July 2026
Where this stands today — read this first#
Backups are currently held on the same server as the sites they protect. An off-site copy is being set up and is not yet running.
So we are covered for what actually goes wrong most of the time — a bad deploy, a corrupted database, a file or mailbox deleted by accident, something we broke ourselves — and we are not covered if the server itself is destroyed.
We would rather say that plainly than let you assume more protection than you have. Section 4 describes exactly what is and is not true right now, and it is updated the day that changes.
1. What we back up#
Nightly, for every hosted site:
| Website database | full dump, consistent snapshot |
| Uploaded files | site storage/ directory |
| Mailboxes | all messages and folders |
| Configuration | site definition, DNS records, mail identity |
We do not back up: anything the client stores outside their site, content on third-party services, or material deleted by the client before a backup ran.
2. When#
2.1 Backups run nightly, outside business hours (target 03:15 CET).
2.2 A backup is taken immediately before any destructive operation we perform, including site removal.
2.3 We do not guarantee a backup exists for any specific moment. Work done and deleted between two nightly runs may not be recoverable.
3. Retention#
Aligned to the package:
| Package | Retention |
|---|---|
| Start | 7 days |
| Business | 30 days |
| Growth | 90 days |
| Add-on | 1 year, €5/month |
Once a backup ages out it is deleted and cannot be retrieved.
4. Where backups are stored#
4.1 Today, backups are held on the same server as the sites they protect, encrypted at rest, within the European Union. An off-site copy is in preparation and is not yet running.
4.2 We state this plainly rather than implying more separation than exists:
- Protected against: our own mistakes, a bad deploy, database corruption, a file or mailbox deleted by accident, and most security incidents — which between them account for very nearly every restore anyone actually needs.
- NOT protected against: the loss or destruction of the server itself. If the machine goes, the backups on it go with it. That is the scenario that destroyed customer data in Strasbourg in 2021, where those with backups in a different facility recovered and those without did not.
4.3 The off-site copy, once it is running, will be held in a different datacentre within the European Union, encrypted with a key we control, so that losing the server no longer means losing the backups. This section will be rewritten — and dated — on the day that is true and a restore from it has been tested.
4.4 Clients whose business could not survive losing their website or mail should keep their own independent copy. That is sound advice with any host. It matters more here until §4.3 is in place. We will help set it up at no charge — see §7.2.
4.5 Backups are encrypted with a key we control. Once they are stored with a third party, that provider cannot read them.
5. Restoring#
5.1 The client may request a restore by any support channel.
5.2 Target restore times, by package:
| Package | We begin within | Restore completes within |
|---|---|---|
| Start | 2 business days | 3 business days |
| Business | 1 business day | 2 business days |
| Growth | 4 business hours | 1 business day |
5.3 Free once per calendar year. Further restores are €90 each.
5.4 A restore replaces current data with the backup. Anything created since that backup is lost. We confirm in writing before proceeding.
5.5 Where we caused the data loss, restores are free and unlimited.
6. Testing#
6.1 We test restores quarterly by restoring to a clean environment and verifying the result.
6.2 An untested backup is not a backup. Test results are recorded and available to clients on request.
7. Limits — read this#
7.1 We do not warrant that data can be recovered in all circumstances. Backups can fail, media can corrupt, and a sufficiently large disaster can destroy primary and backup copies together.
7.2 Clients whose business could not survive losing their website or mail should keep their own independent copy. We will help set that up at no charge — ask us.
7.3 Backups protect against our failures: hardware faults, our mistakes, corruption, and in most cases a security incident. They are not a substitute for the client's own records where those records are legally required.
7.4 Where a client is legally obliged to retain records — tax, medical, professional — that obligation is theirs, and our retention periods above are not designed to satisfy it.
7.5 Our liability for data loss is limited as set out in AGB §8.
8. Deletion#
8.1 On termination, see AGB §5.6–5.9: export available 30 days, data retained 60 further days, then permanently deleted.
8.2 Backups containing deleted client data age out on their normal cycle. We do not selectively purge individual clients from historical backups, as doing so would compromise their integrity.
8.3 On a GDPR erasure request we delete from live systems immediately and confirm that backups will age out within the retention period, during which the data is not used for any purpose. Confirm this position with your lawyer — it is the common industry approach, but it must be stated in the DPA.
9. Security incidents#
9.1 On discovering a personal data breach we notify affected clients without undue delay and within 72 hours, per GDPR Art. 33.
9.2 Notification includes what happened, what data was affected, what we are doing, and what the client should do.