How to build backups that can actually recover your business

A backup is not a guarantee simply because it exists. If no one knows what it contains, it can be deleted through a compromised account, or it has never been restored, it may fail at the exact moment it is needed.

The goal is not to collect duplicate files. It is to restore important information and services within an acceptable period after ransomware, human error, a technical failure, or accidental deletion.

A backup is not measured by the space it uses; it is measured by the proven ability to resume operations.

The CISA #StopRansomware Guide recommends maintaining critical backups that are encrypted, offline, and tested regularly. It also warns that many ransomware variants try to find, delete, or encrypt backup copies they can still reach. Recovery should therefore be designed as part of security, not as an isolated technical task.

1. Decide what you need to recover first

Not all data has the same urgency. Before choosing storage or backup frequency, make a short inventory of the resources that keep the organization running.

• Operational data: customers, orders, invoices, schedules, inventory, documents, or production records.
• Systems and configuration: databases, applications, users, permissions, integrations, and relevant settings.
• Web assets: content, forms, media files, configurations, and data collected through the website.
• Rebuild materials: source code, installers, licenses, technical documentation, and procedures.

For each item, answer two specific questions:

1. How long can it be unavailable? For example, one hour, one business day, or several days.
2. How much recent information can be lost without unacceptable harm? For example, changes from the last hour, day, or week.

These choices turn a vague conversation about “doing backups” into operational priorities. NIST recommends evaluating systems and operations to determine contingency requirements and priorities, preventing critical information and expendable files from receiving the same treatment.

2. Build backup layers, not a single point of failure

Keeping one copy in the same device, server, or account you want to protect does not solve a serious incident. A sound approach separates copies so one problem cannot affect all of them at once.

A practical structure

• Working copy: the data and systems used in everyday operations.
• Fast-recovery copy: a recent backup for restoring common errors or isolated losses quickly.
• Separated copy: a backup stored in another location, account, or environment with different controls.
• Historical versions: multiple points in time that allow a rollback when a problem went unnoticed for days.

You do not need the same combination for everything. A constantly changing database may need more frequent copies than an institutional image repository. What matters is that the frequency reflects the data loss the organization can accept.

3. Protect the backup as a critical asset

A backup exposed to the same credentials and permissions as the primary environment can be changed by an attacker or through an administrative mistake. CISA advises encrypting backups, keeping them offline or separate from the usual environment, and testing them regularly.

In practice, review these controls:

• Use dedicated backup administration accounts rather than shared personal accounts.
• Use multi-factor authentication where it is available.
• Limit who can delete copies, change retention, or alter configuration.
• Separate read, restore, and delete permissions when the tool supports it.
• Enable deletion or overwrite protection and retain versions when your provider offers those features.
• Encrypt information both in transit and at rest.
• Store the keys, credentials, and documentation required for restoration securely.

“Offline” does not always mean manually unplugging a disk. It can mean a copy that production systems cannot reach permanently. The technical implementation depends on your environment, but the principle is durable: compromising the primary environment should not automatically allow someone to destroy every copy.

4. Document restoration before an incident happens

An available file does not necessarily mean an available service. Resuming operations may require restoring a database in a specific order, recreating users, reconnecting an integration, validating permissions, or changing DNS and email settings.

Create a short record for each critical system that includes:

• a primary owner and backup owner;
• the exact backup location and access method;
• credentials or a secure process for obtaining them;
• the order for restoring components and dependencies;
• the target time for an initial functional recovery;
• post-recovery checks for access, data, forms, payments, reports, or integrations;
• a channel for communicating progress to affected people.

NIST SP 800-34 Rev. 1 treats contingency planning as a combination of procedures, recovery strategies, testing, training, and maintenance. That is an important warning: technology without assigned people and clear steps leaves too many decisions for a high-pressure moment.

5. Test an actual restoration and record the result

The only way to know whether a backup works is to restore a copy in a controlled environment. It is not enough to see a green status indicator or confirm that a scheduled task completed.

What a useful test includes

1. Select a system or set of files with a defined priority.
2. Restore from one specific backup without using the original environment to fill in missing pieces.
3. Measure the time required and compare it with the intended target.
4. Verify integrity and usefulness: open files, query records, sign in, process a test transaction, or check integrations.
5. Record failures, unexpected manual steps, missing permissions, and unresolved decisions.
6. Update the procedure and repeat the test whenever infrastructure changes.

NIST explains that testing is critical for identifying deficiencies and validating both system components and recovery procedures. A small recurring exercise usually produces more learning than a lengthy plan that is never run.

6. Make backups part of routine management

Backup arrangements deteriorate as tools change, new systems are introduced, subscriptions expire, or people lose access. Schedule a regular review to confirm that coverage remains correct.

At a minimum, check:

• which new systems or data must be included;
• whether copies finish correctly and at the agreed frequency;
• whether failure alerts are being addressed;
• whether accounts and permissions still belong to authorized people;
• whether retention covers the time needed to detect an incident;
• whether restoration documentation matches current operations;
• when the last test occurred and which improvements remain open.

The NIST Cybersecurity Framework places recovery within ongoing risk management: recovery is not merely returning to an earlier state, but restoring capabilities and learning from the event to improve resilience.

Conclusion: define a recovery you can demonstrate

A strong backup system has clear priorities, copies separated from the primary environment, access controls, sufficient version history, and a restoration process that has already been tested. Start this week with one concrete exercise: select a critical asset, restore it safely, and write down every obstacle. The result will show you exactly what to improve before an emergency.