If you are using Veeam Backup 6 and you run the proxy module on the Veeam Backup server itself (usually a single Windows server with all the Veeam roles installed on it) you could have seen this behaviour.

After a File Level Restore, backup jobs usually running in Hot Add mode, suddenly complete failing over to Network Mode. You can see this by looking at job result changing from Success to Warning.

First of all, do not panic: performances are lower, but backups complete without problems.

The problem, confirmed by Veeam itself, is caused by the interaction between Veeam Backup and vStorage API. As described directly by Anton Gostev in a post in the Veeam forums:

The FLR process reserves a block of mount points from the system (100 of those), making hot add to use those above 100, and there is a bug in vStorage API that makes hot add go crazy in such case. The immediate hotfix will probably be to reduce the number of reserved mount point from 100 to 20 or something. As far as the current workaround, I suggest disabling local VMware backup proxy on your backup server, and using another VM as your hot add proxy server.

So, if you are using deployments with multiple proxies, do not use Veeam Server as a proxy and let it in the role of central control. If you have all the roles installed on a single server, the workaround is to reboot Veeam Server after a File Level Restore.

Until the next patch will fix it.

UPDATE: there is now a patch available through Veeam support, open a ticket to get it.