• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

move nodedata for copypools

sra006

ADSM.ORG Member
#1
I am consolidating data in the primary pools by 'move nodedata ' .
The data is for nodes that are not active/decommissioned.
After consolidation the data is moved to a new pool.
i.e old-backup_pool --> new_nactive_pool.
The copy of the data resided on the old-copy pool.
I ran move nodedata node_name fromstgpool=old_copy-pool tostgpool_old_copy-pool
with intention to consolidate the copy volumes.
The job ran with success almost instantly,
I think the data on the primary pool is already consolidated and the copies are pointing to new pool.
However the volumes on the copypool still shown in the q nodedata command.
Nothing got consolidated yet.
My question : Do I need to run backup new_inactive_pool to old_copy_pool to force the consolidation of the copy volumes?
Does anyone had a similar issue?
Thank you,
Al
 

marclant

ADSM.ORG Moderator
#2
The copypool didn't change by your primary pool consolidation. The objects that are in the new pool that were already in the copy pool are still in the copy pool and still referencing the same objects. So if you were to lose the new primary pool today, you can recover it from the existing copypool.

You can use move nodedata to do a similar thing on the copy pool, with the exception that you can't move the data to a different copy pool.
 

sra006

ADSM.ORG Member
#3
Thank you for the reply.
I did try to do exactly this : move nodedata nodeX fromstgpool=copyX tostgpool=copyX and it did run for a second with cc=0.
The q nodedata still shows the same allocation for multiple copy tapes.
One thing I noticed was that the copy pool has a 10 day volume reuse.
Could this be the cause for the delay?
Thank you,
Al
 

sra006

ADSM.ORG Member
#5
I finally have an answer to the issue.
Very simple , - there is an undocumented ( at least I could not find it) restriction on move nodedata for copy pools.
In order to consolidate it all the copy pool volumes must be on site. In my case the copypool was an offsite pool.
Quite interesting that the message completion is "successful" , while it should be changed to something meaningful like "process completed , data was not moved"
and my mental block of assuming that the command works aka reclamation is gone now.

“Truth is what stands the test of experience.”
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 9 22.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 19 47.5%
  • Let's be formal and just say Spectrum Protect

    Votes: 8 20.0%
  • Other (please comement)

    Votes: 4 10.0%

Forum statistics

Threads
31,001
Messages
131,978
Members
21,255
Latest member
pzzl321
Top