Hey @MichaelEischer, thanks for picking the PR!

Here's my line of thought when I investigated this issue.
I figured, that because of everything in the repository - is just files then there should be one function, the sole responsibility of which is - save any file to the backend. Also, searching for the StorageClass argument, i decided, that Save function is what i'm looking for. And looking through the call queue - it appeared the last stand of Restic before handling the operation to the Minio dependency.
Knowing that - I looked to the arguments of the function and understood that h Handle could help me to determine what is being saved right now. And thanks to all of you, it had a parameter Type, which corresponds to the enum with all object types. So I thought that is safe to assume, that I can filter for the PackFile.

Well, after your question, I've done some more digging and went up on call stack and found that it used in all Flush functions - for data and for indexes. And handlers with datatype are passed down to it.

Also, as a proof of work - here's bunch of screenshots of S3 when I tried this code. (saving just one small text file)
Config (and keys) are stored in Standard because when I init-ed the repo I didn't use StorageClass option (not sure even will it have any effect thou). And you can mention the date of files created.
The Snapshots, Index and Data are created few minutes later, and you can see that they have different Storage Classes

Screenshots

And in opposite, here's my first attempts of saving to the Glacier, when I didn't know about issue.

Screenshots of my tries and errors

Hope this helps.

A pack file can contain either tree or data blobs. To allow a second host without a prefilled cache to use the repository for backups, the second host must also be able to retrieve the tree blobs. However, both tree and data blobs are stored in pack files. To see what I mean just try the following (while using your PR):

restic -o s3.storage-class=GLACIER backup some-small-folder
restic -o s3.storage-class=GLACIER backup --no-cache some-small-folder

The second backup run will use the snapshot from the first backup run as its parent snapshot. And it will try to download the corresponding tree blobs, which will fail.

For that to work a pack file must also not be archived if h.IsMetadata in h backend.Handle is true.

I'm not entirely sure how you intend the restore procedure to work. Do I have to retrieve the whole backup archive?

Thanks for the comments.
You are right @MichaelEischer, I didn't know this about packfiles. I tried to add to the test backup made with my first build and it couldn't get snapshot metadata.
After accepting your snippets I rechecked updating the backup as well as forget and prune and everything worked as expected.

As of how I'm expecting to use this backups - to make it the "1" from "3-2-1" backup strategy. I want a cheap storage for valuable media only in case of failures of local copies and raid setup. So yeah, if I will restore it, it will be a full restore.