Graeme,
I forgot to include the Networker list in my corespondents...perhaps other
readers could find value in our discussion.
I am also seriously looking at Diligent (as well as DDs VTL option). Their
offering is nice because it's just the dedup/VTL software and we can built
our own hardware around it ...even though it offers no replication feature
like DD. Most of our data is on Sun Solaris boxes with about 30-35% on
Windows (~30 TB total). We are also re-evaluating our commitment to
Networker as well as their Agent offerings are not as strong as some other
vendors. We are also looking at CommVault and Veritas.
I agree with your assessment of client-side deduping today, but think that
in the future things may change as CPU's get faster and more specialty
engines get added to them (like Sun's crypto engines this are on their T1
and T2 CPUs).
Thanks
--Brett
On Nov 1, 2007 3:07 PM, Graeme Parker <graeme.parker AT gmail DOT com> wrote:
> Hi Brett,
>
> We are not using the VTL option. If you want fiber connection to the DD
> box then that is the only way.... unless you use the gateway appliance
> attached to a SAN. You are still limited to the same number of TB if you go
> with the SAN vs directly attached storage. We are in the process of
> deciding if this will be an advantage for the VMware infrastructure and
> vRanger. Moving backups directly to the DD over the SAN would be great!
>
> I think there is a place for client side dedup but I don't see any
> advantages for our company. Backups alone are taxing enough on the system
> and I can't see any justification for buying bigger boxes just to do client
> side dedup. To the best of my knowledge no one else does dedup like DD and
> my biased opinion is the rest of the gang is playing catch up :) Most
> companies offer dedup but you need to write to disk first and then run the
> dedup and then store the deduped data. So 2x the disk to do something DD
> can on the fly. Not to say the rest of the gang won't ever offer this, but
> so far I'm unaware.
>
> Just a bit of an overview of our backup procedure.. We write everything
> to DD for 31 days, let the incrementals expire on disk and then move the
> monthly fulls to LTO4 tape for 12 more months... rinse, repeat.
>
>
> Graeme.
>
> On 11/1/07, Brett Monroe <mr.bmonroe AT gmail DOT com> wrote:
> >
> > Graeme,
> >
> > That's encouraging. are you using DD's VTL option? Do you do much
> > cloning of savesets to tape or restores during your backup windows? I am
> > very curious how DD handles concurrent reads and writes (performance wise).
> >
> >
> > I am starting to wonder, with the ever increasing speeds of CPUs, client
> > side de-duping during backup (Avamar, Puredisk, etc) might be the future of
> > de-duplication. Especially with products like Sun's T1 and T2 procs which
> > have built in crypto support (which could off-load the de-duping hash
> > generation).
> >
> > Thanks again,
> > --Brett
> >
> > On Nov 1, 2007 9:31 AM, Graeme Parker < graeme.parker AT gmail DOT com>
> > wrote:
> >
> > > Hi Brett,
> > >
> > > We currently have approx 40TB worth of Data Domain in our envrionment
> > > based on 460's, 560's, and 510s. They work great and generally see an
> > > average of 10x compression. If you are backing up any Virtual Machines we
> > > have seen compression ratios as high as 135x. Mind you this is with the
> > > backup of the vm not being compressed before being dumped to the DD.
> > > Support from DD has been excellent and we will continue to grow our
> > > infrastructure over the next few years. Client side Dedup in software
> > > over a
> > > LAN just seems silly as it requires process cycles on the client side.. it
> > > might make sense when sending data over a WAN as you only send the deduped
> > > bytes. That being said.... we use DD boxes in each remote region so since
> > > we
> > > own the LAN there is no worries about bandwidth usage and the DD boxes
> > > replicate over the WAN to the same effect. Having a dedicated device that
> > > does dedup on the fly has worked great for us. The only issue we have
> > > with
> > > Legato is its ability to understand there are two sets of data somewhere
> > > that it didn't move itself (post replication).
> > >
> > > Graeme.
> > >
> > > On 11/1/07, Brett Monroe < mr.bmonroe AT gmail DOT com > wrote:
> > >
> > > > Hey all,
> > > >
> > > > We are currently in the planning phase of dramatically transforming
> > > > out data
> > > > center's backup environment from the stone age (direct-attach tape
> > > > drives on
> > > > all servers doing fulls every night) to a more modern approach of
> > > > centralization. We are also looking to implement a data
> > > > De-Duplication
> > > > device in the mix but the offerings seem...immature. I was
> > > > wondering if any
> > > > of you fine folks have any experience with any of de-duping
> > > > technology
> > > > whether it's client based software (Avamar) or something that sits
> > > > in front
> > > > of a backup disk device (Data Domain, Diligent, etc). I'd be very
> > > > interested in hearing what your experiences have been.
> > > >
> > > > Thanks
> > > > --Brett
> > > >
> > > > To sign off this list, send email to [email protected]
> > > > type "signoff networker" in the body of the email. Please write to
> > > > networker-request AT listserv.temple DOT edu if you have any problems
> > > > with
> > > > this list. You can access the archives at
> > > > http://listserv.temple.edu/archives/networker.html or
> > > > via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
> > > >
> > >
> > >
> >
>
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
