Hi,
The backup is going to be performing application aware processing which will require all transactions to complete prior to VSS snapshotting, hence the IO freeze you’re experiencing. This is important to make the backup transactionally consistent, important if you’re expecting to restore the database within this backup. Editing the application aware settings will control if or how frequently you run the transaction log shipping.
If the database team are performing their own backups you could instead choose to disable Application awareness to avoid this, though VSS will still need to be used on the system anyway to ensure the data is a static point in time. To avoid that completely you could do a VM snapshot level backup if this is a supported virtual machine.
Hope this helps, there’s plenty of options available to protect the server.
I’ve made some assumptions based on your tags but full insights would certainly help with regards to hypervisor (looks like you tagged GCP for this?) and looks like you’re using the windows agent but you haven’t specified the database type
Hay @MicoolPaul thank you for your kind words to clarify we have an SQL database and I mentioned GCP because the instances are hosted on GCP and Windows-based. For database backup, we have configured VAW (Veeam Agent for Windows) to take the backups.
You mentioned that if the database team is performing their own backups, it could be a factor. What if I address them and request that they stop performing their own backups? Would that be considered best practice, or not?
If they stop performing backups on their end, do you think the I/O frozen issue will no longer occur?
Looking forward to your insights.