chrisb@ALMSA-1.arpa (03/23/87)
I am trying to write dump procedures for a Sperry 5000/80 (same as Arete 1200) running on Unix System V.2 and have run into difficulties trying to copy large filesystems to tape using the tar and the cpio command. I am copying at 6250 bpi in both cases. On large filesystems that require more than one tape, both tar and cpio go to the end of the tape, issue a tape write error message and exit the tar or cpio command. The volcopy command does prompt for additional tapes; however, we have problems restoring files with this command since we do not have an additional disk which is large enough for restoring our large filesystems. Is this the way the tar and cpio commands should handle end of tape or is this something unique to the Sperry? If this is normal, how do you backup large filesystems without writing your own routines to calculate how much of a filesystem you copy to each tape? We do not have source code on the Sperry so we can't modify that. I do not currently subscribe to these mailing lists, please reply to: Christy Blumenkamp<chrisb@almsa-1.arpa> seismo!sysop@almsa-1.arpa USAMC ALMSA, ATTN: AMXAL-TS, Box 1578, St. Louis, MO 63188-1578 COMMERCIAL: (314) 263-5901 AUTOVON: 693-5901 Thank you for your help. Christy Blumenkamp Operating Systems Division - ALMSA
det@herman.UUCP (03/25/87)
In article <5440@brl-adm.ARPA>, chrisb@ALMSA-1.arpa (Christine Blumenkamp) writes: > exit the tar or cpio command. The volcopy command does prompt for additional > tapes; however, we have problems restoring files with this command since we do > not have an additional disk which is large enough for restoring our large > filesystems. > ...... > If this is normal, how do you backup large filesystems without writing your > own routines to calculate how much of a filesystem you copy to each tape? Christy, I have never used this particular command (frec), but it appears in the admin manual and it looks like it could be right up your alley. You say that you don't have enough *space* to restore your whole volcopy on disk, and even though we do on our system, its a "just barely". My principle complaint is the amount of time spent copying back all those reels at 1600 bpi!! Anyway, frec appears to just need an i-node number to recover a given file from a series a volcopy tapes, thus cancelling any need to restore the whole volcopy to disk. All you would have to do is make sure that you get a map of file names and their i-node numbers at volcopy time. As I have said, I haven't ever used it but I would be interested in knowing if anybody out there has used this utility and what the results were (like it *does* stop searching tapes after finding the given file(s), and it *doesn't* use scratch files to make a copy of the volcopy on disk does it?). Anyway, this looks like an option you can check into... derek
wescott@sauron.UUCP (03/25/87)
In article <262@herman.UUCP> det@herman.UUCP (Derek Terveer) writes: > In article <5440@brl-adm.ARPA>, chrisb@ALMSA-1.arpa (Christine Blumenkamp) writes: >> The volcopy command does prompt for additional tapes; however, we have >> problems restoring files with this command since we do not have an additional >> disk which is large enough for restoring our large filesystems. > I have never used this particular command (frec), but it appears in the admin > manual and it looks like it could be right up your alley. I have used it. With vanilla SystemV whatever version there is a problem: frec will not recover files that are big enough to require triple indirect blocks. On the otherhand, it is as smart as it can be about reading the tape. It stops when it has found all the blocks of the file. It can, however, take three or four (I'm not sure of the max) scans of the entire set before finding all the blocks of a file, since indirect blocks found may point to data blocks already read (and ignored). -- -Mike Wescott wescott@ncrcae.Columbia.NCR.COM
tan@bronson.UUCP (03/29/87)
In article <5440@brl-adm.ARPA>, chrisb@ALMSA-1.arpa (Christine Blumenkamp) writes:
# exit the tar or cpio command. The volcopy command does prompt for additional
# tapes; however, we have problems restoring files with this command since we do
# not have an additional disk which is large enough for restoring our large
# filesystems.
# ......
We were stuck with the same problem with Uniplus System V & V.2.
(System III still had dump/restore), Our solution was to ingore
all of System V.* backup tools and use 'bru' written by Fred Fish.
It is not a public domain program, but it has all of the best features
of tar/cpio/dump/store/frec..... It handle multiple volumes, devices.
It does not have a 'append' mode, but then it is a backup program.
Overall I like the program very much and I think it is well worth
the money ! It is a real sham the AT&T thinks it is reasonable for you
to keep a full sized disk just to get a few files off backup !
--
Name....: Tan Bronson
Company.: Microvation Consultants
US Mail.: 20 Sperry Rd Madison, CT 06443 (20)-421-5061
UUCP....: ...{decvax!genrad!teddy,seismo!yale}!bronson!tanjfh@killer.UUCP (04/02/87)
In article <5440@brl-adm.ARPA>, chrisb@ALMSA-1.arpa (Christine Blumenkamp) writes: > I am trying to write dump procedures for a Sperry 5000/80 (same as Arete 1200) > running on Unix System V.2 and have run into difficulties trying to copy large > filesystems to tape using the tar and the cpio command. I am copying at 6250 > bpi in both cases. On large filesystems that require more than one tape, both > tar and cpio go to the end of the tape, issue a tape write error message and > exit the tar or cpio command. The volcopy command does prompt for additional > tapes; however, we have problems restoring files with this command since we do > not have an additional disk which is large enough for restoring our large > filesystems. > I have had this same problem on a number of systems (V7, V.2, BSD). The old dd(1) program seems to work well as both tar(1) and cpio(1) have means for requesting the standard input and standard output as the input and output. Try this: cpio -o < file_list | \ while : do dd of=tape_drive bs=block_size count=some_number done (Your milage may vary, and there is something wrong, I can feel it...) Sorry I didn't EMAIL you the answer, but I don't know how well mail works out of this system... - john. (jfh@killer.UUCP)