I'm facing a bit of an issue with the restore of SnapManager for SQL backups, and one of the venues of investigation is this:
We're using SM SQL 5.2 and SnapDrive 6.4 in a Windows Server 2008 Failover cluster with at the moment two instances. Backups run reasonably well, but we're getting errors during certain restore scenarios. Not boring you with details and logs, I just have a simple question.
We also use StorACL to restrict access to volumes only for set application administrators, server operators etc. From what I've learned, once StorACL is activated, all volumes that are created must be granted an access list or noone will be able to access them. So, when using SnapManager for SQL, which will use SnapDrive to create clones, which will in turn use FlexClone which we have licensed, will the cloned volume inherit the access list from the original volume? If not, the clone would not be able to be used by SnapDrive, sort of breaking the whole solution.
Logs point vaguely in this direction, looking for insights on this.
Curious. I tried a small experiement outside the SMSQL box, on a plain Windows server with SnapDrive connected to a LUN on a filer with StorACL enabled. The original LUN is on lets say /vol/vol_orig/qt/lun. I created a few snapshots from within SnapDrive, and then mounted "Connect disk" on one of these snapshots. This in turn creates /vol/sdw_cl_vol_orig/qt/lun and connects this lun. This volume is obviously created by SnapDrive as I assume FlexClone.
This all works fine, or not fine depending on how you see it. I can mount the LUN, manipulate it in SnapDrive etc. This should not be possible of the above statement is correct, cloned volume do not inherit ACLs from the orginal volume. The /vol/sdw_cl_vol_orig volume is not visible at all if I check permissions in StorACL.exe, and since StoraACL is enabled, all volumes must have an access list explicitly set correct?
Have you assigned any rights to the service accounts to the entire filer? I noticed this was necessary to be able to mount LUNs, since this writes igroup information on the filer level, this configuration information isn't stored in the volume or aggregate.
user add -rsn your_netapp_filer -rtype filer
etc, with permissions as needed, outlined in the StorACL documentation.