Andy, et al: Shared the meat of this discussion with our end users. A question came up about restores.
Scenario: Large Windows File Server on which the SP client is configured with the SKIPNTSECURITYCRC is set to YES. End of academic year arrives in June with the usual turnover in faculty and grad students, requiring a major permissions change that impacts most of the files on the server. However, the backups aren’t impacted because the SKIPNTSECURITYCRC is set. So the only files backed up with the new security are those that are new or those with content changes. This is an annual event Middle of November, file server melts down and all the files have to be restored. Because new backup of copies were NOT made when security changes were made, won’t the files be restored with the permissions as of the time of backup? I believe the answer is “YES” - which results in a potential mess for the end users. Consider the case of a Word document created by a postdoc 3 years ago that hasn’t been modified since but is still used on an on-going basis by one or more classes. The postdoc left 2 years ago, so the file permissions on the file server were updated accordingly - but no new backup copy created. In particular, a new owner was assigned. But when the file is restored, it is restored with the permissions that have the postdoc as the owner. If that is so, then the end users don’t see much of a win from the SKIPNTSECURITYCRC - while it saves a backup copy, it introduces the potential for a lot more work finding and fixing all the outdated permissions. Now, if the SKIPNTPERMISSIONS option was also enabled, then this issue goes away, because end users have already accepted that upon restore, a permissions setting has to occur. So, in our environment, it appears that settings should be either - SKIPNTPERMISSIONS and SKIPNTSECURITYCRC enabled; OR - SKIPNTPERMISSIONS and SKIPNTSECURITYCRC disabled Am I on the right track? Bob Robert Talda EZ-Backup Systems Engineer Cornell University +1 607-255-8280 r...@cornell.edu > On Nov 1, 2018, at 10:39 AM, Andrew Raibeck <stor...@us.ibm.com> wrote: > > Hi Bob, > >> Upon restore, user must rebuild security permissions. > > Are you perhaps thinking of the SKIPNTPERMISSIONS option, which forgoes > backup of any permissions? In that case, for sure you have to rebuild > security permissions after the restore. Outside of a user-specific edge > case, do not specify that option, just use the implicit default (which > happens to be NO). > > SKIPNTSECURITYCRC is not the same, as it merely removes the permissions > from the criteria that go into determining whether files have changed. > However, when files are backed up, permissions are included with the > backup, provided you did not set SKIPNTPERMISSIONS YES. > > In the scenario I described previously, if you restore the backup taken on > Day 1, then the permissions in effect at the time of the backup are > restored. > > Best regards, > > Andy > > ____________________________________________________________________________ > > Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com > > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 2018-11-01 > 09:39:55: > >> From: Robert Talda <r...@cornell.edu> >> To: ADSM-L@VM.MARIST.EDU >> Date: 2018-11-01 09:41 >> Subject: Re: Windows ARL change >> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> >> >> Andy: >> As always, thanks for chiming in. >> >> I was aware of this option but was hesitant to recommend it >> because of a side effect that you didn’t list: >> >> Upon restore, user must rebuild security permissions. >> >> So, if the fileserver/NAS had a strict permissions scheme that was >> easy to apply after a restore, then this option is viable. >> >> This is what bedevils us here - a lot of our units here at >> Cornell have file servers and NASs with complex permissions, and so >> the issue comes down to what is the least amount of pain: bumps in >> cost due to occasional big backups (we are a charge-back service) or >> trying to figure out a way to save permissions outside of Spectrum >> Protect that can be used to rebuild those permissions in a disaster > scenario. >> >> Needless to say, all our customers have gone the big backup route. >> Probably attribute additional charge to usual "Cost of working at a >> university” account >> >> Bob >> >> Robert Talda >> EZ-Backup Systems Engineer >> Cornell University >> +1 607-255-8280 >> r...@cornell.edu >> >> >>> On Oct 31, 2018, at 8:46 AM, Andrew Raibeck <stor...@us.ibm.com> wrote: >>> >>> The backup-archive client has an option, SKIPNTSECURITYCRC [NO | YES] > with >>> NO being the default. >>> >>> Reference: >>> >>> https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.6/client/ >> r_opt_skipntsecuritycrc.html >>> >>> When this option is set to YES, security changes are not used to > determine >>> whether the file is changed. That is, if the ONLY change to the file is > to >>> the security attributes, then the file is not considered changed (but > if >>> the file is backed up due to other changes, the security attributes are >>> included in the backup). >>> >>> Be careful setting this option, though: >>> >>> 1. Practically speaking, this is the kind of change you make once. That > is, >>> do not toggle this option back and forth between YES and NO. Of course > you >>> can certainly do that, but you will defeat the purpose of changing the >>> value to begin with. It is not a "one-time" skip of security changes. > It is >>> a "lifestyle" for your backups. :-) >>> >>> 2. Files that undergo ONLY security changes are not backed up during >>> incremental backup. Consider this scenario: >>> >>> - Day 1: File is backed up (for reasons other than security changes) >>> >>> - Day 2: Security is changed on the file. File is not backed up because > no >>> other changes occurred. >>> >>> - Day 3. Security is changed on the file. File is not backed up because > no >>> other changes occurred. >>> >>> - Day 4. User wants to revert the most recent (Day 3) security changes, > and >>> asks you to restore the file with the security changes from day 2. That >>> will not be possible if you configure SKIPNTSECURITYCRC YES. But you > can >>> revert to the Day 1 backup, assuming your copygroup retention settings > have >>> not caused the older backup to expire. >>> >>> >>> 2. If you later decide to put this option back to its default >>> (SKIPNTSECURITYCRC NO) then you might see a one-time very big backup, >>> because at that time, any files whose change is only to security, will > be >>> backed up, resulting possibly in a backup workload that is larger than >>> usual. >>> >>> In sum: Best practice to ensure most complete incremental backup is to >>> allow the data to be backed up, even if only the security has changed. >>> Proceed with caution, thinking about future ramifications of using this >>> option. >>> >>> Best regards, >>> >>> Andy >>> >>> > ____________________________________________________________________________ > >>> >>> Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com >>> >>> "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 2018-10-30 >>> 14:57:47: >>> >>>> From: Robert Talda <r...@cornell.edu> >>>> To: ADSM-L@VM.MARIST.EDU >>>> Date: 2018-10-30 14:58 >>>> Subject: Re: Windows ARL change >>>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> >>>> >>>> Harold: >>>> Have same issue - often several times a year as departments here >>>> administer their own servers - and no magic bullet. Probably >>>> doesn’t help other than “misery loves company” >>>> >>>> Keeping fingers crossed someone smarter than I has a workaround, >>>> Bob >>>> >>>> Robert Talda >>>> EZ-Backup Systems Engineer >>>> Cornell University >>>> +1 607-255-8280 >>>> r...@cornell.edu >>>> >>>> >>>>> On Oct 30, 2018, at 11:20 AM, Vandeventer, Harold [OITS] >>>> <harold.vandeven...@ks.gov> wrote: >>>>> >>>>> Our "server security" folks are making several changes in Windows >>>> Access Rights at the top of a folder structure which then cascades >>>> all the way down to all files. This is being done on several nodes. >>>>> >>>>> Is there a way to avoid Spectrum Protect from backing up all those >>>> files, most of which haven't changed in content other than the ARL >>> property? >>>>> >>>>> We charge back to agencies based on the bytes in auditocc table. >>>> The ARL change results in a double up of the cost. >>>>> >>>>> The nodes are running various 7.x versions. >>>>> >>>>> Thanks for any guidance you might have. >>>>> >>>> >>
