pashdown@javelin.es.com (Pete Ashdown) (01/24/91)
For those of you who saw my previous query regarding how to dump an NFS
partition, I've got my answer. Basically Sun made a mistake in their
documentation, its not possible. They told me that they have no plans to do
an rdump/rrestore to go with their dump/restore for the Fuji3480 tape drive.
They sold us half a package and we are getting our money back.
However, this still leaves me high and dry on using the Fuji3480 for backups.
What we would like to do now is write our own version of dump/restore/rdump/
rrestore to use here. Is it possible to get any source to these utilities?
Sun said 'no' without a source license, then they happily offered to do the
programming for us, onsite (they don't have a drive), for what would run
about $50,000. Does source exist anywhere in PD form? If so, where can I
ftp it from?
--
"I'm going under the table." - Bernard Shaw
Pete Ashdown pashdown@javelin.sim.es.com ...uunet!javelin.sim.es.com!pashdownbarmar@think.com (Barry Margolin) (01/24/91)
In article <1991Jan23.201918.5649@javelin.es.com> pashdown@javelin.sim.es.com writes: >However, this still leaves me high and dry on using the Fuji3480 for backups. >What we would like to do now is write our own version of dump/restore/rdump/ >rrestore to use here. Is it possible to get any source to these utilities? >Sun said 'no' without a source license, then they happily offered to do the >programming for us, onsite (they don't have a drive), for what would run >about $50,000. Does source exist anywhere in PD form? If so, where can I >ftp it from? I think you can get dump/rdump from the UUNET 4.3bsd source tree. Note that the design of dump makes it very difficult to extend to NFS-mounted directories, so you should plan on extending rdump to support the 3480 drive (this probably just involves recognizing the device-specific status flags). It accesses the partition through the raw disk device, not through the file system system calls, but the NFS protocol only supports file system operations. If you want to be able to dump NFS-mounted file systems you can use utilities such as tar (GNU tar includes some options that are intended to support its use within a backup system) or other 3rd-party backup utilities. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gs26@prism.gatech.EDU (Glenn R. Stone) (01/25/91)
In <1991Jan23.213346.1874@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <1991Jan23.201918.5649@javelin.es.com> pashdown@javelin.sim.es.com writes: >>However, this still leaves me high and dry on using the Fuji3480 for backups. >>What we would like to do now is write our own version of dump/restore/rdump/ >>rrestore to use here. Is it possible to get any source to these utilities? > If you want to be able to dump NFS-mounted file >systems you can use utilities such as tar (GNU tar includes some options >that are intended to support its use within a backup system) or other >3rd-party backup utilities. I use GNU tar exclusively for backing up my RS/6000's.... it supports large block sizes, incremental dumps, stay-in-one-partition (good for backing up / without everything under it), multi-volume archives, sparse file compression (good for databases), reading a list of files to archive, volume labels, interactive processing, verification, reading a file that is a list of files to exclude, and compress-on-the-fly (by doing a popen to compress(1))... among other things. The distribution also includes an implementation of rmt, the remote mag tape server.... I've not seen anything yet that comes close to it, especially for the price... that and a couple shell scripts less than one screenful each, and I can pop a tape in my Exabyte and leave, returning the next morning to find my five-system subnet all appropriately backed up and (with the help of another program with appropriate SCSI calls) the tape out of the drive. -- Glenn R. Stone (gs26@prism.gatech.edu, glenns@eas.gatech.edu) There are no dress rehearsals. We ARE professionals, and this IS the Big Time.
nieusma@cs.colorado.edu (Jeff Nieusma) (01/25/91)
In article <1991Jan23.213346.1874@Think.COM>, barmar@think.com (Barry Margolin) writes: |> Note that the design of dump makes it very difficult to extend to |> NFS-mounted directories, so you should plan on extending rdump to |> support |> the 3480 drive (this probably just involves recognizing the |> device-specific |> status flags). It accesses the partition through the raw disk |> device, not |> through the file system system calls, but the NFS protocol only |> supports |> file system operations. If you want to be able to dump NFS-mounted |> file |> systems you can use utilities such as tar (GNU tar includes some |> options |> that are intended to support its use within a backup system) or |> other |> 3rd-party backup utilities. You really don't want to dump an NFS mounted file system. It doesn't matter how fast you make your program, it will never be faster than reading the raw disk partition and sending it to a remote host via tcp or streams. There is a ton of overhead that cannot be bypassed when using NFS. +-----------------------------------------------------------------------------+ | Jeff Nieusma Logical: nieusma@cs.colorado.edu | | System Administrator/Programmer Audible: (303) 492-0677 | | Computer Science Department Physical: Campus Box 430 | | University of Colorado Boulder, CO 80309-0430 | +-----------------------------------------------------------------------------+ | I only work so I can afford to ski | +-----------------------------------------------------------------------------+
bruce@cs.su.oz (Bruce Janson) (01/25/91)
Barry, In article <1991Jan23.213346.1874@Think.COM> you write: >.. >status flags). It accesses the partition through the raw disk device, not >through the file system system calls, but the NFS protocol only supports >file system operations. If you want to be able to dump NFS-mounted file >systems you can use utilities such as tar (GNU tar includes some options >that are intended to support its use within a backup system) or other >3rd-party backup utilities. >.. Well, fortunately dump *does* access the raw disk device through the file system system calls: fd = open("/dev/dsk/sd0:, ..); .. lseek(fd, ...); read(fd, &buf[0], sizeof(buf)); .. close(fd); -- but I do understand what you are saying... However, given this, a cute trick is to get the remote NFS server to fake up the inode fields of the remote device (special) file so that it looks like a regular file. That way, the local client code doesn't switch out to do local device read()'s but passes all the nfs_*() operations over the wire. As dump only wants to read() the (remote) device this should work well. You've still got to update the remote /etc/dumpdates file though. Cheers, bruce. Bruce Janson Basser Department of Computer Science University of Sydney Sydney, N.S.W., 2006 AUSTRALIA Internet: bruce@cs.su.oz.au Telephone: +61-2-692-3272 Fax: +61-2-692-3838