Net app backup vs SQL backup
I have a question about SAN backup or volume level backup. We have hundreds of MS Sql databases. If we do volumes level SAN backup, we don' t need to do ms sql backup ( .bak), is this right statement?
Also, if we use NetApp to do backup, we don't need to setup mssql backup ( .bak), correct?
Also, if we use NetApp to do backup, we don't need to setup mssql backup ( .bak), correct?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I repeat: when using Netapp Snapmanager for SQL you don't need SQL backups.
I beg to differ with you. It really depends.
I beg to differ with you. It really depends.
It may well take a copy with great accuracy, but you still need SQL Server to run efficiently. So, SQL Server backups (log and data) help that process as well.
BUT... I think we are talking semantics here.
Sure, Netapp Snapmanager does provide cmdlets to do the backup/recovery processes. Which (to me) says it is still necessary for the health of a SQL environment to use the SQL backup/recover functionality built into SQL Server regardless of how it is invoked. And Netapp Snapmanager has accommodated that requirement by including some cmdlets to invoke the SQL processes on your behalf (but will need / can expect to do some config/setup).
Might well be a case of we agree but with different hats on, or a slightly different perspective on how to agree via knitpicking subtleties :)
It is not that you can forfeit one for the other, more like Snapmanager will supply the routines for you and can take on those extra jobs. So, having snapmanager doesn't mean you don't do SQL Server backups, but does mean it can do those (same) backups on your behalf.
BUT... I think we are talking semantics here.
Sure, Netapp Snapmanager does provide cmdlets to do the backup/recovery processes. Which (to me) says it is still necessary for the health of a SQL environment to use the SQL backup/recover functionality built into SQL Server regardless of how it is invoked. And Netapp Snapmanager has accommodated that requirement by including some cmdlets to invoke the SQL processes on your behalf (but will need / can expect to do some config/setup).
Might well be a case of we agree but with different hats on, or a slightly different perspective on how to agree via knitpicking subtleties :)
It is not that you can forfeit one for the other, more like Snapmanager will supply the routines for you and can take on those extra jobs. So, having snapmanager doesn't mean you don't do SQL Server backups, but does mean it can do those (same) backups on your behalf.
ASKER
Thank you for info. The argument is here. My backup team thinks using Netapp Snapmanager should be enough and no need to do traditional SQL backup (.bak, log...) for all production database. If we can now choose only one way or other. Should Netapp Snapmanager be able to handle all kinds of SQL database recovery situations? Should Netapp Snapmanager be able to handle disaster recovery for the company?
What Netapp Snapmanager cannot do for SQL database recovery?
More opinions needed
What Netapp Snapmanager cannot do for SQL database recovery?
More opinions needed
I have only played with Netapp Snapmanager and it does have all the routines that you would need.
It was pretty straight forward - especially if using some of their optimisation routines and facilities (like data ONTAP and SMSQL). Their own GUI interface is SMSQL which does make it easier to configure compared to "rolling you own".
But, I have not used in a production environment (just a review) and being old-school DBA, I always had my own suite of (SQL) tools which I could rely on and have always preferred trusting my own tried and proven set and so, never really focused on what Snapmanager fully offers...
So I guess that is the big question. If you are an established site, and have DR type policies in place, and have used or practised (maybe even in staged scenarios) then you are probably very much aware of what is needed. If you are quite happy and confident with those processes, then do you need to replace them ? Do you need to help justify a purchase decision for the backup team ? Or do you now need to look at (maybe) a more unified solution that accommodates new features that will help you.
Netapp is a MS gold partner so it is unlikely that they don't know or cant support their claims. But does it mean that your own DR plans are redundant ? I say not necessarily so long as you are confident with them.
If you don't have HA / DR with SLA's to deliver to, then it is probably worth a good look.
It was pretty straight forward - especially if using some of their optimisation routines and facilities (like data ONTAP and SMSQL). Their own GUI interface is SMSQL which does make it easier to configure compared to "rolling you own".
But, I have not used in a production environment (just a review) and being old-school DBA, I always had my own suite of (SQL) tools which I could rely on and have always preferred trusting my own tried and proven set and so, never really focused on what Snapmanager fully offers...
So I guess that is the big question. If you are an established site, and have DR type policies in place, and have used or practised (maybe even in staged scenarios) then you are probably very much aware of what is needed. If you are quite happy and confident with those processes, then do you need to replace them ? Do you need to help justify a purchase decision for the backup team ? Or do you now need to look at (maybe) a more unified solution that accommodates new features that will help you.
Netapp is a MS gold partner so it is unlikely that they don't know or cant support their claims. But does it mean that your own DR plans are redundant ? I say not necessarily so long as you are confident with them.
If you don't have HA / DR with SLA's to deliver to, then it is probably worth a good look.
My backup team thinks using Netapp Snapmanager should be enough and no need to do traditional SQL backup (.bak, log...) for all production database.
Great! Get them to put that in writing. Especially the part where you have to restore a backup to a new database and the backup is an archive copy from 2 years ago,
Great! Get them to put that in writing. Especially the part where you have to restore a backup to a new database and the backup is an archive copy from 2 years ago,
Test it out, scenario an errand transaction occurred three hours ago.
Go through snapmanager similar to Anthony's suggestion and restore the DB on a test system. There have been occurances where backup was "setup" but when needed were non functional .......
It is always good to test out your restore to make sure it works. Presumably you include the export of logins with their sids.
The dedicated backup is likely in two parts application level as well as file system.
Having a local backup copy speeds up recovery in an emergency.
The local is also being backed up via the filesystem backup......
Go through snapmanager similar to Anthony's suggestion and restore the DB on a test system. There have been occurances where backup was "setup" but when needed were non functional .......
It is always good to test out your restore to make sure it works. Presumably you include the export of logins with their sids.
The dedicated backup is likely in two parts application level as well as file system.
Having a local backup copy speeds up recovery in an emergency.
The local is also being backed up via the filesystem backup......
Using NetApp SnapManager for SQL Server should be enough. It has all SQL Server backup & restore features plus some more (cloning a database from Production to dev and test environments, for example).
If it's already pay that use it. If not, then it's only a matter for management decision to spend or not spend the necessary money.
If it's already pay that use it. If not, then it's only a matter for management decision to spend or not spend the necessary money.
Using NetApp SnapManager for SQL Server should be enough.
How do we know? The author has not told us (perhaps they simply do not know) what are their requirements, For example, would it be necessary to do point-in-time restores? Do they have the expertise in house to do that with NetApp's SnapManager? Would they ever have to restore old archive backups from say two years ago? What are the chances you would keep a snapshot that long and perhaps more relevant that it is usable.. Last time I checked you could only keep 255 snapshots. Is that going to be a problem?
Again, without knowing the answers to those question we cannot give an answer that has any value whatsoever. Further the author has to provide some feedback as to what they have really tested. Call me a cynic, but I suspect nothing has been tried and they are just on a fishing expedition
How do we know? The author has not told us (perhaps they simply do not know) what are their requirements, For example, would it be necessary to do point-in-time restores? Do they have the expertise in house to do that with NetApp's SnapManager? Would they ever have to restore old archive backups from say two years ago? What are the chances you would keep a snapshot that long and perhaps more relevant that it is usable.. Last time I checked you could only keep 255 snapshots. Is that going to be a problem?
Again, without knowing the answers to those question we cannot give an answer that has any value whatsoever. Further the author has to provide some feedback as to what they have really tested. Call me a cynic, but I suspect nothing has been tried and they are just on a fishing expedition
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Snapmanager takes a SAN based snapshot backup and also completes the necessary housekeeping routines for database health.
So the remarks given above may be correct for a general SAN, in a Netapp context things are a bit more advanced provided you use snapmanager.