restic 0.18.0 compiled with go1.24.4 on linux/amd64
# set RESTIC_REPOSITORY=foo RESTIC_PASSWORD_FILE=/tmp/tmp.xxxx
# restic --verbose=2 mount /tmp/restore
repository 97473a5f opened (version 2, compression level auto)
[2:45] 100.00% 959 / 959 index files loaded
Now serving the repository at /tmp/restore
Use another terminal or tool to browse the contents of this folder.
When finished, quit with Ctrl-c here or umount the mountpoint.
(In another shell, some point after the “Now Serving” message but not immediately)
$ /usr/bin/time ls -l /tmp/restore
hosts ids snapshots tags
0.00user 0.00system 2:23.94elapsed 0%CPU (0avgtext+0avgdata 2444maxresident)k
544inputs+0outputs (5major+138minor)pagefaults 0swaps
The index files reach 959/959 in 24 seconds, it sits at loaded 959/959 for another 2.5 minutes before it says “Now serving the repository”, there’s a short burst of getattr() calls to NFS for about 10 seconds,
then after that it’s another 3 minutes of restic pegging a single core of the CPU 100% and slowly increasing memory usage before the filesystem returns the first ls. After that, everything works as expected and quite snappy. I’ve even run games off the snapshot rather than re-installing them!
Similar deal with restic stats: indexes load in 24 seconds using all cores, whole process takes another 8 minutes of single-core work.
# time restic stats c3fcf9e6
repository 97473a5f opened (version 2, compression level auto)
[2:17] 100.00% 959 / 959 index files loaded
scanning…
Stats in restore-size mode:
Snapshots processed: 1
Total File Count: 21997687
Total Size: 1.990 TiB
920.10user 39.81system 8:20.72elapsed 191%CPU (0avgtext+0avgdata 17129652maxresident)k
13474576inputs+1369952outputs (18487major+4413046minor)pagefaults 0swaps
Is there any way to determine what’s going on in those extra 5/8 minutes? Yes, 21 million files per snapshot over hundreds of snapshots is large, I expect it to take some time, but I don’t expect it to stall for 3-4 minutes after it says it’s ready.