paula@beaver.cs.washington.edu (Paul Allen) (05/02/90)
In article <7069@brazos.Rice.edu> celvin@ee.surrey.ac.uk (Chris Elvin) writes: >X-Sun-Spots-Digest: Volume 9, Issue 138, message 3 > [about a scheme for putting multiple dumps on an Exabyte tape with a table of contents at the fron of the tape.] > >First experiments using dd to dump files to tape and repeatedly re-dump >the first (fixed length) file show that simply rewinding the tape and >writing a fixed length file at the front of the tape is not enough. >Anybody got any suggestions???? If you just dd a file onto the front of the tape, the rest of the tape will no longer be accessible. One of the vendors of 8mm subsystems at the Sun User Group meeting last year told me that their software works something like this: The table of contents at the front of the tape is updated by a program that opens the tape, writes the update, and then forward skips past the tapemark without closing the tape. The program I wrote to do multiple dumps on a tape uses syslog to record the info needed for doing a restore. My newsyslog script grep's the tape log records out of the syslog file each day and appends them to a permanent backup log. Then, when a restore is needed, I simply do an appropriate grep to yield the tape number and how far to forward skip. In the event that the log file is lost, each dump file begins with a 1024-byte header containing the identity of the dump. This header must be stripped off at restore time, but it permits reconstruction of the backup log in an emergency. I do unattended daily dumps of nearly 20Gb of disk, and am fairly happy with how things are working. Paul Allen pallen@atc.boeing.com
jackal@cs.utexas.edu (Phil Hammar) (05/05/90)
In article <7334@brazos.Rice.edu> bcsaic!paula@beaver.cs.washington.edu (Paul Allen) writes: > >If you just dd a file onto the front of the tape, the rest of the tape >will no longer be accessible. [...] >Paul Allen >pallen@atc.boeing.com This is not true in our case. We have an Exabyte and driver from Perfect Byte, Inc., and we dd a file of nulls onto the front of the tape to reserve space for a table of contents when the rest of the tape has finished being written. We then tar(1) the TOC onto teh front of the tape. There are two caveats: 1) the file of nulls must be big enough so that the end of file marker from the tar does not overwrite the end of file marker from the null file (we use 10 MB of nulls as suggested by George Goble in his excellent article in Sun-Spots Vol. 7, Issue 68), and 2) both end of file markers have to be skipped to get to the contents of the tape (ie. mt fsf 2) Hope this helps, Phil Hammar