Sync specific folders only or exclude folders from the sync

[carukc]

Describe the feature you'd like to have.
volsync only appears to replicate the entire volume. There are situations where only certain folders within the volume need to be replicated. Perhaps there could be a feature that allows the the specific folders to be specified.

There are also situations where indifidual nodes may have private (temp) files that are not required by all nodes. This would prevent them from being syncronized or from interfering with another nodes files (in situations where everyhting is stored in a single volume.

For the rsync syncronizations the exclude parameter might be used to specifically exclude files, folders or file patterns. I'm not sure how this would be done for syncthing but if possible it would be enough to sync (or exclude) based on foldernames.

What is the value to the end user? (why is it a priority?)
This will acceperate syncronizations and ensure that space is not wased on files that do not need to be syncronized.

How will we know we have a good solution? (acceptance criteria)
destination file would match the contents of the intial volume less any files or folders specifically excluded or not specifically included.

Additional context
No additional context

[onedr0p]

It looks like this feature is supported with restic too. Maybe there could be a way to pass custom args to the CLI apps like restic or rclone in the ReplicationSource?

https://restic.readthedocs.io/en/stable/040_backup.html#excluding-files

[erenfro]

A big one as well. ext4 filesystems always make lost+found. This is owned by the user root, and the group root, and is intended to always be present. However, this causes a mover running as a less privileged user that is not root, to fail to backup because lost+found exists and is owned by root:root.

This is quite literally a huge show-stopper when it causes backups to outright fail due to this issue.

[tesshuflower]

A big one as well. ext4 filesystems always make lost+found. This is owned by the user root, and the group root, and is intended to always be present. However, this causes a mover running as a less privileged user that is not root, to fail to backup because lost+found exists and is owned by root:root.

This is quite literally a huge show-stopper when it causes backups to outright fail due to this issue.

@erenfro Could you create a separate issue (bug) for this? Please provide details of the mover you are using.

[erenfro]

@erenfro Could you create a separate issue (bug) for this? Please provide details of the mover you are using.

I mean, I'm using restic, it's finding lost+found owned as root:root, it has no permission. Not much more to add here, and this is basic understanding of ext4.

[tesshuflower]

@erenfro Could you create a separate issue (bug) for this? Please provide details of the mover you are using.

I mean, I'm using restic, it's finding lost+found owned as root:root, it has no permission. Not much more to add here, and this is basic understanding of ext4.

Created issue: #1033