Most people discover their backup is broken at the worst possible moment. A laptop dies, a ransomware note appears on a shared drive, or a client asks for last quarter's files, and the restore either fails outright or returns a folder full of zero-byte documents. A 2024 survey of IT teams by a major backup vendor found that roughly a third of organizations that attempted a full recovery hit at least one unrecoverable dataset. The backup "succeeded" in the dashboard. The restore did not.
That gap between a green checkmark and a working recovery is the subject of this article. If you are evaluating backup software in 2026, the feature list on the product page will tell you very little about whether you can get your data back on a bad day. What matters is how the tool handles verification, encryption key management, retention, immutability, and the mechanics of an actual restore under pressure.
Below, we walk through what to check before you trust a backup tool, using a worked example with real numbers, a comparison of common approaches, and a restore test you can run this week. We also point out where a lot of marketing copy quietly skips the hard parts. If you are also tightening the rest of your security posture, our notes on hardening a password manager vault cover a closely related failure mode: credentials you cannot recover.
Key Takeaways
- A successful backup job is not a successful restore. Test restores on a schedule, and measure how long they take.
- Follow the 3-2-1-1-0 rule: three copies, two media types, one offsite, one immutable or air-gapped, and zero unverified backups.
- Encryption is only useful if you have the key. Store recovery keys separately from the data they protect, and test decryption too.
- Retention policies should match how long it takes you to notice a problem, not just how much storage you can afford.
- Immutability (object lock or write-once storage) is the single most important defense against ransomware that targets backup repositories.
- Check the restore granularity you need: file-level, application-consistent, or bare-metal. Many tools do only one well.
What does "backup software" actually need to do in 2026?
Backup software copies data from a source to a destination on a schedule, keeps historical versions, and lets you restore some or all of that data later. That definition has not changed in decades. What has changed is the threat model and the data landscape.
A modern backup tool now has to deal with:
- Ransomware that targets backups directly. Attackers look for mapped drives, backup admin credentials, and deletable cloud buckets before they encrypt production.
- SaaS data outside your servers. Email, Google Workspace, Microsoft 365, and code repositories hold data you do not physically control.
- Containers and cloud-native workloads where the "machine" is ephemeral and state lives in volumes or managed databases.
- Compliance demands around retention periods, encryption standards, and proof of recoverability.
A tool that handles a nightly copy of a folder to a USB drive is not wrong, but it is no longer sufficient for most business or serious personal use.
How do I check whether my restores will actually work?
The honest answer is that you cannot know until you test. But you can design a test that exposes the common failures quickly. Here is a worked example.
Worked example: a small studio with 3.2 TB of data
Imagine a three-person design studio. They have 3.2 TB of active project files, a 480 GB Postgres database for their client portal, and about 40,000 email messages in a hosted mailbox. Their current setup runs a nightly job to a 4 TB external drive in the office. The dashboard shows 90 consecutive successful jobs.
Their nightly job takes about 2 hours and 15 minutes. It reports "completed, 0 errors." Sounds fine. Now run the test:
- Pick a random restore target. Choose a project folder that changed in the last 30 days, plus one file from 11 months ago. Random selection matters because "the newest files usually work" is the most common false comfort.
- Restore to a separate machine or directory. Never restore over production during a test. Use a spare laptop or a temporary folder on a different volume.
- Time the restore. Note wall-clock time from clicking "restore" to the files being usable. Our studio finds that restoring the 3.2 TB set over their office network takes 11 hours, not the "a few hours" they had assumed. That number matters when a client deadline is tomorrow morning.
- Open the files. Check that a Photoshop file opens, a PDF renders, and a video plays. File presence is not file integrity.
- Restore the database and verify row counts. Compare the restored table counts against production. In their case, one table was silently excluded by a filter rule added eight months earlier.
- Restore one mailbox item. Confirm you can get a single message back without restoring the whole mailbox.
- Record the results. Write down the restore time, any failures, and the date. Repeat monthly.
After this exercise, the studio learns three things: the restore takes 11 hours, the database backup has been missing a table, and their only copy sits in the same building as their production machines. Each finding is fixable. None would have surfaced from the dashboard.
What should I compare when choosing backup software?
Backup tools fall into a few broad categories. The right one depends on what you protect and how much recovery speed you need.
| Approach | Typical use | Restore speed | Ransomware resistance | Offsite by default | Best for |
|---|---|---|---|---|---|
| Image-based backup (full system images) | Servers, workstations | Fast for full recovery, slow for single files | Moderate, depends on immutability settings | Optional | Bare-metal recovery |
| File-level sync or versioned backup | Documents, project folders | Fast for individual files | Low unless versions are locked | Usually via cloud target | Small teams, personal use |
| Application-aware backup (databases, mail) | Postgres, MySQL, Exchange, SQL Server | Depends on consistency checks | Moderate | Optional | Transactional systems |
| SaaS backup (email, Drive, M365) | Cloud collaboration suites | Good for item-level restore | High if vendor isolates data | Yes, vendor-hosted | Organizations on hosted suites |
| Snapshot-based (storage or hypervisor) | VMs, block storage | Very fast | Low if snapshots are deletable by the same admin | No, unless replicated | Fast rollback, not a full backup strategy alone |
Notice that snapshots appear in the table but are rarely a complete answer. A snapshot on the same storage array as production is convenient for "I deleted a file an hour ago," but it does not protect against the array failing, or an attacker with admin rights deleting every snapshot.
How should I set up encryption and key management?
Encryption protects backups from being read by someone who steals the destination. It also creates the most common silent failure: a backup that is encrypted with a key you no longer have. Treat the key as more important than the data, because without it the data is gone.
Setup walkthrough for encrypted backups
- Generate the encryption key or passphrase within the backup tool, using at least 20 random characters or a 256-bit key.
- Export or write down the recovery key immediately. Most tools show it once.
- Store the recovery key in a password manager entry that is separate from the machine being backed up. If you use a manager that supports passkeys and vault-based secrets, keep the recovery material in the vault, and make sure the vault itself is backed up somewhere other than the primary machine.
- Store a printed copy of the recovery key in a physical safe or with a trusted person.
- Run a decryption test on a second device using only the stored key, not the one still logged into the backup app. This is the step most people skip.
- Repeat the decryption test after any password or key rotation.
If your backup tool ties encryption to your cloud account login, consider what happens if that account is locked or compromised. Ideally, the encryption key can be recovered independently of any single login.
What retention and versioning policy makes sense?
Retention answers the question "how far back do I need to go?" The honest answer depends on how long a problem stays hidden. Ransomware often sits dormant for days or weeks before encrypting. A silent data corruption bug might not surface for a month. A retention window of seven days would miss both.
A practical starting point most small organizations can afford:
- Hourly or every-few-hours copies kept for 48 hours, for quick rollback.
- Daily copies kept for 30 days.
- Weekly copies kept for 12 weeks.
- Monthly copies kept for 12 months, or longer if regulation requires.
Check the storage math. Using the studio example, 3.2 TB of data with a 2% daily change rate and deduplication producing a 2.5x compression ratio means roughly 1.3 TB of unique stored data per month of daily copies. Keeping 12 monthly snapshots of a fully deduplicated repository might add another 2 to 3 TB. Plan the budget before you pick a retention tier.
Also confirm that retention deletion itself is protected. If an attacker or a disgruntled admin can delete all versions at once, retention policy is irrelevant.
Why does immutability matter so much for ransomware?
Immutability means that once a backup is written, it cannot be modified or deleted for a defined period, even by an administrator. In cloud storage this is usually called object lock or write-once-read-many (WORM) mode. In on-premises systems it may be a hardened Linux repository or an appliance with append-only policies.
The reason is simple. Ransomware operators have learned to find backup credentials and delete or encrypt backup catalogs before they launch the main attack. An immutable copy cannot be removed in that window, so the attacker's best move is gone.
When evaluating a tool, ask:
- Can the immutability lock be shortened or removed by an admin account? If yes, what approval is needed?
- Is the lock applied per-backup or per-bucket? Per-object is more
Cover image: Innovate Maryland Emerging Technology Center by MDGovpics, licensed under BY 2.0 via Openverse.
