This is a bit of information I think others might find useful, and might spark a bit of discussion.
I noticed that Restic 0.9.1 was using the disk a lot when it was running backups. I posted about this on another thread, asking why restic didn’t just check the modified date, to be told it did. I could see a lot of disk access when a backup ran on my PC, so I dug into it.
This was the key graphic that helped me work out what was going on.
As you can see “avguard.exe” was scanning every file that restic needed to backup, even though restic was presumably only looking at the file modified date. I don’t know if this is a bug with the virus scanner, a feature of the virus scanner, or a bug / lack of optimisation in Restic, but when I configured Avira to exclude the folder I was backing up it was much faster and used a lot less disk.
Excluding everything you want to back up from virus scans isn’t very practical. I might try a different virus scanner to see if it’s better optimized / performs better, and if I do I’ll report back - it’ll take me a week or two though. If others are interested they could give it a go.
Hopefully this helps others who are finding restic slow.
The thing is this; You should not exclude folders or files in your AV program, but processes.
If instead of telling your AV to ignore certain folders, you tell it to ignore whatever folders and files the restic process accesses, you have a more dynamic setup and everything should be fine.
Yes, excluding the restic process does work. It might need a reboot, as initially I didn’t think it worked.
It would be useful to make this really obvious to people running windows. Maybe even an output in the windows version of the help / command overview? “Remember to exclude the restic process from your real time virus scanner otherwise performance could be poor”?
FYI the same thing happens with Windows Explorer and the same workaround fixes the problem: Add rustic.exe to the list of excluded processes.
I still find it very strange that whatever restic is doing causes the virus scanners to think files on the disk might have changed. Other programs can read every file in a directory without causing the virus scanner to run.
As I understand it, restic should be reading the directory entries and then calling the moral equivalent of fstat() on each entry. (1) This shouldn’t be interpreted as changing files by the virus scanner so it is strange.
Calling fstat() on every scanned file is a known outstanding performance bug in the scanning code, but lower priority than the issues with restore or prune.
I guess the options are it’s either the virus scanner being more aggressive than required, or restic is making a non-optimal call to get the information required. It really just needs a directory listing, but it may need to read the metadata for an individual file for some reason, triggering the virus scanner.
Well it does need to get metadata for every file which is suboptimal on Windows since Go already had this information and discarded it, but this is still a read-only operation so I don’t see why it should trigger a virus scanner.
