Uninstall Veeam and reinstall on D:\ on host server

[fuzzyrobin]

Hello,

We have a client with a hyperV host server running B&R v12. We need to install an update to 12.3.2 or greater to enable the cloud connector to run so our cloud backups start working again.

The C:\ on this host is only 80gb (legacy drive) and is down to 4gb free. There's nowhere near enough space to install the update and we've scoured the drive in all the usual places for space but can't regain any, it's all Windows critical files, ProgramData and Program Files.

The only solution I can think of would be to do a config backup, uninstall Veeam completely and reinstall on the D:\ (which has 127gb free) in it's entirely. Not move anything but complete uninstall and reinstall in the new location. This location currently has HyperV hard disk image files (the VM disks) and also HyperV snaphots. Question - would running Veeam off the D:\ where these HyperV disks are located cause performance issues with the VMs? They have continuous incremental backups running every hour.

Is there a guide or anything on this process? I know I need to do a configuration backup of course, but will any components still install on the C:\ if I point the ISO file to D:\ when I do the fresh install? Will the SQL instance also be on the D:\? I'd like everything to be on there, SQL, ProgramData, Program Files, everything, as the C:\ has such little space.

Would 127gb be enough space to install the complete Veeam installation?

Any advice or guides would be appreciated,

Thank you

[fuzzyrobin]

To add on more thing to this - this drive (not the repositories) is formatted as Resilient File System (ReFS) - would this cause any issues when installing Veeam or SQL server running on ReFS?

[Mildur]

Hi Jaime,

We strongly recommend using a virtual machine for the backup server. Deploying Veeam Backup & Replication directly on Hyper-V is not advisable.

This is the perfect time to migrate the customer to the recommended design.
You could deploy a Windows VM, install VBR and configure the restore. Alternatively, a better option with version 13 is to deploy a new Veeam Software Appliance from scratch, reconnect to your old repository and import backups. Jobs will need recreating and mapping to existing backup chains.
Keep in mind, your Cloud Connect environment must be on v13 as well if you will use v13

Best,
Fabian

[fuzzyrobin]

Thanks for the quick reply.

Can I ask the reasons why this isn't recommended please? Or can you point me to some documentation? We do have a number of clients set up in this way - this would require extra licensing for server licences, plus storage and other costs. But genuinely interested in the reasons so can put this case forward to my colleagues and bosses to perhaps change our strategy.

However, to get the backups running again in this scenario, we wouldn't be able to spin up another VM in a suitable time. We'd need to go with my original suggestion, are you able to please assist with addressing those questions and if it's possible?

Thank you so much

[Mildur]

Hi Jaime

Sure. You can find the statement in our help center.

Benefits I see by running it as a VM:
- extend disk space easily
- maintenance window to update the backup server does not require a reboot of the entire host with all VMs. That was always a pain for me when I had to upgrade backup servers from customers and the backup server was deployed directly on a Hyper-V server.

If you use the Veeam Software Appliance, you don‘t have to pay for an additional Windows License. Veeam Software Appliance has a Rocky Linux based operating system.

To answer your questions. We never have tested such a scenario and it depends on your hardware, so I can only share assumptions.

Performance:
spindle disks, probably. SSD less likely. If you have high transactional VMs on your datastore with high I/O requirements, I would‘t run a backup server directly from the same disks.

Guide/Location of remote components:
We have a deployment guide in Help Center. It‘s the same as for installing on drive C. A new deployment will use PostgreSQL as database. If you want to use MSSQL as database server, then you must deploy it yourself on drive D.
Regarding the location of the remote components, I will need to double check if they are deployed in the same location as VBR or not.

Disk requirement:
Please check the requirements for disk space in our help center.

Deployment on ReFS:
Will have to double check if it‘s supported or not by us.

Best,
Fabian