ADSM-L

Re: [ADSM-L] Data Deduplication

2007-08-30 10:37:02
Subject: Re: [ADSM-L] Data Deduplication
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 30 Aug 2007 10:34:47 -0400
>> On Wed, 29 Aug 2007 13:40:34 -0600, Kelly Lipp <lipp AT STORSERVER DOT COM> 
>> said:


> I'd like to steer this around a bit.  Our sales folks are saying
> they are losing TSM opportunities to de-dup vendors.  What specific
> business problem are customers trying to solve with de-dup?

> I'm thinking the following:

> 1. Reduce the amount of disk/tape required to storage backups.
> Especially important for all an all disk backup solution.

which I love.

"We don't need tape, because disk is cheap!"
[...hiatus...]
"We have to save disk!  Buy (and integrate, and manage) a new product!"



> 2. Reduce backup times (for source de-dup I would think.  No benefit in
> target de-dup for this).

> 3. Replication of backup data across a wide area network.  Obviously if
> you have less stored you have less to replicate.

> Others?  Relative importance of these?

> Does TSM in and of itself provide similar benefits in its natural
> state?  From this discussion adding de-dup at the backend does not
> necessarily provide much though it does for the other traditional
> backup products.  Since we don't dup, we don't need to de-dup.

I think a back-end de-dup (de do da da) would still offer advantages
to TSM: if you've got mumblety-hundred (e.g.) Win2K boxen, then most
of their system and app space would be identical. This could,
concievably, end up as close to one system-images' worth of space on
the back end.  In a fantasy. :)

However, the server would need to do an awful lot of work to correlate
all these data.



- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>