Re: Tuning TSM
2002-05-17 17:24:42
Reading thru this thread, no one has mentioned that backup will be slower
than archive -- for TWO significant reasons:
1. The "standard" progressive-incremental requires alot of work in comparing
the attributes of all files in the affected file systems, especially for a
LARGE number of files/directories (whereas archive has minimal database
overhead -- it just moves data).
2. Writes to disk are NOT as fast as tape IF the data can be delivered to
the tape device at "streaming" speed; this is especially true if using
no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might
compete if multiple paths & controllers are configured. The big advantage
to disk pools is more concurrent backup/archive operations, then
disk-migration can stream offload the data to tape.
So, firstly, debug fundamentals using tar and archive commands (to eliminate
db overhead comparing file system attributes to identify "changed"
files/objects); once you are satisfied with the thruput for archive, allow
20-50% overhead for daily incremental. If your best "incremental" experience
is not satisfactory, (but archive is okay) consider other options discussed
in the performance-tuning papers -- such as, reducing the number of files
per file system, use incrbydate during the week, increase horsepower on the
client machine and/or TSM server (depending on where the incr. bottlenecks
are).
The SHARE archives do not yet have the Nashville proceedings posted; when
they do show up, they are in the members-only area (I was just there,
searching for other sessions).
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Tuning TSM, (continued)
- Re: Tuning TSM, Zlatko Krastev
- Re: Tuning TSM, Ignacio Vidal
- Re: Tuning TSM, Ignacio Vidal
- Re: Tuning TSM, Cook, Dwight E
- Re: Tuning TSM, Ignacio Vidal
- Re: Tuning TSM, Seay, Paul
- Re: Tuning TSM, Zlatko Krastev
- Re: Tuning TSM, Ignacio Vidal
- Re: Tuning TSM,
Don France (TSMnews) <=
- Re: Tuning TSM, Bern Ruelas
- Re: Tuning TSM, Seay, Paul
|
|
|