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