A practical guide to backups and recovery

A backup is a copy of data that you keep so you can restore it after deletion, device failure, a cyberattack, or another disruption. A usable backup preserves a version of the data from before the problem that you can restore.

File syncing serves a different purpose: it keeps files aligned across devices or locations by copying changes, including accidental deletions and unwanted edits. Some sync services keep version history, but syncing alone does not ensure that an earlier usable copy remains available.

Set the recovery goal before choosing backup software or storage. Decide what you need to restore. Set a limit for how much recent data you can afford to lose, then decide how quickly you need it back. Then choose backup copies and recovery steps that meet those needs. Test a restore to confirm that you can retrieve the files, devices, and online-service data that matter most.

Decide what must be restored

List the data, devices, and services you rely on before choosing backup tools or schedules. For personal use, cover computers and phones. Also include photos, documents, and cloud accounts. For a business, account for records and databases, and include servers and software-as-a-service (SaaS) accounts. Include data stored online. A cloud provider’s copy does not ensure that you can restore the files, account settings, or records you need.

Rank each item by what its loss would mean. Consider missed work and interrupted service, as well as financial loss or harm to customers. Then identify dependencies. A database may need a specific application to use its contents. That application may depend on identity services and network access, along with configuration records. Restoring database files alone does not restore the service.

Set downtime and data-loss limits

Use two targets to turn priorities into recovery requirements. A recovery time objective (RTO) sets the longest acceptable time that a service remains unavailable after a disruption. A recovery point objective (RPO) sets the greatest acceptable span of lost changes, measured in time.

An RTO of one hour means the service must be restored within one hour of the disruption. An RPO of one day accepts the loss of up to one day of changes. RTO limits downtime; RPO limits data loss.

Set separate targets for different data and services. Recovery limits depend on the data: losing a day of changes to replaceable files may be acceptable, while losing an hour of customer transactions may not be. Base each target on the consequences of loss, the cost of meeting it, and the time needed to restore the data and its dependencies. A target matters only if the backup and restoration method can meet it.

Choose backup copies and locations

A backup plan works only when one failure cannot destroy every copy. The 3-2-1 rule provides a practical starting point: keep three copies of important data, on at least two types of storage, with one copy offsite. The original file counts as one copy.

The rule reduces shared risk, but it does not guarantee recovery. Copies can still fail together if they rely on the same account or network. The same risk applies when they depend on the same administrator credentials or encryption keys.

Choose a backup method

A full backup copies all selected data each time. It takes more time and storage space, but recovery begins with one complete copy.

An incremental backup copies changes since the previous backup. It uses less time and storage for each run, but recovery requires the full backup and every later incremental backup in sequence. One missing or damaged incremental backup can prevent a complete restore.

Separate storage locations

An external drive provides fast local recovery without an internet connection. Disconnect it after the backup finishes so malware or an attacker who reaches the computer has less opportunity to reach the backup.

A network-attached storage device keeps backups available across a home or office network. That convenience also creates exposure: an attacker who gains access to the network may reach the backup device.

Removable media, such as external drives or tape, can remain separate from the computers they protect. Cloud storage keeps a copy in another physical location, which helps when a home or office is damaged. Recovery still depends on internet access and continued access to the provider account.

A cloud folder that continuously syncs files can copy deletions, corruption, or malicious encryption. Keep earlier recoverable versions in the backup set, and separate at least one copy from the original data’s location, network, and account.

Offsite and offline copies address different failures. An offsite copy helps when a building, its equipment, or local storage is lost. An offline or otherwise isolated copy is harder for malware on a connected device to reach. CISA recommends keeping backups offline and testing recovery.

Protect copies from attack

Keep at least one backup beyond the reach of the account, network, or device that holds the original data. An attacker who gains access to a network-connected backup location or shared administrator credentials may erase or encrypt both the original data and its copies.

Use an offline copy, an isolated copy, or storage protected by immutability. Immutability prevents a backup from being changed or deleted for a defined retention period.

Limit changes and access

Confirm how immutability works before relying on it. Check whether an administrator can shorten the retention period, remove immutability, or delete the storage account.

Use separate administrator accounts for backup storage and its management console. Give each account only the permissions needed to create, manage, or restore backups. Require multifactor authentication and unique passwords. Separate credentials limit the damage from a compromised everyday account.

Protect keys and cloud access

Encryption prevents unauthorized people from reading backup data. Encryption in transit protects data while it moves between devices and storage. Encryption at rest protects data stored on a drive or with a cloud provider.

Keep recovery keys separate from the backup, while ensuring authorized people can reach them during an outage. Lost recovery keys can make encrypted backups unusable. NIST guidance on storage encryption covers protection for stored data.

For cloud backups, confirm who controls the account, how long deleted data remains recoverable, and how access will be restored if the account is locked or the subscription ends. A backup that exists but cannot be accessed does not support recovery.

Minimum backup safeguards

For a small setup, keep one backup disconnected except while updating it. Use separate credentials for each backup location that remains online. Test file restoration and access to encryption keys before relying on the copies.

The cost of offline backups

Offline storage and strict access controls require someone to manage removable drives, credentials, and recovery tests. That work prevents a single compromised account or device from erasing every copy. Choose safeguards you can maintain consistently.

Key takeaway

Keep at least one backup beyond the reach of ordinary account credentials, and verify that you can access and restore it.

Set frequency and retention

Set backup frequency by the amount of recent work you can afford to lose. This limit is the recovery point objective (RPO): the longest acceptable gap between the last usable backup and a failure.

An RPO of one day can support daily backups. Records that change throughout the workday need more frequent backups because a daily backup could leave a full day of changes unrecoverable. Continuous data protection records changes as they occur and reduces that gap further. Daily backups for replaceable files and more frequent protection for active records are examples, not universal settings. More frequent backups reduce the data lost between recovery points.

Retention answers a different question: how far back you need to restore. Keep enough earlier recovery points to recover data from before a deletion, corruption event, or malware infection. The latest backup may already contain the damaged or deleted data.

Longer retention requires more storage and raises storage costs. Base the retention period on how long a problem might remain undiscovered and how much storage you can maintain. Protect retention settings so an attacker cannot delete the recovery history.

Check devices and services

Laptops and phones that are not always connected need separate attention. A scheduled backup cannot finish while a device is offline. Check the backup tool for the last successful backup, confirm that it includes the files you need, and resolve missed-backup alerts before relying on that copy.

Treat cloud and SaaS data as a separate backup decision. Providers set different limits for version history and deleted-item recovery. Check the provider’s documentation for recovery windows, covered data and settings, and export and restore options. Keep an independent backup when the provider does not preserve the recovery history you need or when recovery depends on the same account that an attacker could take over or that could become inaccessible.

Plan the restore order

Assign recovery roles before an outage or attack. Name who starts recovery and who can access backup accounts. Also assign someone to approve major decisions and someone to update household members, employees, customers, or other affected people. In a household, one person may hold several roles. In a business, assign a backup for every role in case the primary contact is unavailable.

Set the restore order around what makes critical data usable. A database, for example, may need server software, identity services, network access, and configuration records before users can reach its contents. List these dependencies, then rank services by the harm their outage causes.

Keep the recovery plan available when primary devices or accounts are unavailable. Record where each backup is stored and how to reach it. Note the credentials and encryption keys it requires, and how to contact the people responsible for recovery. Protect this information so someone who compromises everyday accounts cannot also alter or delete the backups.

Isolate before restoring

During a suspected cyberattack, disconnect affected devices from the network and do not connect backup storage to them. NIST’s ransomware guidance warns that ransomware can spread between computers, so contain the incident before assessing recovery. When the scope is unclear or sensitive systems are involved, bring in qualified security professionals before restoring data.

Before restoring to live devices or services, scan and test the selected backup in an isolated environment. Confirm that it works and contains no malicious or corrupted data. Then restore in the planned order while keeping recovery accounts, devices, and storage separate from any environment that remains compromised.

Test actual restores

A “backup completed” message confirms that the backup job ran. It does not prove that the copy contains every important file or that you can restore usable data.

Start by restoring a small file to a separate location. Open it and confirm that it includes the expected recent changes. Then test a larger recovery that reflects what you rely on, such as a shared folder, database, or business service. Check that restored files retain the required permissions and that related files or records still work together. For a database or service, confirm that it operates normally after restoration; seeing files reappear is not enough.

Test under conditions that resemble a real incident. Assume that the original device, office, or primary account is unavailable. Confirm that an authorized person can access the offsite backup, recovery instructions, administrator credentials, and encryption keys without relying on the failed location or account.

Define a successful recovery before testing. Record what you restored, how long the restore took, what failed, and what you changed afterward. Compare the result with the RTO and RPO. Did the service return within the required time? Did the restored copy include enough recent changes? Correct gaps and repeat the test.

Retest after significant changes to important data or backup software. Retest as well when cloud providers or recovery instructions change significantly. An annual restore test is one possible minimum schedule. Test more often when data, services, or recovery procedures change frequently, or when a failed restore would cause serious harm.

Where backup plans fail

A backup supports recovery only if attackers cannot destroy it, it contains the data needed to resume work, and it restores safely. Veeam’s 2024 Ransomware Trends Report surveyed 1,200 security and backup professionals at organizations that experienced ransomware in 2023. Respondents said attackers targeted backup repositories in 96% of attacks and breached them in 76%. Those figures describe surveyed ransomware victims, not the risk faced by every organization.

Respondents recovered an average of 57% of affected data. The result shows the gap between possessing backups and recovering usable data after an attack. The survey also found that 63% of respondents did not quarantine or sandbox backups before restoring them. A sandbox is an isolated environment where responders inspect data without exposing live systems. Restoring unchecked backups can return malicious files or corrupted data to live systems.

Paying a ransom is also an unreliable recovery plan. About two-thirds of surveyed organizations that paid reported recovering their data, leaving roughly one-third reporting no recovery.

Maintain separate copies that an attacker cannot access through the primary account or network. Test that critical data restores correctly, and include backup owners and security responders in restoration decisions. During a suspected attack, isolate affected devices, inspect backup data in an isolated environment, and restore only clean, usable copies.

Questions to settle

How many backups are enough?

Start with the 3-2-1 rule: keep three copies of important data on at least two types of storage, with one copy offsite. Then check for shared failure points. Copies that use the same account, administrator credentials, encryption keys, or network connection may fail together.

Keep one copy offline, isolated, or immutable, meaning protected from alteration or deletion for a defined retention period. Test recovery to confirm that the copies are usable.

How often should I back up?

Set the schedule from your RPO: the maximum amount of recent work you can afford to lose. If losing four hours of work is acceptable, capture changes at least every four hours.

Also retain enough older recovery points to recover from problems discovered after the latest backup was created.

Is cloud storage a backup?

Cloud storage can hold an offsite backup copy when it preserves independent, recoverable versions of your data. A sync service alone may copy deletions, file corruption, and unwanted changes to every synced location.

Check the provider’s recovery window, version history, account controls, and export options. Confirm that you can restore data if the primary account becomes unavailable.

How often should I test restores?

Test after major changes to the data, backup tool, account access, or recovery instructions. Use a regular schedule that reflects how quickly those elements change and how serious a failed restore would be.

Each test should confirm that recovered files open, contain the expected data, and remain accessible when the original device or account is unavailable.

Key Takeaways

• Set recovery targets first: Decide what data and services matter, how much recent work you can lose, and how long each can be unavailable. Set backup frequency and restore priorities from those limits.
• Keep independent copies: Use separate storage locations and accounts where practical, with at least one offsite copy and one offline, isolated, or immutable copy.
• Protect enough recovery history: Match backup frequency to the data loss you can tolerate. Retain earlier copies long enough to recover from problems discovered late.
• Test safe restoration: Restore files and critical services, verify that the data works, and record how long recovery takes. After a suspected attack, inspect backups in isolation before restoring them to live systems.

FAQ

How many backups are enough?

Three copies on two types of storage, with one copy offsite, is a useful starting point. Keep at least one copy outside the reach of the primary account or network, and test that you can restore it.

How often should I back up?

Choose a schedule based on how much recent work you can afford to lose. If losing a day of changes is acceptable, daily backups may meet that goal. Data that changes throughout the day needs more frequent backups.

Is cloud storage a backup?

Cloud storage counts as a backup when it keeps independent, recoverable copies with enough history for your needs. Syncing alone can copy deletions or unwanted changes, so check the provider’s recovery window, account access, and export options.

How do I know whether my backups work?

Restore files and confirm that they open and contain the changes you expect. For a database or service, test that it works after restoration. Record how long recovery took and how much data was missing.

What if ransomware reaches my backups?

Disconnect affected devices from the network and avoid restoring unverified data to live systems. Use an offline, isolated, or immutable copy if available. Scan and test the selected backup before restoration, and get qualified security help if the incident’s scope is unclear.

What if my laptop is rarely connected?

Check the backup status after reconnecting and confirm that the latest files have uploaded or copied. A backup schedule does not protect changes that the device has not sent to the backup location.

Does paying a ransom guarantee that I will recover my data?

No. In Veeam’s 2024 survey of organizations affected by ransomware in 2023, about two-thirds of those that paid reported recovering their data. Payment did not ensure recovery. Tested, protected backups provide a separate recovery path.