Well -- The first step in our recovery scenario (after starting the newly
restored TSM server) deletes all administrative schedules. The second step
is to kill any running processes (usually an expire inventory :-). But -
since our TSM database goes off with the data tapes every day, it is in sync
with them; expire inventory won't cost us anything, providing we haven't
done any client backups of non-restored clients yet.
Now, FWIW, we don't do bare-metal Windows restores -- we reload and restore
the application data only; and the vast majority of our mandatory recovery
data is in the form of archives with a given retention -- mostly 21 day.
Loosing the oldest day or so of the archive is not an issue. Not being able
to recover the most current archive IS an issue. I can see where there would
be differences if we were backing up and recovering desktops (and I'm SO
glad I don't need to :-)
Tom Kauffman
NIBCO, Inc
-----Original Message-----
From: Gerald Wichmann [mailto:gwichman AT ZANTAZ DOT COM]
Sent: Friday, September 19, 2003 1:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM and DR
You guys are reading into the question WAY more then need be =). It was a
scenario question and all time lines were made up to drive home the point of
what I was trying to get at, and that's the potential for expire inventory
to expire data you maybe don't want expired. Even if your turn around for a
true disaster is supposedly 48 hours, I would imagine you'd still be
interested in what the question was getting at (if nothing else, just to be
aware of how TSM works if it was a concern).
Also it's a good point that you'd probably only be interested in ACTIVE
files when recovering your environment but none the less, humor me and
assume you're also interested in ensuring no INACTIVE version is lost. In
that case what can one do to ensure no data is expired AT ALL? The only
thing I can think of is to ensure expire inventory never runs. The
dsmserv.opt entry would help prevent that prior to recovering the database
but what about any admin schedules that might've been defined? Is it
possible to disable client and admin scheduling without first starting TSM?
Gerald
-----Original Message-----
From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
Sent: Friday, September 19, 2003 10:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM and DR
I agree with prior comments that you should have tapes available for DR that
are more current than 3 months back.
However, in MOST cases, even if expiration runs it probably won't cause
problems; TSM is NEVER going to be expiring the ACTIVE files associated with
a node. And in MOST cases for DR, you are trying to get your client
machines restored to the latest possible level.
Now where you get in trouble, is if you let the client run a new BACKUP,
before you have restored everything you need. When the client runs, it will
flag any files not on the hard drive as being expired, and that may have
side effects you don't want.
So I would say in a DR situation you should turn off your client schedules.
-----Original Message-----
From: Gerald Wichmann [mailto:gwichman AT ZANTAZ DOT COM]
Sent: Friday, September 19, 2003 1:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM and DR
Say for a moment you're faced with recovering a TSM server in a DR
situation. You have your DB backup and copypool tapes and perform a database
recovery. If that DB was created back in January and it's now March, isn't
there a potential for objects getting expired the first time you start the
TSM server? E.g. when the TSM server is started it typically performs an
expire inventory as part of that sequence. I would imagine that now that
it's 2 months later, would it therefore start expiring objects that you
probably don't want to have expired?
If not, why not?
If so, whats the appropriate step to take before starting the TSM server (or
perhaps even before recovering the DB) to ensure expire inventory doesn't
ruin your recovery? I recall there being an option in dsmserv.opt that
allows you to turn off automatic expire inventory. That seems like a good
idea.. but what if there was an admin schedule that runs expire inventory
back then and you happen to start the recovery while in the schedule's
window?
I think you can see what I'm getting at with all this. I want to make sure
all my bases are covered..
This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service. For more information, visit us at www.zantaz.com.
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law. If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent. Thank you.
This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service. For more information, visit us at www.zantaz.com.
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law. If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent. Thank you.
CONFIDENTIALITY NOTICE: This e-mail and any attachments are for the exclusive
and confidential use of the intended recipient. If you are not the intended
recipient, please do not read, distribute or take action in reliance upon this
message. If you have received this in error, please notify us immediately by
return e-mail and promptly delete this message and its attachments from your
computer system. We do not waive attorney-client or work product privilege by
the transmission of this message.
|
