The new option --dry-run is very interesting. The main use I will give to this option is to previously know the size of what I am restoring. I do not want to fill up my disk with a restore that does not fit in the free space I have. So the idea is to first make the restore with --dry-run option and if the size is less than free disk space, then launch it.
The first results I obtained seems not very promising in terms of speed, until I realize a little detail I would like to share. First, I will show the results:
- I downloaded the latest linux kernel sources and did a snapshot on a local repository:
./restic_v0.16.5-811-g8e27a934d_linux_amd64 backup -r repo kernel_source/
enter password for repository:
repository 63b5531a opened (version 2, compression level auto)
created new cache in /root/.cache/restic
no parent snapshot found, will read all files
[0:00] 0 index files loaded
Files: 84283 new, 0 changed, 0 unmodified
Dirs: 5491 new, 0 changed, 0 unmodified
Added to the repository: 1.350 GiB (276.936 MiB stored)
processed 84283 files, 1.324 GiB in 0:07
snapshot 3b8dc776 saved
# time ./restic_v0.16.5-811-g8e27a934d_linux_amd64 -r repo/ restore latest --target restored_files/
enter password for repository:
repository 63b5531a opened (version 2, compression level auto)
[0:00] 100.00% 2 / 2 index files loaded
restoring snapshot 3b8dc776 of [/root/kernel_source] at 2024-07-09 07:35:38.59864869 +0200 CEST by root@host to /root/restored_files/
Summary: Restored 89834 files/dirs (1.324 GiB) in 0:26
real 0m30.569s
user 0m38.612s
sys 0m6.988s
- Then I did the same restore using
--dry-run:
# time ./restic_v0.16.5-811-g8e27a934d_linux_amd64 -r repo/ restore latest --target restored_files/ --dry-run
enter password for repository:
repository 63b5531a opened (version 2, compression level auto)
[0:00] 100.00% 2 / 2 index files loaded
restoring snapshot 3b8dc776 of [/root/kernel_source] at 2024-07-09 07:35:38.59864869 +0200 CEST by root@host to /root/restored_files/
Summary: Restored 5551 files/dirs (0 B) in 0:24, skipped 84283 files/dirs 1.324 GiB
real 0m29.349s
user 0m25.988s
sys 0m1.524s
I thought that the --dry-run option will be faster than the actual restore, and at this point I felt a little sad about the results. The trick is to restore to a empty dir, the restore process is a lot faster than before. I guess that restic does not check all the local files on the restored_files/ directory. I understand that this is the desired behaviour.
# time ./restic_v0.16.5-811-g8e27a934d_linux_amd64 -r repo/ restore latest --target empty_dir/ --dry-run
enter password for repository:
repository 63b5531a opened (version 2, compression level auto)
[0:00] 100.00% 2 / 2 index files loaded
restoring snapshot 3b8dc776 of [/root/kernel_source] at 2024-07-09 07:35:38.59864869 +0200 CEST by root@host to /root/empty_dir/
Summary: Restored 89834 files/dirs (1.324 GiB) in 0:06
real 0m11.320s
user 0m8.144s
sys 0m0.372s
Another option is to restore pointing to /dev/null:
# time ./restic_v0.16.5-811-g8e27a934d_linux_amd64 -r repo/ restore latest --target /dev/null --dry-run
enter password for repository:
repository 63b5531a opened (version 2, compression level auto)
[0:00] 100.00% 2 / 2 index files loaded
restoring snapshot 3b8dc776 of [/root/kernel_source] at 2024-07-09 07:35:38.59864869 +0200 CEST by root@host to /dev/null
Summary: Restored 89834 files/dirs (1.324 GiB) in 0:05
real 0m10.837s
user 0m7.908s
sys 0m0.452s
Maybe an addition to the docs explaining this behaviour would be helpful for other people that are on the same boat than me. The --dry-run option works very well and the results are fast, but if you only want to know the size of the restored content, it will be faster to output the restore to /dev/null, in that case restic will not check local files on the restore destination, I guess it would consume less resources as well because it does not use local IO to check files stat.
after taking way longer than expected. I hope we’ll be able to release the version in one or two weeks. The upcoming version includes a vast number of new features and internal improvements. I’ve picked just a few highlights in the following table, see the draft changelog for a complete list.
