Andy: Indeed I was - and now I have another option to explore…thanks for raising my (SP) consciousness…
Bob > 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. >>>>> >>>> >>
