My english is basic, this is the original version (italiano) on Skydrive:
http://sdrv.ms/1bIhZ1X
I posted this content on both forum, SyncBack and Syncovery.
I recently looked at a number of mirroring programs with the goal to adopt one as my usual backup procedure.
Some programs are very simple, some even free of charge. These may be sufficient for sporadic copies, or for backing up static system.
A more advanced user who intends to use the mirroring as habitual backup procedure should instead use programs that allow a fine adjustment of the copy procedures, to minimize the transfer of data over time.
Some mirroring programs offer a large number of options, and conversely are complex and require a considerable learning effort. The programs more flexible (and complex) that I tested are SincBack (non free versions) and Syncovery, below I describe some functional differences.
It often happens to rename or move files and directories in the source, without changing the content of the files themselves, in which case the mirroring program should be able to replicate the shift in the destination, avoiding re-copy files whose content has not changed.
SyncBack allows this result only through the procedure "Intelligent Synchronizationhronization", expressly provided for two-way synchronization operations, and that requires the use of a database of source and destination file with all the complications connected.
Syncovery instead allows you to move and rename the files in the destination also in one-way mirroring operations, without using a dedicated database but comparing on the fly source and destination file lists.
The profiles window of SyncBack is more clean and tidy, the most visible effect is that in the same size you can view more profiles than Syncovery. For those who make heavy use of the program the benefit is substantial, you get more visual control of the whole of your backup procedures.
Another typical problem of the backup programs is management of database files, usually bulky; for example, every time you open for reading a file Access or derivatives (.Mdb, .Ocp, ...) the DBMS writes service information and updates the timestamp, without changing the size. In these cases it would be appropriate to avoid copy the file during synchronization, given that the user content in fact has not changed.
None of the two programs still offers a satisfactory solution. Both allow you to not use the timestamp as comparison criterion for a profile, but this is a solution "brute force" that can bring other problems. A satisfactory solution would be that the user could specify the types of files for which do not use the timestamp for comparison.
Regards
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.
Mirroring programs, my remarks
-
- 2BrightSparks Staff
- Posts: 131
- Joined: Thu Jan 04, 2007 10:02 am
Re: Mirroring programs, my remarks
Hi
You could use a separate 'targetted' profile for the files where you do not want copying triggered by date/time differences, by using filters (for file-types, maybe), folder/file selection and judicious Source specification so that only such files are processed. You could use the same concept in reverse to ensure that a profile that does trigger on date/time differences does not process such files.
You could use a separate 'targetted' profile for the files where you do not want copying triggered by date/time differences, by using filters (for file-types, maybe), folder/file selection and judicious Source specification so that only such files are processed. You could use the same concept in reverse to ensure that a profile that does trigger on date/time differences does not process such files.