New repository, new Veeam design doubt

[Giacomo_N]

Hi guys,

my current Veeam environment:
1xVeeam VM backup server on Nutanix on vpshere 6.5 ent.
1xVeeam VM Tape role server and proxy role on an old Dell R710 on ESXi free (old scsi library in pass through)
1xNAS QNAP 12*4TB in the main site as the repository
1XNAS QNAP 12*4TB in the secondary site as the copy-job repository (LAN 10Gb/s)

Primary QNAP finally dead last month and yesterday I received a brand new Dell R740xd with 8*8TB, 16 core, 128GB ram, Win 20016 OEM and vmware essentials.
My first Idea is to replace the old QNAP repository with 1xVM on Windows 2016, but now I'm in dubt to put also the backup server role and proxy role in the same VM server.
Another question, is it good or useless to create 3 Vdisk and set my current 3 jobs to write separately ?

Thanks in advance

[Rick.Vanover]

Hi Giacomo - having the proxy and backup server role (heck even repository) can be very good - especially in regards to performance. Just make sure there data goes 1 more spot - our beloved 3-2-1 rule.

I also encourage you to start using the Scale-Out Backup Repository. It makes migrations of the underlying storage very easy (see recent blog post: https://www.veeam.com/blog/scale-out-ba ... itory.html).

To the question of 3 vDisk and 3 jobs separate writes. That can be fine, in fact, if you had multiple extents (underlying backup repositories) in the Scale-Out Backup Repository, you will be able to get this multi stream anyways!

[Giacomo_N]

Hi Rick, thank you for the reply!

Following your suggestion I want to try to put server,proxy and repository in the same VM.

I've read your very good article of SOBR, but I can't understand if in my (small) environment of 50Vm's and 30TB of total repository, 2 repository and 2 sites, give me performance advantage or cons.
The repository migration data procedure seems to be easy : https://www.veeam.com/kb1729 and this is the first time that i need to move the datastore since 2013.

Thank you in advnce

[Rick.Vanover]

The performance advantage could come if you put the SOBR performance policy in place where full backups go on one storage, increments on a (presumably faster) different storage. At least on restores you would read from the two sources, and on manipulations (like synthetic full) - they will be done on more appropriate storages. But above all - for the next time you move (or if you reconfigure the SOBR) - it is all transparent - meaning that the backup job goes to the SOBR, and the backup job does not change - the targets of the SOBR are abstracted, so you won't miss a restore point.