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 AT VM.MARIST DOT EDU on behalf of storman AT US.IBM DOT 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 | storman AT us.ibm DOT 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 AT VM.MARIST DOT EDU> wrote on 2016-01-24
>05:40:40:
>
>> From: Erwann SIMON <erwann.simon AT FREE DOT FR>
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Date: 2016-01-24 05:41
>> Subject: Re: Copy Mode: Absolute misunderstanding
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT 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" <rouzen AT UNIV.HAIFA.AC DOT IL>
>> À: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On
>> Behalf Of Erwann SIMON
>> Sent: Saturday, January 23, 2016 8:08 PM
>> To: ADSM-L AT VM.MARIST DOT 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" <rouzen AT UNIV.HAIFA.AC DOT IL>
>> À: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On
>> Behalf Of Arbogast, Warren K
>> Sent: Friday, January 22, 2016 8:22 PM
>> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU on behalf of Thomas.Denier AT JEFFERSON
>> DOT 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 AT VM.MARIST DOT 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.
>> >
>>
|
