Due to special requirements to delete files on the Isilon via NFS mounts and ensure they are not recoverable even at the block level, we are evaluating Linux tools such as srm and shred. My questions are:
1. Is there a better way to delete specific files to meet the requirements and ensure they are unrecoverable?
2. By using tools such as shred and srm to overwrite data with zeros and random bits, from the Isilon storage's perspective, are the existing data blocks being overwritten or potentially the existing data blocks still intact?
3. After deleting the files, they can still be recovered via snapshots. Is there a difference between
a. remove all snapshots first and then delete the files vs.
b. delete files first and then remove all snapshots?
I am concerned about if deleting files first, since snapshots are still holding the data blocks, the data blocks may still be intact even after snapshots are removed (assuming removing snapshots is just freeing up the pointers, not touching the data blocks themselves).
Even if you delete snapshots and shred the file the Isilon does not guarantee that the file is destroyed at the disk level and parts of the file could be all over the place and in the journals or l3 cache. The only thing that Isilon might offer in that realm is their self-encrypting drive cluster option so that the disks are unusable once removed from the chassis.
It turns out that this problem is quite a bit more complicated than just considering snapshot blocks. Files in OneFS may be moved around due to tiering, reprotection operations, autobalancing, or changes to a files's protection strategy, and it's currently impossible to determine all of the physical storage blocks within a cluster on which some part of any given file may once have resided. Simply over-writing a file in OneFS does not assure that the blocks on which the file is currently stored will actually be overwritten; the over-writes might instead end up placed on free space that is somewhere else entirely, with the current blocks being returned to the free list. Evidence of a file's data might also be retained for an indeterminate period of time in a journalling file, such as the OneFS Endurant Cache; unlinked, but not obliterated.
Other complications might be pertinent in specific situations. For example, if all traces of a scrubbed file's name had to be eradicated, that would include considering not only its directory entry, but also perhaps any audit logs pertinent to the file. Another example pertains to considering all blocks which may have become lost under certain circumstances which are subsequently recovered to the free list by the OneFS 'Collect' or 'MultiScan' Job Manager jobs.
At present, the only sure way to be certain a file is completely 'scrubbed' from OneFS is not very pretty at all, and also not very scalable. It involves evicting each node from the cluster in sequence, security-erasing the evicted node, then subsequently re-joining the node to the cluster. Most of the data in the cluster will end up being re-protected numerous times, and the process could require a significant amount of calendar time.
Implementing an effective 'Secure Erase' capability in OneFS is an often-requested feature, and some considerable engineering discussions have taken place regarding how it might be done with minimal overhead. However, this feature is not currently on the OneFS development roadmap. I would suggest working with your account team to file a Feature Request for this functionality.
Hello Andres Oliva,
Are you decommissioning your Isilon system? If that is the case, then you can reset the system back to factory and that will erase all data. Here is a link with the steps on how to do a factory reset. https://dell.to/3s7wvyK
Social Media Support Enterprise