SQL VMDK Incremental - Two backups each run?
Each time our incremental backup job runs, SQL registers two backup jobs. Is this normal behavior? Here are the details:
- Backup Exec 16
- SQL Server 2014 running on Windows Server 2012 R2 in a vmware vSphere 6.5 environment
- Full backup runs nightly at 9:00 PM
- Incremental backup runs hourly from 6:00 AM to 9:00 PM
- Verify - At the end of the job
- Instant GRT - Enabled
- Advanced Open File - Use snapshot technology, Automatic VSS provider, Process logical volumes one at a time, enable checkpoint restart
- Virtual machine options
- Use the full backup method...
- Use GRT
- Enable GRT for MSSQL
- Run a SQL Log backup after backing up the VM
- Enable GRT for MSSQL
- VMware
- Use VSS
- Use VSS Copy backup
- Transport mode - NBD
- Use VSS
- Full backup method: Full - back up virtual machines
- Incremental backup method: Incremental (block-level)
When reviewing the BackupExec log for the job, it runs the VMDK backup first and includes that it "discovered and protected Microsoft SQL Server data on virtual machine 'server.mydomain.com'". That takes about 4 minutes.
It then proceeds to the SQL-specific backup. It performs consistency checks and then backs up the 13 databases.
I think that's all normal and to be expected. The DBA managing the application in question sees the following behavior in the SQL logs during an incremental backup (attached):
- I/O is frozen for each DB for 1 second
- I/O is resumed for each DB
- Each database is backed up (according to the log, but we're only 2 seconds in now)
- I/O is frozen for each DB for about 5 seconds
- I/O is resumed for each DB
- Each database is backed up.
- There's now a 4 minute gap. I'm guessing this is during the verify stage of the VMDK backup.
- Each database receives consistency check
- Log backup performed for each database
My DBA is only expecting to see steps 8 and 9.
The most important question for me right now is this: Am I correct in my understanding that the VMDK backup is what is logging steps 1-6 (i.e. this is expected behavior)?
Secondarily, is there a more efficient way to be doing this or is this the best way to protect both the VMDK and SQL?