For the SQL Server (on Hyper-V), I'd probably schedule regular full/diff, and T-Log backups in SQL Server to a local drive that will then be backed up with the Hyper-V VM by CloudBerry. I cannot comment about the time clock software that uses SQL Server. Likely that company has backup guidelines for their software - and may be running backups automatically in the background. Since it's not a SQL Server database you likely have to manage on your own, it's best to follow the product's recommended backup instructions. If you do manage the SQL Server, though, then you can just back it up as needed and let CloudBerry sweep up those backups as described above to the cloud (or wherever you send your backups). If you run your own SQL Server backups outside of CloudBerry, you'll need to manage retention on those files - meaning, delete the backups when no longer needed locally.

If you want CloudBerry to manage the SQL Server backups (and retention) separately from Hyper-V VM backups, you would have to use a the SQL Server version and install it in the VM. It may be easier since we can manage the backups, scheduling, and retention - all without having to use a lot of local disk.

Yes, thats great.

But, if the CBB HyperV product is running a VM backup on the SQL VM, isn't that bad. I basically would have two products backing up the HyperV VM with SQL. I am assuming that you want me to put in an exclusion in the HyperV routine backup that excludes backing up of the SQL in the VM.

I'd have to check, but I would guess Hyper-V, given it's a Microsoft product, leverages VSS when performing the VM snapshots. SQL Server is VSS aware and you can get application consistent backups with VSS. But VSS has some limitations like not supporting transaction log backups. If you use both products (host VM and guest SQL Server), I agree that excluding the SQL Server databases from the VM backup is probably ideal. In the meantime, I'll ping the team for any additional guidance on this setup.

In your case you'd need to install SQL version on VM itself to perform database backups properly. Otherwise those VM backups will only contain SQL environment in a "frozen" state as a part of a VM backup.
Make sure you're not running those backups simultaneously just in case.

By simultaneous, you mean at same hour (example). Not running a SQL and Hyperv. They can be done at different hours.

Interesting discussion here. So we have several hyperv hosts with sql servers as well as exchange server. So just to be clear when you have a VM with sql (full or express) we would need to install the SQL version of cloudberry as well on the guest as well as the VM version of cloudberry for the other guests? So basically we would tell the VM version of cbb to backup all VM's except the VM with sql on it (possibly exchange too) and install the SQL version of cbb on the guest and maintain separate backups?

Just trying to get some clarification on that.

Thanks Dave

VM version can be installed on the host, so only one instance of the software is required. For SQL you need to install SQL version on guest and that's pretty much it.

Thanks Matt. Couple followup questions assuming CB is installed on hyper v host.
1. Since the SQL version will be installed on the guest os does it need to be excluded from the backup at the VM host level?
2. Does this still hold true for Microsoft Exchange running on a VM? Would we need to install the exchange version of CB on the guest?

Thanks

1) That's not necessary.
2) Yes, correct.

Thanks very much. Gonna give it a go.