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