We tend here (MSP) not to use SQL Express unless the installation is in a small datacenter only.  Typically, we have full blown SQL installed at all our DCs to use for the Veeam database and it is never installed on the VBR server always external so it can be configured as per best practices.

Looking forward to testing out a large instance of PostgreSQL with v12 to see how that performs since that could possibly go on the VBR server depending on Veeam BP.  Also need to check on specs for the PG database as well.

Also, we use external SQL servers as with VONE I use the SSRS reporting services.  

I was external with Always On configured, and after a huge issue (Microsoft) I had to reload the Veeam server. I restored the config but didn’t want to overwrite the database in our current state and the DB guy wasn’t in so I went local. It actually was pretty smooth and I recommend every do a Veeam restore at some point.  It was an eye opener how long it takes to read the tapes in our library before things get operational.  I hope in future versions it can read them while still allowing you to restore from object storage, other backups etc. 

As an MSP we use full fat SQL on external servers.

We usually have multiple Veeam DB’s on 1 server i.e. VBR & EM just to save licensing.

Most client deployments Express is a viable and sound option. 

Yes I have already hit the SQL Express limit, cause the infrastructure grew up in the times and the Veeam is used for backup, replication, backup copy, tape...
In v12 this limitation could be change with Postgre.

I never installed a Veeam on a SQL cluster, for me this case apply for the MSPs.

With SQL Enterprise licenses on our hosts I can stack up as many SQL servers as I want.  Same with our Windows Datacenter licenses so lucky for me I never really have to consider that.

Our EM is internal too.. I wonder how hard I’d have to push to max out the Express servers. 

We have hit the MS SQL Express limits in several environments - mostly in environments where File-to-Tape jobs are used.

We are using local databases on the backup server, because we are using physical servers with enough power to handle the Veeam Server and the database.

Impressive.  You win!

I have Backup, Replication, Backup copy, PB’s of Tape, index's, object storage, multiple repository's, multiple proxies.

How many VM’s were you backing up as a ballpark. 

So full SQL on your Veeam server?

That is a pretty cool way of doing it, saves network traffic too. 

I’ve never hit the Express limits on VBR (though I have it it on the Service Provider Console).  But most of my clients are pretty small -- maybe a dozen or less VM’s though there are a couple that are up to 30 or so.  Internally, I think we have the largest protected workload with around 60 VM’s protected and still haven’t hit the Express limits, but we’re not doing anything special like file system indexing or tapes or something like that which would grow the database.  The only thing out of the “norm” that we’re doing is CDP replication on three of the VM’s.  I should probably look at migrating that to SQL Standard though.

Personally, I’m looking forward to trying out Postgres to avoid the potential of hitting that limit.

Yes, we have VBR server, database and Repository on one physical system (and some more physical repository servers - some with tape server on it).

You guys had me worried, Database is 4.2GB so I have a while to go

I’ll switch in V12 and say goodbye to SQL Express.

Hi @Scott , at the customers we always install the SQL-server on the VBR-server itself (even if the VBR-server is virtual or physical).

Why : to make it less complex, no dependencies and because of the performance.

In normal circumstances SQL Express is sufficient.

Did I even ran into the SQL Express limits? Sure, at the larger customers and also for our VCC : there you need definitely a full blown SQL server.

We use it also local on the VCC-server for the same reasons mentioned above, but it could be an option to separate them.

For the VSPC installation we use different servers for the SQL and web because of different VLANs / zones because of the IIS running.

For VEEAM ONE you can soon run into the SQL Express limits, there you have to limit the data being kept.

Regarding Postgres : personally I think first testing and implementing only for those customers that otherwise need a full blown SQL server with expensive license...

Hey!

My experience:

Yep have deployed SQL Always On for Veeam Cloud Connect as it justified the overheads of maintenance to ensure the resilience at the database level.

I absolutely would never put a SQL Server “full” edition onto the VBR server. Nobody has issues with SQL Express coexisting due to its memory constraints. It can’t consume more than 1.41GB IIRC.

Upgrading to SQL Server standard edition, 2014 or newer, uplifts this to 128GB RAM and, be default, SQL Server is configured to consume all the host RAM it wants. So you can very easily page out to disk with minimal application workloads sat alongside a database.

I’ll be clear here, the severity of the point above and the rest of the points I make, will vary based on the resources available, and the requirements of the database from Veeam. Though they may become problematic at the high end, at the low end they could probably be ignored safely.

Firstly, to bypass the SQL Server RAM issue mentioned above that would have the OS paging aggressively to disk, you can set a lower maximum RAM value for the SQL instance, so you can “right size” what you believe the database actually needs, and ensure it’s not overstepping onto Veeam’s resources.

The second issue is that you license SQL based on the number of cores, if you had an all-in-one server that was proxy, repository, tape server, and needed a SQL Server standard edition, you have to license SQL Server for all of the physical cores available to it (all pCPU if installed onto bare metal, or all vCPU provisioned if in a VM). My facts & figures are way outdated now but I recall a rough price of £4k per 2 CPU cores (4 cores minimum) for SQL Server standard editions. Assuming you had an all-in-one physical server you installed SQL onto, and assuming you gave the server 16 pCPU because that’s the minimum Microsoft charge for Windows Server licenses now, that’s a huge expense!

Thirdly, but related to point two, because you have to pay per core, you don’t want to find yourself starved for CPU and need to increase your core count because of other resources running on the same VM as your SQL server, as this would again, increase the costs.

Again, based on this detail, you might be able to safely sidestep these problems, but do you really want to vs putting the SQL Server on another VM? If VBR & SQL were both configured to the same host, they’d talk at a vSwitch level and wouldn’t even generate network traffic. Not that they talk THAT much anyway…

Thx for your feedback @MicoolPaul !

Indeed, you are right, I’m convinced about putting the SQL-server on a separate VM running on the same host. You are less dependent about certain things.

Of course, the RAM is limited, Cores are licensed for the number available, but you’re right, it’s more flexible!

Will consider this moving to a separate VM .

Again, that’s why the community is for, learning from each other 

We have hit the MS SQL Express limits in several DC, one VBR per DC.

We are using local databases on the backup server (virtual), i prefer to be autonomous if a disaster occurs. I had to restrict the resources of the MSSQL engine after investigation with Veeam support on a vbr with a lot of tape jobs. As described very well, the operation of MSSQL is quite greedy. 

Full SQL is on my vbr server, Veeam one and EM are dedicated VMs on the same Lan. I don’t really care of network traffic on local 100gb 

backuping thousands of VMs, many PBs...

I prefer the local DB, or at least a Veeam Specific SQL DB Server. When the DB server gets patched I don’t want to have to check Veeam every time to make sure it’s not backing something up messing with the schedule. 

I have SQL enterprise and MS Datacenter licenses for my VMware clusters. The hosts are fully covered so I can keep installing windows and SQL until I run out of resources.  It’s nice to not have to think about that. It is EXPENSIVE though. 

True about pariing on the host too. I often team up servers such as an App server, Web server and DB server in an affinity rule to keep them together on hosts.   If you have a UCS chassis, traffic stays in the host first, but will stay with in the Fabric Interconnect if it’s within the same Chassis.

I laughed at how little traffic comes out of my VMware environments the other day. 

Hmm not so much around 200-300 VMs 

I found I’m just under 5GB at 170 or so VM’s so that seems about right. I started adding more CDP, Tape/File jobs recently so I'll hit it sooner than later.