Veeam and SQL - Connection Drop outs?

[jpierre]

Have a bit of a strange issue happening with Veeam.

We have a payroll system which utilises a SQL server which is replicated with Veeam 4.1.2 every hour (We are using vSphere 4.1 in source an destination).

During this replication users have been getting connection failures within their software and the times consistently match up with the replication.

Here is the Veeam summary for the job:

Code: Select all

11 of 11 files processed 

Total VM size: 144.00 GB
Processed size: 144.00 GB
Processing rate: 721 MB/s
Backup mode: NBD with changed block tracking
Start time: 7/10/2010 4:04:09 PM
End time: 7/10/2010 4:07:33 PM
Duration: 0:03:24

And I looked at the SQL log on the box and found the following:

Code: Select all

10/07/2010 16:04:56,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:56,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:56,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:56,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:56,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:55,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:52,Backup,Unknown,Database backed up. Database: PAYTestCo<c/> creation date(time): 2010/02/18(17:02:21)<c/> pages dumped: 20057<c/> first LSN: 20512:343:37<c/> last LSN: 20512:359:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{50828D89-FF9E-4959-9DB2-A3A1C184D96D}4'}). This is an informational message only. No user action is required.
10/07/2010 16:04:52,Backup,Unknown,Database backed up. Database: msdb<c/> creation date(time): 2008/07/09(16:46:27)<c/> pages dumped: 2981<c/> first LSN: 746:56:177<c/> last LSN: 746:136:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{50828D89-FF9E-4959-9DB2-A3A1C184D96D}2'}). This is an informational message only. No user action is required.
10/07/2010 16:04:52,Backup,Unknown,Database backed up. Database: Payroll<c/> creation date(time): 2010/02/18(18:26:27)<c/> pages dumped: 33017<c/> first LSN: 29853:57:1<c/> last LSN: 29853:59:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{50828D89-FF9E-4959-9DB2-A3A1C184D96D}3'}). This is an informational message only. No user action is required.
10/07/2010 16:04:52,Backup,Unknown,Database backed up. Database: model<c/> creation date(time): 2003/04/08(09:13:36)<c/> pages dumped: 186<c/> first LSN: 103:1448:37<c/> last LSN: 103:1472:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{50828D89-FF9E-4959-9DB2-A3A1C184D96D}1'}). This is an informational message only. No user action is required.
10/07/2010 16:04:52,Backup,Unknown,Database backed up. Database: master<c/> creation date(time): 2010/09/30(18:52:07)<c/> pages dumped: 379<c/> first LSN: 723:56:72<c/> last LSN: 723:96:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{50828D89-FF9E-4959-9DB2-A3A1C184D96D}5'}). This is an informational message only. No user action is required.
10/07/2010 16:04:51,spid59,Unknown,I/O was resumed on database model. No user action is required.
10/07/2010 16:04:51,spid60,Unknown,I/O was resumed on database msdb. No user action is required.
10/07/2010 16:04:51,spid61,Unknown,I/O was resumed on database Payroll. No user action is required.
10/07/2010 16:04:51,spid62,Unknown,I/O was resumed on database PAYTestCo. No user action is required.
10/07/2010 16:04:51,spid63,Unknown,I/O was resumed on database master. No user action is required.
10/07/2010 16:04:45,spid63,Unknown,I/O is frozen on database master. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
10/07/2010 16:04:45,spid62,Unknown,I/O is frozen on database PAYTestCo. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
10/07/2010 16:04:45,spid61,Unknown,I/O is frozen on database Payroll. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
10/07/2010 16:04:45,spid60,Unknown,I/O is frozen on database msdb. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
10/07/2010 16:04:45,spid59,Unknown,I/O is frozen on database model. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:43,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]
10/07/2010 16:04:35,Logon,Unknown,Login succeeded for user 'NT AUTHORITY\SYSTEM'. Connection made using Windows authentication. [CLIENT: <local machine>]

I am using Veeam with VSS but should it be doing a backup like this? I think the problem is more so when the snapshot is being consolidated than anything but just wondering if anyone else has had similar problems? Here is a screenshot of the VM's events


Thanks in advance!

[Alexey D.]

Hello Josh,

There might be two reasons leading to this situation. I guess your payroll system is a high-transaction server, and you also wrote that you were using VSS.
So this is an expected behavior because VSS writer needs time to commit data and thus ensure consistency of your backup.

The second reason, as you noted, could be snapshot consolidation. This topic tells more: Snapshot removal issues of a large VM.

Hope this helps!