On one server, i did run remove_unknown (took 3 days), it then became slow.
As in too slow to cope with the backup rhythm, the backup went from like 1-2 minutes to 20-30 minutes (x264 servers, that were backup up 4x per day before)
I did then run defrag-database ( took 4 hours) thinking there were too much changes and it would need some maintenance.
After the defrag, the database file was twice as large as before (15gb to 30 gb)
i think it is now in startup maintenance or schema upgrade (showing number of entries processed + percentage at 6.5M files/48%, started 3 hours ago )
The other server which was also updated but on which remove_unknown wasn’t run has normal backup speed. (maybe the problem isn’t actually with remove_unknown)
One of the thing which is slow is :
Referencing snapshot on “xxx” for path “yyy” failed: FAILED
About 1-2 line get printed every second but there s a lot of lines that get printed.
Maybe it is one line per path stored in the .directory_pool ?
So this one is very noticable, because the actual backup is often <1min, but that last step with run during 2-3 minutes.
Ok, i restarted the services and things seems to go back to normal.
I still think this action slow things down a lot, but right now the backup queue isn’t full (it s doing about 5 backup at a time and the max set is 15):
This can go on for 5 minutes even when 0kb are backuped
Referencing snapshot on xxx" for path “.symlink_yyy” failed: FAILED
Question is if that is really the cause, or that it just has to link a lot of files/create a lot of symlinks in those directories. You should see that in e.g. iotop.
If you want to get rid of all those .symlink_xx paths either include the directory the symlinks are pointing to in the backup or disable following symlinks outside of the backed up path.
And the new version does properly reference single file symlinks. That could cause the backup delay…