10 Replies Latest reply: Dec 19, 2014 11:39 AM by Carl Von Stetten RSS

    Snapshot Schedules - Best Practice?

    Joe Eberhardt Wayfarer

      I'm looking to see if anyone has developed a best practice in regards to prioritizing the servers in the environment and creating a volume collection to capture snapshots for them. My original thought was to create a High, Medium, and Low priority volume collection and set snapshot schedules for each of them. I am still fairly new with the way that Nimble captures and stores it's snapshots and have been reading some other community posts that help explain the difference between Dell, EMC, etc. and Nimble to get a better idea of how Nimble separates themselves from the others.

       

      95% of our clients that we're putting in SANs are not extremely diverse with Exchange and SQL database sitting on different volumes than the VM itself, etc. I read an article that made a statement that 50% of clients that have installed a Nimble are storing over a months worth of snapshots. I am used to working with other vendors in a previous job where you'd store maybe 1 weeks worth before purging out the oldest.

       

      Has anyone developed this type of schedule (high, medium, low) and prioritized the volumes into a collection for snapshot storage? If so, how often are you capturing snapshots in each collection? How many are you retaining? Is there a better way that I should be thinking about the snapshot retention for the smaller to mid-sized businesses?

       

      Thanks in advance

        • Re: Snapshot Schedules - Best Practice?
          Jason Liu Adventurer

          Each company is different so what's best for one might not work for another. In our case, based on different applications we set up a combination of hourly,daily,weekly,monthly, and yearly snapshots schedules and also set up retention plans based on different requirements on primary and DR sites. We almost completely get rid of traditional backups(only do a tape backup once every year for longer retentions)

          • Re: Snapshot Schedules - Best Practice?
            Frank Migliaccio Wayfarer

            Joe,

            Each application/service typically has a unique retention requirement.  With your Nimble array you can setup widely different policies for single or multiple volumes.  While I was IT Director at Money Mailer I would use policies that made sense for my unique environment.

             

            For Exchange 2010 (Win2K8R2 vm on ESX with five 1TB volumes mounted with the Nimble Windows Toolkit - iSCSI initiator in the vm) all the volumes were added to a volume collection with a synchronized (VSS enabled) snapshot schedule that ran every 6 hours and replicated to my DR site.  I would keep those for 7 days.   In that same policy I had a job that ran on Sunday night as well that lasted 52 weeks (used for legal discovery).

             

            For SQL 2005 (similar config as Exchange) the DB and LOG volume were included in a SQL volume collection.  Those ran every 4 hours with synchronization (VSS enabled).  I kept 7 days of 4hr snaps locally but only kept the last 6 snaps at the DR site.

             

            For VMFS volumes used for application servers I had snapshots run every night and kept 2 at the DR site.

             

            For VMFS volumes used for VDI workstations I snapped every 12hrs and kept 10 locally and 2 at the DR site.

             

            For volumes used for file/art data (Money Mailer is an advertising company) I would snap every hour and kept 7 days locally and 2 at DR, I would snap Sunday night and keep 52 locally, and 2 at the DR site.

             

            hope this helps!

            Frank

            • Re: Snapshot Schedules - Best Practice?
              valdereth Adventurer

              I'd have to echo Frank and Jason's responses.  I think you'll find the Nimble protection templates to be an excellent compliment to the data protection plan for a number of different scenarios.  Especially when you start looking at utilizing them for Dev/Test situations, you'll really start to appreciate the benefits of redirect on write snapshots 

               

              Start out with a simple template, get familiar with the interface and options.  I'd be willing to bet after a week of testing out the capabilities you'll start to see why there are customers holding on to a large number of snapshots. 


              Don't forget to check out Infosight->Data Protection->Planning after you've got a week of snaps or so!  It really shows you how efficient the snapshots are and takes the guesswork out of bandwidth required for a DR site.

              • Re: Snapshot Schedules - Best Practice?
                Carl Von Stetten Wayfarer

                I pretty much agree with what everyone else has said.  I've got a pretty intense snapshot schedule on my system (might be a little over the top), but it has worked pretty well.  Here are a few things to watch out for:

                 

                • For VMware VMs, if you do quiescing snapshots, don't put too many VMs on the same volume or firing at the same time (like all VMs exactly at the top of the hour).  VMware vCenter will bog down trying to do all the simultaneous VM snapshots with VSS quiescing.  Stagger the volumes or volume groups snapshot schedule times.
                • For SQL Server (especially if you use VMDKs for your data and log volumes rather than direct iSCSI connections) VSS snapshots may create some unacceptable latency to database operations.  If you can survive taking blind snapshots most of the time and reserve the VSS snapshots to off-production hours, that might work better.  I take 15minute and hourly snapshots "blind", then VSS snapshots daily (YMMV).
                • If your Windows VMs do volume shadow copy operations, stagger the times from the Nimble Snapshots.  Otherwise, VSS may be busy handling the shadow copy operation when Nimble tries to initiate a second VSS for the storage snapshot, and you could see "Failed to create vCenter snapshot" errors from Nimble.

                -Carl V.