I just found his answer in similar topic:
So I tried to compare, indeed speed of restore operation is 2 times better than dump:
Now restic is thinking only two minutes instead of five before starting the recovery process and finishes recovery for 5-6 minutes
# time /tmp/restic -r /data/backup/ restore 70db3250 --verbose --target /tmp/some
repository 94affe3c opened successfully, password is correct
restoring <Snapshot 70db3250 of [/dev/drbd/by-res/one-vm-5525-disk-0/0] at 2020-05-24 13:46:03.840012085 +0000 UTC by root@m15c45> to /tmp/some
real 6m44.219s
user 13m38.107s
sys 0m47.877s
# time /tmp/restic -r /data/backup --verbose dump 46a169a5 /dev/drbd/by-res/one-vm-7994-disk-2/0 | dd of=/dev/null bs=64k status=progress
21457734025 bytes (21 GB) copied, 779.736037 s, 27.5 MB/s
321266+13230 records in
321266+13230 records out
21478596608 bytes (21 GB) copied, 780.566 s, 27.5 MB/s
real 13m0.569s
user 14m6.415s
sys 0m56.296s
But my sample is only 21G long and still not all the resources of node utilized on both first step (before actualy copying) and after it, what’s happening on these stages? Unfortunately option --verbose is not working for me.
Is there any chance to make dump operation faster in the foreseeable future?
Regards