3 folders in 2 diff. destin with realtimesync

[siutsch]

Hi,

first of all: excuse me for my bad english (i love google translator!)


I found your fantastic tool and tried to back up 3 folders in 2 different
destinations.

These 3 folders containing my pictures, my documents and software / drivers.

I back up these folders once on a lokal USB disk and once on a network share
of a 2nd computer,
if the network share is available (not always the case).

So I have a double backup of my important files.

The first thing I have tried all directly related to the FreeFileSync gui.

Since I want to backup 3 different folders on each with 2 goals, I have
invested a total of 6 different jobs creates batch files of each of them,
total thus 6 different batch files.

For a manual backup, I can then individually select them, depending on the
what needs to be synchronized.


After that I then found RealTimeSync and of course trying to automate the
backup.

I had not understood just how it is able to monitor more than just one job.
Though you can specify multiple folders, but only to one batch file.

Then I saw that you can create even more jobs in the FreeFileSync gui and then
can save that in one batch file.

But if you import this one batch file with RealTimeSync, all the folders will
be scanned by a change in only one of them.

I have very many files in the folders to be backed up, my pictures folder
contains over 90000 files (70 GB), the software and drivers folder contains
over 120000 files (23 GB)!

The review of the folders containing the backup to the USB disk is still quite
fast, but even here it is obviously annoying if, in a change in one of the
folders are always comparing them all.

The review of the network share takes much longer, also, the network share is
not always available, it is indeed the second additional backup that must not
always be performed immediately.

I initially solved this problem so that I have created one .ffs_real file (6)
for each backup so I have run a total of 6 tasks of RealTimeSync.

I hope my explanation has the problem so far described.

Is there perhaps a different solution or would that be worth if an adjustment
of the RealTimeSync program?

RealTimeSync would need to monitor multiple folders, but with a change in only
one of these folders, only the matching targets should be reviewed and
synchronized.
Then it would be sufficient if the program only to start once.

Or maybe I have not yet really understood the handling of RealTimeSync?


Siutsch.

[Zenju]

> Is there perhaps a different solution or would that be worth if an
adjustment of the RealTimeSync program?
I think your solution is correct. You have six jobs that are independent from
each other. Consequently you have setup six sessions of RealTimeSync, each
monitoring an individual (set of) folder pair and sync'ing only one pair. This
is exactly the right granularity needed based on your requirements.
The only disadvantage is a non-functional one: Six icons of RealTimeSync in
the Systray.

The questions is whether RealTimeSync should be expanded to avoid multiple
Systray icons. I think the costs clearly outweight the benefits in this case:
RealtimeSync currently is very easy to comprehend and to setup. Consequently
any addition to its functionality that affects/complicates GUI and
configuration handling should provide a significant advantage.

Regards, Zenju

[siutsch]

Hello Zenju,

thankz for the really fast answer.

To have more than one systray icon is not a problem, I use Windows 7 and the
icons are not usually visible. :)

I only thought, that x instances of rts uses much more memory than only one.

But if that is not so much I can live with the current solution, the main
thing is it works.

Perhaps the program in the future extended to other things, I'm very excited.

Siutsch.

[Zenju]

>that x instances of rts uses much more memory than only one.
There is no significant overhead that I could optimize away internally even if
I handled all 6 sync-configs within a single session of RealtimeSync. Still I
would need to register 6 sets of folders for monitoring changes. So besides a
few MB of main memory consumed by the executable, there is no performance or
memory drawback at all to your approach.

>I use Windows 7
Then your usecase is fully covered I'd say ;)