Robert Ouzen,
Using copy mode: absolute worked quite well, but not perfectly for our 
purposes. Since it does honor include/exclude statements it did not backup all 
files that were in storage. So there was some cleanup to do afterward (move 
node data fromstg=VTL tostg=b). The target of the mode node data could not be 
the DEDUP pool, but the count of orphan files was small so we moved them to 
tape. It did accomplish 99% of what we wanted it to do, which was to hurry up 
the migration to the DEDUP pool. Keep in mind that an absolute backup increases 
total storage temporarily, till retextra and retonly expire, since it creates a 
new active version for every file, and all the previous active versions are 
promoted to inactive status. For some Linux/Oracle nodes there was also the 
curious case of nodes which had one file per filesystem remaining in in the VTL 
after all the other inactive versions had expired. Five filesystems, five 
files. I can’t make up a story for that one. I used move nodedata again to move 
them off the VTL. 

Best wishes to all,
Keith Arbogast
Indiana University



On 1/25/16, 10:35, "ADSM: Dist Stor Manager on behalf of Andrew Raibeck" 
<ADSM-L@VM.MARIST.EDU on behalf of stor...@us.ibm.com> wrote:

>Hi Erwann,
>
>This option was added to the product, starting with version 6.4.1, through
>APAR IC91871:
>
>http://www.ibm.com/support/docview.wss?uid=swg1IC91871
>
>Best regards,
>
>- Andy
>
>____________________________________________________________________________
>
>Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com
>
>IBM Tivoli Storage Manager links:
>Product support:
>http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager
>
>Online documentation:
>http://www.ibm.com/support/knowledgecenter/SSGSG7/welcome
>Product Wiki:
>https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager
>
>"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 2016-01-24
>05:40:40:
>
>> From: Erwann SIMON <erwann.si...@free.fr>
>> To: ADSM-L@VM.MARIST.EDU
>> Date: 2016-01-24 05:41
>> Subject: Re: Copy Mode: Absolute misunderstanding
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
>>
>> Hi Robert,
>>
>> I thought that it's a new option in the 7.x branch, not already
>> available in 6.x. Anyway, this absolute option does not appear in 6.
>> 4 client documentation.
>>
>> --
>> Best regards / Cordialement / مع تحياتي
>> Erwann SIMON
>>
>> ----- Mail original -----
>> De: "Robert Ouzen" <rou...@univ.haifa.ac.il>
>> À: ADSM-L@VM.MARIST.EDU
>> Envoyé: Dimanche 24 Janvier 2016 07:12:58
>> Objet: Re: [ADSM-L] Copy Mode: Absolute misunderstanding
>>
>> Hi Erwann
>>
>> IN client 6.x.x..x I have to the option of copy mode ABSOLUTE .....
>> so why I nned client vrsion 7+ ?
>> It will not work ?
>>
>> Best Regards Robert
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
>> Behalf Of Erwann SIMON
>> Sent: Saturday, January 23, 2016 8:08 PM
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: Re: [ADSM-L] Copy Mode: Absolute misunderstanding
>>
>> Hello Robert,
>>
>> If you only have client whose version is 7.1 or later, you can also
>> use the absolute option :
>>
>> Use the absolute option with the incremental command to force a
>> backup of all files and directories that match the file
>> specification or domain, even if the objects were not changed since
>> the last incremental backup.
>>
>> This option overrides the management class copy group mode parameter
>> for backup copy groups; it does not affect the frequency parameter
>> or any other backup copy group parameters.
>>
>>
>> --
>> Best regards / Cordialement / مع تحياتي
>> Erwann SIMON
>>
>> ----- Mail original -----
>> De: "Robert Ouzen" <rou...@univ.haifa.ac.il>
>> À: ADSM-L@VM.MARIST.EDU
>> Envoyé: Samedi 23 Janvier 2016 16:12:07
>> Objet: Re: [ADSM-L] Copy Mode: Absolute misunderstanding
>>
>> Hi Keith
>>
>> I am curious of the result .
>>
>> I need too, to back up to a new storage pool of type directory
>> container (new feature inV7.1.4).  Cannot do a nextstg or move nodedata.
>>
>> So want to try your suggestion COPY MODE ABSOLUTE for now I did in
>> another way.
>>
>> Rename the node to node_OLD   (all FI are with extension _OLD after
>> it) , recreate the node and change the destination to the new
>> storage directory.
>>
>> After a wild delete the OLD FI and OLD node.
>>
>> My copypool looks like this:
>>
>> Policy Domain     Policy Set Name      Mgmt Class Name   Versions
>> Data Exists        Versions Data Deleted         Retain Extra
>> Versions          Retain Only Version    Copy Mode     Copy Destination
>>
>> CC                           ACTIVE                      MGCC12
>> 4                                          1
>> No Limit                                60
>> Modified          NET_TSM
>>
>> So  need to change to
>>
>> Policy Domain     Policy Set Name      Mgmt Class Name   Versions
>> Data Exists        Versions Data Deleted         Retain Extra
>> Versions          Retain Only Version    Copy Mode      Copy Destination
>>
>> CC                           ACTIVE                      MGCC12
>> 4                                          1
>> 10                                          10
>> Absolute             V7000_D1
>>
>> So after 10-11 days all my 3 inactive versions will vanish  from STG
>> NET_TSM ....... correct >
>>
>> Best Regards
>>
>> Robert
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
>> Behalf Of Arbogast, Warren K
>> Sent: Friday, January 22, 2016 8:22 PM
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: Re: [ADSM-L] Copy Mode: Absolute misunderstanding
>>
>> Hi Thomas,
>> Thank you for your insight. RETONLY was 60 days during the absolute
>> backups. We just reduced it to 30 days this morning when we saw
>> unexpected files on the VTL. Perhaps tomorrow the VTL will look better.
>>
>> Best wishes,
>> Keith Arbogast
>> Indiana University
>>
>>
>>
>>
>>
>>
>> On 1/22/16, 13:11, "ADSM: Dist Stor Manager on behalf of Thomas
>> Denier" <ADSM-L@VM.MARIST.EDU on behalf of thomas.den...@jefferson.edu>
>wrote:
>>
>> >Is RETONLY also set to 30 days? If RETONLY is longer than 30 days,
>> backup copies some files deleted before the absolute backups would
>> be retained for more than 30 days after the absolute backups.
>> >
>> >Thomas Denier
>> >Thomas Jefferson University
>> >
>> >-----Original Message-----
>> >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
>> >Of Arbogast, Warren K
>> >
>> >We have implemented directory container pools in TSM version 7.1.4
>> and are happy with it.  All new backups are written to the DEDUP
>> pool, and old backups are being migrated from the VTL to the DEDUP
>> pool through a process of replicating existing nodes' files to a
>> DEDUP pool on a target server,  then replicating them back to the
>> DEDUP pool on the source server. That process works well.
>> >
>> >There is an urgency to empty the storage previously used on the VTL
>> so it can be re-purposed. To hurry the migration to the DEDUP pool
>> along we devised a strategy of running FULL backups (COPY MODE:
>> ABSOLUTE) on certain small servers in policy domains whose
>> destination was the DEDUP pool. That would promote all of a node’s
>> previous backups on the VTL to Inactive status. And, since the
>> pertinent RETAIN EXTRA VERSIONS setting was ’30’, we expected within
>> 30 days all inactive versions would be expired and removed from the VTL.
>> >
>> >It’s 30 days later, and the strategy did not work perfectly. There
>> are thousands of files remaining on the VTL for nodes which had  a
>> COPY MODE: ABSOLUTE backup.
>> >
>> >What am I misunderstanding about COPY MODE: ABSOLUTE?  I had
>> understood it would force a 100% full backup, with no mitigation by
>> include and exclude  statements. Apparently that’s not the case.
>> Could someone clarify how it works?
>> >
>> >The information contained in this transmission contains privileged
>> and confidential information. It is intended only for the use of the
>> person named above. If you are not the intended recipient, you are
>> hereby notified that any review, dissemination, distribution or
>> duplication of this communication is strictly prohibited. If you are
>> not the intended recipient, please contact the sender by reply email
>> and destroy all copies of the original message.
>> >
>> >CAUTION: Intended recipients should NOT use email communication for
>> emergent or urgent health care matters.
>> >
>>

Reply via email to