I've been playing around with VEEAM for testing to implement in a new environment. So far I've been able to configure basic backup jobs to disk, tape and Surebackup jobs which work pretty well. I'm currently looking at on planning the backup for an in-house standalone Exchange Server 2019 VM that's self contained (Database, Mailbox on same server) that's hosted on a VSphere/VCenter Hyperflex cluster.
In regards to this, I'm currently testing backup jobs that will backup the entire VM from VSphere including any databases with application aware processing enabled. It works and I am able to restore mailboxes and items individually but in production reality the database size may be large (300 - 500 GB total) which can affect backup and restore times. In regards to this, I was wondering if someone could point me in the right direction on whether:
It's advisable to split the VM OS drive and the VM Data drives into separate jobs or just keep them as one? If it's advisable to split them up, what would be the best way to go about doing this?
Should I opt for using an agent-based backup on the VM as opposed to a VM backup job via VSphere for backing Exchange Server? Would there be any differences in using VM based vs Agent based backups?
Could the latter concepts be taken and applied to MS SQL Server as well?
1. I wouldn't create several jobs for the same VM: it's difficult to manage, moreover, I'm not sure that log truncation would work seamlessly in such a configuration. If you're concerned about performance, I would investigate where is the "bottleneck" and would try to optimize the deployment. Anyway, please keep in mind that you should think about performance optimizations only if you're sure that you don't comply with your RPO/RTO requirements.
2. I recommend using VM backup whenever possible. The main reason is that the Source Data Mover which fetches and compresses data will be running on a dedicated proxy machine, thus you reduce the database server load. With an agent-based approach, the agent will be running on the source server and may affect the server performance.
3. Yes, the same is applicable to SQL server. Also, we have a new plug-in in version 12 which might be also a way to protect your SQL server.