Snapsure \ .ckpt \ Previous versions Permissions

Question

Hi,
So we do not trust all our users with the previous version tab so we are looking at granting our helpdesk staff the ability to restore files from our snapsure checkpoints. We would like the helpdesk to use either the previous versions tab or going to the .ckpt directory.

The problem I am having is how or what permission do I need to grant the helpdesk the rights to get into the folder to allow them to do this?? Obviously we dont want to grant them rights to read or modify the actual contents of the data I was more thinking along the lines of using say the " Restore files and directories" user right assignment for our VDM. I have been testing adding myself to this and I still get not get access to either the folder (for the previous version tab) or when I try to open a folder under the .ckpt folder I still get access denied.

Is there somewhere else I need to set the permissions?

Thanks,

Packetboy.

dynamox · Answer

i don't think you have a choice here but to give them at least read permissions, i would also try to give them backup Administrator rights ..and see if they can restore then.

Peter_EMC · Answer

Checkpoints do have the same permissions than the Filesystem (PFS) they depend on.

So if your helpdesk is not allowed to access a folder of the PFS, then they will not be allowed to access the same folder of the checkpoint

dynamox · Answer

and since checkpoints are mounted read-only ..you can't modify their NTFS permissions either.

dynamox · Answer

i trust my users since they can only 'break' their own home folder. I also keep 14 days worth of snapshots, so if somebody accidentally over-wrote current data with old data from one of the snapshots, i can still go to one of my previous snapshots and un-do what they did. I have ~1000 users and so far i have not had any problems with people blowing away their data by incorrectly using SnapSure.

packetboy2 · Answer

hmm.. yes thats true as well dynamox..

I tried giving my test account local administrator rights and of course this works because cifsserver\administrators have full control NTFS perms..

I guess I was hoping the user rights assignment in the data mover management snapin labeled "Restore files and directories" would enable checkpoint restoration within having to give explicit rights to the file system..

What do you guys do out there? Do you trust your users with previous editions client? Or do you give your helpdesk read access to all the directories?

Rainer_EMC · Answer

For any file in the checkpoint the ACL's that the file had, when the checkpoint was created, are enforced.

So the worst thing a user can do is to mistakingly overwrite his current file with one from the checkpoint.
But even there he gets a choice to save it to a new name or location and the Microsoft SCSF client will warn the user before overwriting and ask to confirm the overwrite

The only other scenario's I've heard are:
- you've caught a virus that was preserved in a checkpoint so you can delete it
- you've had by accident given wider ACL's to a file/dir than it was supposed to so that even after you've changed the ACL's on the current file system they are still preserved in the checkpoint

In these cases your only options are to either delete that checkpoint or at least unmount it

Rainer_EMC · Answer

I guess I was hoping the user rights assignment in the data mover management snapin labeled "Restore
files and directories" would enable checkpoint restoration within having to give explicit rights to
the file system..

I think that is actually a privilege that is only effective if your application is specifically invoking the NTFS backup API - which Windows explorer.exe doesnt

So it works if you are using program that are designed to use it - like NTBackup, emcopy or some other program but not for drag-and-drop from Windows explorer

Since the SCSF client code (the part of explorer that shows you the "Previous Versions" tab) is provided by Microsoft there really isnt much we can do.

telenoiz · Answer

I'm in a similar situation..considering trust/risks for restoring in a shared file system environment.

As far as permissions go for restore, this has already been stated.. that the user doing the restore must have the permissions. I don't think there is anyway around that.

I also looked into this in order to remove users ability to the Previous Versions.. or Restore option, and then limit its use only to a select group of priviledged users to perform restores by request. The only thing I could find was this rather undesireable method from microsoft.
http://support.microsoft.com/kb/888603

Rainer_EMC · Answer

just curious - what risks do you see ?

dynamox · Answer

so you would have to deploy this hotfix to all computers ? Yuk !

telenoiz · Answer

With 'public' type folders setup for many users/groups with adequate permissions, The risks would be that a user could restore an entire folder and thereby wipe out anything changed since the most recent checkpoint. If we are doing daily checkpoints, this could be up to 24 hours worth.

I suppose we could do more frequent checkpoints to limit the exposure.
Does creating more frequent checkpoints have an impact on how much pool space is used/allocated ? what would be other considerations/impact to this?

dynamox · Answer

it depends on the change rate. If you snap your file system twice a day ..then if one file changed at 8am and then again at 4pm, if you snap occurred at 7am and then again at 3pm ..then Savpool will have two copied of the changed blocks in that file.

dynamox · Answer

i would think those would be your standard windows events logged by auditing. Take a look at this thread from a while back:http://forums.emc.com/forums/thread.jspa?threadID=78643&tstart=0

telenoiz · Answer

Understood, not a huge concern there. What about tracking the restores performed by users using the SCSF feature? If someone does cause issues by restoring an entire folder, how could I track that?

Celerra

Snapsure \ .ckpt \ Previous versions Permissions

Was this post helpful?