SnapLock aggregates and root volume

[igor]

Hello, all!

Here's a basic definition of SnapLock aggregates and volumes from NOW:

SnapLock is an attribute of the aggregate; therefore, the  volume contained in that aggregate inherits the aggregate’s SnapLock attributes. Every FlexVol volume created in a SnapLock aggregate is, by definition, a SnapLock volume.  A SnapLock Compliance aggregate contains only SnapLock Compliance  flexible volumes, and a SnapLock Enterprise aggregate contains only SnapLock Enterprise flexible volumes.

I'm wondering if it's at all possible to move the root volume to a new volume on a SnapLock aggregate, since the root volume has to remain free to change/adjust at all times? Even when I make sure my new root volume is a regular one and there are no retention policies active on it, the system still rejects it saying that the new root volume is a SnapLock'd one.

Is there a workaround for this?

Thanx,

Igor

[thomastasker]

Igor,

This is a bit of a "non answer", but why would you want to move your root volume to a SnapLock volume, and more so to one that has no compliance?

Without wanting to sound derogatory or impolite it is a very bad idea, hence ONTAP not letting you do it.

My advice would be to leave root where it is as ONTAP has plenty of security and measures you can take to protect it, assuming this is why you would be moving it to a SnapLock volume and use SnapLock for your compliance data only.

If you're looking for the long term retention of the logs (or some such) from the root volume, may I suggest a script to copy the logs to another aggregate or even filer with SnapLock compliance licensed and go that way?

[igor]

Hi, Tom!

The thing is my client has a very limited budget for IT purposes for the rest of the year and they're thinking of squeezing in a simple FAS2020 with 12 internal 1TB SATA disks, to store cca 5TB of data they wish to keep intact, and build from there.

As we know, upon installation, DataONTAP auto-creates a minimal RAID-DP aggregate (aggr0) with the root volume on it. That's 3 disks, plus one hot-spare, which leaves me the remaining 8 disks to create a new SnapLock aggregate. 9 disks, if I convert aggr0 to RAID4... But that means I still loose 2 whole disks just for the root volume, which is a waste of space.

My goal is to somehow move the root volume to the newly created SnapLock aggregate, thereby freeing those disks and adding them to the SnapLock aggregate later on, making it the only one (using all the disks).

The trick is, the system doesn't allow a SnapLock volume to become the new root volume - and all volumes on Snaplock aggregates as regarded just as such, regardless of their potential "non-locked" purpose and completely disabled retention polices.

That's why I' need a workaround... Any thoughts?

[thomastasker]

Igor,

Ah, now I understandd and see why you need to move the root volume

Reading your reply I think you have already hit upon the problem and best solution of dropping the RAID levels down from DP to 4 on both aggregates and getting the space that way.

Rather than repeat what you have said as my answer, maybe a software solution could help such as dedupe.  Granted it might not bring about the gains you could guarantee from a number crunched "disk v RAID group v disk size calculation", but if you're using SnapLock for archiving the chances are that you are going to get a fairly high level of repeated blocks.

Unfortunately I think a dedupe solution like this will be counter productive to your budget, but you can only work with what you've got...

In short, you're going to need 2 aggregates and a spare so you're going to loose a minimum of 3 disks what ever you do (can you get away without the spare?) leaving you the 9 "data" disks to play with.

Sorry I couldn't be more helpful, but as is often becoming my tag line, if an NetApp guru out there knows better, I will bow down in admiration!

Tom.