How to write files to NetApps filer with Snaplock Compliance Volume

Question

We have a NetApps FAS2040 device with a Snaplock compliance volume configure. Image files are written to the volume using IBM FileNet for compliant storage of scanned post.

We want to replace the FileNet element with a in-house solution where we write the images ourselves to the volume. What I would like to know is what is involved in doing this.

Is it just a case of writing a file to the volume then setting the read only attribute to true?. How would I configure expiration for the file. Can I change the time between it being read only and then permanently committed?

Thanks

Stuart

Answer 1

Setting a file read only will activate the snaplock. It will default to the default snaplock retention period - which is configured on your filer.

Usually this is set to a short interval, to avoid accidentally snaplocking junk for protracted periods of time. There's really nothing more annoying than accidentally locking a 100TB aggregate for 3 years.

You update the individual file retention by setting an access time. By default, when you set a file read only, the atime will be set to now + the default retention. You can update this to a longer timespan (but never shorter) via the touch command:

touch -a -t 201411210000 <filename>

(note - iso date format. YYYYMMDDHHmm)

You can use the stat command to show you the retention dates.

The whole process is geared off the snaplock compliance clock - it's a tamper resistant clock, which should generally match 'real time' but there are a variety of circumstances where it won't. E.g. if you've powered the filer down, or the volumes or whatever, you can't reset the clock, forward date and mess with snaplock. It will adjust itself by up to a week per year, but NO FASTER.

Once the atime is less than the value on the snaplock clock, you can then delete the file (but note - not modify it).

You can set snaplock.autocommit_period to automatically snaplock files that have been static for the defined period.

I would very strongly recommend thinking hard about snaplock retention periods. Setting this to years will almost certainly cause you grief, when you realise you need to do some essential maintenance and you can't because snaplock is in the way. You can only delete an aggregate once every piece of data in it has had the clock expire. (And if any has been offline ever, the clock will be skewed too). That means years after your system is end of life, it will not be usable for anything other than watching the clock tick.

I would suggest instead that you consider a mechanism to refresh snaplock on a periodic basis - e.g. set the retention for 6 months. Run a monthly cronjob to update it and add another month.

You cannot change the time between "read only" and "permanently committed" because that's not the way it works. As soon as it's read only, it's snaplocked. But as said - the retention period should hopefully default to a sensible number.