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