Subscribe
Accepted Solution

SnapManager for SQL SnapInfo sizing

Does anyone have any solid SMSQL snapinfo volume sizing guidelines? The SMSQL admin guide does a good job explaining sizing for the databases, logs but not good at all for sizing the snapinfo directory.

http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsmsql211/html/software/admin/plandat4.htm

Is there a formula that I can use for snapinfo? There's one for database and logs volumes but not for snapinfo. I find myself totally guessing what this number should be when doing snapmanager work for a client. How are we supposed to come up with an accurate snapinfo lun and volume size?

Any suggestions?

Cheers

Ian

Message was edited by: Ian Forbes

Re: SnapManager for SQL SnapInfo sizing

Ian,

SnapInfo is the streaming log repository used for the SnapManager function that is equivalent to SQL's BACKUP Log statements. It should hold the current tlog and all of the tlogs necessary to restore any point in time, going back to your oldest backup that was indicated with "retain up to the minute." This means that if you took hourly full backups A, B, and C--and tlog backups every 15 minutes, it would look like this: A 1 2 3 4, then B 5 6 7 8, then C 9 10 11 12. With this, if backup B was removed, you would still have the incrementals 1 through 12 in the SnapInfo folder to restore all the way back to A.

If I am just complicating the matter : ) please check out TR3431. Good formulas and examples.

I hope this helps.

Re: SnapManager for SQL SnapInfo sizing

Hi Mike. Thanks for the reply. What do A, B, C represent? Different backup sets? I plan on doing probably one full backup daily, replicating that to a secondary site and also doing hourly rolling log snapshots to secondary site (using sdscli scripting). I guess my question is more how do I walk into a customer site and accurately size the snapinfo lun and volume. There are formulas for database and log sizing but not for snapinfo. Even in that TR you gave me section 3.4.5 outlines volume sizing for everything other then snapinfo. Can you specifically point me to snapinfo quantitative sizing?

Re: SnapManager for SQL SnapInfo sizing

Ian,

The A, B, and C would be your full backups. In your scenario: if you did backup "C" last night at 12a, then 23 tlogs all day today--and your retention (this is the key) was set for 23 logs--then your tlog LUN would need to be sized for (23 x The Size of the Logs), with some headroom (as you know).

The SnapInfo sizing would be similar, except the SnapInfo LUN will keep this *and retain all logs* going back to your oldest full backup (in this case, "A" and in this case, therefore, about 75 logs). All these logs get retained when you choose "Retain Up to the Minute" in the backup configuration in SMSQL.

Re: SnapManager for SQL SnapInfo sizing

Mike - Another question would be does snapinfo need to have fractional space reserve at anything other then 0%? The database and log volumes I've set fractional reserve to 100% to ensure writes to those luns (overwrite protection). I don't think that this protection needs to be in-place for snapinfo, does it? If I calculate snapinfo to be 150GB (lun), can I make my volume a little bigger to account for snapshots of that lun? If I mount my backup snapshot it should contain the lun for my databases, logs AND the lun for snapinfo - so I suppose that snapmanager for sql backup protects the snapinfo directory as well. *all quite confusing*

The question is can I set fractional reserve for the volume housing my snapinfo lun to 0%?

Re: SnapManager for SQL SnapInfo sizing

Ian,

Allow me to gracefully bow out of having to think through your very logical question by just saying that, "it is NetApp best practices to leave it on" : )

I do know that if that volume runs out of space, bad things will happen.

Re: SnapManager for SQL SnapInfo sizing

Fair enough Smiley Happy Thanks for your feedback.

Re: SnapManager for SQL SnapInfo sizing

Mike - One last question about restore up to the minute capability. Let's say I decide to schedule fill sql backups nightly at 11pm only. If my database has been corrupted at 3PM and I wanted to restore it up to the minute I'd have to restore my last backup (which was 11pm the night before). At this point all of the transaction logs are still in the log lun/volume. They haven't been truncated because I haven't run a transaction log backup. Wouldn't snapmanager for sql be able to take those logs and play the restored database forward up to the minute?

When I backup up the database I didn't select 'retain up to the minute restore capability....', so, I wouldn't have backed up the logs - but according to my example above that shouldn't matter. The logs are still in the volume and should be available for replay. Is that correct?

Now, if I were to run a full backup followed by a transaction log backup that would truncate any committed logs, right? At that point newly uncommitted logs would start to accumulate in the logs volume. If I follow my example again and corruption occured at 3PM, I'd restore the 11pm full backup from the night before. Would I also have to rstore the transaction log backup? Lastly, there would be a bunch of logs that have accumulated since the last transaction log backup. Are they available for an up to the minute restore?

Hope that wasn't too confuisng Smiley Happy

Re: SnapManager for SQL SnapInfo sizing

I think I found my answer. It seems that when you perform a restore, a dialog box pops up and states that a transaction log backup before restore will take place. If snapmanager fails to perform a successful transaction log backup before restore the transactions that were logged after the most recent full database or transaction log backup will not be restored to the database, if an up to the minute restore was selected. Some data may be lost after the restore is completed.

So, a transaction log backup is attempted before a restore can happen (for up to the minute capability). I'm still confused as to why we're supposed to retain the logs if the restore process will back them up for us anyways.

Re: SnapManager for SQL SnapInfo sizing

Ian,

Yes you would be covered. But for clarification, "Up to the Minute" would not affect your current logs and your ability to use them for restore from the most recent backup, either way.

Consider our previous A, B, and C scenario: "Up to the minute" gives you the ability to have a retention (for example) of three nights' FULL backups and always have the transaction logs on hand to restore up to the minute for any time after A up to the current backup time--including any time in between, even if... (here's the difference) you *remove* the Full Backup "B". Because you will still have retained all of the logs that were written after A, and after B, and any that have happened since C, you will have all of the database transactions for the whole duration. If you removed Fulls B & C, and wanted to restore up to the minute, you would still have the baseline Full A to recover, then all of the logs to enable you to play back to the time of the most recent snapshot (full or incremental).

One more fyi, once Full A expires, all the logs between A and B would expire from the SnapInfo directory. Then you would have B, C, & D's logs. Once B expires, all logs between B and C drop off, and so on...

I hope this helping...