[geeks] Old Archives

[Michael Parson]

On Tue, Sep 06, 2005 at 08:38:01AM -0500, Paul Dunlop wrote:
> About a year ago, I had a Sun Solaris system built in order to access 
> information on a number of Quarter Inch Cartridges (QIC). These QIC's 
> were created in the early to mid 1980's, on SPARC i386's, using Bar 

Just to be pedantic:  The boxes were either Sparcs or i386s.  Sun made
both for a while.

> Compress (the SysAdmin at the time flipped a coin to see if he should 
> use Bar or Tar). Our local 'guru' was able to build the system, 
> figure out how to deal with the Bar Compression, and I was able to 
> get all the data from all the tapes. Life was good!

More more vocabulary: bar and tar are both archive formats, not
compression.
 
> This year we found more tapes and many 3.5" floppies. We were able to 
> extract the data from all the QIC's except for 4. These 4 tapes were 
> created as a spanned Bar Compressed file. In other words, one file 
> was written across the 4 tapes. Also, when working with the 3.5" 
> floppies, I think I'm running into the same problem - whenever a bar 
> compress file is written across more than one piece of media, I'm not 
> able to extract the information.
> 
> Here are the steps used on the QIC's:
> With the tape inserted in the drive, type:
> dd if=/dev/rmt/0b of=dump
> 
> Once the dump file is created, extract the data by typing:
> cpio -ivdH bar < dump
> 
> When the bar compress file is spanned across multiple media, I create 
> a dump file for each media, naming them dump1, dump2, dump3, etc.
> dd if=/vol/dev/rdiskette0/unknown_format of=dump1
> 
> Once all the dump files are created, I concatenate them into a single 
> dump file.
> cat dump1 dump2 dump3 > dump

I only know what I know about the bar archive from what I just read
in the man pages on a SunOS 4.1.4 box, but, most multi-volume backup
archives are not big files just split into tape-sized chunks.  It looks
like each tape would have its own header.  There is probably a 'right'
way to recover these.  For example, when dump(8) spans tapes, you start
with the first tape, then it will prompt you for the last tape in the
archive, then you go back to the first tape and work your way through
them.

It might take some file shuffling to try that out with your stuff above.

> Now when I use the cpio command on the concatenated dump file, or if
> I run the cpio command on the first dump file (dump1), I receive the
> following message: cpio: Can't read input: end of file encountered
> prior to expected end of archive.
>
> If I run the cpio command on the second, third, etc, dump file, I
> receive the following message: error: This is not volume 1. This is
> volume 2. Please insert volume 1.
>
> Our local guru is gone. A search for a new local guru has turned up
> nothing. Is there anyone out there that knows what this problem is and
> how to fix it?
>
> THANKS!

-- 
Michael Parson
mparson at bl.org