Backup Retention Concepts for SMBs

Backup retention is frustrating. It consumes storage faster than expected, resists quick fixes when space runs low, and quietly accumulates costs. Yet it is also what makes recovery possible. The same mechanisms that cause storage headaches—keeping deleted files, preserving multiple versions, enforcing retention windows—are what save you when disaster strikes.

Consider two employees at the same company:

Bobby in Engineering: The storage headache

Bobby downloads a 20 GB ZIP archive of CAD libraries, extracts it to the shared drive (now 40 GB: ZIP + extracted files), and works with the files for a week. Then he deletes both the ZIP and the extracted folder, satisfied that he has freed space.

But your backup system has been capturing this activity daily. For the next 30 days (or whatever your retention window is), those 40 GB remain in your backup repository. If you keep multiple versions, you may have several copies of that ZIP and the extracted files stacked on top of each other. Bobby freed 40 GB on the file server. Your backup storage grew by 40 GB (or more) and will not shrink for a month.

This is maddening when you are trying to control costs. It feels like the backup system is working against you.

Jeremiah, the CEO: The recovery lifeline

Three months ago, Jeremiah saved a critical board report to the shared drive. His assistant, cleaning up old files, accidentally deleted it a week later. Neither noticed at the time—Jeremiah had moved on to other work, and the assistant assumed it was archived elsewhere.

This week, the board asks for that report for a compliance review. Panic ensues. The file is not in the cloud, not in email, not on anyone's desktop. It appears to be gone forever.

Except your backups have been running with 90-day retention. The report, deleted three months ago, still exists in your backup chain. You restore it. Jeremiah has his document. The compliance review proceeds. Nobody has to explain to the board why critical records disappeared.

The same system, two outcomes

The retention rules that made Bobby's cleanup ineffective at freeing backup space are the same rules that saved Jeremiah's report. You cannot have one without the other. If backups immediately deleted files when they were removed from production, Bobby's cleanup would free space—but Jeremiah's report would be unrecoverable.

Important distinction: This guide covers backup retention for disaster recovery—typically measured in days to months. If your industry requires years of records retention (FINRA's 3-year email requirement, HIPAA's 6-year documentation, or legal's 7+ year client files), backups alone are insufficient. You need a broader data retention policy that includes email archiving, live data governance, and SaaS retention controls alongside backups.

This guide focuses on managing the pain: understanding why storage grows, planning for it, and making retention decisions with eyes open. But never forget: the pain exists because the protection is real. The goal is not to minimize retention until backups are easy to manage. The goal is to right-size retention so it matches your actual recovery needs without surprising you with storage costs.

A common SMB surprise: you delete 500 GB of old project files to free space, but your backup repository shows no change. Or worse, it grows.

How retention works: When you delete a file from production, most backup systems keep that file in the backup chain until the retention period expires. If your policy keeps 30 days of backups, a deleted file remains recoverable for 30 days. This protects against accidental deletion—but it also means storage consumption trails file deletion by the retention window.

The version accumulation problem: If your policy keeps "the last 30 versions" of every file, editing a single 1 GB file 30 times creates 30 GB of backup storage. Multiply this across active file shares and storage grows faster than raw data size suggests.

Immutability compounds this: With immutable backups, you cannot manually delete old versions early to free space—even if you know you do not need them. The retention period is enforced by the storage layer.

What to do: Size backup storage for "retained data," not just "current data." Factor in version accumulation and deletion lag. Plan capacity for 18-24 months of growth.

Backup products offer different versioning strategies. Understanding the tradeoffs helps you choose what actually protects your data.

Keep-all versioning

Every change creates a new version. You can restore any point in time within the retention window.

• Best for: Detecting slow-burn corruption, recovering from ransomware that spread over weeks, compliance requiring point-in-time recovery.
• Storage cost: Higher. Every edit consumes space until the retention period expires.
• Recovery granularity: Maximum. You can recover exactly the version you need.

Last-N versioning

Only the most recent N versions are kept. Older versions are removed as new ones are created.

• Best for: Space-constrained environments, files with predictable change patterns, short-term recovery needs.
• Storage cost: Lower and predictable. At most N versions per file.
• Risk: If corruption or ransomware spreads undetected through your N versions, you may have no clean copy to recover. Example: keeping "last 3 versions" and corruption goes undetected for a week.

The SMB compromise

Many organizations use a hybrid: rolling daily retention (30-90 days) plus periodic "anchor" points (weekly or monthly fulls) that are kept longer. This balances granularity with storage costs while maintaining recovery options for different scenarios.

Grandfather-Father-Son (GFS) is a decades-old retention scheme that many backup administrators assume is standard. It is not universal—and many modern products do not use it.

How GFS works

• Son (Daily): Short-term backups, typically kept for 7-14 days.
• Father (Weekly): Weekly full backups, kept for 4-6 weeks.
• Grandfather (Monthly): Monthly archives, often kept for 6-12 months or longer.

The scheme provides multiple recovery points at different granularities. Need a file from Tuesday two weeks ago? Use the weekly. Need something from six months ago? Use the monthly.

When GFS is not used

Modern backup products increasingly use different approaches:

• Incremental forever: One full backup, then perpetual increments. Synthetic fulls are created on-demand for faster recovery.
• Simple rolling retention: Keep the last N days/weeks/months, without the GFS hierarchy.
• Object storage with lifecycle policies: Cloud-native approaches that transition data between storage tiers based on age.

What SMBs should know

Do not choose a product because it has GFS or avoid one because it does not. Choose based on your recovery time objectives and how you actually recover data. If you rarely need files older than 30 days, a simple rolling 90-day retention may be more cost-effective than GFS with 12-month grandfather archives.

Related: RPO/RTO definitions and how they should drive retention decisions.

One of the most painful SMB discoveries: you cannot easily move backup data to new storage without treating it as a completely new backup set.

Why backups resist migration

• Deduplication dependencies: Many backup products deduplicate across the entire backup set. Moving data breaks the deduplication index, requiring a full re-seed.
• Proprietary formats: Backup data is often stored in vendor-specific formats that cannot be read by other products or even the same product on different storage.
• Incremental chains: Moving an incremental backup requires moving its parent full and potentially the entire chain to maintain recoverability.
• Immutability locks: Immutable backups cannot be moved until their retention period expires—by design.

What this means for planning

When you choose backup storage, assume you will be using it for 2-3 years minimum. Do not size for today's data—size for:

• Current data plus 2-3 years of growth
• Retention window storage (data × retention multiplier)
• Version accumulation (for active file shares)
• Immutability overhead (if enabled)
• 20-30% headroom for unexpected spikes

If you must migrate

Plan for a transition period where both old and new backup sets exist simultaneously. Keep the old repository for the duration of your longest retention requirement. This provides continuity while the new backup chain establishes its own history.

Budget for the storage cost of running parallel repositories—this is often cheaper than the business risk of gaps in backup history during a failed migration.

Storage grows faster than expected

Symptom: Backup storage fills up every 6 months despite "only" 2 TB of production data.

Causes: High-version retention on active shares, misunderstanding of retention lag (deleted files stay in backups), lack of compression or deduplication awareness.

Fix: Audit your most active file shares. Consider version limits for high-churn directories. Right-size retention for different data types using data classification.

"We have 90 days of backups" does not mean what you think

Symptom: Confident in 90-day retention, but when ransomware hits, you discover the payload has been present for 120 days.

Reality: Retention depth matters less than detection speed. If you only keep 30 days but detect ransomware in 7, you are fine. If you keep 90 days but detect in 120, you are not.

Fix: Pair retention depth with detection capability. Related: ransomware preparedness and monitoring to reduce time-to-detection.

Immutability lock-in surprises

Symptom: Enabled 1-year immutability as "best practice," now cannot free space during a capacity crunch or storage migration.

Fix: Match immutability periods to actual recovery requirements. Start with shorter windows (30-90 days) and extend as you validate recovery processes. Plan storage capacity as if you cannot delete anything for the immutability period.

Different retention for different data types

Symptom: One-size-fits-all retention means critical data has insufficient history while archival data wastes expensive primary backup storage.

Fix: Align retention tiers to data value and recovery needs:

• Critical operational data: Long retention (90+ days), frequent testing, immutability.
• Standard file shares: Moderate retention (30-60 days), version limits on high-churn areas.
• Archival data: Long retention but infrequent backups, possibly separate storage tier.
• Development/test data: Short retention (7-14 days), minimal versions.

SaaS backup gaps

Symptom: Confident in local server backups, but no retention strategy for Microsoft 365, Google Workspace, or SaaS applications.

Reality: SaaS providers offer limited native retention (often 30 days). Deleted emails or files may be unrecoverable after that window without third-party backup.

Fix: Include SaaS data in retention planning. SaaS backup retention should match your recovery needs, not the vendor's default.

# Backup Retention Planning Checklist

## 1. Define recovery scenarios
- [ ] Ransomware recovery (how far back might we need to go?)
- [ ] Accidental deletion (typical detection window?)
- [ ] Compliance/legal hold requirements
- [ ] Application corruption recovery

## 2. Document retention policies by data type
- [ ] Critical systems: ___ days, ___ versions
- [ ] File shares: ___ days, ___ versions
- [ ] Email/SaaS: ___ days, ___ versions
- [ ] Development/test: ___ days, ___ versions

## 3. Size storage for reality
- [ ] Current data size: ___ TB
- [ ] Retention multiplier: ___x (days of retention)
- [ ] Version accumulation estimate: ___%
- [ ] Annual growth: ___%
- [ ] Required capacity: ___ TB
- [ ] Headroom (20-30%): ___ TB
- [ ] Total target: ___ TB

## 4. Plan for immutability
- [ ] Immutability period: ___ days
- [ ] Storage cannot be freed early: acknowledged
- [ ] Migration impact understood: yes/no

## 5. Test recovery from different retention points
- [ ] Test restore from yesterday
- [ ] Test restore from 30 days ago
- [ ] Test restore from 90 days ago (if applicable)
- [ ] Document any issues or gaps

• Retention defines how long you can recover, but also how fast storage grows. Plan for the lag between file deletion and backup space reclamation.
• Keep-all versioning offers maximum protection but at higher storage cost. Last-N saves space but may miss clean recovery points.
• GFS is traditional but not universal. Choose retention schemes based on your recovery needs, not product defaults.
• Backup migrations are often harder than expected. Size initial storage for 2-3 years to avoid mid-cycle capacity crises.
• Immutability protects against deletion but also prevents early space reclamation. Match immutability periods to validated recovery requirements.
• Different data types need different retention. One-size-fits-all wastes money on some data and under-protects other data.
• The storage pain is the protection. The same rules that make Bobby's ZIP files persist in backups for 30 days are what let you recover Jeremiah's deleted report three months later. Manage the cost, but never forget the value.