I was wondering, is it possible for restic copy to copy data from one repository to another without having to recompress the data? I wonder if my snapshot copies between NVMe disks would go faster if it wasn’t for the recompression?
If you copy between NVMe’s, maybe you can use rsync instead? This won’t recompress.
I’d assume (but I don’t know) that restic has to always decompress and re-compress the data while moving from one repo to another. The target repo might even have (but should not, as it reduces storage efficiency, as I understood) a different pack size, and might possibly even have compression disabled, I assume.
Ah the problem is, I can’t rsync/rclone specific snapshots.
So the main repository is stored on SharePoint. And the performance is… less than stellar. But we get 25TB for every “Team” where I work. So that’s nice. But I think of it more as nearline rather than hot storage, due to the speed.
I often back machines up using a 2TB NVMe stick, then later copy to the cloud. I actually like that it recompresses for this, because I’ll back up at “auto” speeds for the fast chip, then use “max” compression for SharePoint.
However when it comes to restoring, say, a 500GB snapshot - if I have advance notice, I like to copy the snapshot back down to my NVMe chip so that when the user brings their own SSD/HDD I can restore it much quicker. It works as-is, but I assume it would be a little faster if it didn’t have to decompress and recompress everything. Maybe not enough to notice, considering how fast auto compression is (which is what I use for copying a snapshot back down), but I was wondering nevertheless.
It would probably be a bit faster. Although it’s hard to say by how much.
I guess we could optimize the internal
repository.Repack method in that regard. However, we don’t store the compression level of a blob in the repository. Thus, such an optimization would prevent changing the compression level of a blob.
Ah honestly, if I had to choose, I like being able to change the compression more than I’d like not having to recompress. Wasn’t sure how feasible it would be to implement, but that answers it for me. Thanks!