Skip to content
Trivane TECH

Backups and disaster recovery in plain language

Nearly every business has backups. Far fewer have backups they have actually restored. That gap is where bad days become disasters: a ransomware attack, a deleted folder, a failed server or a cloud account mistake, followed by the discovery that the backups are incomplete, too old, or were encrypted along with everything else.

This guide explains the key ideas behind backup and recovery in plain language, and the steps that make them dependable.

Two numbers that shape everything: RPO and RTO

  • Recovery Point Objective (RPO): how much data you can afford to lose, measured in time. If your RPO is 24 hours, a daily backup is enough. If losing even an hour of orders is unacceptable, you need more frequent backups or replication.
  • Recovery Time Objective (RTO): how long you can afford to be down. If your RTO is four hours, you need a recovery plan that can realistically bring systems back within four hours, not just a copy of the data somewhere.

Different systems usually have different targets. Email and finance might need fast recovery; an archive of old projects can wait. Agree these numbers with the business, because they decide how much to spend.

The 3-2-1 rule, and its modern version

The classic 3-2-1 rule says:

  • Keep 3 copies of your data (the original plus two backups),
  • on 2 different types of storage,
  • with 1 copy in a different location.

Ransomware changed the picture, because attackers now deliberately look for and destroy backups before they encrypt systems. Many organisations now follow 3-2-1-1-0, which adds:

  • 1 copy that is offline, air-gapped or immutable, meaning it cannot be changed or deleted, even by an administrator, for a set period.
  • 0 errors, confirmed by regularly verifying and test-restoring backups.

Government guidance such as CISA's ransomware guidance makes the same point: keep offline, encrypted backups of critical data and test them regularly.

What to back up

Make a list. It is usually longer than people expect:

  • Files on servers, shared drives and cloud storage.
  • Email and collaboration data. Microsoft 365 and Google Workspace keep data available, but their built-in retention is not the same as an independent backup you control.
  • Databases and the applications that use them.
  • Servers and virtual machines, including their configuration.
  • Cloud resources: databases, volumes and file systems in AWS, Azure or Google Cloud.
  • Configuration: firewall and switch configurations, infrastructure-as-code repositories, and documentation needed to rebuild.

Protect the backups themselves

  • Separate credentials. Backup administration should use different accounts from your everyday admin accounts, with MFA.
  • Separate location or account. In the cloud, store backup copies in a separate account or Region so one compromised account cannot delete everything.
  • Immutability. Use storage features that lock backups for a retention period (for example object lock or vault lock features offered by major backup and cloud providers).
  • Encryption in transit and at rest.
  • Monitoring. Alert on failed jobs and on unusual deletions.

Test restores, on a schedule

A backup has value only if you can restore it. Build a routine:

  1. Monthly: restore a few files or a mailbox to confirm the basics work.
  2. Quarterly: restore a full system or database to a test environment and check it actually runs.
  3. Yearly: run a disaster recovery exercise. Pick a scenario (for example "the main server is encrypted") and walk through recovery end to end, timing it against your RTO.

Record the results. They show where the plan works and where it needs fixing.

Write the recovery plan down

When something goes wrong, nobody wants to work it out from scratch. A short written plan should cover:

  • Who decides that a disaster recovery is needed, and who does what.
  • The order in which systems are restored, based on business priority.
  • Where backups are, how to access them, and which credentials are needed (stored securely and available even if your main systems are down).
  • How staff, customers and suppliers will be told what is happening.
  • Contact details for providers and insurers.

Where to start

Answer three questions this week: what is your RPO and RTO for your most important system, where is your offline or immutable copy, and when did you last restore something? If any answer is "not sure", we can help. Book a free consultation for a review of your backups and recovery plan.

Want help with your cloud or IT?

Book a free 30-minute consultation.

Book a free consultation