I'm trying to work out, in detail, how to protect our snapVault volumes against deletion by a rogue administrator, whilst still being able to perform restores using FlexClones.
We run our VMs on volumes accessed over NFS on our MetroCluster. These volumes are protected by snapVault to a FAS8200 system. When we need to restore a VM, we clone the relevant snapVault volume from the appropriate snapshot, present this volume to the VM hosts, import the VM then migrate it back to it's original volume on the MetroCluster. All this works perfectly.
We are concerned that a rogue administrator, or more likely a compromised administrator account, could access our snapVault array and delete all the data. Furthermore, they could log into the service processor and re-initialize the system. They could then do the same to our MetroCluster and in less time than it takes to realize what's happened, all of our data is gone. Obviously, we'd like to protect ourselves against this eventuallity.
SnapLock Compliance seems like the answer to this but from what I've read (https://community.netapp.com/t5/Tech-OnTap-Articles/Back-to-Basics-FlexClone/ta-p/84874) you shouldn't create a clone of a snaplock'd volume. My understanding, is that the clone inherits the properties of the parent, therefore cannot be deleted before the retention period expires. My intention had been to set a short retention period, say 14 days, just to protect our most recent snapshots but would this also mean the clone cannot be deteted for 14 days?
If you've solved this issue by another means or have experience of doing so using snaplock, I'd be very interested to hear how. Any help and advice is very much appreciated.
It looks for me that you are trying to find out notional situation and then a protection from it.
By my opinion it is always like that - yes unfortunately in theory it is possible that employees might be rouges, but it is very hard to protect from those kind of situations in general.
here is another theoretical possibility - a rougue admin have an access to data centre and even though he can't physically destroy storage system - he can steal\replace several disks (5 for example) - so data is inaccessible in general, no matter if it was protected by snaplock or by any other solution.
Thanks for the link. To be fair, although I've stated rogue administrator, the case I'm more concerned with is that of an administrator account compromise. In that instance, local access wouldn't be available. This only really came to light when I was reflecting on how long it took to erase all our old backup tapes and I commented to a colleague just how much quicker I could do this with our disk based storage system. If I can do that, so can someone with my level of access; how do I protect us against that I wondered.