I think there are a couple of options:

• Use the Extract Utility to extract the vmdk from the backup
• Install the Community Edition of VBR, import your datastore and recover from there
• Setup a new VBR server, restore the configuration backup and use that from now on.

I’m going to do the third one. 

I’ve discovered a spare Hyper-V host that’s only hosting replica VMs which are turned off.  So it’s doing nothing and as it’s a recovery / standby server it’s actually the ideal place to put the Veeam console. 

After that I can perform my restoration! 

Yeah....agree with @mkevenaar here, & your initial thought, of just restoring Veeam to another VM then going from there. It's just cleaner that way. If you did have another Host already up & going, you could possibly do a full VM restore to a new location, & restore it workout powering it up so you wouldn't run into network conflicts. But again, you really need to separate VBR off so is wise to go the new VBR VM route. 

I agree with new server and config backup.  Especially if it is recent. There is less chance for unexpected results. 

Going forward I recommend Veeam on it’s own server and your config backup to a different location. I script mine to copy it a few places. In the event of ransomware or something very bad, all you need is your air gapped backups and config file to at begin. 

Definitely recommend building a new server and restoring the config database to it.  Make sure your config database backups are encrypted and you have the encryption key.  By having it encrypted, it’ll save your passwords for your infrastructure, encrypted repository, etc.  If you don’t have it encrypted, you’ll need to supply all of the passwords after you restore the configuration database.

yeah, I built a new server.  Something which upset me a bit is the way Veeam have yanked the rug on SQL Express.  I don’t require Postgre advantages and my existing server is SQL so would have required a conversion.  

So during the installation I changed the DB setting to SQL but that then created a problem whereby the Veeam installation no longer automates the installation of SQL Express.  So I had to do a manual installation and had to choose which components to install.  Then I had to set the security access to the DB and create a DB name.  All by myself! 

So when I tried to run the Veeam installation again I got a problem with the SYSTEM user not being allowed to create a database on the SQL Express server. 

Not really being an SQL expert I was relying on internet forum articles to find out how to allow the SYSTEM user to create a DB.  Most of these articles say install SQL Management Studio.  So I had to install a great big bit of bloaty software to set a configuration setting which would have been scripted in the Veeam installation originally. 

I saw your post on R&D forums and I believe this is a valid worry for reinstalls, hopefully the installer evolves to incorporate this functionality

Hi, I think I’m in a similar situation.  My Veeam R&D is installed on a VM that got corrupted and I had to recover that VM.  Similar to above, my datastore is located on another device and unaffected by the VM restore.  The VM was recovered using using a backup from 7 days ago.  Between now and 7 days ago, Veeam has made several backups of machines on the network and those reside on the datastore.  Is there a way to get Veeam to “refresh” using the data in the datastore so it knows about the backups made say yesterday?  Right now, when I open R&D, it is saying the most recent backups were made 9 days ago, and I know backups have been made since then.  It’s just that the local database is out of date,

Thank you

Hi, If you re-scan the repos, veeam should update the info refered to the backup chains,
in a “bad scenario” situation, I wouldnt be worried about missing some statistics, if the info is there.

in the past, with low budget, we normally backed up the VBR VM daily, also the config from Veeam in a different location, and replicate the VBR VM to another ESXi host daily.

We had the situation of losing the main VBR, so we had several options.

To us, the most important outcome was, we have some options, we are not relying on a single plan,

• Install a community and restore the VBR VM to the lastes working backup
• Turn on the réplica (in worst case scenario) to start restoring the VBR, turned off and continue as “normal” as possible.
• Clean install, importing the config file and re-scanning the repos
• etc.

Try to find always what best work for you, depending on your infra, options and RPOs, RTOs, expertise, etc.

Never trust a single plan, always have plan B and C, just in case (like the 3-2-1).

cheers.

I always to recommend install a brand new server and import the config backup. It will work and is simple. If you are paranoid you can copy that config backup to more locations if needed.  Have a clean vanilla VM or physical host waiting at another site even to save time if needed. 

Previously, I had a small repo on a DFS share, so the config backup was replicated via DFS to secondary sites.  We’ve since disabled that replication, but my backup server now also runs at my DR site, so it’s less of a need.  But that method worked well for me, or you could place a copy somewhere and have a scheduled task copy the config back to 1 or more remote locations., or use a file copy job within Veeam.  I also don’t mind putting it in a VCC repo somewhere if available.

Veeam FileCopy is a very underrated feature, but a scheduled task works just fine too.