Hitting the 255 snapshot limit on the snapinfo LUN

[sojdehei]

Hello

This is very urgent!   IHAC that is hitting the 255 snapshot limit on the SnapInfo LUN.  This is happening when we already set to delete snapinfo snapshots in excess of 8.  Is there another place else in SMSQL to set number of snapshots retained for snapinfo?  filerview scheduler is already turned off for snapshots on snapinfo volume.  It looks like SMSQL is ignoring "in access of 8" completely?  Thank you for your help!

- Mitchell

[abuchmann]

Marc, thank you for confirmation!

Kind regards,

Adrian

[martin_fisher]

Hi,

After reading this thread, just wondering if anyone got any success with the P2 release and if anyone has experienced this with the 64bit version.

Im currently using SMSQL 5.0.0.388 (SMSQL 5.0R1), SnapDrive 6.1, Windows Server 2008 std, with SQL Server 2008.

This issue appears every few days, as we are retaining (or wish to) 174 snapinfo snaps. However after 3 days, the snaps are not cleared and we experience the same issues previously mentioned in the thread.. The only consistent fact is this is affecting 2 systems, using the same software which are not directly connected. the build of both systems is identical.

Unfortunately it looks like this issue may/may not be fully resolved until a later release of SMSQL....

Thanks

[abuchmann]

No, I created a case because of that behaviour, but I didn't get a usable answer...

Our workaround is called snap autodelete 🙂 It's the hard way, but I don't need hundreds of snapinfo-snaps.

[marcconeley]

Hi guys,

This was a problem on earlier versions of SMSQL, but the SMSQL5.0R1P2_x86.exe fixed the problem for me.

I also have a Windows 2008 R2 64bit Server running SQL 2008 64bit and it's also working fine with SMSQL5.0R1P2_x64.exe.

If you don't need the the SnapInfo LUN to be snapped during a backup, you can disable this in the SMSQL Backup Settings (again, this didn't seem to work for me prior to the P2 release!).

As you can see below, I currently snap my snapinfo LUN after backup, but only keep 3 days worth of snapshots:

It was important I got this working because the alternative was to turn on "snap autodelete" on the filer, but then SMSQL doesn't know about it (you may end up in a situation whereby SMSQL thinks a snapshot exists that has actually been deleted by the filer). Therefore I believe it states in a best practice paper somewhere that you should let SMSQL handle the deleting of old snapshots.

I have to say, I spent many hours on this originally trying to solve it - but since the P2 release it's been working fine.

I have also tested doing backups with the above "create snap of snapinfo drive" disabled - and that also worked. But to be honest, as long as the snapinfo snapshots are being cleaned up properly, it's better to leave this enabled.

Finally, I am performing a 1 time daily full backup, and a every 30 min log file only backup - both of which are working fine and retaining the correct number of snapinfo snaps.

I would check that you're using the P2 version of SMSQL before you resort to turning on snap autodelete on the filer.

Marc

[martin_fisher]

Hi Guys

Thanks for the updates..and possible workarounds. Glad to know that the p2 release fixes the issue (x64 included), just need to scehedule some time to do it !.

looks like the problem/bug was also logged under another BugID.

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=352356

The solution, exactly as you guys have done, upgrade to P2.

Thanks Martin..

[nimalraj6]

Apologies for resurrecting this thread but this bug seems to have come back with SnapManager for SQL 5.1 - at least for me.

RetainSnapofSnapInfo is being ignored and snapinfo snaps are retained for as long as the full backup is retained for. I have a support call logged with NetApp and the support representative is telling me that this is by design and snapinfo snaps are required for every full backup snapshot I like to retain. This doesn’t make any sense to me and does not correlate with what I am reading on this thread.

I would appreciate if someone could explain if that really is the case.

Thanks,

Nimal

My original thread on this subject below... http://communities.netapp.com/message/54340#54340

[shannontuten]

We see the same behavior and are being told that it is by design.  I'm fine with the answer as long as they agree by poor design.  If you think about what is in the snapinfo directory, *all* data is there to do any restore for which you have the snaps on your dbs and tlogs *and* the tlog back ups to do a point in time restore are sitting there are trb files.  The only reason to snap snapinfo is to protect you from losing snapinfo.  I'm fine with keeping a few snaps of snapinfo for the "oh crap" I just destroyed the snapinfo directory, let me get it back -- but keeping it for my entire rentention period is insane.  If you crack open the oldest of your snapinfo snaps you'll find meta data for really old backups (twice your rentention) and tlog backups for however long you keep them.  So for us, we keep weekly fulls for 4 weeks, daily for a week and point in time for 3 days. By keeping snaps of snapinfo for 4 weeks they trap all the churn of our tlogs for each daily, then it rolls that churn into the weekly and then keeps it for 4 weeks.  On some systems this makes the snaps of snapinfo as much as 600 GB, on a snapinfo lun that is only 50 GB --- sad sad waste of space (since it buys you nothing).

[nimalraj6]

We have been using snapshot autodelete as a workaround on the snapinfo lun for some time now without any issues.

Thanks,

Nimal