A practical guide to building a business backup strategy

A backup strategy should answer those questions before an incident occurs. Hardware failure, human error, ransomware, accidental deletion and system corruption can all create very different technical situations, but from a management perspective they eventually lead to the same question: how quickly can the business return to an acceptable level of operation?

That makes backup a business continuity issue, not simply an IT task.

Many companies can confidently say that they have backups. There may be a NAS in the server room, an external storage device, cloud storage or an automated backup job running every night, but the existence of a second copy does not by itself define how the organisation will recover from a serious incident.

A practical backup strategy establishes what needs to be protected, how frequently copies need to be created, where they are stored, how long they are retained and who is allowed to access them. It should also define how restoration works and which systems need to return first when several services are unavailable at the same time.

This last point is often overlooked.

Restoring every system simultaneously may not be realistic, which means the business needs to understand its priorities. An accounting system, production database or customer platform may require much faster recovery than archived documents that are rarely accessed.

Before choosing storage capacity, backup software or a cloud service, management and IT need to agree on what the business can actually tolerate.

Which systems and data are critical? How much recent data could the company afford to lose? How long could each important service remain unavailable before the disruption became serious? And who is responsible for making sure that the recovery process actually works?

These questions lead to two useful concepts: recovery point objective, or RPO, and recovery time objective, or RTO. RPO describes how much data loss is acceptable in terms of time, while RTO describes how quickly a system or business function needs to be restored.

They are technical parameters based on business decisions.

A company that can tolerate losing one working day of changes has very different requirements from one where losing an hour of orders, production records or transactions would create a serious problem. The same applies to downtime: some systems may remain unavailable for a day without major consequences, while others can begin affecting revenue or operations within minutes.

The traditional 3-2-1 backup principle recommends maintaining three copies of data, using two different types of storage, with one copy kept separately from the primary environment. It remains a useful way to think about resilience because it reduces the likelihood that a single hardware failure, storage problem or local incident will affect every available copy.

Modern threats, however, require another question: can an attacker who compromises the production environment also reach the backups?

If backup storage is continuously accessible using the same accounts, permissions or administrative environment as production systems, ransomware or a compromised administrator account may be able to affect both. Depending on the organisation's risk and recovery requirements, additional protection may therefore include isolated backup environments, offline copies, immutable storage, separate credentials or other controls designed to prevent production access from automatically becoming backup access.

Separation matters.

The objective is to make sure that a serious incident affecting the primary environment does not remove the organisation's ability to recover from it.

Documents are usually the first thing people think about when discussing backup, but restoring business operations may require considerably more.

Depending on the infrastructure, recovery may involve file servers, databases, virtual machines, application data, user information and important system configurations. Network and security configurations can also become critical when infrastructure needs to be rebuilt quickly after hardware failure or a security incident.

Cloud services need the same level of consideration. Using a cloud platform does not remove the need to define retention and recovery requirements, because service availability, platform-level resilience and the organisation's ability to recover particular business data are not necessarily the same thing.

The practical question is simple: if this system disappeared tomorrow, what would we actually need in order to rebuild it?

That question often reveals dependencies that a file-only backup strategy misses.

One of the most dangerous assumptions in backup management is that a green status indicator means the business is protected. A backup process can complete successfully every day while the organisation still has no reliable understanding of how long restoration will take, whether the recovered system will function correctly or whether all required data and configurations are actually included.

Recovery needs to be tested.

Testing does not necessarily mean rebuilding the entire company infrastructure every week, but restoration procedures should be verified at appropriate intervals and the results should be documented. Critical systems deserve particular attention because the first full recovery attempt should not take place during an actual ransomware incident or hardware failure.

Monitoring is important here as well. Failed jobs, unexpected changes in backup size, unavailable storage or other anomalies should not remain unnoticed simply because nobody checked the backup console that morning.

Backup therefore becomes more useful when it is connected to monitoring and operational processes rather than treated as an isolated nightly task.

There is no single correct answer to how long every backup should be retained. The appropriate period depends on the type of data, business requirements, contractual obligations, applicable legal and data protection requirements, available storage and the kinds of incidents the organisation needs to recover from.

Keeping only the most recent copy can be dangerous because some problems are discovered long after they first occurred. A corrupted database, accidental deletion or security incident may already be present in several recent backup generations before anyone notices it.

Keeping everything forever creates different problems.

A sensible retention model therefore usually includes several recovery points across different periods rather than relying on one continuously overwritten copy, while ensuring that retention decisions are consistent with the organisation's wider data management and compliance requirements.

Within the IT-Pack Shield approach, backup and recovery are not treated as isolated storage tasks. They form part of a wider operational security environment alongside network protection, monitoring and visibility, access management, secure connectivity and the controls needed to maintain business continuity.

This connection becomes particularly important during a real incident. Network controls may help contain affected systems, monitoring may provide information about what happened, access controls can help protect recovery resources, and reliable backups provide a path towards restoring operations.

For management, the most useful backup report is therefore not simply “backup completed successfully”. A stronger level of assurance comes from being able to answer which critical systems are protected, when the last successful backup occurred, whether backup access is separated appropriately, when recovery was last tested and how long the organisation expects restoration to take.

A backup has real value only when it can be recovered.

And a backup strategy has real value only when that recovery supports the needs of the business.