Version history and retention
A backup overwrites the stored copy of a file that changed. Version history keeps the copies it would otherwise overwrite, so the version from before the bad edit, the ransomware, or the wrong save is still there.
Turning it on #
On any backup job's Options step: Keep previous versions, then how many of each file (3, 5, 10 or a number), and optionally Also keep versions for a minimum age so a file overwritten ten times in an hour still has yesterday's copy. The same setting exists on a cloud drive. Off by default because it costs storage; on by default in the nightly template's spirit — turn it on for anything that matters.
Where versions are kept #
| Destination | Mechanism |
|---|---|
| Amazon S3, Wasabi, Backblaze B2 with bucket versioning on | Native object versioning: the bucket keeps every overwritten object itself; Caryvane prunes past the limit. Caryvane will try to enable versioning when the key allows. |
| S3-compatibles without versioning (R2, Spaces), Azure Blob, SFTP, local folder | A .versions sidecar folder beside the data, filled by a server-side copy — no download. |
| FTP, SMB, Dropbox, OneDrive, SharePoint, Google Drive, Egnyte | The same sidecar, filled by download and re-upload through the agent or worker. |
The decision is made per destination by the version engine; jobs and drives never construct a version path themselves, so "keep the last five" means one thing everywhere.
Getting a version back #
- On a Windows cloud drive: right-click the file → Version history… → pick a version → restore it in place or open it beside the current file. Restoring makes the current file the newest previous version; nothing is lost.
- From a backup: a Restore job pointed at the version's path in the sidecar (versions are named with their timestamp), or, on a natively versioned bucket, any S3 tool that lists object versions.
Things to know #
- A version is a whole copy of the file; ten versions of a 2 GB file are 20 GB. Set the count with that in mind, and use the minimum-age option rather than a large count when the aim is "yesterday's copy".
- Wasabi bills deleted objects for 90 days, so pruning is not free within that window.
- Connector backups (Microsoft 365, Google Workspace) and continuous jobs version like any other job; App-consistent captures version each night's image, which is large — prefer a small count there.
- The conflict policy SkipIfUnchanged (API) disables version capture for that job.