


So, a tip here is if you are dealing with a small number of physical machines is prep the virtual environment ahead of time. Somebody correct me if I'm wrong, but the fact Veeam is involved doesn't help this part much. There's always some screwing around with the migrated or restored operating systems loading virtual NIC drivers and integration tools, setting proper IPs, removing hardware based drivers and software like RAID tools etc. While I've had good results with hundreds of P2V's on all platforms rarely is it is a simple turn key process. So, a DR recovery in this scenarios is, for all intents and purposes a P2V conversion.just done with a gun to your head and people screaming "the server is down!" :-) Bulk data, files and databases aren't the issue.Data could give a damn if it's executed inside a VM or physical host and doesn't need to be converted - just moved. In a physical to virtual DR scenario the hardest part and the one prone to most variables is spinning up the original operating system inside the VM environment. So might as well start planning of virtualizing the servers now. It is easy to P2V but many many issues if going back from V2P. Then you will also have to prepare your customer that is a one-way process if DR does really happen. Then you will also need to know what is running on the Server 2012R2 box as well.the last things you want is MS Exchange, MS SQL, Domain Controller, ERP solution (that have a DB like SQL or Oracle) or even Hyper-V. There are always exceptional cases and thats where you would probably need some Veeam vendors to step in. I really dun wanna sound rude.but I would highly recommend that you do a POC before suggesting it to your customer. if not, then i assume veeam backup creates a virtual disk during its backup that it uses and can just attach to and boot up? thats where im a bit fuzzy. within that procedure does the data get transferred from the backup file back into the newly created vm dynamic hard drive? that would take a while if you have a 4TB data disk.
