4 Replies Latest reply: Oct 17, 2016 11:44 AM by Paul Sabin RSS

    Delete all orphaned snapshots at once

    Adam Schoenemann Newbie

      I know when you change volume collections and or rename them the previous snapshots no longer become managed and are basically orphaned.  Is there a way to do this en-mass without having to go to each volume individually?


      This would save us a TON of time as we are changing volume collections to better line up with DR.

        • Re: Delete all orphaned snapshots at once
          Ben Watson Newbie

          Agree, I've been wondering this myself.


          It would save a large amount of time.

          • Re: Delete all orphaned snapshots at once
            Nick Dyer Pioneer

            Hi Adam,


            There's no way to do this manually as it could be dangerous en masse - however if you speak with support they will happily pass you a customised script which will clear these down for you should you wish.

            • Re: Delete all orphaned snapshots at once
              Paul Sabin Newbie

              Forgive me for posting in an older thread, but I came across this discussion when looking for a solution to the same problem. Since one didn't exist, I wrote a way to find and (optionally) remove orphaned snapshots using PowerShell and Nimble Storage's RESTful API's. The script can be found here: Use PowerShell and Nimble's RESTful API's to remove orphaned snapshots.

                • Re: Delete all orphaned snapshots at once
                  Nickolay Milovanov Wayfarer

                  @Paul Great work! Any human "busy work" is saved is a win in my book.. I do want to mention couple of gotcha's regarding unmanaged snapshots on Nimble Storage array.


                  Currently, an unmanaged snapshot is defined as any snapshot not currently managed by an active volume collection schedule.

                  This means that snapshots created on volume level manually, snapshot collections created manually, third party app snapshots/collections are considered "unmanaged" by the system.

                  Only schedule-generated snapshots which no longer have said schedule are the snapshots which become unmanaged due to configuration error/change.


                  An interesting case is where volume collection or a schedule is deleted, but one with the same name is created. In this case, the snapshots are in-fact unmanaged, but many scripts which use name comparison cannot detect them.

                  The more frequent and more impacting scenario, however, is where a schedule name or a volume collection name was changed without deletion/recreation first. In those scenarios, the snapshots with different name are actually still managed by the schedule and will follow the retention policy. Using name comparison, however will show those snapshots as unmanaged which could lead to unexpected deletion of the snapshot and restore point data loss.


                  Another very important to note, that it is possible to delete a snapshot which was left in "online" state. Thus, script should account for such scenario and not attempt to delete an "online" snapshot.


                  I hope this information provides clarification of the potential impacts of using scripts. However, as you have mentioned, script is marked as "Use at your own risk".