I have a server here that i have no idea what version of slack was on it (the main drive died), and i need to get the data off the tapes ASAP. I don't have a copy of slackware, anyone have any idea what i can do ?

I ahve redhat 7.1 running on a pc atm ...

tape drive is exabyte TR-4 (travan i believe)

thanks

TR-4 tapes drive can be either SCSI or IDE controlled units. Perhaps you have any system available that can install the tape drive or another drive that will read the same tape. If the drive is IDE then I suspect your Redhat system will take the drive just fine, if the tape drive is SCSI then you may need to transfer the controller with it. If you also mount your replacement hard disk in your RedHat machine then your could restore the tape directly to the hard disk if it was a complete system backup. The SCSI device ID for a tape drive is normally /dev/st0, and the IDE units are usually /dev/ht0. There are also some commands that are hard coded for the device /dev/mt0 (mag tape) but you can make a sym link as required for mt0 to point to st0 or ht0.

The more difficult question will be what format is the data on the tape? If the data is a simple tar backup then one of the commands below should display the contents without restoring any data anywhere. Just list the tape contents.

tar -tf /dev/st0
tar -tzf /dev/st0

Use st0 or ht0 as required. The "f" option instructs to use a file for the operation. The "t" option instructs to print a table of the tape contents. When you are ready to actually restore the files then use the "x" to extract the files. The "z" instructs to decompress using gunzip. I suppose that option will work under RedHat. I know some systems do not like it. If yours doesn't, then you will may need to use "zcat /dev/st0 | tar -t". At least I think that would work. If you require it I can verify. I have an IDE TR-4 and a SCSI TR-4 available to me here.

I suppose it also possibe that the data format could be cpio based as well. I am not as familar with that format as the tar command. I tried cpio several years ago and I like tar far better. But if it not a tar format then I will investigate some commands for cpio.

There are also some proprietary formats available as well. So if you have any information on the data format it would be of great help. So let's just hope it is just a tar format for now.

Since you may be new to tape operations and the data here may be at least reasonably critical, I would suggest setting the READ-ONLY latch to prevent the tape from being written accidentally. On the TR-4 it is a small red latch that you slide toward the inside of the tape.

Perhaps it will help.

/Edit: Oh, one other item that you may need to know. The last time I saw a RedHat system I think it was entirely based on modules. But I do not recall about the autoloading stuff though. The kernel module if you need to load manually for IDE tape drive is "ide-tape" and for SCSI a drive use "st".

modprobe ide-tape
modprobe st

For SCSI will also need to load a module for the controller card as well, but it will depend on the SCSI card. (Usually aic7xxx these days.)

thanks for replying.
the TR4 drive is a IDE drive.

so far i have modprobe ide-tape and that was sucessful.

i can control the tape with mt commands.

but when i try tar -tf /dev/ht0 (also nht0)

the messages says IDETAPE_CHRDEV_OPEN,
from what i've read this means i need to put the drive into scsi emulation using the following

hdparm -d0 /dev/hdd (hdd is where the drive is)

this just brings up a error
HDIO_SET_DMA failed : operation not permitted
using_dma = 0 (off)

or if i just use hdparm /dev/hdd

it displays input/output errors also.

thanks.

I would think that reference only indicates the program opened a character device for an IDE tape drive. Also, I would not think you need SCSI emulation to use the tape drive. If the mt commands like "mt rewind" and "mt retension" are working then I would think the drive is fully operational.

What is more important is the output regarding the tape from the tar command. If it replied that it wasn't a tar file and skipping to the next header, then press Ctrl-c to terminate and wait for it to rewind back to BOT. Then try again using the "z" option to see if it is gzipped compressed.

If you want to view the first 1K of data on the tape, perhaps it might contain something legible to help identify the format. Then I suggest;

dd if=/dev/ht0 bs=1k count=1

Will dump to the screen the first 1k of info from the tape.

ok, i used the tar -zf command and the /var/log/messages brought up alot of ide-tape : ht0: i/o error

i'm going to try extract it this time, i hope it works

The command should have been "tar -tzf /dev/ht0". Note the "t". Perhaps just a typo though. Anyway, if the drive is functioning, the /var/log/messages is not important at all. That will only contain info regrading the program and the tape drive. The ide-tape code always spits out a lot of info for debuging purposes.

The primary concern is the output of the program directly to the screen. Is it reading the data from the tape and is it legitimate?

ok, well the file came off the tape and into the directory i was in (using tar -xvf blah.tar.gz).

i tried extracting the files in the file and it said unexpected end of file.
does this mean its permanently corrupted and i can't get data ?

I am not sure what you mean "file came off the tape". A tape unit does not have an addressable file system. The data is written in more of a raw format to the device. A tape drive is a sequential character device and is not capable of using a file system. Now the data from the tape could be transferred from the tape into a file, like a backup file of the tape. (cat /dev/ht0 > output.file) But the data in the file remains the same as the tape cartridge was. If the data on the tape was not in a tar type format, then tar will still not be able to read it. I am left just guessing here at what you did to create this file, so I am not sure if this is an accurate response or not.

On a tar data format there are three variants that I know of.
1) Straight tar data format, no compression.
tar -tvf /dev/ht0

2) Compressed tar format using gzip. Tar command option would be "z".
tar -tzvf /dev/ht0

3) Compressed tar format using bzip2. Tar command option would be "j".
tar -tjvf /dev/ht0

If none of those three commands produce readable output, then I would consider the data is not a tar format. And other formats must be considered.

Would it be possible for you to write the first 1k header of the tape into a file and send it to me as an email atachment? (James@jpf.biz) The command below will write a 1K file with the tape header in it with the filename of "tape.header". Attach it to a mail message and send it to me. Please do not try to copy/paste this stuff it will not work and I would not be able to use it anyway.

dd if=/dev/ht0 of=tape.header bs=1k count=1

Perhaps I will be able to identify the structure of the data on the tape. Simplest resolution would be to just ask the person that setup the backup process on the server to start with, but I assume that is not possible from your original post.

when i write the first 1k of data to screen the only ledgable characters are the name of the file "wilderness.tar.gz"

so i assume its a gzip file.

i used

tar -xvf /dev/nht0

and for about an hour or so it makes noise etc.

then says
"skipping to next header"
then exits saying there were errors.

then i try un-compressing the file created from the data on the tape and it says "unexpected end of file".

OK, if that is the first file on the tape and it ran for an hour and you only received the single file extracted from the tape. I would also conclude that the backup was created to a file and then transferred to the tape. I have done a similar process when making backups of multiple servers and then transfer the backup file from each server to the server with the tape drive and write them to a single tape.

If it ran for about an hour then I would expect the output file size to be about 4 GByte. And that sounds like to me the backup process ran out of tape during the transfer and you may not have a complete backup file.

Normally, the file name extensions are used to indicate the file data format. But they are not written in stone. With the extensions of tar.gz it should be a gzipped tar file, but it could really be anything. As you know the tar commands operate the same on files as they do on devices. So then if it is a gzipped tar file then;

tar -tzvf wilderness.tar.gz

Should display the contents of the file; directories,filenames,sizes,dates etc. unitl the end of the file is reached. If it states the unexpected end of file message then it was probably still reading a file when it terminated at the end of the file. The incomplete file would be the last filename displayed. It would not know what the filename of the next file is until after it was through reading the current file.

Confirm the size of the file wilderness.tar.gz. The TR-4 tape is a 4GByte tape cartridge. If the file is appx. 4 GByte then it would be at the capacity of the tape. I would think the part you do have could be restored. But I would not know how close it would be. If the /etc directory was included and restored, look for a file called slackware-version and cat it out. It should report what version of slack was installed. You could try posting the last file that it was attempting to restore and maybe I could guess as to how much had been completed. Have you identified if the real data part was restored? Like /home or /var/spool? Since I do not know what role the server was in use for I cannot even guess as to where the critical data would be. The /home is typical for userland files/SMB shares and /var/spool for a mail server for example.

If you have a 4 GByte compressed tar file, at 2:1 compression ratio that would be about 8 GBytes available, more or less. Would you expect this server to have that much? Consider the size of the hard disk that failed as a maximum.

heh.

well, when i run tar -tzvf wilderness.tar.gz it sits there for a little while then comes up with unexpected end of file.

when i run it with -xvf /dev/nht0 it writes a file to the harddrive called wilderness.tar.gz .

if i try tar -xvf that file (the one that is now written to the harddrive) it goes for 15mins or so and says "unexpected end of file"

the file size is 1.8gb

The file size is not at the cpacity of the tape so we have to assume it is complete, unless a bad tape and it could only read that mcuh of it. But if no file names, or anything was displayed then it is not a tar file. You didn't mention if you tried using the "z" option for a gzipped tar file.

The dd command will also work on a file. So to view the first 1k header of the file;

dd if=wilderness.tar.gz bs=1k count=1

sorry, i did use the z option when trying to uncompress the written file.

i also ran
dd if=wilderness.tar.gz bs=1k count=1

first 2 lines were -
1+0 records in
1+0 records out

the rest was just garbage

Well it could still be a bzip2 compression I quess. Try using the "j" option on the tar command, instead of "z". The man page also describes using the option "Z", capital z. To use a program called "compress". I have never used it, but it might be similar to the zip format.

Also, you mentioned that you were working from a RedHat system. If it has X server running and KDE or GNome or something, then you might try a program like ark. See if it will open the file and identify the compression type used. Or even perhaps Konqueror file properties might identify it. Of course they may just try to use gzipped tar from the filename as well. But it might worth a try if possible.

It is getting close to 01:00 hrs here and I am going to be signing off for the night. I'll check back in the morning though.