Hello everyone,
I’m facing some issues with the restore times when using restic dump. Currently, I’m trying to restore an .img file directly to the disk (/dev/sda) by utilizing restic dump and piping the standard output to /dev/sda. However, I’ve noticed that restic is quite slow with this command, which makes it challenging to use for disaster recovery scenarios involving large disks.
I was wondering if there are any methods to improve the speed of this process (consider it’s restoring a single file). Additionally, I’m curious if it’s possible to utilize “restic restore” and redirect its output to std-out, since that would be much faster
Thank you
Restic version: 0.15.2
“Dump” is inherently slower because chunks need to be restored in a specific order - and duplicate chunks must be restored in order as well. “Restore” takes one chunk, sees it’s in, say, 50 files, and restores it 50 times all at once, then moves on to the next chunk - which may append to the other files that had the previous chunk. So dump, by it’s nature, has to be serial rather than parallel. I mean, so are tarballs and disk images themselves. If you pipe “Restore” to stdout… you get a garbled mess. Why? It’ll throw that one chunk 50 times in the beginning, for instance - then more random chunks, because it’s expecting a random-write file system, not a serial file. So, optimally, you’d want the chunks in order, right?
And that’s exactly what “Dump” does. 
I understand.
Well, this is letdown since the dump command is roughly 20 times slower than restore in my use case.
It might be better attaching an additional volume to the vm that needs to be restored, using it as --target for the “restore” command, then using “cat” or “dd” to output the restored img to the disk.
Yeah, I was storing whole-disk images in Restic for awhile myself - but yes, it took forever to dump them back out. I generally just pipe the whole thing to Zstandard - “sudo sh -c ‘cat /dev/rdiskX | zstdmt -1v > /path/to/disk-image.img.zst’” - and save it that way now. Much faster and is usually compressed enough for my purposes.