Backup strategy: from the 3-2-1 rule to a tested recovery

A copy alone does not restore a business process

On Monday a project folder is missing, but synchronisation has already propagated the weekend deletion everywhere. Another company retains its data but cannot restart inventory management after a server failure because the licence file, database configuration and administrator access are missing. Both examples show why a strategy must explain more than where a copy is stored.

The outcome is a particular process working again with an acceptable data state within an agreed time. A small trade business may need a different approach from a round-the-clock ordering system. Economic planning begins with that distinction.

Choose acceptable loss before the backup schedule

Recovery Point Objective (RPO) limits acceptable data loss in time. A four-hour RPO requires a recoverable point no more than four hours old at failure. Recovery Time Objective (RTO) describes the target time until service resumes. Nightly backups alone do not meet a four-hour RPO, and a fast download does not prove the RTO.

The business team must agree these objectives. Re-entering orders from emails may compensate for some lost data, but still costs staff time. Waiting for hardware, supplier availability and final business validation all count toward actual interruption. The following examples are planning illustrations, not universal recommendations.

• Project documents: RPO four hours, RTO one working day; several daily points and targeted folder restoration.
• Current orders: RPO one hour, RTO four hours; database protection and an immediately available recovery environment.
• Public website: RPO 24 hours, RTO eight hours; protect content, application, configuration and domain administration together.

3-2-1 needs genuinely independent copies

The classic rule means three copies including production, two media types and one off-site copy. Also examine shared failure causes. Two directories on one NAS are not independent protection. A second cloud account helps only if the primary administrator cannot alter its retention and data too.

A practical combination is production data, a local backup for fast restores and a separate external copy for site loss. An offline or temporarily immutable copy further limits unwanted changes. RAID can sustain some drive failures but does not provide independent historical versions.

Immutability has product-specific limits. S3 Object Lock protects particular object versions for a defined period, while new versions can still be created. Test retention and align it with the storage budget and recovery procedure.

Files, databases and cloud services need different methods

Documents often need a particular past version. A database needs related changes to be consistent; copying open files at an arbitrary instant may not provide that. Application-aware backups coordinate a recovery point with a supported application. Check the relevant database support rather than assuming application consistency is universal.

For cloud services, inventory accounts, permissions, retention and exports. Recycle bins and version history can help but are not automatically independent backups. Determine whether required data remains available after account loss or history expiration. An export is useful only if the destination can import it.

Cost the complete recovery path

Include licences, growth, external copies, recovery capacity, monitoring and exercise time. Providers may charge for retrieval, minimum retention or transfer. Long retention does not reduce cost when large amounts of new data arrive daily. Measure deduplication and compression with actual data instead of assuming a standard discount.

This bandwidth calculation is illustrative: transferring 1 TB over a continuously fully usable 100 Mbit/s connection takes about 22.2 hours using decimal units and ignoring protocol overhead. Unpacking, starting the database and validation take longer. A four-hour recovery needs a faster path or copies already near the recovery environment.

A proposal should name protected systems and exclusions, copies, retention, objectives, an available contact, documented access and the first timed successful restore. Accept restoring individual items and restarting the whole service separately.

Run an exercise with a verifiable outcome

Choose a complete but manageable process, such as order management. Restore a selected point into an isolated test environment and verify login, order search, document retrieval and a harmless test transaction. Prevent real notifications or orders reaching external systems. Record the starting point, dependencies and expected result before beginning.

Measure more than copying: record the start of the simulated incident, availability of credentials, application start, completion of business checks and recovered data timestamp. Compare actual recovery time and loss with RTO and RPO. Assign each deviation an owner and deadline rather than adjusting the report to appear successful. Re-test after material database, encryption or hosting changes.

An alert must lead to action

Failed jobs are only one signal. Missing backups, unusually small datasets, sustained growth and recovery points older than the agreed window also matter. Classify each alert and send it to someone able to act during contracted support hours.

A critical system could alert when the last confirmed recovery point reaches an internal warning age, leaving time to investigate and check alternative copies before violating the RPO. Test the reporting route and confirm that a deputy receives the same information.

Handover is part of acceptance

The recovery plan must remain accessible without the failed server or one person's knowledge. Name contacts, products and versions, dependency order and secure access to keys and credentials. Store passwords in an appropriate manager with controlled emergency access, not exposed in a general handbook.

A second person should perform a bounded restore using only the documentation. Record any knowledge gaps. Exercise frequency follows change rate and criticality: an annual documented review can be a starting point, while frequently changed core systems or missed objectives require closer checks.