Backup is a recovery process, not merely a copying process. It creates value only when it is connected to real business services and verified regularly.
Four characteristics of a useful backup
A backup plan must answer four questions: what is protected, how often it is copied, how long it is retained and how it is restored. If one answer is missing, the level of protection remains unclear.
The policy may need to cover not only files but also configuration, databases, virtual machines, Microsoft 365 data, websites, applications and the keys required to operate them.
- Completeness: it includes data and critical configuration.
- Isolation: it does not depend on the same credentials and storage.
- History: it keeps enough versions to identify delayed corruption.
- Repeatability: the restore method is documented and tested.
The 3-2-1 principle and its modern adaptation
The classic principle calls for three copies of the data, on two different media types, with one copy outside the primary location. Modern designs often add an immutable or offline copy and verification that backup jobs complete without errors.
The exact architecture depends on volume, rate of change and acceptable data loss. A large design archive, an accounting database and a mailbox do not necessarily need the same policy.
RPO and RTO in plain language
RPO describes how much recent data can be lost. If backup runs every night, potential loss may reach one working day. RTO describes how long a service can remain unavailable before it must be restored.
Targets should be realistic and set per service. Shorter RPO and RTO normally require more resources, automation and standby infrastructure.
- List the critical services.
- Set acceptable data loss for each service.
- Set acceptable downtime.
- Connect each target to a specific technical solution.
Restore testing is part of backup
Testing should take place in a controlled environment and confirm that data opens, applications start and permissions remain correct. It is also the only reliable way to measure actual recovery time.
After the test, record the steps, delays and required improvements. Restore then becomes a repeatable operating process rather than a theory.