Retention and versions
Each successful backup creates another recoverable state. Retention controls how much history remains without allowing old copies to consume the entire destination.
The newest copy answers “what do I have now?” Earlier versions answer different questions: “What did this look like yesterday?”, “What was in the folder before I reorganized it?”, and “Can I recover a file that disappeared last week?” A backup with only the newest state cannot answer those questions.
What counts as a version​
A version is the previous copy of one file, set aside at the moment a run replaces it with a newer one. It is stored next to the current copy under a date-stamped name. The current copy is never a version, so the newest state of every file always stays.
This is a per-file history, not a per-run history. A run that finds nothing changed creates no version at all; a run that copies one changed file creates exactly one version. A destination can therefore hold many restore points for a document you edit every day and none at all for a folder you have not touched since the first backup.
Deleted source files remain recoverable while a stored version still holds them. Retention is not immediate synchronization: deleting a file in the source does not remove the copies that are already stored. Use the restore timeline to select the state you need.
Managed thinning​
The standard policy keeps dense history while changes are fresh and thins it as they age:
- Every version from the most recent hour
- One version per hour for the last 24 hours
- One version per day for the last month
- One version per week for older months
Within each window the newest version is the one that is kept, and the comparison always happens among the versions of the same file. Whole backup runs are never removed as a unit.
The stages follow one another—hour, day, week—and the weekly stage has no end: it continues for as long as the history exists. There is no monthly stage, and nothing is removed because of its age alone. History therefore keeps growing, just far more slowly than the number of runs suggests.
Thinning is a property of the individual backup, not of the program: Manage storage automatically (thin out older versions) is on by default and can be switched off for a single backup. With the option off, every version is kept until you remove it yourself. Thinning takes place as part of a run of that backup and then covers its whole destination, not only the files this run copied.
When the destination runs low on space, the oldest stored versions are removed as well, until a small reserve on the destination drive is available again. The newest stored version of every protected file is kept even then.
This graduated policy preserves detail where it is most useful. Recent mistakes are often noticed quickly, so recent versions remain dense. Older recovery points are spaced farther apart, providing long-term history without treating every hour from months ago as equally valuable.
Why history often looks unthinned​
Thinning only has work to do where several versions of the same file fall into the same window. Seeing no effect for weeks is therefore normal and not a sign of a problem:
- A young backup. Versions from the most recent hour are all kept, and the hourly stage merges only versions of the same file from the same hour.
- About one change per day. With a daily rhythm and a file that changes roughly once a day, each day already holds a single version, so the daily stage has nothing to merge. The first visible reduction usually happens after about a month, when a week of daily versions becomes one weekly version.
- Few changes overall. Files that do not change produce no versions at all, so there is nothing to thin.
- No run since the versions aged. Thinning happens during a run of that backup. A backup that has not run is not touched.
To watch the mechanism at work without waiting, edit one file several times within an hour and back it up after each change, then run the backup again more than an hour later. Of that hour, only the newest version of the file remains.
Optional limits​
In addition to the stages, a backup can carry two hard limits: Delete versions older than (an age in days) and Maximum versions per file. Both are optional, so you can keep all versions, limit retention by age, or let available destination space set the practical boundary. Both limits apply on top of the stages and only while automatic management is on; the current copy of every file is outside their reach. More history improves recovery choices but requires more capacity.
Keep all is appropriate only when destination growth is monitored and storage is intentionally expanded. A time limit is predictable but can remove the only old copy of a rarely noticed deletion. Space-managed retention adapts to actual usage but still requires enough room for current data.
How to tell that thinning happened​
A run that removed versions records a cleanup entry for that backup in the activity list on the start page, and the program log notes how many versions were removed and how much space that returned. In the restore timeline, individual restore points disappear as they are merged, while the newest state of every file remains available.
Example​
Suppose Budget.xlsx is edited at 09:00, 10:00, and 15:00. The backup initially retains all three versions. As they age, the policy thins the dense history while keeping representative hourly, daily, and weekly points. Restoring from noon shows the 10:00 version; restoring from the previous day shows the version that existed then.
Retention operates on stored history, not on the live source. Removing an old restore point does not delete the current source file.
Synchronization pairs​
Only a backup keeps a version history. In Mirror and Two-way pairs, replaced and removed files normally go to the Windows Recycle Bin. Where that is not possible—on a network share, for example—the previous copy stays behind under a date-stamped name instead of being lost. Such leftovers are treated like a recycle bin rather than like history: a few versions per file and roughly a month, then they are cleaned up. Keep a Backup pair when the history itself matters.
The first backup size is only the baseline. Frequently edited media projects or databases can produce much more history than mostly static documents. Review destination capacity after the first week.