Hi there!
I have download and start using Syncback free and i have a question.
I have a folder with all my photos and this is the folder witch i would like to have as backup.
What is the differences between (in types) Backup and Mirror?
I would like any changes i made in the source folder to happen and in the destination.
In both backup and mirron i found i can do that. For example if i delete a file or a folder in source i would like to delete from destination also.
This can be done and in backup and in mirror.
Is there a difference that i didn't understand? What is the best way to do that? With backup or with mirror?
Thanks for helping
Before posting, and to avoid disappointment, please read the following:
- This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
- If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.
- If you are entitled to technical support then please submit a support ticket. Please do not post the same question to the forum and also via a support ticket. Once again, 2BrightSparks does not provide technical support via this forum.
differences
-
cliffhanger
- Expert
- Posts: 606
- Joined: Tue May 31, 2011 5:59 pm
Re: differences
If you set a Backup to start deleting orphan files on your Destination, it becomes a Mirror (and is displayed in the main UI as such).
Similarly, if you set a Mirror to stop deleting orphan files on the Destination it becomes a Backup (and is displayed as such)
Note: make sure you have the latest version of SyncBackFree (v8.5.43.0) as I seem to remember there was a bug in this respect recently that sometimes affected the automatic re-labelling of the profile's Type. I may have remembered wrong about the bug, but it does no harm to have the latest official release installed anyway. Simply install 'over the top' (do not uninstall/re-install, or you may lose your profiles & settings)
Similarly, if you set a Mirror to stop deleting orphan files on the Destination it becomes a Backup (and is displayed as such)
Note: make sure you have the latest version of SyncBackFree (v8.5.43.0) as I seem to remember there was a bug in this respect recently that sometimes affected the automatic re-labelling of the profile's Type. I may have remembered wrong about the bug, but it does no harm to have the latest official release installed anyway. Simply install 'over the top' (do not uninstall/re-install, or you may lose your profiles & settings)
-
czam
- Newbie
- Posts: 2
- Joined: Sat Apr 14, 2018 10:00 pm
Re: differences
Thanks for the answer!
Something i notice (because is the first time i am using a backup software), is that if you rename a file in source, and you would like to make this change and in destination the only way that a backup software can do it is to delete the "old name" file from destination and copy again the "new name" file from source in destination, is that right? I mean there is no ather way of application to understand the action of renaming a file...
I just ask to see if i understand it right!!!
Thanks again
Something i notice (because is the first time i am using a backup software), is that if you rename a file in source, and you would like to make this change and in destination the only way that a backup software can do it is to delete the "old name" file from destination and copy again the "new name" file from source in destination, is that right? I mean there is no ather way of application to understand the action of renaming a file...
I just ask to see if i understand it right!!!
Thanks again
-
cliffhanger
- Expert
- Posts: 606
- Joined: Tue May 31, 2011 5:59 pm
Re: differences
You are correct that in the Free variant, only 'delete and re-copy' is supported.
In the Lite, SE & Pro variants, there are options on the (enhanced) Intelligent Sync variant of the Decisions-Files settings page as follows (from the Help file):
· Detect file renames on Left (note this may reduce performance): If this option is ticked then SyncBack will try to detect files that have been renamed/moved on the left. If a file has been renamed on the left then it will rename the right file to match it. Note that this option requires that file contents be compared, which means this option could be very slow when there are many files or very large files. It will only compare files when it needs to.
· Detect file renames on Right (note this may reduce performance): If this option is ticked then SyncBack will try to detect files that have been renamed/moved on the right. [rest of comments above also apply, but with L & R 'reversed' where appropriate]
Notes (mine)
This is not available in the Free variant because Free does not support Intelligent Sync (which creates/uses/maintains a state database of 'content' each side last run on both 'Left' & 'Right' to help make 'intelligent' deductions' next time what to do about changed/edited files & so on). Such a database can (must) also be leveraged to try & identify renamed/moved files (if there are any; if so, which?) by cross-checking 'what was where' last run (by files' properties such as LastModified & Size in the database) versus what is where now (current run's scan results). If a file seems to have maybe been renamed/moved, SB can look for possible candidates whose properties match but name or location have changed. If candidates are found, SB will hash the contents of the two candidates and if found to be exactly the same, will rename or move the appropriate file (as per the option/s you selected). If no match is found, or the hashing fails, the profile will fall back to 'delete & re-copy' for that file.
The enforced hashing can (as alluded to in the Help comments above) take a considerable time, possibly longer than a 'delete & recopy' operation, especially if the resource providing the hash value on one side is a non-standard resource such as an FTP server with slow hashing ability. For data-safety reasons (I assume), you can not skip the hashing crosscheck process if potential candidates are found.
'Rename' in this context means changes of one or more symbol in the name (X to Y and so on) but excluding case-variation (X to x and so on). The latter is handled by built-in options to detect case-changes present in all SB variants.
Note that the '(try to) detect rename' functions refers to files. Folders are not supported (presumably for technical reasons)
Any files which have been renamed/moved and their contents have also been edited will fail the hashing (because contents differ, obviously) and the profile will fall back to 'delete & re-copy' for that file.
In the Lite, SE & Pro variants, there are options on the (enhanced) Intelligent Sync variant of the Decisions-Files settings page as follows (from the Help file):
· Detect file renames on Left (note this may reduce performance): If this option is ticked then SyncBack will try to detect files that have been renamed/moved on the left. If a file has been renamed on the left then it will rename the right file to match it. Note that this option requires that file contents be compared, which means this option could be very slow when there are many files or very large files. It will only compare files when it needs to.
· Detect file renames on Right (note this may reduce performance): If this option is ticked then SyncBack will try to detect files that have been renamed/moved on the right. [rest of comments above also apply, but with L & R 'reversed' where appropriate]
Notes (mine)
This is not available in the Free variant because Free does not support Intelligent Sync (which creates/uses/maintains a state database of 'content' each side last run on both 'Left' & 'Right' to help make 'intelligent' deductions' next time what to do about changed/edited files & so on). Such a database can (must) also be leveraged to try & identify renamed/moved files (if there are any; if so, which?) by cross-checking 'what was where' last run (by files' properties such as LastModified & Size in the database) versus what is where now (current run's scan results). If a file seems to have maybe been renamed/moved, SB can look for possible candidates whose properties match but name or location have changed. If candidates are found, SB will hash the contents of the two candidates and if found to be exactly the same, will rename or move the appropriate file (as per the option/s you selected). If no match is found, or the hashing fails, the profile will fall back to 'delete & re-copy' for that file.
The enforced hashing can (as alluded to in the Help comments above) take a considerable time, possibly longer than a 'delete & recopy' operation, especially if the resource providing the hash value on one side is a non-standard resource such as an FTP server with slow hashing ability. For data-safety reasons (I assume), you can not skip the hashing crosscheck process if potential candidates are found.
'Rename' in this context means changes of one or more symbol in the name (X to Y and so on) but excluding case-variation (X to x and so on). The latter is handled by built-in options to detect case-changes present in all SB variants.
Note that the '(try to) detect rename' functions refers to files. Folders are not supported (presumably for technical reasons)
Any files which have been renamed/moved and their contents have also been edited will fail the hashing (because contents differ, obviously) and the profile will fall back to 'delete & re-copy' for that file.