Problems VSS Backing up with Mutiple vLANS

[slidek9]

Hello,

On our production side, we have multiple vLANS

Our management vLAN houses the VC server; our production vLAN cannot see our VC server or Hosts at all.

So if I put our Veeam server in the production vLAN it cannot see the HOSTs or VC, thus we cannot select VMs to backup.

So I put Veeam on the management vLAN, now I am unable to do a VSS backup because it uses the ADMIN$ (in the production vLAN) to do backups.

Is there are trick here that I can use to do VSS backups in this situation?

Thanks!

[Gostev]

Hello Leon, I don't think there is anything you can do to resolve this today. VSS processing in such deployments will only be supported in the upcoming 5.0 release. Thanks!

[slidek9]

Okie,
Is there a release date yet for the 5.0 release please?

[Gostev]

Late Q3.

[slidek9]

Cool.
Gostev, the non-VSS type backups - would they really hurt a SQL server? As far as I understand it, the snapshot get's dropped and then Veeam backs up what is essential static data at that point in time. If the data is not changing then it would be transactionally correct. If thats so a non-VSS type backup for SQL servers using Veeam would be safe to use?

[Gostev]

To be safe with non-VSS backups, I recommend that you disable VMware Tools quiescence in the Advanced job settings, as VMware SYNC driver used to sync the file system is known to cause issues to production SQL. With VMware Tools quiescence disabled, backups will be safe for your production systems at least.

[tsightler]

Cool.
Gostev, the non-VSS type backups - would they really hurt a SQL server? As far as I understand it, the snapshot get's dropped and then Veeam backs up what is essential static data at that point in time. If the data is not changing then it would be transactionally correct. If thats so a non-VSS type backup for SQL servers using Veeam would be safe to use?

Non-VSS backups with Veeam would be "crash consistent" which means they would basically be as consistent as if the server was powered off/crashed at the exact moment the backup was takes. SQL should pretty much always be able to recover from this, but it's a good idea to continue to run SQL native backups just to be 100% sure you're safe.

[slidek9]

The DBA is happy with crash consistent - thank both for your input