I'm all for KISS, makes my job easier. My position is such that a
second master server is not needed for the amount of data that it is
backing up. My problem comes from NDMP data. I have a few TB's of data
on NetApp and the catalogue's for these are stored on the master server
as well. Regrettably the only solution I can see is greater efficiency,
unless you can see an alternative...
~JK
Gregg Yurchak wrote:
>
> Catalog efficiency is always on the drawing board when regarding future
> plans for NetBackup. There is a serious downside to this as well, being
> that generally the more efficient you make the catalog, the more complex it
> also becomes. Right now, it is very hard to screw up the catalog so bad you
> make recovery impossible. When your site blows up, or you migrate master
> servers, or add or remove media servers, it's a very easy task. I'm always
> 100% confident when going into DR tests, or doing conversions, that things
> may not always go as planned, but we will be able to make it work. That's a
> good thing that I'd like to stay with (but your opinion probably outweighs
> mine for future direction). Right now, many customers will add another
> master to reduce complexity and increase overall performance long before
> they hit an issue with catalog size. We also have customers with one master
> and many, many media servers, with a huge catalog who want more efficiency,
> and VERITAS is working on that problem.
>
> Thanks,
> Gregg Yurchak
> VERITAS Professional Services
> Biloxi, MS
> Cell: 228.324.6939
> Office: 228.575.6299
>
> -----Original Message-----
> From: Jeff Kennedy [mailto:jlkennedy AT amcc DOT com]
> Sent: Monday, November 26, 2001 12:51 PM
> To: larry.kingery AT veritas DOT com
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] NBU master server catalog size concerns
>
> Larry,
>
> Does Veritas have any plans to make the catalogue more efficient? I
> have figured that the catalogue takes about 3% of the total data backed
> up, which can be huge in current environments and it will do nothing but
> get bigger. I realize that compression is an option but that can lead
> to issues in time to restore, which is why we backup in the first
> place.....
>
> Thanks.
>
> ~JK
>
> Larry Kingery wrote:
> >
> > The master size can become an issue. At around 20GB, it can take an
> > hour or so to backup (or restore), and during that time no backups can
> > be initiated. When it gets to the point where it will no longer fit
> > on a single tape, you have to add a second step to the database backup
> > process.
> >
> > The layout of the "database" is just a hierarchy of files. There are
> > of course a few which are critical in that they affect the whole
> > system, but the vast majority (both in size and number) have no
> > dependence on each other. They're just files, and if one gets dinged
> > you can restore it from backup, or scan the tape, etc.
> >
> > You've got a long time before you have anything to worry about.
> > Personally, I'd take some time to walk through the DR process (chap 5,
> > troubleshooting guide) and make sure your catalog backups are
> > configured correctly and restorable, and document the process in your
> > own words.
> >
> > chad.haywood AT storability DOT com writes:
> > > Hi,
> > >
> > > As someone familiar with Legato Networker 5.x index stability issues, I
> > > was concerned to learn that a Netbackup 3.4 master server I recently
> > > assumed responsibility for has a master server catalog size of 1.6 Gig
> due
> > > to NFS mounted backups. In a Networker environment I would have made
> > > shrinking this a major priority to avoid likely headaches should a DR
> > > situation arise. From those of you with more Netbackup experience, is
> the
> > > master catalog size a major issue in a DR situation? Obviously it will
> > > impact the time needed to recover the master's catalog, but how likely
> is
> > > it to cause difficult to resolve issues due to corruption or other
> > > problems?
> > >
> > > Thanks,
> > > Chad
> > >
> > > Chad Haywood
> > > Senior Solutions Engineer
> > > Storability, Incorporated
> > > www.storability.com
> > > _______________________________________________
> > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
> > --
> > Larry Kingery
> > It's not if, it's when and how hard
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> --
> =====================
> Jeff Kennedy
> Unix Administrator
> AMCC
> jlkennedy AT amcc DOT com
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--
=====================
Jeff Kennedy
Unix Administrator
AMCC
jlkennedy AT amcc DOT com
|
