See https://forum.restic.net/t/compression-support-has-landed-in-master/4997/40

In order to solve this, IMO we have to add #3290 and save processed packs in preliminary index files during prune.

This is how it is implemented in rustic, see e.g.
https://github.com/rustic-rs/rustic/blob/main/src/commands/prune.rs

If you want to try out how prune works with these two features, feel free to try out rustic. But note that rustic prune does a two-phase prune, i.e. instead of removing packs it first marks them for removal and only removes them on a following prune run if they have been marked long enough.

Just as a hint. Currently I'm pruning / converting a 9 TB repo to new compression format. Since the HDD is not big enough to prune it all in one I use this simple code

#!/bin/bash

for i in {1..10}
do
./restic prune --repack-uncompressed --compression max --no-cache --max-repack-size 1099511627776
# 1TB 1099511627776
done

You can lower the repack size and increase the loop counter. So you won't lose prune results in case of interruption. Of course it is not exactly what you suggtest but still for me it suffices.

I've run into this issue recently as I compress and repack a 12TB repo. Because of the lack of prune resume, I've been using --max-repack-size 750gb and just manually running it after it finishes. For some reason the VPS I'm using keeps going down, so twice now I've lost hundreds of GBs of uploads that needed to be reuploaded, which unfortunately maxes out at 5MBps upload for me. The solution is obviously lower my --max-repack-size but it was a painful gotcha.

@Zaxim The main "problem" of restic not having a resumable prune is that the new index is only stored after all pack files are written. It you rerun an aborted prune, all already-written packfiles are therefore treated as additional and unused and therefore removed again.

So, if your prune run aborts and you won't lose the already-created packfiles, you must manually run rebuild-index to add the already-created packfiles to the index. Then the next prune run recognizes them and thanks to #3290 (IIRC) it will choose to keep the pack files generated by the last prune run and remove the old and already-repacked pack files.

Sweet! That's good to know that I can just run rebuild-index if it happens again.