Database named "RollbackSnapshotTempDB" left after System Recovery 2013 backup

Hi, we have the same problem here.

Windows 2008R2 SP1 Standard, with SQL Server 2008 Standard with SP3:

Microsoft SQL Server Management Studio      10.0.5512.0
Microsoft Analysis Services Client Tools      10.0.5500.0
Microsoft Data Access Components (MDAC)      6.1.7601.17514
Microsoft MSXML      3.0 4.0 6.0
Microsoft Internet Explorer      9.10.9200.16635
Microsoft .NET Framework      2.0.50727.5472
Operating System      6.1.7601

Now we have BackupExec 2010 full updated to perform SQL backup and System Recovery 2013 (no VSS in use to void conflicts with BackupExec) for full server backup. "SystemRecovery 2013" jobs runs fine, with no errors. SQL creates a "RollbackSnapshotTempDB" databases for each run of BackupExec even and only for the same database. Backup's jobs doesn't overlap each other.

 To delete this db, you can take it offline before deleting.

We done a complete full database consistency check (DBCC CHECKDB) on that db with no errors but problem persists.

We done a SQL backup of that db, deleted it and restored it  but problem persists.

We disabled SystemRecovery 2013 schedules and the problem disappear, so this software should be the cause, maybe a VSS interference. With SystemRecovery2010 we had no problems.

You may be seeing this issue now, with SSR 2013, because we now use Microsoft VSS to take a snapshot.

With earlier versions of SSR/BESR, we had our own VSS provider to do this work.

I'm not saying this is a Microsoft issue but I would recommend one of you, if you can, open a case with Microsoft support so we can get their input on this.

While we are duplicating the problem, its not clear from the post that SSR 2013 SP1 is installed. Could you confirm it ? We have a VSS fix gone into this. If not, please install it and let us know if problem persists.

 LiveUpdate reported that no updates are available, I presume that SP1 is installed (version 11.0.1.47662).

 I've enabled the option "PERFORM FULL VSS BACKUP" in SSR 2013 and I'll run a job in this way in a few minutes but I think that this setting will cause the job will to fail with the following error "The Backup Exec SQL Agent was not used to create the last full, differential, or log backup of this database. You must use the SQL Agent to run a full backup before you can run a differential backup or transaction log backup."
 

Yes, that is SP1.

The 'Perform Full VSS Backup' option only applies to Exchange backups - it wont have any effect on SQL backups..

Done.

After performing a full VSS backup, SSR 2013 leave again a RollbackSnapshotTempDB. Following, the output of "VSSADMIN LIST WRITERS" (attached). Are all "stable" except for the following:

 Writer name: 'SqlServerWriter'
   Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
   Writer Instance Id: {f2902d58-a841-4700-8cc2-03c61207060a}
   State: [11] Failed
   Last error: Non-retryable error

In Windows EventLog we have the following errors:

1_ (EventID 24583, Source SQLWRITER):

Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000, Native Error: 3724
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: Cannot drop the database 'RollbackSnapshotTempDB{A80DC5F4-8004-4718-BCBC-AB66A9C66F08}' because it is being used for replication.
 

2_ (EventID 8229, Source VSS):

A VSS writer has rejected an event with error 0x800423f4, The writer experienced a non-transient error.  If the backup process is retried,
the error is likely to reoccur.
. Changes that the writer made to the writer components while handling the event will not be available to the requester. Check the event log for related events from the application hosting the VSS writer.

Operation:
   PostSnapshot Event

Context:
   Execution Context: Writer
   Writer Class Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
   Writer Name: SqlServerWriter
   Writer Instance Name: SQL Server 2008:SQLWriter
   Writer Instance ID: {f2902d58-a841-4700-8cc2-03c61207060a}
   Command Line: "C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe"
   Process ID: 3380

We have also the following entry in Windows "Application" EventLog (3 times before EventID 24583):

Starting up database 'RollbackSnapshotTempDB{A80DC5F4-8004-4718-BCBC-AB66A9C66F08}'.

CHECKDB for database 'RollbackSnapshotTempDB{A80DC5F4-8004-4718-BCBC-AB66A9C66F08}' finished without errors on 2013-07-17 09:10:29.477 (local time). This is an informational message only; no user action is required.

Setting database option RECOVERY to SIMPLE for database RollbackSnapshotTempDB{A80DC5F4-8004-4718-BCBC-AB66A9C66F08}.

Setting database option SINGLE_USER to ON for database RollbackSnapshotTempDB{A80DC5F4-8004-4718-BCBC-AB66A9C66F08}.

I think this is not exact... With SSR 2010 we uncheck this option due to the issue I've reported, as suggested from Symantec Support. Anyway, the problem persists.

So there looks to be some problem with the SQL VSS writer.

According to this (http://www.sqlcoffee.com/Troubleshooting116.htm), these temp DBs should be removed at the end of the backup process.

The fact that the SQL writer is failing makes me think that you need to contact Microsoft for help.

We (Symantec) can work with Microsoft if required but I think first port of call is MS support.

Let us know what MS have to say about this issue.

The problem on my server seems to be identical to SER-VIS. I have tried the SSR 2013 backup with and without the "Perform full VSS backup" box checked and it doesn't make a difference. We are also on SSR 2013 SP1, and after an SSR 2013 backup job completes the VSS writer "SqlServerWriter" shows a failed status with a non-retryable error. Restaring the "SQL Server VSS Writer" service clears the failed status. We do not have shadow copies enabled on any volumes.

I would like to work with Microsoft to get to the bottom of this but I have a lot of other projects that need my attention so my work around for now will be to disable SSR 2013 on this particular server and rely on Backup Exec 2010 to backup the entire server.

It seems to me that even if this does come down to being a problem with Microsofts VSS Writer, it's still to Syamtecs benefit to work directly with Microsoft to resolve this issue as it will make your customers happier and more likely to reccomend the product to others.