Just a quick tip here, I’ve noticed a fair amount of people do not know what happens when we restore a volume concerning the special “hidden” operation we take in case you make a mistake. So I thought it worth a quick post.
The FlashArray snapshots are not tied exclusively to any volume or any state of that volume. In other words, you can refresh the data image of any given volume at any given time from any given snapshot.
A snapshot, not only contains the data of a point-in-time of a volume, but also its geometry, so when you restore from a snapshot, it not only restores the target volume’s data, but it also resizes the volume to the volume size the snapshot reflects. So for instance, if you snapshot volume A which is, let’s say, 100 GB, then resize that volume to 500 GB, then restore the volume from that snapshot the volume will revert back to it’s original size of 100 GB in addition to having its data refreshed.
This provides for a lot of flexibility in snapshot management. On the other hand, this flexibility opens room for more error. Since now every volume is a potential restore target, the change of accidentally restoring to the wrong volume goes up. Basic math. This is where the point of this post comes in.
One of the operations we secretly take during a snapshot operation is that we create a snapshot of the volume the instant before we perform the restore, then we delete this snapshot. Since snapshots are so lightweight on the FlashArray from a creation and capacity standpoint this is a helpful addition to help protect against mistakes. Since we “delete” the snapshot it will automatically go away in 24 hours. Like volume deletions (which we actually call “destroys”) it goes into our “Destroyed Volumes” folder. All items in that folder get eradicated (as we call it) in 24 hours. Or you can force the eradication sooner if you so choose.
Let’s take a look. I create a 10 TB volume and then take a snapshot:
The snapshot is now listed:
Now I resize to 15 TB from 10 TB:
Then I decide to restore from my snapshot, and that reverts the volume back to the dataset preserved by that snapshot and therefore also the original 10 TB size:
So if that restore operation was actually a mistake, you can go to your Destroyed Volumes folder and restore the snapshot we took and then restore it back to the volume. Otherwise that snapshot will go away in 24 hours.
This is a built-in, default behavior. So if you saw some snapshots being created that you didn’t know where they came from, this behavior is likely the source.
Is it possible to reduce retention time of eradicated snapshots from 24 hours to say 6 hours ? If yes, how ?
Unfortunately no, the 24 hour period is not configurable. You could write a workflow/script that runs on a schedule and eradicates snapshots more aggressively though