On this page
What backup and disaster recovery covers
Backups protect you against the events prevention can’t stop: a failed disk, a deleted database table, a botched update, ransomware, a compromised server or a hosting provider closing an account. Disaster recovery is the plan that turns those backups into a working business again — what gets restored, in what order, by whom, and how long it takes.
Our service covers both. Backups are automated, stored off-site, encrypted and restore-tested on a schedule, and you receive a written recovery procedure with realistic time estimates for each scenario. We also tell you what cannot be recovered, so expectations are honest before anything goes wrong.
The plan is written for the stressful moment it will be used in. Recovery steps are specific, list the credentials and access required, and name who is responsible, so the business isn’t dependent on one person remembering how everything fits together.
Who needs it, and the warning signs
Every business with data it can’t easily recreate needs this: a clinic’s appointment and patient records, an online store’s orders and customer accounts, a real estate firm’s CRM and listings, a SaaS product’s customer data, or a manufacturer’s ERP and production records.
- Backups exist, but nobody has ever restored one.
- Backups are stored on the same server they protect.
- The database is backed up but uploaded files, configuration or email are not.
- Nobody knows how long a full recovery would take.
- The only backups are the hosting provider’s, and you don’t control them.
What’s included
- An inventory of what needs protecting — databases, uploaded files, application code, configuration, environment secrets, email and DNS records.
- Automated backups on a schedule matched to how much data you can afford to lose.
- Off-site, encrypted storage, separate from the production account, with retention of older versions so an infection discovered late can still be rolled back.
- Backup monitoring that alerts when a backup fails or is unexpectedly small.
- Scheduled restore tests to a separate environment, with results recorded.
- A written recovery plan covering each likely scenario, with steps and time estimates.
Setting realistic recovery targets
Two questions shape every backup plan. How much data can you afford to lose? This is the recovery point objective — if backups run nightly, up to a day’s changes could be lost. How long can you be down? This is the recovery time objective — the time it takes to get systems running again. Tighter targets need more frequent backups, more automation and sometimes standby infrastructure.
| Scenario | Typical recovery approach |
|---|---|
| Accidental deletion | Restore the specific file or records from a recent backup. |
| Failed update | Roll back application and database to the pre-update backup. |
| Server failure or loss | Rebuild the server from documentation or configuration code, then restore data. |
| Ransomware or compromise | Rebuild on clean infrastructure and restore from a backup taken before the compromise, after closing the entry point. |
How we deliver it
- Agree scope and confirm you own the systems and data involved.
- Map data and dependencies, including external services the business relies on.
- Agree targets for data loss and downtime per system.
- Implement backups and off-site storage, with access restricted so a compromised server can’t delete them.
- Run a first restore test and time it.
- Write the recovery plan from the real test, not from assumptions, and schedule regular re-tests.
What affects timeline and cost
- The amount of data and how often it changes.
- How tight the recovery targets are.
- The number of systems and how they depend on each other.
- Storage and retention requirements.
- How often restore tests are run.
Common mistakes
- Keeping backups on the same server or account, so one failure or attacker takes both.
- Backing up files but not the database running alongside them, or the reverse.
- Keeping only the latest copy, which may already contain the problem.
- Forgetting configuration and secrets, so data restores but the application won’t run.
- Assuming restores work because the backup job reports success.
Frequently asked questions
Aren’t our hosting provider’s backups enough?
They are useful, but they sit with the same provider as your server, you may not control their schedule or retention, and they may be lost if the account is suspended or compromised. An independent off-site copy is safer.
How often should backups be tested?
On a regular schedule agreed with you, and after any significant change to the system. A restore test is the only real proof a backup works.
Can backups protect us from ransomware?
They are the main defence, provided older versions are kept and the backups can’t be deleted or encrypted from the compromised server. We design storage and access with that in mind.
Can you restore just one file or one record?
Usually, yes. We keep versions in a form that allows selective restores, so recovering a deleted page or a handful of database records doesn’t require rolling back the whole system.
Where are backups stored?
In encrypted, off-site storage separate from your production environment, in a location agreed with you. If you have data residency requirements, we take them into account.
Talk to us about backup & disaster recovery
A recovery plan that has been tested under real conditions, not just written down.