Mirroring programs, my remarks

[silverni]

My english is basic, this is the original version (italiano) on Skydrive:
http://sdrv.ms/1auyr9z
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 "Smart Synchronization", 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

[p1ea]

Good post, silverni, you make excellent points. And btw, your english is FAR beyond basic, my friend. I would venture to say it's better than most US-born high school graduates.