Multiple backupsets from a common root/repository - or multiple prefs - or multiple filters :)

Nelvin     Dec 24 8:49AM 2017 CLI

So far, if I understand everything correctly, we can only have one backup set based on the folder where the backup repository is initialized for? We can either just init it and get the prefs stored in the .duplicati folder at the root of the repository or use the -pref-dir option to save the preferences/filters etc. for the backup to another location than the root of the repository. But then we get a .duplicati file pointing to the folder defined using -pref-dir. That's probably meant to be able to have all the backup prefs located close to each other which I quite like.

But I think we're still limited to a single backup configuration per repository root folder, or did I miss something? We can't just add a -pref-dir to all other commands and be able to have multiple backups/filterlists for the same root folder?

In my current situation f.i. I do have most of my relevant data in a common/projects folder - but within this I do have active folders I change multiple times a day and others that may be stable for weeks. Another one are the Outlook.pst files, even after a simple mailcheck it's often usually around 100MB that have to be uploaded to the storage so a backup ever hour is a bit demanding compared with the rest of the changed files that might just be a few kb in a .txt file.

Please tell me if I missed something, or, if not, have you thought about adding the option to provide the -pref-dir for all commands?

Another option would be to just add a -filter option to the backup command, so instead of alway using the same filter file it would be possible to use different filters to define the files included in the backup (which, I guess, basically is the same as multiple backup sets, just rooted in a common repository)?


gchen    Dec 24 12:56PM 2017

I think the -filter option is the best. Can you create a github issue for this feature?


Nelvin    Dec 25 6:48PM 2017

In general, it's no problem to modify the filters before any given execution of a backup command in a repository?

This would mean, given I experiment mostly with the CLI version anyway, I could already fake this by creating a few filters files, like f.i. filters_hour, filters_day, filtersmedia ... and, before starting a backup I could just copy the chosen filters* file to .duplicacy/filters and then start the backup? Am I missing something? Any potential problems? Done in a batch file this would be as simple as the regular backup using CLI - so nothing additional to think about after the initial setup.


gchen    Dec 25 9:33PM 2017

You can do that but that is too error prone. If there is an error in copying over the filters file then all of sudden you're backing up a completely different set of files. A -filters option for the backup command would be much safer.


Nelvin    Dec 26 6:13AM 2017

Of course you're right, any potential source of errors should be removed if possible. It's just me still toying around with Duplicacy to see what's possible already and how I'll use it eventually. Also I don't expect any feature request to be implemented at all and even less in a short timeframe - so right now there's either this workaround or not use Duplicacy this way at all.

I'll still add an feature request / issue on github.