Issue restoring dir containing a .duplicacy dir

Hi, I setup my backup to include the Duplicacy dir itself, that includes the prefs to my repos, so I have everything in one place.

I’m performing some test restore and noted that I’m not able to restore:

duplicacy restore -r 8 Duplicacy/Prefs/home/.duplicacy/scripts/*

Is there maybe a problem with Duplicacy restoring a dir containing a dir named .duplicacy?

Thank you!

.duplicacy folder is always excluded from the backup.

I see, is there a way I can force include this one?

As I inited my repo with -repository option in here I have my scripts and filters. I suppose this is true for all .duplicacy dirs actually.

I did the opposite. Important files (scripts and filters) are stored elsewhere and symlinked into actual .duplicacy folder. Backing up the whole .duplicacy folder would be very counterproductive as it mostly contains transient stuff.

The correct solution would be for Duplicacy to store its different types of data in the correct designated places on each OS, then this issue would not have existed.


I abolutely agree.

Can I ask how you organize these dirs?

I actually inited my repo with -repository flag in Duplicacy/Prefs/home/ so I have Duplicacy/Prefs/home/.duplicacy/ . The idea is to have others repo here as well, like Duplicacy/Prefs/other_repo/ etc.

Where do you place and how you organize the filters and scripts for each repo? Who knows if Duplicacy is able to handle soft links under Windows.

I only have one repository per machine (located in /Library/Duplicacy, backing up /Users); the cache subfolder is symlinked to /Library/Caches/Duplicacy, logs are symlinked to /Library/Logs/Duplicacy; I keep filters file in my documents folder and symlink it to /Library/Duplicacy/.Duplicacy/filters.

This is on macOS. On Windows the situation would be similar, with APPDATA instead of Library.

1 Like