Backups Are a Recovery System, Not a Storage Feature

The comforting sentence

“The backups are running” is comforting because it sounds like the hard part is complete. But a backup is not the same thing as a recovery system. A recovery system includes the data, the instructions, the people, the permissions, the replacement environment, and the time required to put the business back together.

What a backup is supposed to preserve

Start with business functions rather than devices. Which systems allow the company to accept orders, communicate, produce work, pay people, serve customers, and meet its obligations? The answer may include files, cloud applications, identity, configurations, line-of-business databases, phones, network equipment, and vendor portals.

A list of protected devices can be technically accurate and operationally incomplete.

Isolation and access

CISA guidance for managed service providers and small and midsize businesses recommends backups that are automatically and continuously created, stored in an easily retrievable location, and kept air-gapped from the organizational network. The reason is straightforward: if an attacker can alter the production environment, the backup environment must not be equally easy to alter.

Isolation is not only a technical property. It is also a permission property. Who can delete backups? Who can change retention? Who receives an alert?

Recovery objectives

Two common terms help clarify expectations. The recovery time objective is how quickly a function needs to return. The recovery point objective is how much recent work the business can afford to lose.

These are business decisions. A file server used for reference may tolerate a different recovery point than a system used to process orders. The most expensive backup is the one designed without anyone deciding what “back soon” means.

Restore testing

Restore testing is not a ceremonial click. It should answer whether the restored thing is usable, whether its dependencies are available, whether permissions work, and whether someone besides the backup administrator can perform the sequence.

Begin small. Restore a representative file. Then restore a mailbox or application object. Eventually run a recovery exercise for the most important business process.

The human layer

Instructions should name owners, dependencies, escalation paths, and the location of credentials or recovery keys without putting secrets in an uncontrolled document. They should say what happens first and what can wait.

Questions for a provider

• What is protected, and what is explicitly not protected?
• How are backups isolated from the production environment?
• Who can delete or alter them?
• When was the last successful restore test?
• What is the expected recovery time for the three most important business functions?
• What happens if the primary administrator is unavailable?

The point is not to make recovery sound easy. It is to make the unknowns visible while there is still time to improve them.