netap snap manager for exchange

[sawyer]

Hello

I am running Exchange 2007 sp2, I have only one mailbox server, the servers
storage is located on a netapp filer, and we use snap manger for exchange to
take one snap shot a day of the database. I understand that if just take a
snapshot of the database, and do not backup the log files, then this
snapshot backup is a "point in time backup" meaning that if I needed to do a
restore from this backup, that I could only restore to the point when the
snapshot backup was taken. I am having a hard time understanding why this is
true, because if I still have all the log files that were created after the
snapshot was taken, then I should be able to restore the database from the
snapshot and then roll the log files forward, but the documentation in the
admin guide for snap manager for exchange doesn't appear to allow for this.
It appears that I either have to take a frequent recovery point backup or I
need to backup the transaction logs when I do a snapshot backup. Niether
option is one that I want to use, as both options take up more storage space
on the volume.

Can someone please confirm this is correct?

Thanks

[Mark Arnold [MVP]]

On Mon, 23 Nov 2009 10:16:56 -0800, "sawyer" <occo...@cox.net>
wrote:

I am stunned that your NetApp SE hasn't asked me this question and had
me respond to you :)

Doing one database snapshot a day is one thing. The point-in-time part
is a function of how many times a day you do FRPs(frequent recovery
points) on the transaction log volumes. If you only do once a day then
you can either recover to the point of the last backup or you can
recover to the point of failure, nowhere in between. That's the same
with every backup.

You don't quite understand the logs part of the deal though. If you do
(say) hourly FRPs on the logs you do have to have an extra day's worth
of space in the volume (but not in the LUN) because you are doing
snaps of the volume. If you do a SME database backup at (say) midnight
and then experience a failure at 8am you are able to roll forward to
any hour you wish. SME will replace the 8am volume with (say) the 6am
volume and you'll be back up and running to 6am. You will lose two
hours of email.

Actually you won't lose two hours of email because you will have done
an emergency snap of the 8am volume at the time you failed and can
then FlexClone that and get the 'lost' two hours of email out to PST
and into the store, maybe not even with PST files if you're using
SMBR.

Who's your SE? Cox. Atlanta GA? If you want you can contact me
directly at marnold at netapp dot com, or via your SE if you wish.

[sawyer]

I guess I still don't get this.

If I do one snapshot backup a day, and with this as you have described I can
restore to the point of failure or I can restore to point of the last know
good backup, and I agree this is the same procedure with any exchange aware
backup, and one that I am familiar with. If this is true, then this is all I
would need, as long as I can restore to the point of failure then this
works.

Example

corruption in the database occurs Monday at 8 am, the last backup was taken
at Monday at 6am, then I should be able to restore the backup taken at 6am
using snapmanger for exchange, and then roll all the logs files forward that
were created between 6 and 8. Shouldn't this restore get me to the point of
failure? If this is correct, then what is the significant importance of
FRP's? As long as I have all the logs files from that were created since the
last full backup, and the backup is verified and good, then I still don't
see the point in creating FRP's?

thanks

"Mark Arnold [MVP]" <ma...@mvps.org> wrote in message
news:v4slg55d512tt3p8a...@4ax.com...

[Mark Arnold [MVP]]

On Mon, 23 Nov 2009 13:05:44 -0800, "sawyer" <occo...@cox.net>
wrote:

>I guess I still don't get this.
>
>If I do one snapshot backup a day, and with this as you have described I can
>restore to the point of failure or I can restore to point of the last know
>good backup, and I agree this is the same procedure with any exchange aware
>backup, and one that I am familiar with. If this is true, then this is all I
>would need, as long as I can restore to the point of failure then this
>works.
>

So far so good.

>Example
>
>corruption in the database occurs Monday at 8 am, the last backup was taken
>at Monday at 6am, then I should be able to restore the backup taken at 6am
>using snapmanger for exchange, and then roll all the logs files forward that
>were created between 6 and 8. Shouldn't this restore get me to the point of
>failure?

Yes and that's perfectly normal and again, what you'd expect from any
application.

> If this is correct, then what is the significant importance of
>FRP's? As long as I have all the logs files from that were created since the
>last full backup, and the backup is verified and good, then I still don't
>see the point in creating FRP's?
>
>thanks

NetApp have lots, and I mean lots, of customers using FRPs. One thing
that it enables them to do is to restore (in your example) up to the
point of 7am rather than 8am and if they do FRPs every five minutes
(you'd be amazed at how many do) they can restore to 7:25 if they
want. Another benefit is that it allows the Exchange people to control
the RPO in SnapMirror situations. It's safer to do an FRP and then a
SnapMirror than simply do a volume snap from the controller and then a
SnapMirror. Remember it's all about the logs. You can replicate the
database once or twice a day and then replicate the logs every few
minutes, or hour or whatever the RPO is.
Here's something else. What is a colleague of yours did something
really dumb like delete a load of logs and you had a failure of a
store (yeah, rare but it's happened). What would you do? You'd snap
the logs back to the FRP five minutes earlier to get everything back.

[sawyer]

"What is a colleague of yours did something
really dumb like delete a load of logs and you had a failure of a
store (yeah, rare but it's happened). What would you do? You'd snap
the logs back to the FRP five minutes earlier to get everything back."

Ok I can see the value with this type of scenario.

Also do the snapshot backups get stored on the transaction log lun? it
appears as if they do. If I start doing FRP's would these log files get
stored on the transaction log lun or the database lun? and if I start doing
frp's do I need to worry about adequate disk space on the volume the holds
the database lun, or just the volume that holds the logs lun?

Many thanks

"Mark Arnold [MVP]" <ma...@mvps.org> wrote in message

news:iuulg51cd57a4ftgv...@4ax.com...

[Mark Arnold [MVP]]

On Mon, 23 Nov 2009 14:15:14 -0800, "sawyer" <occo...@cox.net>
wrote:

>"What is a colleague of yours did something
>really dumb like delete a load of logs and you had a failure of a
>store (yeah, rare but it's happened). What would you do? You'd snap
>the logs back to the FRP five minutes earlier to get everything back."
>
>Ok I can see the value with this type of scenario.
>
>Also do the snapshot backups get stored on the transaction log lun? it
>appears as if they do. If I start doing FRP's would these log files get
>stored on the transaction log lun or the database lun? and if I start doing
>frp's do I need to worry about adequate disk space on the volume the holds
>the database lun, or just the volume that holds the logs lun?
>
>Many thanks
>
>

They aren't stored 'on' the LUN. The thing that gets snapped is the
volume. You don't actually need that much more space because the sum
of 24 hourly snaps is only the same as one 24 hourly snap. You are
increasing the level of protection.

Now, if you don't know the difference between a LUN and a Volume we
need to take this offline and get you on a call with either me, your
NetApp SE or even your own storage people.

[sawyer]

I do understand the difference between a lun and a volume. Luns get carved
out or created from volumes

"Mark Arnold [MVP]" <ma...@mvps.org> wrote in message

news:9o2mg5ddclrj8ear3...@4ax.com...

[Mark Arnold [MVP]]

Good, so then you are now in good shape about not needing to assign
much extra space to the LUN and make sure that you have sufficient
space in the volume. Make sure your storage people are either using a
percentage Fractional Reserve (100% is too much) or are using 7.3 with
volume autogrow and snapshot autodelete and specify the try_first that
suits your business requirement.

Then you're good to go.