June 18, 2013 at 2:33 pm
-Disclosure NetApp Employee-
To paraphrase Mark Twain, "The rumours of the death of snapmanager, have been greatly exaggerated".
While NetApp works very closely with CommVault and OEM portions of their technology for our SnapProtect product, NetApp continues to make significant investments in the development of all of our Snapmanagers, including SnapManager for SQL Server.
The audience/usecase focus for Snapmanagers and SnapProtect are slightly different, and while this isnt the place for a full explanation, generally SnapProtect is developed with Backup Administrators as it's primary audience, and includes full tracking of a backup workflow all the way to tape. SnapManagers on the other hand are developed with Database administrators as its primary audience and includes D/R workflows.
There's a lot more to it than that, and I'd be happy to contribute more to this thread, or help start another one if anybody wants a more detailed breakdown on the usecases. It's worth noting, that these products, and the alliance relationships we have with IBM and Symantec all form part of a larger Integrated Data Protection (IDP), program, and if you're interested you should be able to get a full briefing from one of NetApp's data protection focusses consuting systems engineers.
The latest Snapmanager for Windows have just gone into Beta, and there is a strong roadmap for future releases.
More information on SnapProtect can be found here - http://www.netapp.com/au/products/protection-software/snapprotect.aspx
Regards
John Martin
Principal Technologist - NetApp ANZ
@johnmartinit
June 18, 2013 at 3:17 pm
John - Thank you for taking the time to update the thread with this information. I personally appreciate vendors input on this site and appreciate you providing correction in regards to the CV / NetApp relationship. My apologies in the misrepresentation that I shared.
I'll definitely check out the link you shared and if you have other information pertinent to this thread, please feel free to share.
Thanks again.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
June 18, 2013 at 6:35 pm
David,
no apologies are necessary, our data protection strategy does look confusing from the outside and I think we could do a better job of explaining it to avoid the confusion.
There are some really interesting longer-term developments in infrastructure automation where we expect applications like SQL server to make requests for storage resources independently of the storage admin or DBA.
Imagine if the database, based on the code of a stored procedure, was able to provide hints or explicit instructions to the storage layer about which parts of the database are about to become hot, and then the storage array was able to proactively move indexes, columns etc into solid-state storage close to the CPU of the database engine. NetApp does a pretty good job of that today by dynamically recognizing workload patterns in real time and making intelligent guesses about what will be asked for next, but it could be a lot more efficient/aggressive with the right kind of supporting information. In order to do that there needs to be something that understands the layout of both the database, and the supporting storage resources.
I'm not saying that this is a feature of an upcoming SnapManager release, but it's this kind of thing that means we will invest in storage and data management software like SnapManager for SQL for the foreseeable future.
Regards
John Martin
January 28, 2014 at 6:32 pm
I've been using SnapManager for the last year after inheriting it with the job. It works great ... when it works. SnapDrive is a moderately unstable dependancy of SnapManager, and we seem to lose a SnapDrive installation at least weekly across 120 or so servers. A repair installation is then required, and it all comes back just peachy-keen. Also, SnapDrive has a 2 TB limitation on the backing volume for any LUN. This limitation thankfully went away with SnapDrive 6.5, however came back once we upgraded vSphere to version 5.1. Some form of interoperability issue. It has killed our ability to use NetApp Snap products to clone or restore our most critical databases. The folks at vSphere indicate this is fixed in vCenter 5.5, but it's an upgrade we're likely to be studying for another month or more, wondering what else will bite us.
We use SnapManager as part of a 5 tier backup/recovery system. When it works, it's fast and efficient and usually the first method of recovery we attempt. However we cover our other bases as well, by also taking traditional full backups + differentials and frequent t-log backups. We also use NetApps to mirror our data drives and t-log backups to a remote data center, as well as snapshotting our RDM volumes datastores frequently and snapshotting our vmdks datastores in vSphere frequently. Finally, we push the traditional backups to tape nightly, and ship them to the bank. We have discovered corrupted snapshots when testing our SnapManager backups, and had to fail to other recovery tiers before. Frankly, I would not put all my eggs in any single basket, as each of the methods I've detailed above have failed at one time or another. I suppose my point is, SnapManger is not a replacement for traditional backups or DR methods, but can be used to augment them, providing a fast and efficient path to recovery ... when it works.
March 18, 2014 at 7:34 am
We have been using SMSQL for several years but find it a flaky backup agent - for example if a database is added or removed, or is changed from full to simple mode, theSMSQL snap backup simply fails. The only way to change the job is edit via SQL or delete the job within SMSQl and recreate. Netapp support is weak on resolving our issues
Previously we used EMC Networker SQL agent and this worked - regardless of whether databases had been deleted or amended in any way
July 7, 2014 at 4:44 pm
I've been using NetApp SnapManager for SQL for almost 2 years now. Like all snapshot technologies, it is quick, handy and useful when it works, but should not become your only solution for backups and restores. We have experienced around a 10% failure rate on our largest databases. (3-5 TB) The configuration tool is woefully inadequate and counterintuitive, and must be run anytime there's a change in drive structure or database structure (adding more .ndf files, etc) Not sure why NetApp hasn't simply built in an automated system to query the master and msdb databases for this info. I would say the interface itself shouldn't be used to manage more than 10 servers at once, so I have broken our servers into different divisions as well as functional groups. (Dev, Test, Prod) and manage each group from a different control server. This works well. Attempting to manage all 100+ servers from one interface would be madness.
We use clones a lot for testing and validation, they are very handy but be cautious with them. They contain actual live data, and must be secured accordingly. The PowerShell cmdlets that allow for automation of cloning do not include options for selecting several vital pieces of information, such as the connector, used to mount the drives. Instead, they default to the first connector in a list stored somewhere in NetApps. If a server ends up with clone drives attached that use a Fiber Channel connector, rather than an iSCSI connector, the server will die if it's controller dies, rather than vMotion to another controller. This negates the DR/BC functionality that makes NetApp so peachy-keen. This is because FC is host-dependant, whereas iSCSI can be "grouped" in igroups managed by multiple host machines. Hence we manually mount clones (until this is fixed by NetApp) directly from consistent snapshots taken by SnapManager. Quiescing the SQL databases and thus taking consistent snapshots is one of the most useful features of SnapManager. This process takes microseconds to finish, but seems to fail in about 10% of cases ... hence my warning above. This SHOULD NOT be your only strategy!
If it sounds as though you will need to become a storage administrator to make things work, you will at the very least need to understand many of the details of SAN/NAS management using NetApps. We maintain 5 different backup/restore strategies, with SnapManager being just one of them. Another of our strategies involves using NetApps to mirror to a another remote NetApps installation. We also do periodic classic backups, and frequent T-Log backups, which are immediately mirrored to a remote location. We also mirror differentials of all our critical DB servers to a remote location, as well as fall back, when needed, on classic tape drive backups stored offsite at yet another secure location.
As DBA's we should all know that nothing is ever easy or flawless, so it's common sense not to put all your eggs in one basket.
Cheers!
-Rick
July 24, 2014 at 10:33 am
Still using smsql but are running into an ongoing problem where the largest database comes up in suspect mode on the disaster recovery side. No evidence of any corruption on the source/production database.
Our method is 1) break the mirror ( or it breaks itself if a real DR )
2) bring up DR netapp luns
3) fire up the DR sql failover cluster and the databases come online since they were attached when the cluster was last shut down. In other words most of the time sql is not running in DR.
3456,Server,"Could not redo log record (1741525:1017743:2), for transaction ID (0:0), on page (1:30607705), allocation unit 281474979397632, database 'COLLATERALMANAGER' (database ID 5). Page: LSN = (1741525:942479:31), allocation unit = 281474979397632, type = 1. Log: OpCode = 4, context 18, PrevPageLSN: (1741525:995618:2). Restore from a backup of the database, or repair the database."
July 25, 2014 at 9:35 am
Indianrock - I think you might be better off starting a new topic for this issue mate 🙂
August 5, 2014 at 9:42 am
I have an encrypted SQL and I have to backup the SQL with encryption as it is.
Can SMSQL backup my SQL in encrypted stage?
Viewing 9 posts - 46 through 53 (of 53 total)
You must be logged in to reply to this topic. Login to reply