Versioning is configured on Source Storage locations.
You can enable versioning on Source locations which have not been used or if all data in the archive from the source location has been deleted. Typically, you would configure this setting when creating a new location.
Versioning cannot be enabled or disabled if a Source location has had any data migrated out of it and is still under StorCycle management.
The ‘DELETE FILES’ feature can be used to delete migrated project data from a target. If 100% of migrated data has deleted from archive, Versioning can be enabled/disabled.
Enable Versioning
Versioning can be configured to make a copy of every file on the source during each archive or create versions if the file has changed. With either of these options, the feature can be configured to only keep a certain number of versions. If you only need to keep the most recent version of any file in the archive, you would set ‘versions to keep’ to 1. When deleting older versions of a file from the archive, StorCycle will execute a Version Delete job at UTC Midnight which cleans up older versions. Version control does not happen in real time as new versions are added.
After Versioning is enabled/disabled and data has migrated from the source, this setting cannot be toggled. All data must be deleted from from the archive which came from the Source location if you wish to turn versioning on or off. "Only When Files change' and ‘Versions to Keep’ can be updated at any time.
By default, all newly created Source Locations will have Versioning Enabled with ‘Only When Files Change’. This must be disabled before first use if versioning is not desired.
Version Only When Files Change
With the ‘Only When Files Change’ option, StorCycle will only make a versioned copy of the file if has changed since the last scan or archive.
StorCycle determines if a file has changed by calculating a checksum for each file and comparing it to the last calculated checksum.
StorCycle assumes that if a source contains an identical file name from a previous archive that it is a new version, not a new file - even if the entire contents of the file have changed.
With this option disabled, StorCycle will make a copy of every file from the source on each archive.
This option can be enabled/disabled at any time when Versioning is configured on a source.
Number of Versions to Keep on Archive
‘Versions to Keep’ is a way to maintain version control and ensure the archive does not grow exponentially.
When this field is set to 1, StorCycle will maintain only the latest version of a file. When set to 3, StorCycle will maintain the three most recent versions of a file.
StorCycle deletes older versions from the archive with a Version Delete job which runs at UTC Midnight.
‘Versions to Keep’ can be modified at any time when Versioning is configured. If this value is decreased on an existing location, StorCycle will remove any extra versions from archive during the next Version Delete job.
 |
When StorCycle makes a new version of a file, it will add a date/time string to the end of every file. For example, File1.txt will land on the target location as File1.txt-202303232023.
Upon restoration, the date/time string will be removed and the file will be restored to it's original location.
Note:
- The date / time string is the date when the migrate/store job which migrated the files was initiated
- If restoring multiple versions of the same, the date/time string will not be removed due to filename collisions
- In the Restore Wizard, when browsing for ‘latest versions’ of files, the date / time string will not be displayed
|
Before Archive and After Restore:
|
Versioned Files on Target Archive: A date and time string is added to the end of files which are versioned. Below are TestFile3 and TestFile4, each with two versions of the file migrated. |
 |
 |
|
When restoring data which came from a versioned source, you will have the option to:
|
|