Hi
We have a client who we have recently deployed VEEAM for, they were previously using ShadowProtect.
They are using SQL server on the backend and a customised VB6 application on the front end as their main corporate app.
Because VB6 isn't VSS aware, it expects fulltime connectivity to the SQL server and when VEEAM snaps the backup of the SQL server it throws all sorts of errors into their application.
Short of asking them to re-write their application, does anyone have any tips on either
a) best practices for backing up a SQL server in general
b) reducing the 'snap' time on the SQL server so that we can get this done without causing issues
Because ShadowProtect just did an in Windows VSS freeze it only took 1-2 seconds which wasn't enough to cause a problem, but VEEAM seems to be taking 8-10 seconds to do a similar task (at the Hypervisor level) so is affecting their application.
Any assistance would be appreciated.
Cheers
Rob
-
- Lurker
- Posts: 1
- Liked: never
- Joined: Apr 14, 2014 2:55 am
- Full Name: Rob Pickering
-
- Veeam Software
- Posts: 21163
- Liked: 2148 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: VEEAM, SQL Backup and VB6 application
Hi, Rob. Here's a good topic containing some useful links regarding SQL server backup best practices, please review.
As for the snapshot time, as you might know, Veeam B&R does not perform snapshot operation by itself but rather calls the corresponding vSphere API to do that, so the issue is on hypervisor level, indeed (you can take the snapshot of the VM manually via vSphere client and compare the times to confirm that). Here's a huge topic that contain several recommendations that might allow to decrease time VM performs on snapshot and its commit time (enabling parallel processing is among them).
That said, I must admit that 8-10 seconds for the SQL snapshot is actually not that bad and I don't think it could be significantly decreased.
As for the snapshot time, as you might know, Veeam B&R does not perform snapshot operation by itself but rather calls the corresponding vSphere API to do that, so the issue is on hypervisor level, indeed (you can take the snapshot of the VM manually via vSphere client and compare the times to confirm that). Here's a huge topic that contain several recommendations that might allow to decrease time VM performs on snapshot and its commit time (enabling parallel processing is among them).
That said, I must admit that 8-10 seconds for the SQL snapshot is actually not that bad and I don't think it could be significantly decreased.
Who is online
Users browsing this forum: Baidu [Spider], Bing [Bot], deivin.chaconvindas, Semrush [Bot] and 93 guests