Yes, technically speaking, it is possible, but is certainly not trivial. If this is a requirement please consider opening an RFE for this.
Have you looked at deduplication? Those would certainly mitigate the impact of security-only changes. 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-13 05:16:25: > From: Hans Christian Riksheim <bull...@gmail.com> > To: ADSM-L@VM.MARIST.EDU > Date: 2018-11-13 07:30 > Subject: Re: Windows ARL change > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > Is it technically possible to develop a client that extracts the ACLs > during backup and store these as separate metadata? We are having the same > challenge and who knows how much unnecessary backup data our customers are > paying for. > > Hans Chr. > > On Tue, Nov 6, 2018 at 7:25 PM Andrew Raibeck <stor...@us.ibm.com> wrote: > > > Hi Bob, > > > > If SKIPNTPERMISSIONS YES is in effect, then SKIPNTSECURITYCRC might be > > moot, but yes, you have the idea. > > > > I would agree that setting SKIPNTSECURITYCRC YES and using the default > > SKIPNTPERMISSIONS value can present a challenge since you cannot know which > > files are restored with the latest permissions. > > > > If security permissions are important to the organization, then best to > > just use the default values and back them up. If the organization chooses > > to skip the permissions during the regular incremental backup, then best be > > sure an alternate permissions backup and recovery plan is in place. Example > > of a follow-on complication: What if someone does a restore, but forgets to > > apply the separate procedure to put the correct permissions back? > > > > For the general usage case, I can only repeat what I said earlier (lest > > someone else coming into the middle of this discussion misses it): Best > > practice to ensure the most complete incremental backup is to allow the > > data to be backed up, even if only the security has changed. Before doing > > otherwise, proceed with caution, thinking about future ramifications of > > using non-default values for these options. > > > > 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-06 > > 11:13:21: > > > > > From: Robert Talda <r...@cornell.edu> > > > To: ADSM-L@VM.MARIST.EDU > > > Date: 2018-11-06 11:19 > > > Subject: Re: Windows ARL change > > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > > > 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. > > > >>>>> > > > >>>> > > > >> > > > > > >
