Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!husc6!bu-cs!eap From: eap@bu-cs.BU.EDU (Eric Pearce) Newsgroups: comp.sys.sgi Subject: Re: ... and Backups on the SGI Message-ID: <31660@bu-cs.BU.EDU> Date: 23 May 89 18:11:58 GMT References: <31330@bu-cs.BU.EDU> <110@odin.SGI.COM> Reply-To: eap@bu-it.bu.edu (Eric Pearce) Followup-To: comp.sys.sgi Organization: BD&HR (Beer Drinkers & Hell Raisers) Lines: 34 In article <110@odin.SGI.COM> mitch@rock.sgi.com (Thomas P. Mitchell) says: >Each has its advantages. I (not SGI) would be curious how >well gnu_tar works for you. Are you considering nfs >mounting the usr file systems, each in turn on one central >system for backups? We currently have 5 GTX's and each one is on a different subnet. It is our current policy not to do nfs mounts across routers to minimize network load. It might work to just mount a file system for the duration of the backup though, if it was done at off-peak hours. We do have a "disk-farm" machine that we could use for disk-to-disk backups. (these could then be archived to tape at leisure) The speed and the size of the backup are not as big of an issue as how the backup procedure will fit into the current enviroment. We want to be able to do all the backups remotely, as the machines are squirled away in people's offices. This rules out the internal 1/4 tape for a backup medium, of course. GNU tar seems to mimic the behavior of BSD dump/restore. This means we don't have to retrain the operations staff, as we can make it's use transparent via the shell scripts that already use BSD dump on our other machines. -e -- ------------------------------------------------------------------------------- Eric Pearce ARPANET eap@bu-it.bu.edu Boston University Information Technology CSNET eap%bu-it@bu-cs 111 Cummington Street JNET jnet%"ep@buenga" Boston MA 02215 UUCP !harvard!bu-cs!bu-it!eap 617-353-2780 voice 617-353-6260 fax BITNET ep@buenga