Designing recovery before disruption.

What does a useful disaster recovery plan protect?

A useful disaster recovery plan protects the ability to resume work, not merely a collection of files. It connects business-critical systems to an acceptable recovery time, an acceptable amount of data loss, multiple storage locations, and a restore process that has been checked before an incident.

The protected scope covers ERP data, production files, and configuration needed to rebuild services. The working targets are an RTO under four hours and a 24-hour RPO. Those numbers turn a vague instruction to "keep backups" into operational decisions about frequency, storage, and restore priority.

How the 3-2-1 backup design works

The design keeps three copies of important data across two types of storage, with one copy away from the primary site. Each copy has a different job.

1. Local RAID copy: provides the fastest practical route to routine recovery.
2. Cloud copy: places data on a separate medium and outside the local storage system.
3. Encrypted off-site copy: separates a recovery copy from incidents affecting the primary location.

Separation matters because multiple copies on the same hardware or in the same building can share the same failure. The architecture is designed around distinct failure domains, not only copy count.

Why backup verification matters

A completed backup job is evidence that data was written somewhere. It is not proof that the data can be restored into a usable system. Verification checks integrity, access, restore order, and whether the recovery procedure still matches the current environment.

The recovery path is treated as part of normal system ownership. That means checking integrity, keeping recovery information understandable, and confirming that the required credentials, configurations, and dependencies are available when the primary system is not.

Principles I carry into recovery work

• Start with the services the organization must resume, then map their data.
• Define RTO and RPO before selecting tools or schedules.
• Separate copies by medium and location.
• Protect credentials and configuration alongside business data.
• Test restoration and document what was learned.

Primary reference

NIST contingency planning guidance provides the general planning context. The targets and architecture described above are the project-specific design.