Re: [ADSM-L] Using pools during restore

Unfortunately, it is quite difficult to move pools offline due to other active 
operations.
I have very fast VTL primary and FILE copy pools at HO, but sometime TSM Server 
is selecting the slowest NFS copy pool from DRS for restore operation.

Grigori G. Solonovitch
Senior Systems Architect  Ahli United Bank Kuwait  www.ahliunited.com.kw

Please consider the environment before printing this E-mail


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Nick Laflamme
Sent: 14 04 2013 12:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Using pools during restore

"UPDATE STG pool1 ACC=UNAVAIL"  would tell TSM not to try to use that 
particular storage pool. That might be heavy-handed in normal operations, but 
it works well in DR situations.

What problem are you really trying to solve? :-) You're going to have the same 
"rehydrate" performance penalty whether it's VTL or NFS, for example.

Nick


On Apr 14, 2013, at 4:22 AM, Grigori Solonovitch <Grigori.Solonovitch AT 
AHLIUNITED DOT COM> wrote:

> Configuration:
>
> -          TSM Server 6.3.3.100 AIX 7.1-01-06;
>
> -          Primary pools are on Data Domain VTL, copy pools on FILE storage 
> pools out of Data Domain.
> Is there any way to control which pool (primary, copy 1, copy 2, ...) is used 
> during restore operations?
>
> Thank you very much in advance.
>
> Grigori G. Solonovitch
> Senior Systems Architect  Ahli United Bank Kuwait  www.ahliunited.com.kw



Please consider the environment before printing this Email.

________________________________

CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.