For a description of versioning see the section What Is Versioning below. Versioning cannot be used (on the destination) when compressing to a single Zip file.
|
Some cloud storage services, e.g. OneDrive for Business, forcibly enable their own native file versioning. The storage space used by these file versions is counted in your quota (unlike services like Dropbox that do not count it). Because of this you may want to configure SyncBackPro to automatically purge excess versions, if possible. See the Automatically delete excess versions on destination/right option below. |
•Enable versioning on source/left/destination/right: If enabled, versions of files will be kept in that location. You can, for example, choose to only keep versions in the destination/right.
•Where versions files are stored...: This setting defines where the versions files are kept. They are either kept in a sub-folder of each folder, or kept within a folder in the source/destination. Once you choose a setting it is not recommended that you change it otherwise you will no longer have access to your versions.
•When to version...: This setting defines when SyncBackPro should make a version of a file. By default, versions of deleted and replaced files are kept. However, you may only want to keep versions of deleted files, or only keep versions of replaced files.
•Automatically delete excess versions on destination/right: Some cloud storage services, e.g. OneDrive for Business, forcibly enable their own native file versioning. The storage space used by these file versions is counted in your quota (unlike services like Dropbox that do not count it). Because of this you may want to configure SyncBackPro to automatically purge excess versions, if possible. To have SyncBackPro purge them, enable this option and then set the number of versions to keep below.
•Keep a maximum of x versions: The number of versions of a file to keep can be specified here. Note that obviously the more versions of files you keep the more disk space will be used. When the profile is next run it will automatically delete any excessive versions (starting with the oldest version). If you are using delta versions refer to the notes on how many versions are kept. If the value is set to zero then versions are never deleted based on the number of versions (except when using Backblaze B2 or the option Automatically delete excess versions above is enabled, when zero means keep no versions). If you are using Backblaze B2 then the default is 32. You can also set the life-cycle rules for files stored within a Backblaze B2 bucket.
•Keep versions for a maximum of x days: When a version of a file is made the date & time when the version was made is recorded. Note that this is not the last modification date & time of the file, nor is it the creation date & time of the file, it is the date & time when the version was made. Using this option you can specify how long a version should be kept. Once the version is older than the specified number of days it is automatically deleted when the profile is next run. If the value is set to zero then versions are never deleted based on their age. If you are using delta versions refer to the notes on how many versions are kept.
•Version Filter: When this button is clicked you can choose what types of files are versioned or not. The filter applies to versions on the source/left and destination/right. For example, entering *.exe and *\temp\* in the "Files NOT to version" field will not version any EXE files, or any files in sub-folders called \temp\.
Versioning is available in Expert Mode and is associated with the Copy/Delete settings. If you are using Backblaze B2 then you can only decide on the number of versions to keep. Use zero if you want your bucket life-cycle rules to manage the versioning.
A version of a file is automatically created when one the following actions occurs, and depending on the settings When to version...:
•A file is to be replaced (a copy of the file to be replaced is made before it is replaced)
•A file is to be deleted (a copy of the file to be deleted is made before it is deleted)
•A file is to be moved (a copy of the file to be moved is made before it is moved, which is essentially the same as being deleted)
Assuming versioning is enabled, here are some examples of how it works:
•You choose to delete a file. SyncBack makes a version of the file and then deletes the file. At a later time you may decide that you actually wanted to keep that file. If so you can run the profile and retrieve the version and so restore the file.
•You make some modifications to a document then make a backup of it. SyncBack will make a version of the backup file that is about to be replaced then make the backup. At a later time you may decide that you did not want those changes. If so you can run the profile and retrieve the version and so restore the file to before the changes were made.
Where are the version files kept?
Where the versions files are kept depends on the choice you made:
•In a hidden sub-folder of the folder that contains the original file: The versions of files are kept in a special hidden sub-folder called $SBV$. Each folder will have this special sub-folder if there any versions of files in that folder. SyncBack will automatically mark the folder as hidden when it creates it. You should not rename the folder or the files inside it otherwise the versions files cannot be used. You are free to delete the folder and the version files in it (you will obviously lose those versions) but it will not affect SyncBack as no database of those versions files is kept (it is always built at profile run time).
•In a hidden sub-folder of the base folder: The versions of files are kept in a special hidden folder called $SBV$ which is in the base folder. For example, if your destination directory is X:\My Backup\Documents\ then the versions folder will be X:\My Backup\Documents\$SBV$\. You should not rename the folder or the files inside it otherwise the versions files cannot be used. You are free to delete the folder and the version files in it (you will obviously lose those versions) but it will not affect SyncBack as no database of those versions files is kept (it is always built at profile run time).
When deciding where to keep the versions files, please consider the following:
•In a hidden sub-folder of the folder that contains the original file: If you have more than one profile that is using the same folder, and is using versioning, then the advantage of choosing this option is that all the profiles will have access to the same versions. Another advantage is that you can change the base folder and not lose the versions (as long as they are still sub-folders). The disadvantage of choosing this option is that it becomes impossible for SyncBack to know if a directory is truly empty or not. For example, if there are versions of files in the folder, but no actual files (e.g. they've all been deleted), then SyncBack does not know if the folder should be left empty of whether it shouldn't exist. This has implications for Intelligent Synchronization profiles as it may cause empty folders to be created on the opposite side when you don't want them.
•In a hidden sub-folder of the base folder: The advantage of this option is that it removes the "empty folder" issue. This is because the versions are not stored in a sub-folder of the actual folder, so the actual folder can be deleted without affecting the versions. A disadvantage of this option is that the versions folder is pinned to the source/destination folder, so if you change the source/destination folder then you lose the versions. Also, if more than one profile is using the same folders then they will not share the versions (unless the source/destination path is the same).
Changing where to store the versions will result in losing those versions. If you are using Backblaze B2 then you cannot choose where to store the versions (B2 manages it).
How to Restore Versions
Versions can be restored from the Differences window (or from the File Collision window). When a profile is run as a Restore, and versioning is used, the Differences window will automatically show skipped files. This allows you to restore old versions of files that no longer exist, and restore versions of files where there is no change.
If you wish to restore versions without using Restore (e.g. you are using an Intelligent Synchronization profile and so cannot run it in Restore mode) then select the profile in the main window, then select Run Attended (Ctrl-R) from the drop-down menu on the Run button. This will ensure the Differences window is shown. You then need to enable it to show skipped files (see the Filter tab at the top of the Differences window to see the options).
See the Differences help page for details on retrieving versions of files. If you are using Backblaze B2 then you must use the Backblaze B2 web interface to change and restore versions.
Frequently Asked Questions
Q: Can versioning be used with Fast Backups?
A: Yes, but it can greatly reduce the performance gains you get with Fast Backup. If your profile is configured to display the Differences window then it is recommended you switch off this option as displaying the Differences window forces SyncBack to scan every folder to see which versions are available for each file.
Q: Can versioning be used with Intelligent Synchronization profiles?
A: Yes.
Q: Can versioning be used with single zip files?
A: No.
Q: What if I switch from not using compression to compressing each file into its own zip file (or vice-versa)?
A: You will be warned that you can no longer use the existing versions. This is because if compression is used then the old versions are also stored compressed (and encrypted, if configured so). If no compression is used then the versions are not stored compressed.
Q: What if I switch off versioning? What happens to the versions files?
A: If a profile does not use any versioning (on the source/left or destination/right) then the old versions files will be treated like any other kind of file. If you were using versioning on both the source/left and destination/right, and then switched off versioning on one side, then the old versions on that side are ignored. For example, if you had versioning on the source/left and destination/right, and then switched off versioning in the source/left, then the old versions files in the source/left will be ignored, i.e. SyncBack will pretend those files do not exist.
Q: What if I change where versions are stored? What happens to the versions files?
A: You will lose access to the existing versions. You must manually delete the versions files, or configure your profile to ignore the $SBV$ folders.
Q: Are the versions stored compressed or encrypted?
A: Only if the files themselves are. When using delta versions, the delta files are compressed.
Q: Why aren’t the versions stored compressed?
A: Because it would slow down the profile considerably. When using delta versions, the delta files are compressed.
Q: What if I decrease the number of versions to keep, or how long they are kept?
A: When the profile is next run any excess versions will be automatically deleted.
Q: Which versions are deleted first?
A: Assuming you have set a maximum number of versions, then any excess versions are deleted (starting with the oldest version). If you have set a maximum age, then any versions over that age are deleted next. If you are using delta versioning, refer to the notes.
Q: Can I choose to store the versions in a directory I choose?
A: No.
Q: What if I change the source/left and/or destination/right path? Are the versions files automatically moved?
A: No (this is the same as using variables).
Q: What if I used variables in the source/left and/or destination/right path?
A: If versions are kept in a sub-folder of where the original file actually is, then using variables has no effect, except obviously the versions files will be scattered across various folders based on the variable values.
Q: If a folder is filtered out (or unselected) does SyncBack still manage the versions in that folder?
A: No, because the profile is specifically configured not to use that folder.
Q: If a file is filtered out (or unselected) does SyncBack still manage the versions in that folder?
A: Yes. When looking at file versions it ignores any filtering or selection rules. This makes sense because the original file may no longer exist anyway, for example.
Q: Does versioning affect performance?
A: Normally it has a very small effect on performance (unless you are using delta versioning). SyncBack has been developed to make versions as quickly as possible. However, there are cases where a version cannot be made quickly (i.e. the file to be replaced or deleted has to be copied, instead of being moved, in which case it can affect performance if the file is large).
|
Note that if you are using Fast Backups then enabling versioning on the destination can greatly reduce the performance gains you get with Fast Backup. |
Q: My log file has the error “The profile "profile name" was automatically disabled: reason why disabled.” What do I do?
A: What happened is that a version of the file was made (i.e. it was moved into the versions sub-folder, called $SBV$), but the copy failed. SyncBack then attempted to move the file back from the versions sub-folder to where it was originally. However, something went wrong and the file cannot be moved back. You must manually move the file back from the $SBV$ folder to its parent folder and rename it. Once done you should re-enable the profile via the main window (right-click on the profile and select Enable from the pop-up menu). This situation is extremely unlikely to happen.
All Content: 2BrightSparks Pte Ltd © 2003-2024