Imagine discovering that thousands of important files have disappeared from your computer.

You feel relieved because you have a backup.

Then you open the backup drive — and discover that the files there have been encrypted too.

Or perhaps your cloud folder contains the same accidental deletions as your laptop.

Or the backup exists, but nobody knows the password required to decrypt it.

Or the files appear to be there, yet the archive is corrupted and cannot be restored.

In each case, a backup technically existed.

But recovery did not.

That distinction is one of the most important lessons in data protection:

The purpose of a backup is not to create another copy. The purpose is to make recovery possible.

What Is a Backup?

A backup is a separate copy of data created so that the original can be recovered after loss, corruption, accidental deletion, hardware failure, cyberattack or another disruptive event.

That sounds straightforward.

The difficulty is the word separate.

If your original files and their backup can be destroyed by the same event, your protection may be much weaker than it appears.

For example, suppose all your photographs are stored on your laptop and copied into another folder on the same laptop.

You now have two copies.

But if the laptop's storage drive fails, both copies may disappear together.

Moving the second copy to an external drive is better.

But if that external drive remains permanently connected and ransomware reaches it, both the computer and the backup could potentially be affected.

A resilient backup strategy therefore considers not only how many copies exist, but also:

  • where they are stored;
  • how they can be accessed;
  • who can modify or delete them;
  • how frequently they are updated;
  • how long previous versions are retained; and
  • whether they can actually be restored.

Why Ransomware Makes Backup Separation Important

Modern ransomware does not necessarily stop after encrypting the files someone uses every day.

Attackers may deliberately look for backup systems, network storage, cloud resources and other recovery mechanisms because destroying those copies makes the victim's situation considerably worse.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity.

One reason is simple: many ransomware variants attempt to find accessible backups and delete or encrypt them.

That means a backup sitting permanently within reach of the same compromised account or computer may not provide the isolation you expected.

A Useful Question: Can the Disaster Reach the Backup?

Whenever you evaluate a backup, ask:

Could the same incident destroy both the original and this copy?

Consider a few examples.

Hardware failure

Original files and backup are on the same physical drive.

Problem: One failed drive can destroy both.

Theft

Laptop and backup drive are stored together in the same bag.

Problem: One theft removes both.

Fire or flooding

Computer and all backup drives are stored in the same room.

Problem: One physical disaster can destroy every copy.

Accidental deletion

A synchronised cloud folder automatically mirrors a deletion across devices.

Problem: A convenient synchronisation system may reproduce the mistake instead of preserving an independent historical copy.

Ransomware

A backup drive stays mounted and writable from an infected computer.

Problem: Malware may be able to reach the backup as well.

Account compromise

Production data and cloud backups are administered through the same compromised credentials.

Problem: An attacker who controls that account may be able to damage both environments.

A good backup design tries to reduce these shared points of failure.

The 3-2-1 Backup Strategy

A widely used starting point for backup planning is known as the 3-2-1 strategy.

The idea is to maintain:

3 copies of your data

One working copy plus two additional backup copies.

2 different storage media or systems

Do not make every copy dependent on exactly the same storage mechanism.

Depending on the environment, this could involve combinations of:

  • internal storage;
  • external drives;
  • network-attached storage;
  • backup appliances;
  • tape;
  • object storage; or
  • appropriately configured cloud backup services.

1 copy off-site

At least one copy should be stored somewhere physically or logically separated from the primary location.

Why?

Because having five backup drives sitting beside the same server does not protect you very well from a fire that destroys the entire room.

The 3-2-1 approach is not a magical formula, and more demanding environments may require additional protections, but it forces you to think about failure independence, not simply copy count.

Offline Backups Add Another Layer of Protection

An offline backup is not continuously accessible from the systems it protects.

A simple example for an individual might be an external drive that is connected for a scheduled backup and then safely disconnected.

For an organisation, the implementation could be considerably more sophisticated.

The important property is separation.

If ransomware compromises a workstation or network, a genuinely inaccessible backup is harder for that malware to modify or destroy.

CISA specifically advises users of external backup drives not to leave them connected when they are not actively being used for backups because ransomware may be able to access, corrupt or delete those copies.

What Is an Immutable Backup?

Another increasingly important concept is immutability.

An immutable backup is designed so that stored backup data cannot simply be changed or deleted during a defined retention period.

Think of it as placing a recovery copy behind a temporary protective barrier.

Even if an attacker obtains significant access to other systems, properly implemented immutable storage can make destruction of protected backup versions much more difficult.

This is particularly valuable against:

  • ransomware;
  • malicious deletion;
  • compromised administrator accounts; and
  • accidental modification.

However, the word immutable should not become another checkbox.

Poor configuration, inadequate retention periods or compromised administrative controls can still undermine a backup architecture.

Encryption Protects the Backup Itself

Backups solve an availability problem, but they can also create a confidentiality problem.

A backup may contain:

  • personal photographs;
  • financial records;
  • customer information;
  • employee information;
  • databases;
  • confidential documents;
  • passwords or configuration files;
  • intellectual property; or
  • business records.

If somebody steals an unencrypted backup drive, they may have obtained an extremely concentrated collection of sensitive information.

Encryption helps protect backed-up data from unauthorised access.

But encryption introduces another responsibility:

You must protect the encryption keys, passwords and recovery information.

An encrypted backup whose only decryption key has been lost is effectively another form of inaccessible data.

Synchronisation Is Not Necessarily a Backup

This distinction catches many people.

Services that synchronise files between your laptop, phone and cloud account are extremely useful.

But synchronisation and backup solve different problems.

Synchronisation is primarily designed to keep files consistent across locations.

If you edit a document, the change may propagate everywhere.

If you delete it, that deletion may also propagate.

That behaviour is useful for keeping devices in sync.

It is not always what you want from a historical recovery system.

A true backup system should make it possible to recover an earlier state after something has gone wrong.

Some cloud platforms provide version histories, retention periods, recycle bins and backup features that make recovery possible, but you should confirm exactly what your service provides rather than assuming that “it is in the cloud” automatically means “it is safely backed up”.

Backup Is Not the Same as Redundancy

Another common misconception is that redundant storage eliminates the need for backups.

Suppose a server uses multiple drives so that it can continue operating after one drive fails.

That is valuable.

It improves availability.

But if somebody accidentally deletes an important database record, redundant storage may faithfully reproduce that deletion across the storage system.

The same can happen with corrupted data.

So remember:

Redundancy helps keep systems running.

Backups help recover previous data.

A resilient system may need both.

How Often Should You Back Up?

There is no universally correct schedule.

The right frequency depends on a simple business question:

How much recent data could you afford to lose?

Imagine a company backs up its database once every 24 hours.

If the database fails at 11:55 p.m. and the previous successful backup occurred shortly after midnight, almost an entire day's transactions could be missing.

For a personal computer, that might be tolerable.

For a payment platform, hospital, online shop or large business system, it may be completely unacceptable.

This leads to an important disaster-recovery concept called the Recovery Point Objective, or RPO.

Recovery Point Objective: How Much Data Can You Lose?

The Recovery Point Objective (RPO) describes the maximum acceptable amount of data loss measured in time.

For example:

RPO: 24 hours

The organisation may tolerate losing up to approximately one day's recent changes.

RPO: 1 hour

Recovery should normally lose no more than roughly an hour of data.

RPO: 5 minutes

The system requires far more frequent protection.

A smaller RPO generally requires more sophisticated infrastructure and often higher cost.

The correct answer depends on how valuable rapidly changing data is.

Recovery Time Objective: How Long Can You Stay Down?

There is another question:

How quickly must the system be restored?

This is known as the Recovery Time Objective, or RTO.

A backup might contain every required byte of data and still be operationally inadequate if restoring it requires three days while the business can only tolerate two hours of downtime.

So backup planning should answer two separate questions:

RPO: How much recent data can we afford to lose?

RTO: How long can we afford to remain unavailable?

These questions turn backup planning from a storage exercise into a business-continuity decision.

Why Testing a Backup Matters

Seeing a message that says:

Backup completed successfully

is reassuring.

It is not the same as proving recovery works.

A backup can fail operationally for many reasons:

  • files may be corrupted;
  • critical folders may have been excluded;
  • database backups may be inconsistent;
  • encryption keys may be unavailable;
  • credentials may have expired;
  • software required for restoration may be missing;
  • permissions may be incorrect;
  • the backup may depend on infrastructure that no longer exists;
  • nobody may know the restoration procedure; or
  • the restoration process may take far longer than expected.

That is why CISA specifically recommends regularly testing backup procedures and testing backup availability and integrity in disaster-recovery scenarios.

A recovery test converts:

“We think we have backups.”

into:

“We have demonstrated that we can recover.”

What Should a Restore Test Check?

A useful test should answer more than “Can I open one file?”

Depending on the system, verify:

1. Can the backup be found?

Know exactly where the required backup is stored.

2. Can authorised people access it?

Confirm that passwords, encryption keys and recovery credentials actually work.

3. Is the backup complete?

Check whether the files, databases, application configuration and other dependencies required for restoration are present.

4. Is the data intact?

Validate that files or databases are not corrupted.

5. Can it be restored into a clean environment?

Do not discover during a real ransomware incident that recovery depends on the compromised system itself.

6. Does the restored application actually work?

A restored database file is not enough if the application cannot connect to it or critical configuration is missing.

7. How long does restoration take?

Measure actual recovery time against the required RTO.

8. Is the recovery procedure documented?

A system should not depend entirely on one employee remembering a complicated restoration process.

A Simple Backup Strategy for Personal Devices

A family laptop does not need the same infrastructure as a multinational company.

A sensible personal approach could look like this:

Working copy: Files on the computer.

Local backup: Automatic backups to an external drive.

Separated copy: An appropriately secured cloud backup or another copy stored away from the computer.

Then:

  • disconnect removable backup storage when appropriate;
  • enable encryption;
  • use multifactor authentication on cloud accounts;
  • retain previous file versions where possible; and
  • occasionally restore several files to prove recovery works.

The goal is not maximum complexity.

It is avoiding one event destroying everything you care about.

A More Mature Business Backup Strategy

Business environments should additionally consider:

  • backup inventories;
  • defined RPOs and RTOs;
  • separate backup credentials;
  • least-privilege access;
  • immutable storage;
  • offline or logically isolated copies;
  • encrypted backups;
  • off-site copies;
  • multiple backup generations;
  • automated monitoring of failed backup jobs;
  • documented restoration procedures;
  • clean recovery environments;
  • prioritised recovery of critical systems;
  • incident-response integration; and
  • scheduled disaster-recovery exercises.

Businesses should also identify restoration dependencies.

Restoring a database may be useless if the organisation has forgotten to preserve:

  • application source code;
  • encryption keys;
  • certificates;
  • infrastructure configuration;
  • licence information;
  • identity systems; or
  • required software.

Recovery needs the system, not just its most obvious data file.

Do Not Wait for an Emergency to Learn How Recovery Works

The worst time to discover your restore procedure is during ransomware, a server failure or a major accidental deletion.

At that moment, people are already under pressure.

A restoration process that has never been tested adds uncertainty precisely when the organisation can least afford it.

A much stronger approach is:

Back up automatically.

Separate important copies.

Protect backups from unauthorised modification.

Keep critical copies off-site or isolated.

Encrypt sensitive backup data.

Monitor whether backup jobs actually succeed.

Test restoration regularly.

The Most Important Backup Question

When evaluating your own backup system, do not stop with:

“Do I have a backup?”

Ask instead:

“If everything failed today, what exactly would I restore, where would I restore it from, who could perform the recovery, and how do I know it would work?”

If those questions are difficult to answer, there is still work to do.

Because a backup file sitting quietly on a drive is not the final objective.

Successful recovery is.