SnapManager SQL not showing transaction log backups in restore wizard

[SEVECHR]

Hi,

i'm faced with a problem concerning restore functionalities in snapmanager sql.
Most of my sql databases run with "full recovery" model.

In snapmanager i created jobs for backing up these databases, one for full backups, another for regular transaction log backups.

The backups are doing fine. In snapinfo you can see the *.DMP files as well as the *.TRB backup files.

When i now try to restore those databases via snapmanager restore (wizard), for some of them "No Log Backups" are shown.

Does anyone perhaps know this problem / issue and can give me some advice ?

Versions:

SQL Server 2008 SP3

SnapDrive 6.5

Snapmanager 6.0

[welch]

I would suggest trying a couple things.  First, make sure that you do not have another process dumping transaction logs or doing SQL backups other than SMSQL.  This can cause an interruption in the LSN numbers and make SMSQL unable to replay logs.  Second,creating a clone of one of the offending databases using SMSQL and bring the database up into standby mode.  Now try using SQL and manually play the .TRB files like you would a normal .TRN file against the database.  This process should validate that the logs are in fact there and good. 

Also, are you using a CIFS share for your T-LOG dumps, or are you using the SnapInfo directory?

Please post back and let us know if either of these fixed your issue.

[gunthermontez]

I'm having the same issue as Christian with almost the same setup: jobs alternate every hour between a full snapshot (with log backup) and a log-only backup. All the log backup files are stored in a snapinfo directory, and I see one for each hour. Since this issue only affects some of our databases and not all of them, I was able to make an educated guess that this issue probably started when someone manually deleted several .TRB files when the snapinfo LUN was almost full, and so there probably was a broken log chain at some point.

I tried the scenario you suggested and cloned one of the problem databases with a snapshot from 7am this morning. Then, using the log backups in the snapinfo directory, I manually restored the 7am log backup followed by the 8am log backup, both worked fine with no issues.

I know that a regular SQL full backup will reset the log chain, I'm guessing that a SnapManager full snapshot doesn't do the same? Would creating a SQL full backup solve the issue with SnapManager not recognizing any successive log backups?

Versions:

SQL 2008 R2 Ent. SP1

SnapDrive 6.4.2

SnapManager 6.0.0.1170

[qzhang]

This is an issue in SMSQL 6.0, the bug number is 665306. There is a workaround, and I think the problem is also fixed in 6.0.1. For the quick workaround, here I quote:

%%% TITLE: SnapManager for SQL Server (SMSQL) shows 0 transaction log backups available to be restored, although log backups are available

%%% DESCRIPTION:

During a restore process using the SnapManager for SQL Server GUI, several databases display 0

Transaction Logs, even though the logs have been backed up and are visible in the snapinfo

directory. Because there are no log backup copies shown as available to be restored, no up-to-the minute

or specific point-in-time restore operation can be performed.

%%% WORKAROUND:

From "Restore setting", enable "Ignore Logbackups from SMSQL repository

share" option.

%%% NOTES:

SMSQL 6.0 introduced SMSQL repository share, where the log backups can

be copied to a share and those log backups can be used by a different

system. This feature is mainly for SQL Server 2012 Availability Group

database gapless restore functionality to allow up to minute restore

on any node of a cluster.

This option will only search for log backups located on the local snapinfo

directory and ignores log backups in the share when trying to enumerate

log backups.

If you are not using SQL Server 2012 AG (or you do not use SMSQL

repository share), there are no side effects in using the workaround

suggested.

Thanks,

-Qing

[gunthermontez]

Thanks for the info, I can confirm that the workaround works for me (although I should also look into getting the updates installed). Hopefully the original poster will mark this as answered.

[SEVECHR]

Hi,

the workaround worked for me too ! I'll update my installations of snapmanager to the current version soon.
Thank you very much for your help !!!