yes, so if you're 'paving over' the existing installation with a restoration you don't want to overwrite the drivers which are already present and dissimilar to the drivers of the machine you are trying to restore. This is assuming the machine you're attempting to BMR is radically different specification from the one you backed up. As I'm sure you're aware, the language we're using is 'bare metal restore'. A total restoration of a backed up machine to different hardware. A recovery .iso for the original machine will only be useful if restoring to the same hardware or a nearly identical specification.
A standard rule-of-thumb is that you can add incompatible drivers to a build in either direction but Windows won't try to use them if they're incompatible. To use incompatible drivers in Windows you have to be very persistent and manually specify for each device an incompatible driver or windows will just ignore it.
I believe the purpose of the recovery .ISO is to be able to boot the machine. Once booted you can restore data from the Veeam job. Without a compatible recovery .ISO you would have to build a fresh machine and then restore the Veeam job. i.e. if the recovery .ISO is for incompatible hardware it wouldn't be of any use anyway.
If you wanted to guess what would be best without defining your own policy based on testing in your own environment then prepare recovery with drivers included as your default.
I'll tell you what I'm doing and you can critique my approach as it might be useful for me if you can see any problems or vice versa, it may change your view on your approach. For my physical servers I've created my recovery .ISO files which are a one-time file you generate when you install the agent on the physical machine. After that, I do two kinds of backup for each server. I have an 'Entire Computer' backup of the machine which includes all the drives and a system state. On top of that I also have separate jobs defined for the system drive and the data drives. With this granularity I can restore any kind of data in any kind of scenario. I'm depending on de-duplication features to reduce the effect of backing up the same data multiple times and the stats I have show that this is working. All I'm doing with my different kinds of job definitions is giving myself multiple restore options, the additional data cost isn't too high.
In both cases the strategies we're discussing wouldn't provide very fast recovery for a failed physical server. If you don't know what you're going to be BMR'ing to then a delay is unavoidable. Just make sure you have a copy of your data that you can use. If you know exactly what you're going to BMR to then there's no debate, create the .ISO and backup the server and you're done.
Another option I've seen from another contributor on this forum is to replicate your physical server to a VM. That provides the maximum efficiency when you have to do a total recovery of the server as the replicated server is on standby and only has to be made live.
