Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!ucla-cs!oahu!frazier From: frazier@oahu.cs.ucla.edu (Greg Frazier) Newsgroups: comp.unix.admin Subject: Re: Network backups (was Re: parameters for (r)dump to an exabyte) Message-ID: Date: 25 Jun 91 19:32:58 GMT References: <1991Jun19.222701.29689@cs.ucla.edu> Sender: usenet@cs.ucla.edu (Mr. News Himself) Organization: UCLA, Computer Science Department Lines: 63 Nntp-Posting-Host: oahu.cs.ucla.edu janet@cs.uwa.oz.au (Janet Jackson) writes: >In frazier@oahu.cs.ucla.edu (Greg Frazier) writes: >>For the curious, here is the context. I am writing a dump script, >I'd like to know more about your dump script, as I am hoping to avoid >having to write one. We have a network of Sun workstations, about 25 >at last count, two of which have Exabyte drives. Currently I'm using >a thing called "backup" which supervises dump to do multiple dumps from >one machine to one tape. I need to do multiple machines as There are millions and millions of backup scripts. Before I started writing mine, I polled comp.sys.sun and alt.sys.sun for some (I didn't know about this newsgroup then). I got a lot, but none were *exactly* what we wanted, so I have embarked on writing my own. My script is very simple. It assumes that each dump will fit onto a single tape and that every dump is a level 0 dump (that could easily be changed). It is written in perl, and maintains a simple database of tapes. The goal of the program is to minimize user intervention - cron runs the script every night. If there is a dump to be done that night, the dump is done, and email is sent to the operators asking them to remove the tape and specifying which tape to put into the drive. If no dump is to be done, it just checks the drive to make sure the correct tape is in it (and sends email specifying the correct tape to be put in if it isn't). The schedule of dumps is placed in a configuration file. The configuration file consists of a list of file system groups. A file system group consists of the file systems that are to be dumped to a single tape. The group has a name, a day of the week that it is dumped, a list of file systems (host:dir), and a list of tapes to be saved. The list of tapes consists of something like "1 week, 4 week, 16 week", which will preserve the dumps of the last two weeks, the last two 4 week intervals and the last two 16 week intervals). The list of saved tapes is in another file, so you can look there to find the number of the tape that has the filesystem that you want to recover. For us, the key features of this script are that 1) it keeps track of the tapes and tells you what tape you sould put into the tape drive and 2) other than swapping tapes it operates with zero human interaction. The disadvantages of it include 1) no provisions for dumping more than one tape's worth, or one file system group, on a given day, 2) you'd have to put a single file system in more than one file system group to dump it more than once a week (I don't know if that is really a disadvantage) and 3) at this point, file recovery is not at all automated. At this point, I'm still having troubles getting dd to confirm that the dumps were error-free, but other than that the script is basically done. If there is interest, when I think it is bug-free I'll put it in some ftp-able place. *But*, consider that there are a lot of other scripts out there, surely written by better hacks than myself. -- Greg Frazier frazier@CS.UCLA.EDU !{ucbvax,rutgers}!ucla-cs!frazier