Create a known pitfalls topic?

Site Feedback
#1

Perhaps we should create a topic called “Known pitfalls and confusions”? Things to include there would obviously be the filtering logic in general and this symbolic links issue in particular. Another thing might be the terminology issue around snapshots etc.

One could also recomment to new users to start installing the web-ui and switch to CLI if so desired rather than the other way around (cause this wont work without extra effort).

Another thing I can think of would be fixed vs variable chunksize (pointing out that it might be worth working with two repositories, one for databases etc and the other for the rest.

I’m sure there’s more…

Edit: to think twice before using -bit-identical might be another candidate, though it’s probably not relevant for the average user.

2 Likes
Include patterns for symbolic links
#2

I agree, a “Things to consider before…” topic might be useful. Or ‘Known issues’ but that sounds like there’s a flaw with Duplicacy, which wouldn’t be accurate at all.

There’s two issues I mentioned in that -bit-identical thread btw - the other one is that, in order to create a copy-compatible storage, users should use add -copy -encrypt and not another -init. IMO, that’s a big problem since it’s lots of effort to fix.

Also, I’m willing to bet there’s quite a few users that have inadvertently created their new copy-compatible storage without encryption, thinking that it inherits the -encrypt option from the copied storage. (Pretty sure one user here mentioned that already.)

1 Like
#3

Isn’t that something to add to the init documentation? Like I recently added a note there about avoiding duplicate IDs… Perhaps you could add something like: If you intend to store the same backups in different storages, use init only for the first storage and add for the other storages. Otherwise: .?

Isn’t this a design flaw? Why shouldn’t the new storage automatically inherit the encryption?