07-17-2014 08:05 AM
Hi, we're trying to backup an SQL server using V-Ray technology and Vmware Accelerator. We can successfully backup SQL server with "Truncate Logs" option unchecked, but when we try to truncate logs, it gives below warnings.
We have uninstalled Vmware VSS Provider and installed Symantec VSS Provider, so it's not the problem.
We also tried a full VM backup (tried with both "SQL recovery" checked and unchecked) before checking "Truncate logs" option, as written inside this article:
http://www.symantec.com/business/support/index?page=content&id=TECH190421
We installed a new sql server with a new database, and that vm did not have the same issue. What can we do? Should we first backup using the traditional SQL agent backup and then without having any transaction backups try a V-Ray backup with "Truncate Logs" checked?
Thanks.
7/17/2014 3:53:23 PM - Info nbjm(pid=9704) starting backup job (jobid=974915) for client DBSERVER.domain.local, policy V-Ray_SQLDB, schedule Full
7/17/2014 3:53:23 PM - Info nbjm(pid=9704) requesting MEDIA_SERVER_ONLY resources from RB for backup job (jobid=974915, request id:{AA32FA43-26EE-44FE-867E-81C5A0204400})
7/17/2014 3:53:23 PM - requesting resource PD-STU01
7/17/2014 3:53:23 PM - requesting resource BACKUPSERVER.NBU_CLIENT.MAXJOBS.DBSERVER.domain.local
7/17/2014 3:53:23 PM - granted resource BACKUPSERVER.NBU_CLIENT.MAXJOBS.DBSERVER.domain.local
7/17/2014 3:53:23 PM - estimated 0 Kbytes needed
7/17/2014 3:53:23 PM - begin Parent Job
7/17/2014 3:53:23 PM - begin Application State Capture, Step By Condition
Status 0
7/17/2014 3:53:23 PM - end Application State Capture, Step By Condition; elapsed time: 0:00:00
7/17/2014 3:53:23 PM - begin Application State Capture, Application State Capture
7/17/2014 3:53:27 PM - Warning ascc(pid=4312) MSSQL: Log truncation failed for database : DB1
7/17/2014 3:53:27 PM - Warning ascc(pid=4312) MSSQL: Log truncation failed for database : DB2
7/17/2014 3:53:27 PM - Warning ascc(pid=4312) MSSQL: Log truncation failed for database : DB3
7/17/2014 3:53:28 PM - Warning ascc(pid=4312) MSSQL: MSSQL application state capture was partially successful
Status 1
7/17/2014 3:53:28 PM - end Application State Capture, Application State Capture; elapsed time: 0:00:05
Status 1
7/17/2014 3:53:28 PM - end Parent Job; elapsed time: 0:00:05
the requested operation was partially successful(1)
The job was successfully completed, but some files may have been
busy or inaccessible. See the problems report or the client's logs for more details.
07-17-2014 04:37 PM
What type of recovery model these DBs are configured with?
Simple? If so transaction logs can not be trancated as transaction logs in simple model is truncated automatically inside SQL server in short period - truncate operation is not supported at SQL Server side.
07-18-2014 01:56 AM
Hi Yasuhisa, they're all Full and we're still having the same issue...
07-23-2014 04:27 PM
Have you ever taken full backup of this VM without log truncation? If not, please try after taking full VM backup that does not have "Truncate Logs" option.
07-24-2014 10:46 AM
M,
I ran into a similar issue, where the root cause was that the database had never recieved a Full backup by any method, and the solution was to perform a Full backup outside of NetBackup VMware prior to the VMware SQL backup. I my case I performed the initial Full backup through the Netbackup SQL agent, but could have done it through SQL Server SSMS management console.
Once the initial Full was performed, then the VMware SQL log truncation would succeed.
To see if you have this issue, check under Event Viewer's "Administrative Events" for a Backup Exec error event (even though this is Netbackup) at the time of the ASC log trunc'ing failure, and look for this text embedded under the General tab...
"1076
BACKUP LOG cannot be performed because there is no current database backup."
(see attached)
Ken W
09-19-2014 06:24 AM
I've tried all combinations of the above talked about, but the results did not change, the problem still continues.
09-20-2014 05:30 AM
So, these backups have been failing for about 2 months now?
Have you logged a Support call yet?
09-22-2014 04:17 AM
Despite the mistakes that I can do restore. I restored all database and also I restored a single database.
So, I did not want to support from Symantec.