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