Veritas-bu

[Veritas-bu] Backups to disk

2004-10-15 14:51:10
Subject: [Veritas-bu] Backups to disk
From: Sto Rage© <netbacker AT gmail DOT com> (Sto Rage© )
Date: Fri, 15 Oct 2004 11:51:10 -0700
Is there a reason why you chose NetApp NearStore just for Disk-based
backups? I mean, by doing so you are not taking advantage of NetApp's
snapshot or snapvault features, are you? So why buy a nearstore, when
you could buy an ATABeast from NexSan and hook it up as direct
attached to your media server and use it for disk-based backups and do
the stuff you are doing today - bpduplicate to tapes etc.
We are looking at the NearStore product from a completely different
angle , using their OSSV (Open System SnapVault) product. That gives
us the benefit of using the snapshot feature and block level
incrementals for Windows and Unix clients. In one of our evals we
found that it used just under 100GB of snapshot space for 13 weeks'
worth of backups for a source that had about 1.1 TB of total used
storage. Meaning the target disk consumed just 1.2 TB of space with 13
weeks of full backups. Try getting that kind of efficiency with
Veritas or any other virtual tape solution. The source has a lot of
large files (PST files) that change everday, so our incr to tapes (or
to disks for that matter) using Netbackup used to be almost like fulls
every night. With OSSV we may be able to increase the frequency of
daily incrementals, like twice or four times a day and still get the
kind of storage efficiency.
But then the product is still in a very early stage of development, no
integration with Veritas's netbackup (yet) and the Nearstore with all
the software licenses is very expensive overall. Thats why we are
looking to see other software products that provide similar feature
and will allow us to use any disk array hardware we choose. Data
Domain looks good, but then they too insist on providing thir own
disks and the units are not scalable. Each is limited to 2 TB raw. We
would like to utilize all the old/cheap disk arrays we have lying
around and pool them into a single disk pool behind some sort of head
that would do all the backups for us. Hope this is not a fantasy for
long.
Hope I am getting my point across.

-G



On Fri, 15 Oct 2004 10:55:51 -0700, White, Steve
<steve.white AT pacificorp DOT com> wrote:
> There are actually a number of "virtual tape" solutions out there that
> would provide what you're looking for, specifically they look like a
> tape drive to the backup application, but they're actually disk in the
> background, and they compress the data when you write it.  They may not
> keep just one copy, but at least they'll compress it for you, and when
> you "eject" a tape, it will create a physically for you to send offsite.
> Check out the VTL offerings from ADIC, EMC, StorageTek, Quantum, etc.
> I'm sure one of these devices might be just the ticket for you.
> 
> For us, we're using ATA disk in a NetApp NearStore to hold our
> disk-based backups.  We're not at 12TB per day, but it's still a pretty
> cost-effective solution.  We have found some bottlenecks in the
> "bpduplicate" process, which we're told has a fix in NBU 5.1 and will be
> permanently resolved in a future release.
> 
> Steve White
> 
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Sto
> Rage(c)
> Sent: Friday, October 15, 2004 8:29 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Fwd: [Veritas-bu] Backups to disk
> 
> Well, for one it uses the disks as virtual tape and dumps these large
> image files for every job. So you end up needing as many TB of disk
> space as you needed tapes. You cannot afford to keep a month's worth of
> data on disk, at least not for us. We have 12 TB of storage that needs
> to be backed up every day.
> Have you seen products from Data Domain or NetApp's SnapVault ? These
> are nice but even these force you to use their disks arrays.
> Wish there was a software or an appliance that would allow you to
> attach any disk
> array you want but will intelligently compress your backups such that
> they keep only one instance of a file and keep track of just the
> changed fragments.
> -G
> BTW, I don't work for either of these companies.
> 
> On Thu, 14 Oct 2004 21:19:52 -0400 (EDT), Steve Quan <sq01 AT yorku DOT ca>
> wrote:
> > Hi,
> >
> > Can you explain why (re:efficency) ?
> >
> > Thanks,
> > /Steve
> > ---
> >
> >
> > On Thu, 14 Oct 2004, [ISO-8859-1] Sto Rage(c)  wrote:
> >
> > > We have a lot of ATABoy and ATABeast units. But none of them are
> being
> > > used with Veritas for disk backups. We use them for online archives.
> > > We think Veritas's backup to disk is an inefficient solution.
> > >
> > > -G
> > >
> > >
> > >
> > > On Thu, 14 Oct 2004 19:32:02 -0400, dyankowski AT cits.canon DOT com
> > > <dyankowski AT cits.canon DOT com> wrote:
> > > >
> > > >
> > > > Anyone every use a Nexsan ATABoy with Veritas?
> > > >
> > > > Thanks,
> > > >
> > > > Dan
> > > >
> > > > _______________________________________________
> > > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > > >
> > > _______________________________________________
> >
> >
> > > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > >
> >
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> 
> ------------------------------------------------------------------------------
> 
> This email is confidential and may be legally privileged.
> 
> It is intended solely for the addressee. Access to this email by anyone else, 
> unless expressly approved by the sender or an authorized addressee, is 
> unauthorized.
> 
> If you are not the intended recipient, any disclosure, copying, distribution 
> or any action omitted or taken in reliance on it, is prohibited and may be 
> unlawful. If you believe that you have received this email in error, please 
> contact the sender, delete this e-mail and destroy all copies.
> 
> ==============================================================================
> 
>

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