Veeam v8.0 Backup BP with VM Running SQL Express 2008R2

[XpertEssentials]

Happy New Year to you All!

We are looking for a best practice related to the topic in the subject line. We just did a P2V on this server, and with some “basic” troubleshooting, the server seems to be healthy and operational in regards to its own functionality and in regards to Veeam Backups.

What is concerning us are the backup times of this particular VM. While my other 4 VMs are backing up in about 5-15 minutes on average, this VM is taking 1-3 hours on average (utilizing Reverse Incremental). We are utilizing AAIP in Veeam and NOT truncating the logs. The version of SQL is using a simple database (as opposed to Full or Bulk-Logged), so there are no transaction logs on the side being backed up. This database is being used by our ERP, which is small in scale (maybe 7-9 users logged in at one time).

**On a side note, the lengthy backup time is causing the snapshot to hang around longer than 60 minutes per the Veeam ONE alarm we are receiving. The snapshot does eventually get purged. Lengthen alarm? Or indication of an issue?

We appreciate you taking a look at this and offering any advice to speed up/optimize this process – or confirming this is a normal amount of time.

Much appreciated and thanks!!

[veremin]

Would you mind providing additional information, such as:

- Is the processing speed the same in both cases (SQL VM, other VMs)
- What about amount of changes (processed, transferred metrics)? Aren’t those metrics noticeably bigger in case of SQL server?
- What component is identified as a major bottleneck in the job session statistics?
- What proxy server is being used in both cases?

Thanks.

[XpertEssentials]

Happy New Year, Vladimir. Thanks for responding!

I need some clarification on some of the questions you have so I can give you the proper information:

Is the processing speed the same in both cases (SQL VM, other VMs)

Do you mean the time it actually takes? Definitiely not. My 5 VMs not running SQL take about 5-10 minutes to complete in a differential cycle. The server running the SQL takes between 2-4 hours.

What about amount of changes (processed, transferred metrics)? Aren’t those metrics noticeably bigger in case of SQL server?

Forgive me, I'm not sure what you are asking here, or how to find this information for you. I understand that being a SQL server there are many changes that happen in a given day, but as I indicated, it is an Express install with a small amount of users. I know that may be subjective, but I guess, with my inexperience with SQL, I wouldn't expect it to be that big of a deal.

What component is identified as a major bottleneck in the job session statistics?

For that particular VM -- The source @ 72%

What proxy server is being used in both cases?

Not sure what you mean by "both" cases, but this VM job shows the physical server Veeam is installed on as being the proxy, although the job has access to 4 of the 5 VMs to uses as a hotadd proxy. The other VMs uses a combination of the physical server Veeam is installed on a VM on the host as a proxy. One thing I noticed -- The jobs that used a VM as a proxy indicated [san] and not [hotadd] as it did when v7 was installed. Not sure if this is an issue.

[XpertEssentials]

I'd like to bump this, please. I feel like there has to be something we are not optimizing here that should improve the process.

Is it the snapshot removal? 4 hours seems LONG for a 340GB VM of which only 1.5 GB is read and only 350MB is actually transferred.

I'm sure its something in my process, but would love some help identifying the issue. Should I open a ticket?

[NightBird]

High IOPS on backend storage during snapshot removal may be the issue.
If your VM (or some kind of VM) is doing high disk iops during snapshot removal or backup interval

[Gostev]

Note that snapshot removal is not managed by Veeam but rather ESXi host, so for that particular part best is to open a support case with VMware.