It's Windows 10 using the built-in Windows Defender. I tried disabling real-time protection, but it didn't help.
Resource monitor just confirms the SQL process using the CPU. The following was captured during the spike.
However, I reset the VAW database using the article at https://www.veeam.com/kb2335 and it seems to have stopped the spikes for now. I'll let you know if they come back (only one full backup has run so far).
I'm unsure of what tests / diagnostic I can do. I've stopped the Veeam Agent service and started the SQL LocalDB manually using SqlLocalDb.exe (had to do this as system via psexec). There didnt seem to be any spikes when I did this, but the when I checked next, the SQL instance had stopped itself anyway.
I tried to use the tracing function of SqlLocalDb.exe, but the timestamps of the trace files didn't change, so I'm guessing there's nothing to be gained from those (and I don't have Sql Profiler installed).
OK. I tested a bit more thoroughly by running the SQL instance alone - and I was wrong about it not causing the spikes. It seems as though when VeeamEndpointBackupSvc is stopped, but the SQL LocalDB instance is started, the regular CPU spikes do continue.
Therefore not a Veeam problem, but a SQL one. However, I'm still stuck on the possible cause as I am not a SQL expert. Will update if I find more.
This issue happens when there is not enough free memory on the machine running SQL LocalDB. Not sure though if Microsoft is going to do anything about it.