If it's causing a problem at your site, you could consider locating the NDMP
catalog info on a separate mount inside db/images, and then only mounting it
in when doing NetApp backups or restores. If it's performance on NetApp
restores and we're talking about the catalog being on a hardware RAID setup,
you could carve out small luns, one for each month, and only mount in the
necessary month(s) to get the restore, and just keep the current month
mounted all the time for regular backups. If you've got all the NetApp
catalog files on a separate backup tape, they wouldn't even have to be
mounted in during normal catalog backups.
I just made all that up, so it'd probably need some testing before getting
put into practice. But I don't see a problem with it offhand.
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 2:08 PM
To: Gregg Yurchak
Cc: Larry Kingery; 'veritas-bu AT mailman.eng.auburn DOT edu'
Subject: Re: [Veritas-bu] NBU master server catalog size concerns
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
|
