Just want to say that I've restored probably 100+ vCenter servers over the past 5 years (a lot of these were for a handful of customers testing this specific DR scenario), in both test and production customer environments, and I've never had an issue with not being able to recover the vCenter assuming the backup was properly made (i.e. included the database).
I did have one very complex issue with vSphere 5.5 because the inventory database itself was outside of the SQL database. We had to stop the inventory service and use file level recovery to restore some older backups, but we were finally able to get the inventory database to start and run properly. This was important because, while it's completely possible to create a fresh inventory database, in vSphere 5.5 all of the tag information was stored there, and this customer made heavy use of tags. I'm pretty sure in vSphere 6 that tags information is now in the main vCenter database.
Regardless, restoring vCenter is a "special" event. While you can backup vCenter with Veeam using the vCenter connection, it is obviously impossible to restore using this method since, to restore vCenter you must power vCenter off, but it is obviously impossible to communicate with a powered off vCenter, so it creates a significant chicken-and-the-egg problem.
The solution is to determine which specific host the vCenter VM is currently registered against, temporarily add that host to the Veeam console via IP address as a standalone ESXi host, and then chose and advanced restore and restore either the VM disks or entire VM, mapping the resources to the standlone hosts. The reason you have to add the host by IP address, rather than by name, is because the Veeam console will not allow you to have the same host added twice, once via vCenter and again by direct host, so adding the host by IP address is a little bit of a trick.