-
- Enthusiast
- Posts: 35
- Liked: 4 times
- Joined: Jan 24, 2014 11:31 pm
- Full Name: Brian Killigrew
- Contact:
Latest Patch broke transaction log truncation
We have a case open for this, 00728221, but wanted to see if anyone else is seeing this. We are on Version 8, patch 1.
In the documentation for using application aware processing on SQL, there is nowhere that states that the guest account (svc.veeam in our case) has to have any kind of special rights inside SQL whatsoever. I am under the impression that the network service or NT Authority\System account handles that on the SQL side via VSS.
On some of our SQL servers, that account, does in fact have a login and role in SQL, and everything is working on them just fine, even after patch. On the ones that don't, the backup portion still works, but the Log backup/truncation does not.
Here's the day before I applied the patch, and as you can see, the login error for svc.veeam still exists, however both backup of DB and Logs happen just fine.
Here's the day after, and as you can see, the login error for svc.veeam still exists, however ONLY the backup of the DB happens.
What in the code changed that would make it a requirement for this account to have this kind of access, and why did/does it work for the db backup just fine even after giving the same message?
In the documentation for using application aware processing on SQL, there is nowhere that states that the guest account (svc.veeam in our case) has to have any kind of special rights inside SQL whatsoever. I am under the impression that the network service or NT Authority\System account handles that on the SQL side via VSS.
On some of our SQL servers, that account, does in fact have a login and role in SQL, and everything is working on them just fine, even after patch. On the ones that don't, the backup portion still works, but the Log backup/truncation does not.
Here's the day before I applied the patch, and as you can see, the login error for svc.veeam still exists, however both backup of DB and Logs happen just fine.
Here's the day after, and as you can see, the login error for svc.veeam still exists, however ONLY the backup of the DB happens.
What in the code changed that would make it a requirement for this account to have this kind of access, and why did/does it work for the db backup just fine even after giving the same message?
-
- Enthusiast
- Posts: 35
- Liked: 4 times
- Joined: Jan 24, 2014 11:31 pm
- Full Name: Brian Killigrew
- Contact:
Re: Latest Patch broke transaction log truncation
Also, I should add....yes, application aware processing is still enabled on these jobs, yes truncate SQL is still checked, and yes NT Authority\System has the correct rights in SQL on 2012 servers.
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Latest Patch broke transaction log truncation
Can you verify if applying these permissions help in your situation?
-
- Enthusiast
- Posts: 35
- Liked: 4 times
- Joined: Jan 24, 2014 11:31 pm
- Full Name: Brian Killigrew
- Contact:
Re: Latest Patch broke transaction log truncation
I'm 100% sure that would work, as a couple of our instances that are being truncated, have the guest account as a sysadmin (god rights in SQL). My concern is, what changed during this update to require this, when before it was not a requirement. I also think if this is a requirement now, there should be some better documentation as to what is needed SQL permission wise for the OS guest account...
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Latest Patch broke transaction log truncation
Let me find out the difference between how SQL Server backup was handled in the previous version and in the latest patch. I will let you know once I hear more details from the devs.
-
- Enthusiast
- Posts: 35
- Liked: 4 times
- Joined: Jan 24, 2014 11:31 pm
- Full Name: Brian Killigrew
- Contact:
Re: Latest Patch broke transaction log truncation
Vitality, Just as an FYI, I did make the permissions changes, and truncation started working again as I suspected. That being said, it appears that something definitely changed...just not sure what.
-
- Enthusiast
- Posts: 64
- Liked: 12 times
- Joined: Jan 08, 2013 6:14 pm
- Full Name: José Ignacio Martín Jiménez
- Location: Madrid, Spain
- Contact:
Re: Latest Patch broke transaction log truncation
Same issue here. Solved with the above in bold.briguyiu wrote:I'm 100% sure that would work, as a couple of our instances that are being truncated, have the guest account as a sysadmin (god rights in SQL). My concern is, what changed during this update to require this, when before it was not a requirement. I also think if this is a requirement now, there should be some better documentation as to what is needed SQL permission wise for the OS guest account...
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Latest Patch broke transaction log truncation
Yes, sorry for the late reply, but we've been discussing this behavior with the devs and found out the reason for this change.
Basically, there are three main reasons for that:
1. New Explorers functionality required extra permissions on the database
2. Starting from SQL Server 2012 BUILTIN\administrators and Local System (NT AUTHORITY\SYSTEM) are not automatically provisioned in the sysadmin fixed server role
3. NT Authority\System account was used to handle logs truncation in v7
In the next minor update we will bring previous method of logs handling, and if it fails (due to insufficient permissions on the SQL Server 2012 and above), we will use the account specified in the AAIP option.
Thanks guys for bringing this to our attention.
Basically, there are three main reasons for that:
1. New Explorers functionality required extra permissions on the database
2. Starting from SQL Server 2012 BUILTIN\administrators and Local System (NT AUTHORITY\SYSTEM) are not automatically provisioned in the sysadmin fixed server role
3. NT Authority\System account was used to handle logs truncation in v7
In the next minor update we will bring previous method of logs handling, and if it fails (due to insufficient permissions on the SQL Server 2012 and above), we will use the account specified in the AAIP option.
Thanks guys for bringing this to our attention.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Latest Patch broke transaction log truncation
Just to follow up, what Vitaly has described was included in 8.0 Update 2. Thanks!
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Jul 10, 2015 3:39 pm
- Full Name: Izudin Dizdarevic
- Contact:
Re: Latest Patch broke transaction log truncation
Just started getting SQL warnings after an update to 8.0 with the Update 2 applied.
Any help would be appreciated.
Thank you!
Any help would be appreciated.
Thank you!
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Latest Patch broke transaction log truncation
Izudin, please review this thread for details.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Jul 10, 2015 3:39 pm
- Full Name: Izudin Dizdarevic
- Contact:
Re: Latest Patch broke transaction log truncation
Thank you Foggy!
I appreciate the help.
I appreciate the help.
Who is online
Users browsing this forum: No registered users and 48 guests