bbackup - Essential Steps for Secure Backups

Most backup conversations focus on whether a copy exists at all, but the harder and more consequential question is how long that copy should stick around. Retention policy — the rules that decide when an old backup gets deleted and when it gets kept — is where a lot of otherwise solid backup programs quietly fail. Get retention wrong and you end up in one of two bad places: paying to store years of redundant data nobody will ever restore, or discovering during an actual incident that the one backup you need was already overwritten. Retention isn't a checkbox next to "backups enabled." It's a design decision that has to account for how systems fail, how ransomware behaves, and what regulators or auditors will eventually ask for.

Want expert help putting this into practice? B-Backup Pro can guide you through it.

Why retention length is a deliberate decision, not a default

Backup software ships with a default retention window — seven days, thirty days, sometimes just "keep the last three copies." Those defaults exist to keep storage costs predictable for the vendor, not because they match your operational reality. A retention policy should instead start from a question: if something goes wrong, how far back might we need to reach for a clean, usable copy of this data? A shared file server might need weeks. A financial database subject to statutory retention might need years. A build server that regenerates its own state from source control might need only a few days. Treating retention as a single fleet-wide number wastes storage on low-value systems and under-protects the high-value ones.

Grandfather-Father-Son and other rotation schemes

Related: bbackup - Expert Advice for Secure Data Backup.

The classic answer to "how do we keep enough history without keeping everything" is a tiered rotation scheme, and the best known is Grandfather-Father-Son (GFS). Under GFS, daily backups ("sons") are kept for a short window — commonly a week or two — before being deleted. One backup per week is promoted to "father" status and held for a month or more. One backup per month is promoted again to "grandfather" and held for a year or longer, sometimes with a single yearly backup retained indefinitely for archival purposes. The effect is a pyramid: dense, recent history for fast operational recovery, and sparse, long-range history for going back further in time when needed.

Variants exist for different needs. Tower of Hanoi rotation spreads backup media use more evenly across a cycle, which mattered more in the tape era but still helps minimize wear on backup targets. Incremental-forever schemes, common in modern disk and cloud backup, keep a single full backup plus a long chain of incrementals, then apply synthetic full construction so restore chains don't grow unmanageably long. Whichever scheme you use, the goal is the same: more granularity close to "now," less further back, and a defined point where data ages out entirely.

Retention and ransomware: why version history is the actual recovery mechanism

Ransomware recovery is where retention policy stops being an abstract cost-versus-value tradeoff and becomes existential. Modern ransomware frequently sits dormant inside a network for days or weeks before triggering encryption, specifically to poison backups taken during that window. If your retention only reaches back seven days and the dwell time before detonation was ten, every backup you have is a backup of already-compromised data. The only thing that gets you out of that scenario is version history that reaches back further than the attacker's dwell time — enough restore points that you can walk backward until you find one that predates the initial compromise, not just the encryption event.

This is why security-conscious retention design usually specifies a minimum lookback window explicitly for ransomware resilience — often 30 to 90 days of daily or near-daily restore points, independent of whatever the "normal" operational retention would otherwise be. It's also why immutable or write-once backup storage matters alongside retention: a long retention window is meaningless if an attacker with admin credentials can simply delete the older backups along with the live data. Retention length and backup immutability are two different controls that have to work together — one determines how far back you can look, the other determines whether that history survives an attacker who knows it's there.

Compliance retention versus operational recovery retention

See also: How to Master backup and protect your data.

It's worth separating two retention needs that often get conflated into one policy, because they're answering different questions. Operational recovery retention exists to answer "can we undo a mistake or recover from corruption quickly," and it's driven by how often data changes and how soon errors tend to get noticed. Compliance retention exists to answer "can we produce records that a regulator, auditor, or court requires," and it's driven entirely by external rules — tax record requirements, industry-specific regulations, contractual obligations with customers, or data protection law. These two clocks rarely match. A company might need daily operational restore points for only 60 days but be required to retain certain financial or health records for six or seven years.

Bundling both into a single retention number produces the worst of both worlds: either operational backups are kept far longer than useful (expensive, and a larger attack surface for exfiltration of historical data), or compliance-relevant records get deleted on a schedule that doesn't satisfy the legal requirement. The more durable approach treats compliance retention as its own archival tier — separate from day-to-day rotation, often stored differently, and reviewed against actual regulatory text rather than assumption.

Balancing storage cost against retention length

Every additional day of retention costs storage, and with incremental or deduplicated backup that cost isn't linear — it depends heavily on how much data actually changes between restore points. A file server with mostly static archives can afford long retention cheaply, because incrementals stay small. A database with high write volume or a system that rewrites large binary files regularly will see storage grow quickly the further back retention reaches. This is one of the practical reasons GFS-style tiering exists: full granularity is expensive to hold indefinitely, so you thin it out as data ages, keeping the most valuable (most recent) history dense and the older history sparse. When setting retention, price out a few candidate windows against each system's actual change rate before locking in a number — a policy that looks reasonable on paper can turn out to be far more expensive once real deduplication ratios are known.

Setting a retention policy that will actually hold up

A workable retention policy documents, per system or system tier: the minimum lookback window needed for ransomware resilience, any compliance-driven retention that overrides the operational default, the rotation scheme (GFS or equivalent) that governs how backups age from dense to sparse, and who is responsible for reviewing the policy when regulations or business needs change. It should also be tested, not just written — a retention policy that has never been used to actually restore a 45-day-old file is a policy nobody has verified. Providers like B-Backup Pro build retention and version history into the backup architecture itself, rather than leaving it as an afterthought bolted onto storage configuration, precisely because retention is the setting that determines whether a disaster recovery actually succeeds when it's needed. Get the retention design right, and everything downstream — cost control, compliance posture, and ransomware resilience — gets substantially easier to defend.