tag:blogger.com,1999:blog-1647638669183418902.post1526139094068137228..comments2023-10-05T03:51:47.245-07:00Comments on Let's Talk SQL Server: The Skinny on SnapManager for SQL ServerScott's Bloghttp://www.blogger.com/profile/10268635352433432298noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1647638669183418902.post-53857385188822339452011-09-13T10:31:03.286-07:002011-09-13T10:31:03.286-07:00Hey Scott,
I would like to point out that taking ...Hey Scott,<br /><br />I would like to point out that taking hourly full snaps does not in any way serve the same purpose or allow you to do the same thing that hourly transaction log backups do. A transaction log backup using FULL recovery will allow you to roll a database forward to a specific point in time facilitating point in time recovery of the database. For example if someone drops a table by accident you can roll the logs forward to the ponit in time just before the table was dropped and minimize the total risk for data loss. Using full snapshot backups only, you can get up to the point of the last snapshot, which if that was 59 minutes before the table was dropped, you have 59 minutes of data loss potential. Log backups with full recovery at 59 minutes you would take a log backup and use the STOPAT command to stop the redo operation before the event occurred for near zero data loss.<br /><br />Jonathan KehayiasAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1647638669183418902.post-76267305754687770552011-07-13T06:41:54.190-07:002011-07-13T06:41:54.190-07:00Taylor, we store logs in the SnapInfo directory. B...Taylor, we store logs in the SnapInfo directory. But we don't normally take log backups. Our databases run in simple mode but we take hourly full snaps. This saves us some configuration hassles and serves the same purpose as taking hourly logs. Our configuration problems are with isolating datafiles on their own volumes and separating out any application data. Our older systems usually have a single D drive and everything is stored there. Well, this won't work when moving to a SMSQL solution.<br /><br /><br />We use RDM and run the latest SMSQL version (5.1.0.676) and SnapDrive 6.3.2.<br /><br />I'll ask NetApp about SnapCreator and see if that's an option for us. <br /><br />Our real concern is in the SMSQL application and not necessary in how the storage is configured. SMSQL is just not a prime-time tool for managing backup and recovery in large SQL Server shops. Maybe it will be one day.<br /><br />Thanks for you commentsScott's Bloghttps://www.blogger.com/profile/10268635352433432298noreply@blogger.comtag:blogger.com,1999:blog-1647638669183418902.post-48412259710449162352011-07-13T05:53:01.297-07:002011-07-13T05:53:01.297-07:00Scott, I believe the SnapInfo volume contains most...Scott, I believe the SnapInfo volume contains most of the backup & recovery configuration and history (backup logs). Or were you thinking about something else?<br /><br />Also, how did you have your storage provisioned to your SQL servers? RDMs? MS iSCSI software initiator?<br /><br />Have you looked at using newer versions of SMSQL and SnapDrive with NFS-connected datastores? This really simplifies things IMHO. You just leave your databases sitting on a VMDK on a NFS-based datastores. SnapDrive 6.3 now supports this and is aware of such configuration.<br /><br />Also, has anyone at NetApp spoken to you about SnapCreator? SnapCreator is a framework by which you can create a single-pane of glass to manage snapshot backup utilities in one central location. It also allows you to write your own "SnapManager-ish" scripts that interact with SnapDrive and the applications to take application-consistent snapshots. You can essentially create a SnapManager for Anything using SnapCreator.Taylorhttps://www.blogger.com/profile/08314476437316313836noreply@blogger.comtag:blogger.com,1999:blog-1647638669183418902.post-7238630803057718382011-07-12T13:39:17.132-07:002011-07-12T13:39:17.132-07:00I would like to suggest to people who are using SM...I would like to suggest to people who are using SMSQL to add a comment telling me what improvements you would like to see in the tool. My first suggestion to NetApp is to think about using a repository for backup and recovery configuration and history. All good 3rd party backup tools use one and it adds speed and scalability. This is also a good start to a truly centralized management console. Any others?Scott's Bloghttps://www.blogger.com/profile/10268635352433432298noreply@blogger.com