Hi,
Hi,
First deteremine what is the slowest chain in your restore path.
Following assumes tapes are the weak point.
First check the actual impact of tape speed on your restore time:
Try once a dsmc select backup
for small portion of file server, maybe 1 GB consisting from your
typicall small files.
Be sure you have enough place in your disk storage pool to keep this
backup and allow no reclamation.
Test restore time from this backup.
Compare this to restore times you get when restoring from incrementals
=> from tapes.
Probably there will be significant penalty resulting from keeping small
files on tape drives.
If so, and only then,
try to use even better tapes if you can afford, (1)
try to use more tape drives in parallel even for single restore, (2)
try to reduce tape usage at all, (3)
try smarter, not harder (4)
1)For small files on tapes
search, rewind, mount/unmount, start/stop times
and not data transfer rate are important.
Give a look to either 3590 or AIT, they might be better in this point.
3575 definitely is better here, but the capacity is not acceptable any
more.
2)
a)if your file server has more file systems, use a)if your file server has more
file systems, use collocation=filesystem
(check for correct syntax, please)
and be sure to use enough tapes to allow backups really be spread over
more media.
This will allow parallel restores from more tapes.
Yes, you would have to start more restores manually, one session for
each file system.
b)With 10(!) tape drives you even can think about collocation=off.
I know, it is heretic, but this would spread your files over many tapes,
thus allowing more parallel restores to use more tape drives in
parallel.
You would have to start more restores at once to profit from this,
each restore for different directory or file system.
On the other side there would be penalty from even more tape mount and
seek operations.
The usability would strongly depend on your actual data and hardware,
surely a thing to be thoroughly tested, not a generall recommendation.
c) define a couple TSM nodes on your file server and let them backup
alternative parts of it. Not nice from managament point of view,
but this would easilly allow for controlled collocated environment
thus parallel usage uf tapes during restore.
3)keep your disk storage pools (very) large and try to keep them
as many data from your file server as possible. There are many ways to
optimise this, you may want , for example,
to create a management class for files beeing
notoriosly small and a separate disk storage poll for them.
This is common practise for smallest files possible: fordirectories,
isn´t it?
4)as others mailed, try disk extender.
Or consider file server cluster which might eliminate the need for
disaster restore.
5) Other thoughts: test your file server how auickly they are able to
create small files.
How quickly runs a xcopy with small files?
Do you use GUI TSM or command line? GUI is notoriously slower with small
files comparing to command line.
6)share your experiences with us once you have worked it out for you.
regards
Juraj Salak
A&H Familienholding
|
