On this page
What a real backup solution looks like
A backup solution is more than a nightly copy. It answers four questions: what is backed up, where the copies are kept, how long they are kept, and how quickly you can restore. If any of those answers is “not sure”, the backup is unlikely to help when you need it.
Common failures include backups that silently stopped months ago, copies stored in the same account as the server, databases copied while being written so the file is unusable, and nobody knowing how to restore.
Who needs it
- Any business whose only backup is the hosting provider’s snapshot feature.
- E-commerce stores whose orders and customer data change every day.
- SaaS platforms responsible for their customers’ data.
- Clinics and coaching platforms holding records they cannot afford to lose.
- Anyone about to migrate, upgrade or rebuild a server.
A warning sign worth taking seriously: a file-level server backup that does not include a proper dump of the database running on it.
What’s included
- An inventory of what must be backed up: databases, uploads, configuration, secrets and application data.
- Consistent database dumps rather than copying live database files.
- Automated schedule with retention, such as daily, weekly and monthly copies.
- Off-site storage in a separate account or provider from the server itself.
- Encryption at rest and in transit.
- Alerts when a backup fails or does not run.
- A tested restore and a written restore procedure with realistic timings.
How we set it up
- Agree how much data you can afford to lose and how long you can afford to be down.
- Choose a schedule, retention and storage location that match those answers.
- Configure the backup jobs, encryption and failure alerts.
- Restore to a separate server to prove the backup is complete and usable.
- Document the restore steps and schedule periodic test restores.
Tools and storage
We commonly use tools such as restic or Borg for encrypted, deduplicated file backups, native dump tools for MySQL, MariaDB and PostgreSQL, and object storage such as AWS S3, Google Cloud Storage, Azure Blob Storage, Hetzner Storage Box or other S3-compatible services. Provider snapshots are useful as an extra layer but not as the only copy. Backup success can be reported into Uptime Kuma or Prometheus so a missed run raises an alert.
What affects timeline and cost
Backing up one server with one database is straightforward. More work is needed for large datasets, many servers, strict recovery targets, point-in-time database recovery or compliance-driven retention. Storage is billed by the provider and depends on data size, retention and how often you restore.
If you already have backups, we can review them rather than starting over: checking what is included, where copies go, whether they run reliably and, most importantly, whether a restore actually works.
Very large datasets may also need a first full backup that runs over several nights, followed by incremental backups afterwards. We plan that initial run so it does not slow down the server during busy hours.
Setting recovery targets
Two simple questions shape the whole backup design, and we ask them before choosing any tool:
- How much recent data could you afford to lose? This is the recovery point. If the answer is “an hour of orders at most”, backups must run at least hourly or the database must support point-in-time recovery.
- How long could you afford to be offline? This is the recovery time. It determines whether restoring from off-site storage is fast enough or whether you also need a standby server.
| Example | Likely approach |
|---|---|
| Brochure website that changes monthly | Daily backups with a longer retention period |
| Busy online store | Frequent database backups plus daily file backups |
| SaaS platform with customer data | Continuous or frequent database backups, tested restores, documented recovery runbook |
Writing these targets down also sets honest expectations. The restore procedure we hand over includes realistic timings from the test restore, so you know in advance roughly how long recovery would take.
Common mistakes
- Keeping backups on the same server or in the same account as the data they protect.
- Never testing a restore until the day it is needed.
- Missing the database, environment files or secrets from an otherwise complete backup.
- No alert when backups fail, so they stop without anyone knowing.
Related: Server Migration, VPS Setup & Management and our Cyber Security services. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Are hosting provider snapshots enough?
They are a useful extra, but they usually live in the same account as the server. If that account is compromised or closed, the snapshots go with it.
How often should we back up?
It depends on how much data you can afford to lose. A busy store may need frequent database backups; a mostly static site may need far fewer.
Do you test that backups work?
Yes. We restore to a separate environment during setup and recommend periodic test restores after that.
Are backups encrypted?
Yes, both in transit and at rest. Encryption keys are documented and stored separately so a restore is always possible.
How long are backups kept?
Retention is agreed with you. A common pattern keeps recent daily copies, a number of weekly ones and a smaller set of monthly ones, balancing storage cost against how far back you might need to go.
Talk to us about backup solutions
Automated off-site backups with a restore procedure that has actually been tested.