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 [EMAIL PROTECTED] wrote: > > Message: 6 > Date: Fri, 19 Jan 2007 16:31:46 -0500 > From: Dave Botsch <[EMAIL PROTECTED]> > To: [email protected] > 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 > [EMAIL PROTECTED] > ******************************** > > --__--__-- > > Message: 7 > Date: Fri, 19 Jan 2007 17:01:12 -0500 > From: Mike Anderson <[EMAIL PROTECTED]> > To: [email protected] > 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 <[EMAIL PROTECTED]>: > > > I would certainly be interested in hearing more about how the backups and > > restores work w. Symantec backup. > > > --__--__-- > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
