Your policy appears to do what you intend. Keeping the retextra and
verexists at different numbers is kind of funny in my estimation. You can't
actually guarantee the ability to restore back 120 days so why have it. I
guess I liked your original better if the intent is to give the user the
ability to always restore back 120 days. I suppose you could go 30 30 30
120. That would keep the final copy of a file that has been deleted 120
days. Having blathered on I'll go back to the beginning. Yes, it does what
you say you want to do.
As for moving to SDLT. You could also create the new pool using the new
SDLT device class and set it as the next stg in the original DLT pool, drop
the migration thresholds and voila you're making new tapes. I don't really
know what the behavior will be when a tape is selected for migration: will
it move all of the non-collocated data on that tape to collocated output
tapes? Or will it do like it does in a disk storage pool: choose the client
occupying the most space in the pool and move all of that data? I'm
thinking the first is what will happen. Either way: lots of tape mounts
either the input tapes or the output tapes.
If I were doing it and I had a good bit of disk storage pool, I'd use move
data commands to disk and let migration happen later.
Another thought I had about collocating using SDLT. Since the tapes are so
large be careful about using collocation with small clients. You will find
that you have used lots of (expensive) tapes and few if any will be at
capacity. The way around that problem is to limit the number of scratch
tapes in the pool so that multiple clients are forced to share a tape. For
instance, if you have 30 small clients say less than 30 GB each, set
maxscratch to 10. Three clients per tape (or so no real good way to
predict) and the tapes will be fairly full. Be aware of the dreaded "server
out of data storage space" when using this technique.
Collocation is the way to go if you have the library space and enough tape
drives to speed migration. SDLT will have long mount times so lots of
mounts will be expensive. You probably have fast migration now. You won't
in the future! Be prepared for that.
I discussed the notion of limiting the maxscratch and some ways of making
sure you don't get bit. Search the adsm.org archives to find that.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (240) 539-7175
Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Scott G Davis
Sent: Monday, August 27, 2001 8:47 PM
To: [EMAIL PROTECTED]
Subject: Tivoli Setup
I have one Tivoli Server servicing 63 Netware and NT clients. I have a
two part question-
1. I run backup once a day. I want to be able to restore anything for
30days. After that, keep 30 versions for 120 days. I do not want to
get keep anything inactive past 120days. I was running at NOLIMIT,
NOLIMIT, 120, and 120. I was retaining too much data so I reduced it to
30, 30, 120, 120. Am I keeping too much still or not enough?
2. I am wanting to upgrade my tape technology from DLT to SDLT and I
am wondering the best way to accomplish this. Along with this I want to
switch to co-location to speed up restore times on large volumes. I can
add the drives to the libraries and issue move data commands for one,
but what else could be done to get the data copied to new tapes and
colocated at the same time?
Thanks,
Scott G Davis
Alltel
