In this mail, it really sounds like you're using your DD as both primary 
storage and for TSM storage.

If the DD box fails, what are your losses?

Sorry for all the questions, I'm just trying to get an idea how you're using 
this box. It's sounds alot like you're using it both as a filer and as TSM 
storage. That means if you loose it, you've lost both the primary storage (the 
filer part) and your primary storage within TSM (the storage pool). That means 
you have to restore the data from somewhere else (tape?).

Best Regards

Daniel



Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: "Allen S. Rout" <asr AT UFL DOT EDU>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 09/27/2011 22:59
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file 
systems for pirmary pool

On 09/27/2011 02:48 PM, Daniel Sparrman wrote:

> When u bought it, did they think you're gonna use it as a
> fileserver?

Well, exactly.

> I'm not to specialized into Data Domain, but arent they marketed as
> backup hardware? So you get a disk, but if you want to use it for
> something else than that, you need to pay a license?

> Sorry for sounding bitter, but I've always heard people referring to
> Data Domain as a VTL.


DD is deduplicated storage, plain and simple.  There are more general
ways to use it, and more specific.

For example: Say you dump a MySQL database to disk; where do you put
it?  You can dump daily, compress, stick it in a directory and manage
it. I do this for several of customers.

With a DD in the picture, you NFS-mount a share, and dump to NFS.  You
don't compress, you let it dedupe and compress thereafter.  Resulting
space occupation is substantially smaller than the bzip2 -9ed
allocation of the same set of files.


Less simple: Say you've got an Oracle database.  Any one else out
there with one of those? ;) RMAN dumps its stuff to "somewhere".  We
now use a somewhere on the DD.  We're currently getting dedupe numbers
in excess of 30:1

Different use-case: lots of VMWare VStorage backups dump their image
files, to... "somewhere".  Most of them are happy with a CIFS share.
If that's provided by the DD, then it gets deduplicated in a manner
that leverages all the other stuff on the same DD device.


So, these are very general methods: "I got a NFS mount"; "I got a CIFS
mount".  They bootstrap common, existing hardware and software.  Your
dedupe appliance already talks to the network, why not make it talk
fast, and then use that for service provision?


Exposing that filesystem via FC requires a bunch of additional code,
and a bunch of additional hardware.  So it's a separate feature, and
you can unbundle it if you like.  We did.

Some applications are unwilling or unable to talk to a share (I'm
lookin' at you, DPM...) so you have to get the extra features to
enable the additional type of fabric connection and the extra protocol
translation.



- Allen S. Rout