--- title: "Backups that actually restore: a small business guide" description: "Most small-business backups fail at the moment they are needed. The four ways they fail, and how to prove yours works before you have to rely on it." source: "https://wardio.net/guides/backups-that-restore/" --- **Backups** # Backups that actually restore Almost every small business has backups. A surprising number find out, when they try to restore, that all they have is archives. By David Kabel · Updated 2026-09-01 · 4 min read **The short answer** Back up the application files, the database and the configuration as three separate jobs. Dump databases rather than copying their files. Store at least one copy in a different failure domain from the machine, using credentials production cannot use to delete it. Then restore from it on a schedule and time the restore. Until you have restored a backup, you do not know it works. ## The four ways backups fail These failures are ordinary ones. In each of them everything looks healthy until the day you need to restore. 1. **Something was excluded and nobody reviewed it**: An exclude pattern written on day one can, by month six, leave out a directory that matters, and nobody notices. The archive extracts perfectly, but the data you needed is not in it. 2. **The backup ran against a live database**: Copying database files while the engine is writing produces an archive that restores into a corrupt database. Use a dump or a snapshot instead of a file copy. 3. **The copy is in the same failure domain**: A second disk in the same machine protects against disk failure only. A bucket with the same provider in the same region protects against host failure only. 4. **The credentials that write backups can also delete them**: Ransomware and a compromised host both use the same credentials you do, so if production can delete the backups, they count as part of production. ## Off-site means a different failure domain A folder on the same server is not off-site. Off-site means a *different failure domain*, infrastructure that can fail independently of the thing it protects. For any backup destination, try to name a single event that takes out both it and the server. If you can name one easily, the destination is not off-site enough. Credentials matter as much as location and get less attention. If the server holds keys that can delete the backup bucket, then anything that compromises the server can delete your backups. Append-only or write-once retention stops that kind of deletion. Neither is free, and the resticprofile guide sets out the [trade-offs between an append-only key and Veeam's immutable repositories](/guides/resticprofile-production/#downsides). ## The restore test decides whether you have a backup Everything above only matters if the restore test passes. Restore to a scratch machine, bring the application up, log in and check that the data is there and current. Then write down how long it took. During an outage, that elapsed time is what you would tell a customer, and your backup schedule cannot give it to you. **A restore that worked** In May 2026 a client had a serious failure and needed everything back. Their words afterwards: *“We had a serious issue and he restored everything from backup quickly.”* Luck had little to do with it. That backup setup had been exercised with real restores, and a setup that has only ever been configured has shown nothing. WaterArchery, May 2026. [More client feedback](/reviews/). ## A cost problem specific to Backblaze B2 If your off-site copy is on B2, the bucket will grow faster than the backup does, and the lifecycle rule most guides recommend does not fully stop it. [We escalated this to Backblaze and wrote up what they confirmed](/guides/restic-backblaze-storage-growth/). ## Questions ### How often should I test a restore? Monthly for anything the business depends on, and right after any change to what the backup covers. An archive that extracts is not a pass. A pass means a working system came back and you know how long it took. Write down the elapsed time. That number is your real recovery time, and it is usually several times longer than people assume. ### Is my hosting provider already backing this up? Usually the provider snapshots the whole VM on a schedule. That is useful, but it is a different thing from a backup. Provider snapshots typically live in the same account you might lose access to, are kept for a short window and restore the entire machine rather than one database or one directory. Treat them as a convenience. They do not replace your own backup strategy. ### Does GDPR require backups? Article 32(1)(c) requires the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. It does not name products or schedules. If you are ever asked to demonstrate an appropriate measure, an untested backup is hard to defend. **Want backups you have proof of?** Wardio checks the integrity of its backups automatically, stores them off-site in a different failure domain and writes down the restore procedure. A full restore rehearsal of a large dataset is separate work with its own scope. [See pricing](/pricing/). [Free server review](/contact/) Related: [How to secure a VPS you just bought](/guides/secure-a-vps/) · [File integrity monitoring for a small online store](/guides/file-integrity-monitoring/)