Andy, et al: I should have mentioned this - this is exactly the strategy we are pursuing: moving backups of large Windows filesystems to container storage pools and enabling client-side deduplication. SP client will be working hard - but little or no data will be transferred to the server.
Do we get any credit for thinking of this ourselves in advance? Bob Robert Talda EZ-Backup Systems Engineer Cornell University +1 607-255-8280 r...@cornell.edu > On Nov 13, 2018, at 7:59 AM, Andrew Raibeck <stor...@us.ibm.com> wrote: > > 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. >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>
