How Long Should You Keep File Versions After a Ransomware Attack?

Keep daily file versions for at least 30 to 90 days as a practical starting range after a ransomware attack, but do not treat that as a universal deletion deadline. Retention should extend beyond the earliest plausible compromise date, preserve selected weekly or monthly clean points, and keep incident evidence separately until recovery, investigation, insurance, legal, and compliance work are complete.

A Practical Starting Range Is 30 to 90 Days

Many backup designs use 30 to 90 days of daily immutable history for operational ransomware recovery. An immutable-backup overview notes that 30 to 90 days is a common daily retention range for ransomware protection. Treat this as a starting point, not a guarantee that the oldest retained version is clean.

The lower end is only reasonable when infection is detected quickly, older copies are isolated, and a clean restore has already been proven.

Start the Clock Before the Ransom Note Appeared

The visible encryption event may occur days or weeks after initial access. A ransomware backup strategy should account for the dwell time between initial compromise and the visible ransomware event. If the earliest suspicious login, script, credential use, or file change occurred 45 days before encryption, a 30-day version window may contain no clean point.

Use the earliest plausible compromise date from logs, endpoint alerts, identity records, and incident-response findings. Then add a safety margin for incomplete evidence. The retention window should cover that date, not merely the date users first saw encrypted files.

Use Tiered Retention Instead of One Rolling Window

A flat rolling window can delete every older clean point on the same schedule. Tiered retention keeps dense recent versions while preserving fewer long-horizon checkpoints.

A recent retention analysis shows why selected weekly and monthly restore points can extend recovery beyond a compromised short rolling window. The exact tiers should follow your data value, storage budget, and detection capability.

Preserve Incident-Era Copies Outside Normal Rotation

Do not let normal pruning delete the versions, logs, backup catalogs, ransom notes, affected file samples, and configuration records needed to understand the event. Create an incident hold or export those artifacts to a protected location with documented access.

Incident evidence and operational backup retention solve different problems. The backup history provides recovery options; the incident hold supports scope analysis, insurance, legal review, and lessons learned. Coordinate deletion with the people responsible for those obligations. This article is operational guidance, not legal advice.

Retain Longer for Slow-Changing and Rarely Opened Files

Ransomware can modify a file long before anyone notices if that file is rarely opened. Archives, tax records, design assets, project masters, family photos, and historical documents often need longer version history than active working folders.

Find the Latest Clean Version Before Deleting Older Ones

The newest version before encryption is not automatically safe. Cyber recovery requires identifying a point that is free of indicators of compromise and can run without reconnecting the attacker. A recovery workflow should assume that the latest clean backup is unknown until restore points are scanned and validated.

Validate candidate versions in an isolated location. Check file readability, hashes where meaningful, application consistency, malware indicators, user permissions, and the ability to open representative old files. Keep older versions until at least one clean point has passed those tests.

Restore Testing Sets the Real Retention Threshold

A retention policy is only useful if the versions can be restored. Recovery planning guidance recommends scheduled restoration tests to prove that file recovery is actually possible.

Test at least three points: a recent version, one near the suspected compromise boundary, and one older weekly or monthly anchor. If only the newest point is tested, you do not know whether the long-term versions needed for ransomware recovery are complete, decryptable, and indexed correctly.

Make Sure Older Versions Survive the Attack Path

Long retention on a writable share does not provide long-term protection if the same compromised account can delete it. Older versions should be separated by permissions, storage account, administrative domain, network path, or offline rotation. Immutability prevents early deletion during a configured period, while offline copies remove the live attack path.

The ZimaSpace guide to protecting backup control planes and immutable recovery copies explains why retention settings, repositories, credentials, and backup consoles must be protected together.

Check Whether Storage Can Sustain the Retention Plan

Estimate capacity from the daily change rate, not only the size of the active files. A simple planning model is:

Required version capacity ≈ baseline copy + retained daily changes + weekly/monthly anchors + temporary restore and verification space.

Measure actual repository growth for several weeks. Include compression, deduplication, database churn, deleted-file retention, immutable lock periods, and the working space needed for merges or restore tests. If capacity is too small, reduce version frequency for low-value folders before shortening the entire clean-point window.

Shorten Retention Only After Specific Conditions Are Met

You can consider reducing dense daily history after all of the following are true:

• The earliest plausible compromise date has been established with reasonable confidence.
• At least one clean recovery point has been validated in isolation.
• Incident evidence has been preserved outside normal backup rotation.
• Critical systems and files have been restored and verified by their owners.
• Security, legal, insurance, and compliance stakeholders have cleared normal deletion.
• Weekly and monthly anchors still cover delayed discovery and seasonal data.

If any condition is unresolved, preserve the older points. Storage pressure is not a safe reason to delete the only versions that may predate the attack.

Act Quickly When Versions Are Stored by a Cloud Sync Service

Cloud file-history and recycle-bin windows may be shorter than your backup policy, and ransomware changes may synchronize into the cloud. Recovery guidance warns that older file versions and deleted items may disappear when a service retention limit expires.

From a clean device, freeze sync where appropriate, preserve the account, export critical versions, and document the earliest available clean point. Do not assume the cloud provider keeps unlimited history.

Frequently Asked Questions

When can you delete versions that may contain encrypted files?

Delete them only after the incident scope is understood, clean versions have been restored and tested, evidence has been preserved, and any legal or insurance hold has been cleared. Isolate suspicious versions rather than mixing them back into production.

Are more versions always safer?

No. More versions help only when they are complete, protected from deletion, indexed, decryptable, and regularly tested. Hundreds of versions controlled by the same compromised account can still fail together.

Should snapshots and independent backups use the same retention period?

Usually not. Local snapshots are useful for dense short-term rollback, while independent or immutable backups should cover longer ransomware and disaster windows. Use different retention tiers so one storage failure or account compromise does not erase every recovery point.