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.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -----"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> skrev: ----- Till: ADSM-L@VM.MARIST.EDU Från: "Allen S. Rout" <a...@ufl.edu> Sänt av: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.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
