[OpenAFS] Symantec Support for AFS Backups
Kathryn Hemness
kfhemness@ucdavis.edu
Sat, 20 Jan 2007 14:27:46 -0800 (PST)
Hi John,
The patch broke something in the client bpbkar binary.
The backup would completely finish up to 99% done and then
fail with the following error:
12/18/2006 10:45:16 master-server.ucdavis.edu client.ucdavis.edu File: nbe_cat_c_api.cpp Line: 1040: invalid input dataFunction: decode_data_field
12/18/2006 10:45:17 media-server.ucdavis.edu client.ucdavis.edu successfully wrote backup id reality.ucdavis.edu_1166466735, copy 1, fragment 3, 125472 Kbytes at 5763.263 Kbytes/sec
12/18/2006 10:45:18 media-server.ucdavis.edu client.ucdavis.edu db_FLISTsend failed: file read failed (13)
I replaced the client MP6 bpcd with the MP5 binary first, and the backup still failed.
Then I replaced the bpbkar with the MP5 bpbkar and the problem went away. Reinstating
the MP6 bpcd and keeping the MP5 bpbkar still caused failures.
I get my NetBackup support through Sun but I didn't just open a call with Sun; I also
went to the Symantec website and reported the problem. And, amazingly, Symantec actually
responded even though I don't have a direct support contract with them.
Symantec has sent me an engineering bpbkar binary for me to use until the next
NB51 maintenance pack. This engineering binary works with the MP6 bpcd binary.
I've tested both backups and restores with it.
On Sat, 20 Jan 2007, John Howard wrote:
> Date: Sat, 20 Jan 2007 14:43:12 -0500
> From: John Howard <jmhoward@gmail.com>
> To: Kathryn Hemness <kfhemness@ucdavis.edu>
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] Symantec Support for AFS Backups
>
> Kathryn,
>
> How did MP6 break your AFS backups and was it the server patch or the client
> patch that caused the issues. I'm just wondering if they (Symantec) tested
> AFS backups against MP6, if they did and missed a bug that is acceptable but
> if they didn't bother to test that is bad.
>
> john
>
>
>
> On 1/20/07, Kathryn Hemness <kfhemness@ucdavis.edu> wrote:
> >
> > Greetings,
> >
> > The NetBackup AFS backup capability has been built into the standard
> > backup client/server binaries since NetBackup 4.5 (at least for Solaris,
> > I don't know about for other operating systems).
> >
> > The basic (but not optimal) way it's used is to just create a an
> > AFS backup policy with containing /vicep* partitions or volume
> > names in the backup file list along with a CREATE_BACKUP_VOLUME
> > and/or SKIP_SMALL_VOLUMES=X where X would be the size in Kbytes
> > of volumes to skip.
> >
> > When the scheduled policy is launched, the AFS client system
> > would run a listvol command which creates a file in
> > /usr/openv/netbackup/listvol showing all existing volumes on the
> > client. Then the CREATE_BACKUP_VOLUME would trigger the
> > backup-volume-cloning of all of the RW volumes (including those
> > volumes whose size is less that the SKIP directive.
> >
> > All meta information for the backup volume is retained, and
> > when you wish to restore a file, you can't - instead you
> > restore the entire volume (which is restored as R<vol name>.
> > You can then create a mountpoint for the restored backup
> > volume and allow your clients to get whatever files they wish from
> > the backup volume. When your client is done with the restore,
> > you can remove the mountpoint and the restored volume.
> >
> > This basic functionality works well when your AFS file storage
> > is small. But when the AFS storage grew to hundreds of gigabytes
> > and then to terabytes, the length of time required for the
> > listvol and backup volume cloning caused backup timeouts and the
> > backups were running 12+ hours. To complicate matters even more,
> > NetBackup would only use a listvol listing younger than 3 hours.
> >
> > I've optimized my AFS backups by using cron to run a backupsys
> > command at midnight daily (this backupsys command allows for
> > there to be incremental and full backups of volumes); the
> > backupsys command creates the backup clone volumes. Then,
> > about 2 hours prior to the scheduled backup window opening,
> > I have another cron script that runs the listvol. When
> > the backup window opens, NetBackup uses the existing listvol
> > file to backup the pre-existing backup clones. The total time
> > of my largest AFS backup policy is now less than 8 hours
> > (a significant improvement). Most of the time I am getting
> > backup speeds of 4-9MB/sec to my backup sans.
> >
> > I've been extremely happy with the NetBackup capability which is
> > why I want to find more than the handful of customers who use
> > it for backing up their AFS storage. Symantec's perception that
> > there is only a handful of organizations is based on their lack
> > of support calls because the AFS capability is not a separately-priced
> > agent. I've only had to call in their support because their most recent
> > NB51 maintenance patch (MP6) broke the functionality. I find their logic
> > flawed since satisfied users don't call for support.
> >
> > On Sat, 20 Jan 2007 openafs-info-request@openafs.org wrote:
> > >
> > > Message: 6
> > > Date: Fri, 19 Jan 2007 16:31:46 -0500
> > > From: Dave Botsch <botsch@cnf.cornell.edu>
> > > To: openafs-info@openafs.org
> > > Subject: Re: [OpenAFS] Symantec Support for AFS Backups
> > >
> > > I would certainly be interested in hearing more about how the backups
> > and
> > > restores work w. Symantec backup.
> > >
> > >
> > > --
> > > ********************************
> > > David William Botsch
> > > Programmer/Analyst
> > > CNF Computing
> > > botsch@cnf.cornell.edu
> > > ********************************
> > >
> > > --__--__--
> > >
> > > Message: 7
> > > Date: Fri, 19 Jan 2007 17:01:12 -0500
> > > From: Mike Anderson <Mike.Anderson@nd.edu>
> > > To: openafs-info@openafs.org
> > > Subject: Re: [OpenAFS] Symantec Support for AFS Backups
> > >
> > >
> > > I am very interested in hearing more details about how they work.
> > >
> > > Mike Anderson
> > > OIT Operations & Engineering
> > > University of Notre Dame
> > > 320 IT Center
> > > Notre Dame, IN 46556
> > > Phone: 574-631-4966
> > >
> > >
> > > Quoting Dave Botsch <botsch@cnf.cornell.edu>:
> > >
> > > > I would certainly be interested in hearing more about how the backups
> > and
> > > > restores work w. Symantec backup.
> > > >
> > > --__--__--
> > >
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
>
--Kathy
=======================================================================
Kathryn Hemness kfhemness@ucdavis.edu
System Administrator phone: 530.752.6547
Campus Data Center & Client Services fax: 530.752.9154