Hi Erik, Looking at your option set INCLEXCL statements, at least part of the binding problem looks to be the sequence of statements:
INCLEXCL 0 Yes INCLUDE.BACKUP d:\MSP\...\*.* BA7Y_L INCLEXCL 1 Yes INCLUDE.BACKUP d:\FTPDATA\sapdw\...\*.* BA7Y_L INCLEXCL 2 Yes INCLUDE.BACKUP d:\FTPDATA\workathome\...\*.* BA7Y_L INCLEXCL 3 Yes include.backup d:\...\*.* BA14_L INCLEXCL 4 Yes include.backup c:\...\*.* BA14_L (note: The FORCE option is ignored for INCLEXCL.) The above include-exclude statements are processed from the bottom up, the same as if you put them in your dsm.opt file. For example, a file such as "D:\FTPDATA\sapdw\somefile.txt" matches the pattern "d:\...\*.*", so it is bound to BA14_L. You can fix this by resequencing the INCLEXCL options in the client option set. For example: update clientopt mpsserver inclexcl 0 5 update clientopt mpsserver inclexcl 1 6 update clientopt mpsserver inclexcl 2 7 Thus the new sequence is: include.backup d:\...\*.* BA14_L include.backup c:\...\*.* BA14_L INCLUDE.BACKUP d:\MSP\...\*.* BA7Y_L INCLUDE.BACKUP d:\FTPDATA\sapdw\...\*.* BA7Y_L INCLUDE.BACKUP d:\FTPDATA\workathome\...\*.* BA7Y_L Note that if you run "dsmc query inclexcl", the include-exclude list is displayed in inverted order (don't ask me why...), so patterns closer to the top of the displayed list are matched first. One more observation: The "*.*" pattern means "match any file name with a dot ( . ) character in the name. Thus files with no extension, though not so common on Windows, do not match the "*.*" pattern. In general, it is best to use "*" to refer to any file name... unless you really mean to include only files that have a dot in the name. To augment this comment from Josh-Daniel Davis: > * Directories always are bound to the longest retention management class > unless you use DIRMC to override it. Specifically, it is the management class with the longest RETONLY setting. If more than one management class has the same (highest) RETONLY setting, then the management class name that is last in ascending sort order is the default DIRMC. For example, if you have two management classes named DISK and TAPE, and they both have the same highest RETONLY setting of all the management classes, then the default DIRMC is TAPE. You probably are not doing this, but I will mention it anyway, for completeness: When you do incremental backups, do NOT do this: dsmc incremental c:\* -subdir=yes Instead, use the idiomatic file system specification for full incremental: dsmc incremental c: Regards, Andy Andrew Raibeck IBM Spectrum Protect Level 3 IBM Systems, Storage stor...@us.ibm.com IBM -----Original Message----- From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Josh-Daniel Davis Sent: Wednesday, 3 August, 2022 14:57 To: ADSM-L@VM.MARIST.EDU Subject: [EXTERNAL] Re: Files not rebinding as expected For windows systems, the filespaces are not stored as C: and D:. They are stored as UNC names such as \\hostname\c$. The drawback here is that if the hostname ever got updated, you could have C: backed up two or more times. Q OCC will tell you what to expect. When you run an incremental, it will not update filespaces which do not exist at the time of the incremental. That includes mismatched UNC names. As to the binding: * UPD NODE will not change the management class assigned to any backup objects. * If an object belongs to a management class that exists in both policy domains, then EXPIRE INV will work as expected, using the new retention plan. * If an object belongs to a management class that does not exist in the target policy domain's ACTIVE policyset, then EXPIRE will process as DEFAULT, and the next incremental will rebind the objects to the default management class. * If the default management class is missing a copygroup, then the rendition grace period will be used. * Directories always are bound to the longest retention management class unless you use DIRMC to override it. * If client-side inclexcl is used, that can override server-side depending on settings. * If the node does not have the client option set assigned, it will not be used. * ARCHIVE data is never rebound. If the target is missing, then you get DEFAULT. If default is missing you get the grace period. * TOCDEST is used for nas (NDMP) and , snapmirror, and ndmp backups. If this does not explain it, then it would help to get Q OCC and also a few records out of the backups table for examples to what you're seeing. Also, the default line wrap is difficult to read. Please post -tabdelimit or data that is in stanza format (one field per line) for readability. Please do not omit ACTIVE when doing Q CO. If you did not, then did you forgot to ACTIVATE POLICYSET? With friendly Regards, Josh-Daniel S. Davis On Wed, Aug 3, 2022 at 3:28 AM Loon, Eric van (ITOP DI) - KLM < eric-van.l...@klm.com> wrote: > Hi Martin, > > The strange thing is that I also see active files still bound to the > no-more-existing-in-new-domain management class... That should not be > possible, I think. We are running full incremental backups only. > I think I will open a case for it, I'll keep you all posted on the outcome. > > Kind regards, > Eric van Loon > Air France/KLM Core Infra > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > Martin Janosik > Sent: dinsdag 2 augustus 2022 13:18 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: Files not rebinding as expected > > Hi Eric, > > from my observation updating node to new policy domain is > instantaneous no matter how many files are stored under the node. > There is no way that during this instant operation files are re-bound > from no-more-existing-in-new-domain management class to new domain's > default management class. That would explains question #3. > > Also: > > if a user changes the binding in an include statement, then instead > > of running a full incremental backup, only selective or > > incremental-by-date backups are performed, then only active versions > > will be rebound, while inactive versions will remain bound to the > original management class. > > If you run anything else than full incremental (in this case `dsmc incr C: > D:`) then only newly backed up files are stored under new management > class > > Expire inventory goes through all inactive files and if their MC > matches with the MC defined in the policy domain, it expires data accordingly. > If there is no matching MC present, objects will expire based on > default management class (or grace retention period). > > Is the destination by any chance a directory pool? I *think* that > deduped objects (=those referenced by multiple backup versions) are > not necessarily re-bound. > > Martin Janosik > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > Loon, Eric van (ITOP DI) - KLM > Sent: utorok 2. augusta 2022 12:42 > To: ADSM-L@VM.MARIST.EDU > Subject: [EXTERNAL] Re: [ADSM-L] Files not rebinding as expected > > Hi Skylar, > > Yes, this node is backed up every day... > > Kind regards, > Eric van Loon > Core Infra > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > Skylar Thompson > Sent: maandag 1 augustus 2022 17:43 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: Files not rebinding as expected > > Hi Eric, > > Have you run an incremental backup yet? You'll need to do that in > order to get active versions rebound to the management classes in the > nodes include/exclude rules. > > Inactive versions will stay bound to their old management class but, > in the event of a domain change, I think will use either a management > class with the same name in the new domain/policyset, or the domain > default management class if that management class doesn't exist. I'm > not sure how that would be reported with SQL or QUERY BACKUP, though. > > On Mon, Aug 01, 2022 at 11:51:08AM +0000, Loon, Eric van (ITOP DI) - > KLM > wrote: > > Hi everybody, > > > > I have a node called YS0023SA, which uses domain MPS_7_YEARS and > > client > option set MPSSERVER. I listed all policy details down below. > > I issued a select * from backups for this node and for some reason, > > all > files are either bound to mgmtclass DEFAULT, bound to BA14_L (which is > the default), or to TOC, which doesn't even exist in this domain (it > does exist in the node's previous domain). > > Can anybody explain: > > > > 1. Why are files using both DEFAULT and BA14_L? > > 2. Why is the include.backup for the other mgmtclass BA7Y_L in > > the > cloptset not working? > > 3. Why are some files (active and inactive files) still bound to > > a > management class from the previous domain? > > Thanks for any help in advance! > > > > Kind regards, > > Eric van Loon > > > > > > > > Domain MPS_7_YEARS: > > Policy Domain Name: MPS_7_YEARS > > Activated Policy Set: MPS_7_YEARS > > Activation Date/Time: 19-07-2022 12:04:05 > > Days Since Activation: 13 > > Activated Default Mgmt Class: BA14_L > > Number of Registered Nodes: 1 > > Description: Domain for MPS server Backup > > Retention (Grace Period): 14 Archive Retention (Grace Period): 14 > > Last Update by (administrator): XXXXXXXX > > Last Update Date/Time: 19-07-2022 12:04:05 > > Managing profile: > > Changes Pending: No > > Active Data Pool List: > > Domain Type: Standard > > > > Policy set MPS_7_YEARS: > > Policy Policy Default Description Last Update by > Last Upda- Managing profile Changes > > Domain Set Name Mgmt (administrator) > te Date/T- Pending > > Name Class > ime > > Name > > --------- --------- --------- ------------------------ > > --------------- > ---------- -------------------- ---------- > > MPS_7_YE- ACTIVE BA14_L Policy set for MPS XXXXXXXX > 19-07-202- No > > ARS server 2 > 11:46:- > > > > > 26 > > > > MGMTClasses: > > Policy Policy Mgmt Default Description > > Domain Set Name Class Mgmt Clas- > > Name Name s ? > > --------- --------- --------- ---------- > ------------------------ > > MPS_7_YE- MPS_7_YE- BA14_L Yes Management > Class for > > ARS ARS MPS server 14 > days > > backup > > MPS_7_YE- MPS_7_YE- BA7Y_L No Management > Class for > > ARS ARS MPS server 7 > years > > backup > > > > Cloptset: > > Optionset Description Last Update > by Managing profile Replica Option > > > (administrator) Set > > ------------------------- ------------------------- > --------------- -------------------- --------------- > > MPSSERVER Optionset for the MPS XXXXXXXX > No > > server > > > > Option Sequenc- Use Optio- Option Value > > e number n Set > > Value > > (FORCE) > > ------------------------- -------- ---------- > ------------------------------------------------------------ > > DIRMC 5 Yes BA14_L > > INCLEXCL 0 Yes INCLUDE.BACKUP > d:\MSP\...\*.* BA7Y_L > > INCLEXCL 1 Yes INCLUDE.BACKUP > d:\FTPDATA\sapdw\...\*.* BA7Y_L > > INCLEXCL 2 Yes INCLUDE.BACKUP > d:\FTPDATA\workathome\...\*.* BA7Y_L > > INCLEXCL 3 Yes include.backup > d:\...\*.* BA14_L > > INCLEXCL 4 Yes include.backup > c:\...\*.* BA14_L > > > > ******************************************************** > > For information, services and offers, please visit our web site: > http://www.klm.com > aQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV > 37I&m=KR3f4affZjpqLkgzlwG7WLHBqy-WmemI9QwNx0QqLpbFUGybfBO6XXQ5gHXpPW8L > &s=oHHbWf0pt3qVVMl7FYrAixy0Es1aQpX-8MPthG-q-T4&e= . This e-mail and > any attachment may contain confidential and privileged material > intended for the addressee only. If you are not the addressee, you are > notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > ******************************************************** > > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department (UW Medicine), System Administrator > -- Foege Building S046, (206)-685-7354 > -- Pronouns: He/Him/His > ******************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com > aQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV > 37I&m=KR3f4affZjpqLkgzlwG7WLHBqy-WmemI9QwNx0QqLpbFUGybfBO6XXQ5gHXpPW8L > &s=oHHbWf0pt3qVVMl7FYrAixy0Es1aQpX-8MPthG-q-T4&e= . This e-mail and > any attachment may contain confidential and privileged material > intended for the addressee only. If you are not the addressee, you are > notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any delay > in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ******************************************************** > > Unless stated otherwise above: > Kyndryl Česká republika, spol. s r. o. > Sídlo: V Parku 2294/4, Chodov, 148 00 Praha 4, > IČ: 096 28 886 > Zapsaná v obchodním rejstříku, vedeném Městským soudem v Praze (oddíl > C, vložka 339277) Registered address: V Parku, 2294/4, Chodov, 148 00 > Prague 4 Company ID: 096 28 886 Registered in the Commercial Register > maintained by the Municipal Court in Prague (Part C, Entry 339277 > ******************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com > aQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV > 37I&m=KR3f4affZjpqLkgzlwG7WLHBqy-WmemI9QwNx0QqLpbFUGybfBO6XXQ5gHXpPW8L > &s=oHHbWf0pt3qVVMl7FYrAixy0Es1aQpX-8MPthG-q-T4&e= . This e-mail and > any attachment may contain confidential and privileged material > intended for the addressee only. If you are not the addressee, you are > notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any delay > in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ******************************************************** >
