Re: [ADSM-L] Win Server 2008 question
2010-06-10 23:27:58
----- "Andrew Raibeck" <storman AT US.IBM DOT COM> wrote:
> > Any one know anything about this ...
>
> > ... and how to avoid its effects?
>
> a) Hardware deduplication in your TSM server storage.
>
> b) TSM deduplication (6.1 and up for server-side, 6.2 for
> client-side)
>
> c) Progressive incremental backup of the system state's System Writer
> component (TSM 6.2 client, compatible with TSM version 5.5 and 6.1
> servers)
>
> (a), (b) and (c) help reduce TSM server storage requirements.
>
> (c) also helps reduce impact to the TSM server database.
>
> Best regards,
>
> Andy
Just a side note to Andy's comment - if I understand it correctly, the dedup in
TSM works with file pools only. Regrettably that means there's no saving in
tape slots, TSM database size, copy pool tapes, etc., but it does allow a heap
more data to be stored within a file pool, and with the features in 6.2 this
can be realized immediately rather than only after processing.
Hardware dedup - e.g. ProtecTIER - is a more complete way to save on TSM
storage, but comes at a cost which may or may not be justified by the savings
in space alone.
What's the impact on restoring the system state when using (c) above? I'm
guessing eventually it means more tape mounts unless there's some pretty
aggressive collocation going on.
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: [ADSM-L] Win Server 2008 question,
Xav Paice <=
|
|
|