2 Drive synching - best practise

[ipconfig]

Hello All,

I have on my win 10 PC a SSD Drive called C:\ and a 2 TB HD called D:\
On C:\ and on D:\ i have some directories to become backed up.
I would like to go for versioning in case of deletion of a file from the sources.
(I use RealTimeSync for watching...)

SO:
which setup do you suggest?

i had the following ideas:
2 RTS processes, one on C and one on D -> i have two different versioning drives, but also 2 processes of RTS running.

1 RTS process with 2 Folder Pairs: C:\ and D:\ both mapping to Z:\Backup
I make use of the filter section and put every folder taht should be synced in the include section:
\Users\ipconfig\Documents\*
\Users\ipconfig\Desktop\*
\Users\ipconfig\Pictures\*
\Users\ipconfig\AppData\Local\Microsoft\Outlook\*
\Temp\*
\Tools\*
\MP3\*
\Download\*

--> I recognized that I am not allowed to use drive letters in the filter section?
--> having 2 folder Pairs versioning may become a problem, since i could have a folder ABC on D:\Download while also on C:\Users\ipconfig\Documents.
Problem is that inside Z:\Versioning (my deletion folder for versioning) i will have a folder ABC having files that came original from C:\..\ABC AND from D:\...\ABC.

what is a best practise in your oppinion for the scenario described above?

BR
Ingo

[ipconfig]

PS: Is it possible to let RTS call 2 ffs_batch files? RTS is able to look in folders from c and in folders from d. So idea could be that if it find something it will call FFS with 2 different ffs_batch files?

[Plerry]

As syncing both C:\ and D:\ to Z:\Backup creates an overlap of your two syncs on Z:\Backup,
it is probably simpler/smarter to sync C:\ to e.g. Z:\BackupC and D:\ to Z:\BackupD.
Similarly it is probably also simpler/smarter to use non-overlapping versioning locations,
e.g. Z:\VersionsC and Z:\VersionsD. This will prevent the potential problem you seem to anticipate.

All (include and exclude) filter definitions are relative to the root of your left and right base locations and are therefore never allowed to contain drive-letters. As per your example, with C:\ and Z:\Backup being the left-, resp. right base location of one of your FFS syncs, \MP3\* would refer to C:\MP3\* and to Z:\Backup\MP3\*, but e.g. not to C:\Users\ipconfig\MP3\*

Regarding the use of RTS:
Monitoring your entire C:-drive and/or D:-drive will (depending on your settings) likely either continuously or never trigger an FFS sync. If you just want to sync the above 8 folders upon changes in their content, you might consider to simply define 8 RTS tasks, each monitoring the respective folder, and define 8 separate FFS syncs; one for each of those 8 folders. Or you might have RTS monitor C:\Users\ipconfig\ and define just 5 FFS syncs, combining the first 4 into 1.

You likely want to keep the FFS sync(s) called by RTS as small/compact as possible (hence my above suggestion).
It does therefore not sound to be a good idea to have RTS call an ffs_batch-file unrelated to changes it has detected.
I don't know if RTS can directly call two ffs_batch files. However, RTS could call a *.bat- or *.cmd-file that would invoke two FFS syncs sequentially. But, if you really want to invoke two syncs, it seems to make much more sense to combine those two sync jobs into one, using two left-right base location pairs and possibly local filter definitions and sync-settings (e.g. the versioning location), rather than global settings.

BTW: are you sure you want to monitor and sync your Temp-folder?

[ipconfig]

Thank you for your nice answer!

I think I will go for 2 RTS processes. One is watching the mentioned C folders and the other the D folders.
Of course you are right that my RTS is not watching whole C or D Drive. It is only watching those folders that are part of the syncing.

Regarding my temp folder: it is not a windows temp folder. It is something that i use like a sandbox. ;) e.g. the sync cleanup proggi i want to develop will find its testscenario there...

Again. Thank you for your point of view.
I guess that the root always needs to be a drive? Computername is not allowed as a root?

[Plerry]

... I guess that the root always needs to be a drive? Computername is not allowed as a root?

Drive-letters are not required; a network-path name is also quite OK for your left- and/or right-base-location.
The base location also does not need to be at the root of a drive or network location, but is also allowed to be an arbitrarily deep (sub)folder in the tree of that drive or network location.
E.g. \\[IP-address]\[share-name] or
\\[computer_or_resource-name]\[folder-name]\[subfolder-name]
In the latter case, the [computer_or_resource-name] obviously needs to be able to be properly resolved via NetBios, a DNS-server or the local etc\hosts-file.
If required, FFS will ask you for a user/password for connecting to the network resource, just like Windows does when mapping a network location to a drive-letter.