I would just mark all the tapes that are not in the library as "unavailable",
then run your "copy activedata". When It finishes, eject as many tapes as you
can and put in other tapes. It will tell you which tapes that were needed, but
were marked unavailable in the actlog. Change the unavailable/readw flags
around and repeat until you get through all the tapes it asks for.
At the end, mark all of them readw again and rerun the copy activedata to catch
any stragglers.
I don't know how expire inv affects the active data pool though. The word
"expire" is used in two contexts in TSM and is confusing. The TSM client
"expires" data in its logs, but it is actually making it inactive. This is
different than the expiration that happens with the expire inventory process.
Hopefully, the active data pool only needs to identify inactive files during
the reclamation.
Insert usual comments about not expiring data in TSM here....
Regards,
Shawn
________________________________
Shawn Drew
> -----Original Message-----
> From: ADSM-L AT VM.MARIST DOT EDU [mailto:ADSM-L AT VM.MARIST DOT EDU]
> Sent: Friday, November 08, 2013 6:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Active Storage Pools
>
> Does anyone have much experience with active storage pools?
>
> My current customer isn't allowed to reclaim tapes, so their inventory of
> primary storage volumes is much larger than their ATL. This makes client
> restores prone to failure because of the number of primary volumes that
> need manual intervention as well as the lack of routine operational
> support at the site.
>
> I'm considering creating an active storage pool. Once fully populated, its
> tapes would remain in the ATL; mere primary volumes would be on-site but
> not in the ATL. I know I can start to create it by defining an active data
> pool to be written to as primary tapes are being written to (we already
> use this for copy volumes), but there's still the matter of copying into
> the active pool the active data on the existing primary storage volumes.
> Is there any way to build the active storage pool in phases, such as "all
> the data that's four weeks old or younger" or "all the data on volumes
> that are available; don't flinch at volumes that don't mount"? Otherwise,
> the COPY ACTIVEDATA process is going to run 24x7 for a long, long time. If
> I cancel an COPY ACTIVEDATA command and then start a new one, does it
> correctly understand what it no longer has to copy?
>
> Do reclaims of active data storage pools rely upon EXPIRE INVENTORY
> running regularly? We haven't been running EXPIRE INVENTORY out of an
> abundance of caution to avoid any risk that we lose track of an inactive
> object someone might demand from us, but I suspect we'll need EXPIRE
> INVENTORY to keep the active pool correctly populated. I can imagine how
> to set the retention policies to mimic not running EXPIRE INVENTORY, but
> that still might make Some People nervous.
>
> Thanks to Wanda's tip about EXPORT NODE a couple of weeks ago, I think I
> know how large (roughly) my active data pool would be if I create it and
> populate it.
>
> What am I forgetting? Is my plan fatally flawed?
>
> TSM Server 6.3.4, if it matters.
>
> Thanks,
> Nick
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
|
