ADSM-L

Re: [ADSM-L] Reuse Delay

2011-10-04 14:49:21
Subject: Re: [ADSM-L] Reuse Delay
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 4 Oct 2011 14:16:37 -0400
A non-zero reuse delay on your primary pool protects you from a situation
where you need to restore your database, but your primary pool tapes are
not lost.  (Not a full DR situation).

If you have a reuse delay of 0, you will still have the data available in
the copypool, but if you wanted to get back into a full production state,
you will need to audit all the volumes in your primary storage pool and
rebuild the lost data from the copypool.  (You will be able to service
restore requests during this time, but it will take a long time to fully
recover)  If you don't have than many volumes in the pool and a small
library, it might be worth it.

Ideally, if you can afford the slots and tapes, you would have a reuse
delay on both pools that will match the amount of time you retain your DB
backups.

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
ceh AT INDIANA DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
10/04/2011 10:38 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
[ADSM-L] Reuse Delay






Good Morning/Afternoon/Evening fellow TSM Adminers,

I have a question to pose to the group about the Reuse Delay parameter and
what is the best way to utilize or not utilize it on your storage pools. I
have come across two different schools of thought on this subject and
before I do something rash and change a config setting, that might regret
changing later, I thought I would pose the question to the group.

One school of thought on this subject is to keep the reuse delay parameter
of your primary pool set to zero days while setting the reuse delay
parameter to 5 on your copy pools.  The idea behind this being that even
if you do need to restore your database to an older version the file
references that are no longer available in your primary pool will still be
available in your copy pool while letting you reuse volumes in your
primary pools sooner.

The second school of thought is that the reuse delay on your primary pool
and your copy pool should both be the same giving you the greatest chance
to cover your posterior in the event of a database meltdown since you will
have two copies of the files that an older database version might
reference.

With all this in mind, I just wanted to see what method other TSM Admins
thoughts about this are and what they are using in their environments.

Thanks,
Chad Harris



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.

<Prev in Thread] Current Thread [Next in Thread>