Perhaps you are right.
On the other hand I am sure that a chunk (compressed or not compressed) has a checksum (i.e. the checksum of the raw data). When restic encounters a zip file and decides not to compress then it could check if the checksums of the zip file’s chunks are already existing. If a chunk is alread existing then it doesn’t matter if the existing chunk was compressed or not. The checksum is the criteria.
To update from thses points,
How much has changed ?
I don’t know but we must check too,how fast is the restore, and how fast is the prune and check, because is part of every backup. and restic is very slow at least on my machines…
For the record, most of the shortcomings mentioned here have been addressed: the code for the archiver and restic prune was rewritten from scratch and we’ve just merged compression support to master, see