Veeam for a large enterprise

[rtheseeker]

We are currently in the process of a Veeam solution; we have a very large environment with multiple physical sites and presence in both AWS and Azure

The design we have received is one VBR server with dedicated repositories(HPE appollo with Linux for immutable repos) for each site(100TB each usable) with multiple proxies depending on the size (one site has 17 proxies another one has 4 and likewise). Currently we use a legacy backup product(BE) and it has around 20 physical servers(5 CAS servers with 4 member server at each site) with each connected to 12 store one devices; a group of servers are backing up only VMs and another group of servers are used for backing up agents/physical servers
However, reviewing the design in the Veeam solution, we are only using one virtual VBR server with multiple proxies for each site which will send data to a single local repository at each site. A dedicated SQL cluster will host the Veeam DB, Veeam One DB, VBEM DB. The networking is 10G across all the sites

However, I have few concerns; just wanted to validate my concerns from anyone who have such a large environment and using Veeam

How many jobs can a VM based VBR can handle considering (VM jobs, Agent based jobs, File Cluster Jobs, Enterprise App jobs(Oracle, SQL), Veeam Agent for Azure and AWS jobs)

Backward compatibility; say for example if VBR stops supporting a certain version of OS, VMWARE platform etc. having a single VBR means we will have to stop upgrading it further. For example if VMWARE 6.5 supported is ended in the next release we may be stuck

Will having a single VBR and 1 Repo for each site will take us backwards in term of performance and cause operational challenges; just from a physical design perspective at the moment we have 20 physical servers writing to multiple catalyst stores spread across multiple physical storeonce devices with data is deduplication up to 90% ; now using multiple Veeam proxies to write data to a singly hardened repository each site.

The design goals are to keep data encrypted in transit and at rest; and it appears SQL VDI based backups do not support such configuration

Also, we want DB Admins (SQL and Oracle) to manage the jobs themselves so would we have to use Enterprise app backups using backup policies rather than via Managed jobs

Although there would be a test environment if for any reason VBR stops functioning all the backups would stop functioning (we do have an active/passive VBR design )

Any feedback would be appreciated

[HannesK]

Hello,
as "large" is very different for everyone, I will give some general answers. If the design you received is from one of our Veeam Solution Architects, then it should be okay in general if they had all information when creating the design.

One backup server is recommended up to 10,000 machines (some customers go higher, but I would avoid it if there is no need). If you are (far) below that, then going for one backup server is usually okay. But of course one can split that for the reasons you mentioned. I know customers doing it per VCenter (if VMware is used), GEO or country to have smaller domains to manage. It depends a bit on personal preferences. Most prefer virtual backup servers, but physical are also fine of course (up to 1000 machines, I like the "all-in-one design with copy to immutable storage)

VBR Database: having a remote database is a common design at scale. Having the database local removes latency and can also make troubleshooting easier because one might not need to talk to a remote database server team (depends on customer, hard to give a general recommendation). So I try to go with local DBs as much as possible. And I would also go for Postgres if you deploy 12.1 (especially if you want to split into smaller backup server anyway). There was a recommendation for up to 5,000 machines with Postgres in V12, but that was lifted in 12.1. If you have SQL admins, then going with SQL is also fine of course. Just personal preference and we put most R&D effort into Postgres.

Enterprise Manager DB: relatively irrelevant. I would go for local if I can, but remote is also fine. Not much load there anyway.

VeeamONE DB: yes, dedicated SQL server. That DB has high load.

Jobs: depending on the resources, I have seen 1000-3000 jobs per backup server. It's recommended to go with larger and less jobs, but some customers put 1-3 VMs in one job end then end up with thousands which are harder to handle.

The database admins can manage everything on their own, that's fine (for SQL it's actually the only way today). Encryption for the database plugins is a highly demanded feature request, but I cannot give a timeline yet, when it will be delivered. We count your request +1 The only workaround "at rest" would be to use file system encryption (dm-crypt)

Apollo servers vs. what you have now: that's hard to recommend via forum (especially without numbers). Apollo servers are one of the the most popular (if not most) systems and can scale very high. As you only mention 100TB per site, that would be rather small anyway where one can go with relatively small disks and relatively high performance (I guess it's not all-flash )

Best regards,
Hannes

[rtheseeker]

Thanks very much; at least I have 10K machines as a baseline to request additonal VBR servers;