fclose() getting failed in SCSI tape
 

I am using SCSI tape in RHEL 5.2 version. Also I am using informix to create a tape backup.

Once it is done, when i tried to create label for the tape, it failed.
I used fopen to open the tape and fprintf to write the data.
When i used fclose(), the command is always getting failed.

Any help would be appreciated

Backup then labeling tape? Hmm...
 

I won't pretend to be an Informix expert so I'm not sure I can help with that aspect of this. But... can you describe the process you're following to do the backup and label the tape? The reason that would be helpful to know is that I would think that you'd label the tape first and then do a backup to the tape. The order you described would, I think, make it time consuming to verify what tape was being used later on since your label would be at the end of the tape rather than at the beginning and would require a lengthy search to find it. Worst case I think you run the risk of accidently obliterating your backup. (Especially if you use the rewinding tape device ("st" vs. "nst"). Maybe it's just me and a misunderstanding on how your labeling the tape. There's a standard format for tape labels (he says, dusting off the brain cells that knew how to manipulate 9-track tapes). Try Googling for "ANSI tape label" for more info. I know some Linux backup software (like Bacula) recognizes them. Hopefully we're talking about the same thing.

--
Rick

Hi Rick,

I have used what u have specified.
I used the following steps:
1. Checked the status of the tape
2. Rewind the tape
3. Label the tape in non-rewinding mode
4. take a backup

While restore,
1. Rewind the tape
2. Read the label (here it fails)
3. Restore it

-Lakshmi

Also use the link http://www.linuxquestions.org/questi...e-tape-705892/ to find the labelling program

Sounds like what I would have done.
Does the restore actually work?

It's been ages since I've done any really low-level work with tapes but I wonder if you are actually writing a label to the tape. Have you tried writing a label, rewinding the tape, and then using something like "dd" to dump the contents of the tape to a disk file? You could then examine the contents with "od" to see if the label was written, the format correct, etc. If it checks out, I wonder if the "error" you're seeing is due to not taking the tape mark into account before trying to read data. My memories are a little hazy but I seem to recall, after reading a tape label, needing to rewind the tape forward spacing past the first tape mark, and then reading the tape's data. (Like I said, it's been ages...)

BTW, I'll have to check out that tape labeling program you provided a link to. It might come in handy to make my backup procedures a little more bulletproof. (Lately, labeling tapes involves sliding the little paper label into the front of the DLT cartridge and writing the name of the mount point on it. Not very sophisticated but meets my modest needs here at home.)

Cheers...

Rick

Not sure why this never occurred to me before...

You can do tape labeling as part of GNU tar using the "-V" or "--label" command line switches. (Look at the "info" page for tar; scroll down to and select "All Options" and then select "Option Summary" and scroll down some more.)

Could you dump output of your database backup into a file and then pass the name of the file to tar and use the tape label that tar generates? Something like:If you try to try to extract something from today's backup volume, you'll need to specify the correct volume label on the tar command line. For example, if I specify yesterday's tape label (B20090220), I'll get an error message like:I don't think those tar tape labels are exactly ANSI standard (I think the volume-name I used in the example is too long) but it's a label and it works.

It'd be really nice if tar would just read data directly from a pipe but it really wants a file name. So you'll have to back your database up to disk before you can stash it on tape. On the otherhand, backing up to disk minimizes the time that the database is bogged down with the backup.

"cpio" isn't much help either; it doesn't know anything about labels.

If you want to stick with your existing code, I'd put together a function that can read/write to the tape using ioctl (see "man st") and use a standard tape label record. (Ever find anything via Google on ANSI tape labels?) This seems like a lot of work to me.

An alternative might be to try Bacula. It claims to handle ANSI tape labels. It may seem like overkill but it might be easier to load and configure that than writing a custom tape label handling utility. The downside is that you're still backing up to disk first and then to tape. As a plus, though, you get a system-wide backup tool instead of just something for the database.

Just a thought...

Cheers...

Rick

Hi Rick,

Thanks for your qucik reply.
I am using the informix database utility to do a backup/restore.
Lemme give some commands as example:
ontape -s -> for backup of database
ontape -r -> for restoring the database
These commands when used(without label), did the backup/restore exactly the same way as it is intended.

I would rather prefer fprintf/fgets because my other back up tapes have the label in that format.
If i have no other go, i would prefer labelling usinng tar commands.

I created a file containing the label, time and other stuffs.
tar -czf /dev/st0 /tmp/bkup_label
This works fine and status displayed a file

I could restore it back to hard disk.
tar -xzf /dev/st0 /tmp/bkup_label

But the problem lies only when i do backup using informix utility and try to read the label.

As you mentioned, i will try to forward the current reader pointer past one file from startup.
I though of using mt command for this.

But all these days i am breaking my head to find out why the labeling is not working in RHEL when fprintf is used?
The same piece of code is working great in SCO environment???????????

And once again, thanks for spending time in analysing the issue rick!!!

Thanks,
Lakshmi

I suspected something like that.
I tried that and you need to specify at least one file for tar to act on. So when I tried to merely label the tape using tar -- with the command "tar --label=B20090222 --file=/dev/st0 /dev/null" -- what I saw when I listed the tape contents was the volume label and "dev/null" (the leading slash was stripped). I think you'd want to avoid accidently restoring from that chunk of the tape lest you create a bunch of extra bit buskets. :) I guess you could use some non-descript throwaway (zero-byte?) file created in /tmp to use in the tar archive so avoid putting some file on there that you'd rather not restore by accident.

The good part of using tar for the label processing is that it does all the matching of the labels for you. All you need to do is check the exit status in your backup script. (A mismatched label will return "2" instead of "0".)

What about the following:

1.) Label the tape with "tar --label=volume-id some-file" or tar your "bkup_label" file to the tape using the non-rewinding device.
2.) Write a tape mark using "mt -f /dev/nst0 weof". This may not be necessary if you're closing the tape device after writing your label and if the fclose() function writes a tape mark for you.
3.) Run the informix backup command and send all the data to tape.
4.) Issue "mt -f /dev/nst0 weof 2" to indicate "end of tape". (Two tape marks is/was the traditional way of denoting the end of data on the tape. Hitting two tape marks in a row with no file between meant "you're at the end of the tape stupid". Back in the era of nine-track tapes this kept you on the good side of the operators who really disliked threading a tape back onto the reel after you read too far. Uh oh... I just dated myself.)

You'll have a sort of weird tape in that it'll contain a tiny tar archive and a bunch of raw (?) Informix data.

When restoring, you could merely:

1.) Extract "bkup_file" from the tape
2.) grep for the string that tells you the correct tape is being used. If it's not, "mt -f /dev/nst0 rewoffl".
3.) If this tape is the one you want, skip past the next tape mark
4.) Tell informix to begin reading from the tape.

You could play some tricks using the rewinding and the non-rewinding device and "mt" to get you positioned at the beginning of the database data. For example, processing the label using the rewinding device. If the tape is the correct one, use mt's "fsf" command to skip over the label file/tar archive to the beginning of the data.

SCO? You're a brave man. I used to have to support some SCO systems years ago. Even bought a couple of books (out of my own pocket) on that flavor for reference. It was my second go at working on SCO systems. The experience was bad enough that I left the books in the bottom desk drawer in my office when I left. I never want to see another SCO box as long as I live.

Good luck...

Rick

Rick,

U know what? My database got corrupted.
I am having some issues in building it again.
Hope i will be resolving it soon. Then i will try for the steps you suggested and let you know!!!!!!

-Lakshmi

Argh! I do hope you've been exporting it to disk somewhere until the tape problem is solved.

Good luck...

--
Rick

Hi Rick,

I tried the following:

For creating the backup,
1. tar -cf /dev/nst0 bkup_label
2. mt -f /dev/nst0 weof
3. Ran the informix backup command, ontape -s
4. mt -f /dev/nst0 weof 2a

For Restoring,
5. tar -cf /dev/nst0 bkup_label
But the command failed reporting that the archive could nt be read!!!!!

Is there anyother way i could do labelling to a tape?

Thanks in advance!!!!!!

-Lakshmi

Lakki wrote:
Looks OK. I tried something similarThat's the wrong option to read the tape label, right?

Also, I hope you did rewind the tape before trying to restore.

I was able to restore the tape label and data file using:I would have thought that after the first tar extract from the tape that "mt -f /dev/nst0 fsfm 1" would have skipped over the tape mark written after the tape label and place the tape at the beginning of the second file. It didn't for me so a quick rewind and skipping over the tape label file did the trick. You can also useafter you extract the label. It's equivalent to the two separate "mt" commands I used.

Hope this helps...

--
Rick

Rick,

I would like to correct myself. I have used tar -xf option only when restoring the label.
With that command, i was able to restore the backup label.

I used in non-rewinding mode. But i didnt try "mt -f /dev/nst0 fsf 2".
I will try this too and let you know by monday..

Rick, Again Thanks a lot!!!!

Have a great day!!!!!

-Lakki

Hi Rick,

I used the below commands for taking the backup:
mt -f /dev/nst0 rewind
tar -cf /dev/nst0 tape.lbl
mt -f /dev/nst0 weof
ontape -s (I found that the Informix utility automatically writes into tape in rewinding mode. It just rewinds the tape after writing the contents. Hence i didnt use "mt -f /dev/nst0 weof 2")

For restoring,
mt -f /dev/nst0 rewind
tar -xf /dev/nst0 tape.lbl
mt -f /dev/nst0 rewind
mt -f /dev/nst0 fsf 2
ontape -r (Got failed with invalid archive type)

I am wondering whether the tape is not able to find the EOF or something like that!!!!
Eventhough i am not able to restore the database contents, i am successfully able to restore the label back!!!!!

Thanks,
Lakki

One supposes that the ontape utility is able to tell when it's reached the end of the data it's previously saved to tape and doesn't rely on tape marks (or it writes them itself so you don't have to). Is there a means of overriding the tape device? I'm wondering if you can't gain control of what the ontape command uses by issuing a command likeor something similar.

After you "fsf 2" to the (supposed) beginning of the Informix data, issue the commandDoes it indicate that you're at the beginning of file 2?

Well that's something, I guess. :-/


Cheers...
Rick