Field Test: How We Actually Pick Backup Software for Tier 1 Data

“Which backup software should we use for our critical systems?” That’s the question we hear from every team that’s just been hit by a ransomware scare or a storage failure. They want a product name, a version number, a box to check. But in our line of work, we know the software is only a fraction of the answer. The real decision starts with numbers: how much data can you lose, and how fast must you be back?

Imagine you are a systems administrator at a mid-sized logistics company. You’ve been tasked with selecting backup software for your Tier 1 databases—the ones that handle customer orders and inventory. Your boss wants a recommendation by Friday. You’ve evaluated a few products, but you’re stuck because every vendor claims to be the best. This field report walks through how we actually decide, step by step.

Step 1: Define Your RPO and RTO Before You Look at Software

We never start with software. We start with the business requirements. The Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time—the latest point to which data can be restored (NIST). The Recovery Time Objective (RTO) is the maximum acceptable downtime (NIST). For mission-critical systems, these are often under one hour and under five minutes, respectively (NIST). That’s a common starting point for Tier 1.

In our scenario, the databases are mission-critical, so we set an RPO of five minutes and an RTO of one hour. That means we can lose at most five minutes of transactions, and we must be fully operational within an hour of a failure. These numbers are non-negotiable; they drive every other choice.

Step 2: Map the 3-2-1-1-0 Rule to Your Environment

The classic 3-2-1 rule—three copies of data, on two different media, with one off-site—is still the baseline (CISA). But modern ransomware has pushed us toward the 3-2-1-1-0 rule: add one immutable or air-gapped copy, and zero unverified backups (CISA). That’s not optional anymore. NIST SP 800-209 defines immutability as locking data after creation, preventing alteration or deletion (NIST SP 800-209). We need that.

For our Tier 1 data, that means we’ll have three copies: the primary database, a local backup on a different device (say, a NAS), and an off-site copy in the cloud. On top of that, we’ll create an immutable copy—perhaps in object storage with versioning or write-once-read-many (WORM) settings—and we’ll commit to testing every backup. That’s the 0: no unverified backups.

Step 3: Choose the Right Backup Types for Each Tier

Not all backups are created equal. A full backup copies everything but takes time and storage (Backup terminology). Incremental backups copy only changes since the last backup, requiring the last full plus every incremental to restore (Backup terminology). Differential backups copy changes since the last full, needing only that full plus the latest differential (Backup terminology). And snapshots are point-in-time copies that use pointers, so they’re fast but may not survive if the source is lost (NIST SP 800-209).

We use a mix. For Tier 1, we rely on continuous data protection (CDP), which transmits changed blocks continually to a target, improving RPO (NIST SP 800-209). That gives us near-real-time recovery points, easily meeting our five-minute RPO. But we also take daily full backups and hourly snapshots, because CDP alone might not protect against logical corruption. The key is to match backup types to recovery objectives—snapshots should be configured to meet the RPO: if you can’t lose more than five minutes, snapshot intervals must be five minutes or less (NIST SP 800-209).

Step 4: Plan for Off-Site and Immutable Copies

Off-site backups are non-negotiable. A site-level disaster—fire, flood, theft—can wipe out everything on-premises. Cloud storage is a common choice, but we must ensure the same level of protection as primary storage: encryption of data at rest and access restrictions (NIST SP 800-209). And if we encrypt backups, we must protect the encryption keys for the same duration, and never store them with the data (NIST SP 800-209).

For the immutable copy, we use object storage with object lock or a dedicated air-gapped appliance. That copy is our last line of defense against ransomware that tries to encrypt or delete backups. NIST SP 800-209 warns that attackers target backups and may poison them over time (NIST SP 800-209). So our immutable copy is isolated and write-protected.

Step 5: Test, Test, and Test Again

An untested backup is an assumption—that’s the mantra we live by (NIST). Regular restore tests are essential; high availability (replication) is not a substitute for backups. CISA advises maintaining offline, encrypted backups and regularly testing them (CISA). NIST SP 800-209 recommends testing backups at least monthly for critical data, and doing end-to-end test restores for applications with strict RTOs (NIST SP 800-209).

In our scenario, we schedule a monthly restore test of the Tier 1 databases into a sandbox environment. We also keep a recovery catalog that records each copy and the results of anti-malware scans, and we periodically scan a subset of past copies with current anti-malware tools to catch poisoned copies (NIST SP 800-209). And we review the backup plan annually (NIST SP 800-209).

One concrete example: last quarter, we simulated a ransomware attack. We restored the database from the immutable copy, and because we had tested the restore process, we were back online in 45 minutes—well within the one-hour RTO. Without those tests, we would have been scrambling.

Step 6: Evaluate Software Against Your Requirements, Not the Other Way Around

Now we’re ready to look at software. We list the must-haves:

• Supports CDP or frequent snapshots to meet the RPO.
• Can create immutable copies in cloud storage or on-premises.
• Allows tiering of backup frequency and retention per data class.
• Integrates with our existing monitoring and alerting.
• Provides automated restore testing or at least a simple restore workflow.

We also check whether the software can handle both file-level and image-level backups, as NIST SP 800-209 distinguishes between them (NIST SP 800-209). For our databases, we need image-level backups for consistent restores, but we also use file-level for less critical data.

We shortlist three products. The first is an enterprise suite that does everything but costs a fortune and is complex to manage. The second is a cloud-native tool that’s easy but lacks immutability features. The third is a mid-range product that supports CDP, immutable backups, and has a good API. We choose the third because it meets all our requirements without overkill.

Bottom line

The single best move is to define your RPO and RTO first, then enforce the 3-2-1-1-0 rule with immutable copies and regular testing. Software is just the vehicle; the destination is a verified, recoverable backup. Do that, and you’ll be ready when the worst happens.

Sources

• CISA - https://www.cisa.gov/stopransomware
• NIST - https://csrc.nist.gov/glossary
• NIST SP 800-34 Rev. 1 - https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
• NIST SP 800-209 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
• CISA ransomware response checklist - https://www.cisa.gov/stopransomware/ive-been-hit-ransomware