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...
Quote:
-- 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
|
Quote:
Quote:
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 |
Quote:
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: Code:
backup-cmd --output=some-file Code:
tar: Volume `B20090221' does not match `B20090220' 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 |
Quote:
Quote:
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".) Quote:
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. Quote:
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 |
Quote:
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:
Quote:
Code:
tar -cf /dev/nst0 tape.lbl Quote:
Also, I hope you did rewind the tape before trying to restore. I was able to restore the tape label and data file using: Code:
mt -f /dev/nst0 rewind Code:
mt -f /dev/nst0 asf 2 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 |
Quote:
Code:
TAPE=/dev/nst0 ontape -s Quote:
Code:
mt -f /dev/nst0 status Quote:
Cheers... Rick |
Rick,
Given the command "mt -f /dev/nst0 status" doesnt actually display any data. It just tells File Numbers as "0" May be, should i try moving to the end of tape and issue an feof (after backing up the data) By doing so, can we make sure the informix doesnt skip the end of file and stops at the marker? Thanks, Lakshmi |
Quote:
Quote:
Q: Any luck figuring out if you can override the default tape device that the "ontape" utility wants to use? If you can't, you may be outta luck trying to add a label to the tape. Cheers... Rick |
Hi Rick,
Instead of using fopen, fprint and fclose, i have used open, write and close to write a label to the tape. It works fine without any error!! :-) Then i just put a "weof" and written the informix contents. This time, i used dbexport, (different from ontape as that requires tape in rewinding mode). With dbexport, i can specify the tape device, whether in rewinding/non-rewinding mode. I am able to successfully do the database export and import operations along with the label too. During import, as specified by you, i have used the "fsf" option to advance to the next contents and did the dbimport in non-rewinding mode. Though i need to look into the ontape usage, its a different issue. But i am able to successfully do dbexport/dbimport. Your suggestions really helped me a lot!!!!!! Thanks, Lakki Thanks, Lakshmi |
FYI, the tape model is "TANDBERG DATA - Tape Drive - 20/40 GB SLR7"
|
Quote:
I suspect that because the "ontape" tool only (at least by default, anyway) knows how to use "st0" instead of "nst0" it's rewinding the tape before attempting to read and upon finding that label of yours gets horribly confused and errors out. At least you're able to get the database backed up in some fashion. Cheers... Rick |
All times are GMT -5. The time now is 04:52 PM. |