Not sure what benefit cache would produce for that scenario as the thought process behind the cache was really a Plex/Emby use case for keeping media files locally for a period of time.
That being said, if repeat restores of the same things happened, the cache would be beneficial for that as it wouldn’t have to redownload things.
If the use case is more restore one time and not use again, it would be a waste of local disk space.
You can use cache just like any other remote or mount, but the limitations are only one process can use the cache at the same time. If you are backing up to the remote, you wouldn’t be able to restore from it at the same time so I think you’d have to use a mount unless you limited yourself to 1 operation.
The “best” parameters really depend on what your particular setup and how you’d like it to work. If you have a lot of local disk space, you can use a bigger cache area. If you have less, you’d turn that down. What cloud provider are you using as that would impact how it would work as well.
The point in using cache remotes to restore restic data is to take advantage of deduplication.
Assuming I am restoring 2 host I connect to the cache remotes to restore so I don’t redownload deduplication data from the repository again while the second host is restoring data.
I think using serve restic is good… But was wondering if cache could save some time and bandwidth to restore the second host a bit faster