Caching in restic - large retrieve times on some cloud storages

[alexweiss]

If I understood it right, restic does cache alle data files (=packs) that contains a tree object. Or did I get something wrong?

Therefore I guess your list can be changed if you assume that you have a complete cache where all packs containing tree objects are included.

Under that assumption only packs with data blobs are inaccessible and I would change the table as follows:

Command	Affect of inaccessible data-only packs
backup	should fully work
check	should work when using --with-cache
find	should fully work
ls	should fully work
stats	should fully work

Moreover I’m not sure if the prune problem is mainly based on the fact, that prune always does include something like rebuild-index…

In particular: a huge caveat to restore is that it can’t give you a list of packs it needs because it must first crawl all the trees to locate all of the objects. It will fail on a specific pack. You can go restore that one pack, then it will fail on another pack, and so on.

Here I also disagree . I think it would be possible the produce that list. However, I agree that the current implementation does assume that everything can be accessed immediately and would probable fail like you describe it.

You must not transition any other objects or restic likely won’t even run against the repository.

Again, I disagree
The other objects must be either immediately accessible or in the cache. For snapshots and indices caching is already implemented. For config, keys and locks I’m trying to change the implementation, see my comment above (#9).