Hello TSM folks...
What is the prevailing opinion of TSM de-duplication?
I'm in the middle of building out a fresh TSM 7.1.1 install (on RHEL6,
x86_64, w/TDP for VE {vsphere}), and the de-dupe feature could really come
in handy -- I've already read the documentation and believe I have enough
Aside from distribution of processing, are there clear benefits one way
or the other, between client-side and server-side de-dupe?
Client-side dedup has a impact on backup storagepool to tape performance.
Client-side dedup is much more reclaim (and reuse delay) friendly.
Client-side dedup
What is the OS platform of the client? It matters. The reason is that
the restore process must rebuild the directory tree on the client system
before it can repopulate it by restoring the files, and with that many
files it is likely a complex directory tree.
If it's Windows, you may be seeing a
Dear TSM Folks,
Has anybody tried this approach to enhance tape drive availability ?
Create 64 tape drives in data domain and allocate 32 tape drives only for
TSM server backup ( Lan based backup) and remaining 32 tape drives dedicate
for storage agent
Is this possible to implement this setup ?
Saravanan,
You could setup your tape library so that it is partitioned to use one
half for normal backup clients and one half for your storage agent(s), or,
you could setup your TSM server as a Library Manager and the storage
agent(s) as Library Clients. Since you are using a VTL, the library
Yes this will work and we use it now with our LanFree client.
My suggestion would be to create two libraries rather than splitting the drives
in half.
Each library with 32 drives would work.
Ron is correct in suggesting the use of a library manager configuration. This
works best for us.
I
When I worked in a TSM/DD shop with Data Domain VTLs, we did something a
little different: we defined for each TSM server both a normal VTL
instance and a LAN-free library for any storage agents. The TSM master
server needs access to the LAN-free library so it can mount tapes and
validate tape
Thanks for your response ,
Why 32 drives ?
Yes VTL can write 10 TB/ hr without DD Boost
I may not start with 32 but still need to calculate total number of servers ,
any time constraint and database size to decide the count
By Sarav
+65-82284384
On 16 Sep, 2014, at 1:57 am, Nick
I never said 32 drives. In fact, they routinely defined 48 drives per
library, although I don't think they ever had that many in use. Larger
numbers let more large clients (databases, mostly) use more streams
(drives) concurrently, but at some point, the SAN becomes a limiting
factor, if the
Thanks Ronald. That was an example because I have only 10 LAN free client to
start with setup , mostly will allocate 16 drives for LAN free ( multiple
database in the same server)
By Sarav
+65-82284384
On 16 Sep, 2014, at 1:02 am, Ron Delaware ron.delaw...@us.ibm.com wrote:
Is this not what mountlimits are for?
Set up two device classes in the same library, one with mountlimit of
32 and one with maybe 40
The device class that your normal TSM stgpools and operations use is
the one with 40 mountlimit. TSM server can use up to any 40 of the 64
drives. The lan free
11 matches
Mail list logo
