Backup and Recovery Checklist for SMBs

Do you follow a 3-2-1 backup strategy?

Why it matters: 3 copies of data, on 2 different media types, with 1 offsite. Backups stored only on the same local network as your systems can be encrypted by the same ransomware attack that hits your servers.

Is at least one copy stored offsite or in the cloud?

Why it matters: A local backup doesn't protect against fire, flood, theft, or ransomware that spreads across your network. Confirm that an offsite or cloud copy provides the location separation and access isolation your recovery plan needs.

Do you have an immutable or ransomware-protected backup copy?

Why it matters: Properly configured immutable backups are designed to resist modification or deletion during their retention window, including many ransomware scenarios. Where appropriate, keep at least one recovery copy immutable, isolated, or otherwise protected from the credentials and systems used in day-to-day operations.

Are backups encrypted at rest and in transit?

Why it matters: Backup copies often contain sensitive business data. Unencrypted backups that are stolen or accessed by an attacker are a separate breach. Encryption at rest and in transit is the baseline standard.

Are backup credentials separate from production credentials?

Why it matters: Attackers who compromise administrator credentials often target backup systems specifically. Backup admin accounts should use separate credentials not used anywhere else.

Are backup jobs monitored for failures and alerts sent?

Why it matters: Backup jobs fail for many reasons: full disks, network issues, software conflicts. Without monitoring and alerts, a failing backup can go undetected for months.

Have you tested a restore on a documented, risk-based schedule?

Why it matters: The most dangerous assumption in IT is that a backup works without ever testing it. Restore tests provide evidence that the sampled data can be recovered under the tested conditions; they do not guarantee every future restore.

Do you know your Recovery Time Objective (RTO)?

Why it matters: RTO is how long your business can survive without access to systems. If your RTO is 4 hours but restoration from backup takes 48 hours, you have a critical gap. Knowing this number allows you to plan accordingly.

Do you know your Recovery Point Objective (RPO)?

Why it matters: RPO is how much data your business can afford to lose. If the latest usable recovery point is from the previous night, work since that point may be lost. If that's unacceptable, more frequent backups or continuous replication may be required.

Is there written documentation of the recovery process?

Why it matters: Recovery documentation should describe: what systems to restore first, how long each step takes, who is responsible, and how to test that recovery is complete. This documentation should be stored somewhere accessible during a crisis — not only on the systems you're trying to restore.