2013-05-22 03:31 AM
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 ?
SQL Server 2008 SP3
2013-05-28 09:00 PM
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.
2013-06-11 09:15 AM
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?
SQL 2008 R2 Ent. SP1
2013-06-11 09:31 AM
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
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.
From "Restore setting", enable "Ignore Logbackups from SMSQL repository
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
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
2013-06-11 10:26 AM
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.
2013-07-01 10:19 PM
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 !!!