The Basics of Data Backup Strategy

Data backup strategy is one of those topics where everyone agrees it matters and very few organizations get it right. The shape of the failure is consistent: the backup ran every night, the team assumed it worked, and when restore time came (after a ransomware attack, a hardware failure, an accidental deletion, a corrupted database), it turned out the backup was incomplete, untested, or compromised by the same incident that took down production. A backup nobody can restore from is a hope, not a strategy.

This post walks through what a real data backup strategy looks like, the 3-2-1 rule and why it still matters, the concepts of recovery point objective and recovery time objective, the specific practices that separate working backup discipline from theater, and a realistic approach for small and mid-sized businesses that don’t have dedicated IT operations teams.

What backups are actually protecting against

Before talking about how to back up data, it helps to be clear about what backups defend against. The threat list is broader than it looks:

• Hardware failure: disks fail, servers fail, RAID arrays sometimes fail in ways that take all the disks at once. Hardware redundancy is not the same as backup.
• Accidental deletion: a user, an admin, or an automated process deletes data that shouldn’t have been deleted. Common in databases, file shares, cloud storage buckets.
• Software corruption: a bad update, a buggy migration, or a failed schema change leaves data unrecoverable in its current state.
• Ransomware and malicious encryption: attackers encrypt your data and demand payment to decrypt it. Backups that can be cleanly restored defeat this attack entirely.
• Insider threat: a disgruntled employee deletes or corrupts data deliberately.
• Disasters: fire, flood, power surge, datacenter outage. Physical loss of the production location.
• Vendor failure: a SaaS provider loses data, goes out of business, or experiences a multi-day outage. Backups for SaaS data are often overlooked.

Different threats stress different parts of the backup strategy. Hardware failure needs working recent backups. Ransomware needs backups that the attacker can’t reach. Disasters need geographically separated backups. A complete strategy covers the full threat list, not just the most familiar parts.

The 3-2-1 rule (and why it still applies)

The 3-2-1 backup rule is decades old and remains the foundation of credible backup strategy. The rule:

• 3 copies of your data
• on 2 different storage media types
• with 1 copy stored offsite

The "3 copies" means production data plus two backup copies, not just two total. The "2 different media types" originally meant disk plus tape; today it more often means disk plus cloud, or local storage plus a different cloud provider. The "1 offsite" means at least one backup copy is physically or logically separated from the production environment, so a local disaster or local compromise doesn’t take out both production and backups.

Many modern practitioners extend the rule to 3-2-1-1-0:

• 3 copies, 2 media types, 1 offsite (original rule)
• 1 copy is immutable or air-gapped (can’t be modified or deleted, even by privileged accounts; this is the modern ransomware defense)
• 0 errors during regular restore tests

The extension reflects how the threat environment has evolved. Modern ransomware operators specifically target backup systems before deploying encryption; an immutable backup that can’t be deleted even by an admin account is the response to that pattern.

Recovery Point Objective and Recovery Time Objective

Two metrics quantify how good a backup strategy is, and they’re the right vocabulary for negotiating priorities.

Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time. An RPO of 24 hours means a worst-case restore loses up to 24 hours of data (because backups run daily). An RPO of 5 minutes means you’ve invested in continuous data protection (real-time replication, transaction-log shipping, snapshot intervals every few minutes).

Recovery Time Objective (RTO) is the maximum acceptable amount of downtime between the incident and full restoration. An RTO of 4 hours means you’ve committed to being back up within 4 hours. An RTO of 30 days means you’ve accepted that recovery might take a month.

RPO and RTO drive the backup design. Tight RPO means more frequent backups; tight RTO means faster restore mechanisms and warm standby capability. Both come with cost: tighter objectives require more infrastructure and operational investment. The discipline is to set realistic objectives by data category (financial transactions might need 5-minute RPO; marketing analytics might tolerate 24 hours) and then design the backup approach to match.

The mistake most small organizations make is not having stated RPO and RTO at all. Without explicit objectives, the backup strategy ends up shaped by what’s convenient rather than what the business actually needs.

What needs to be backed up (and what often gets missed)

A complete backup strategy covers more than the obvious categories.

The obvious things that almost everyone backs up: production databases, file shares, source code, websites and their content.

The things that frequently get missed:

• SaaS data: Microsoft 365, Google Workspace, Salesforce, QuickBooks Online, Notion, and other SaaS providers’ built-in data protection has gaps that aren’t covered by their own retention policies. Third-party SaaS backup tools fill this gap; most organizations don’t deploy them.
• Configuration: server configs, application configs, infrastructure-as-code state, network device configs. Restoring a database without the application configuration that runs against it is incomplete.
• Secrets and credentials: API keys, certificates, database passwords. These need backup (in encrypted form, with separate access controls), or restoration becomes a credential-replacement exercise.
• Email: not just the email server’s data, but individual mailboxes, especially for departed employees whose mailboxes hold business records.
• Endpoint data: laptops and workstations hold data that may not exist on the server. Endpoint backup is its own product category for this reason.
• Documentation and runbooks: if the wiki that documents how to restore the system is itself on the system that needs restoring, the restoration is harder than it should be.

The completeness check: if a serious incident took out every system in your office and your primary cloud account, what’s the path to restoring the business from scratch? Anything required for that path that isn’t backed up is a gap.

The practices that make backups actually restorable

Test the restore. This is the single most important discipline. An untested backup is a hope. A monthly (or quarterly) restore test against a subset of data confirms the backup actually works. Many organizations have discovered during a real incident that their backups had been silently failing for months because nobody tested them.

Use immutable or air-gapped storage for at least one backup copy. Cloud providers offer immutable storage features (object lock, retention locks). Tape backups (still surprisingly common in regulated industries) are inherently air-gapped. Offline rotated drives in a fireproof safe accomplish the same thing manually. The point is that at least one backup copy must be unreachable by anyone (or anything) with current production credentials.

Encrypt backups, both at rest and in transit. Backups contain everything sensitive that production contains. Treat them with at least the same security as production data; arguably more, because backups are a high-value target precisely because of their completeness.

Separate backup credentials from production credentials. The administrator who runs production should not have credentials that can delete the backup system. The whole point of immutability is broken if a single compromised admin account can wipe the backups.

Monitor backup jobs and alert on failures. A backup job that’s been failing for a week and nobody noticed is the worst case. Monitoring and alerting on backup completion is non-optional.

Document the restore procedure. Knowing how to restore is not the same as having backups. Write down the procedure, keep it accessible (and backed up itself, in a location separate from the production environment), and update it when anything changes.

Test restoration of the full system periodically. Smaller restore tests catch most issues, but a periodic full-system restore (annual at minimum for organizations with serious continuity requirements) catches issues that smaller tests miss.

A realistic approach for small and mid-sized businesses

For a small business that doesn’t have a dedicated IT team, the realistic baseline:

• SaaS backups: a third-party backup product for Microsoft 365 or Google Workspace (typical cost: $3–$10 per user per month). The major SaaS providers do not provide the level of granular backup that most businesses assume they do.
• Cloud backup for endpoints: a managed endpoint backup product (CrashPlan, Backblaze Business, Carbonite Endpoint, or similar) that protects laptops automatically.
• Cloud storage backup for any business-critical data not already covered by SaaS or endpoint backup. Versioned, with retention long enough to recover from delayed-discovery incidents (ransomware sometimes sits for weeks before encrypting).
• Documented restore procedure: a short written document covering how to restore each category of data, who has the credentials, and the rough time expected.
• Quarterly restore test: pick one backed-up category, restore a sample to a test location, confirm it works. Document the test and any issues found.

The investment is small ($10–$30 per user per month for the combination of tools, plus a few hours per quarter for testing). The return is the ability to actually recover when something goes wrong, which is usually only obvious in hindsight after a serious incident.

Frequently Asked Questions