Weird requirement.
Not something that I'd recommend. And I don't see the logic for having only
part of the data, but, its an intellectual challenge as to how this can be done.
Try this
Set up a random diskpool big enough to hold one nights backup. Point backup at
this.
Set up a main sequential file diskpool. Make this the nextstg of the nightly
pool with manually controlled migration between the two.
Each day, run a backup stg from the nightly pool to the tape pool and send the
tapes off site. Then migrate the nightly pool to the main pool.
Script a tape return process keyed on the state and update date of the drmedia
table.
When the tapes come back, run a delete vol discardd=yes on them.
HTH
Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia
>>> mds AT HELICES DOT ORG 02/03/2004 13:05:26 >>>
My client has an existing TSM setup that is quite different from the
textbook examples ;>
They are running TSM v5.1.5.4 on Windows 2000, and also have DRM.
Currently, they are keeping seven (7) versions for 150 days, and the
backups are going to a 6TB array. That's right -- currently, there is
*no* tape involved.
In January, they bought an Overland LoaderXpress LTO-2 system, including
one (1) magazine with eleven (11) slots. Can anybody comment on any
gotchas using this device with TSM?
The client says that they want to copy daily to tape only the most
recent version of files that have changed since previous day.
They will accept copy daily to tape all most recent file versions.
Each morning, those tapes last written will be taken offsite, and tapes
from seven (7) days ago brought back onsite and available.
Furthermore, there are two (2) offsite locations, one for Windows
platforms, and one for *NIX platforms.
I am thinking that this can be accomplished by _archiving_ from the
arrays to tape. I am not clear how to specify policy. Any ideas?
Their idea is, in the event of catastrophic failure at the current data
center, the offsite tapes will facilitate recovery at a remote site.
Everything is file based, including SQL Server dumps generated by DBA's.
The array is said to meet their onsite expectations, and they have
successfully recovered files from it during production. As far as I
have determined, this client has never actually restored a whole machine
nor application.
Moreover, although they have DRM, previous consultants have left it
untouched, and implemented a plethora of scripts to facilitate disaster
recovery. Unfortunately, the staff do not understand the scripts, and
have disabled all of them.
Please, consider this an invitation to comment, criticize, suggest
alternatives, &c.
What do you think?
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipients(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipients(s), or if you have received this e-mail
in error, you are asked to immediately notify the sender by telephone or by
return e-mail. You should also delete this e-mail message and destroy any hard
copies produced.
***********************************************************************************
|
