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. >>> >>
