TAPE PROBLEM

[Nobody's Hero]

OK,
Each night we send out oracle export files to one disk area. Then we back them up to tape from that one area. I am trying to restore one of the files that is further down the tape, but tape just sits and blinks and does this for up to 4 hours. I can dump the index on the tape just fine. I do know that near the beginning of the tape. one of the files gets an 'unable to stat file' message during the backup. I think this is where the tape is confused. I cant restore any files from this tape past the point where the errored backup was. Question,we used fbackup. Is there anyway to fsf past the bad spot so I can restore a file further down the tape? I knoe fbackup always wants to rewind.

[harry d brown jr]

Have you let it go longer than four hours??

live free or die
harry

[harry d brown jr]

Actually I'm confused, because if this disk area is used to push oracle exports to, then why are files open on this directory? and being written to?? which is what the "unable to stat file" usually indicates.

live free or die
harry

[Nobody's Hero]

No, I havent let it go longer than 4 hours.
Not sure why the one file was in usr during the backup, maybe a timing problem or something.

[harry d brown jr]

How long does the backup run for each night? and how much data is being backed up?

live free or die
harry

[Nobody's Hero]

Runs about six hours, backs up around 70gig.

[harry d brown jr]

Well restores can take 2X to restore.

I'm not aware of any utilities to skip files of an fbackup.

live free or die
harry

[MANOJ SRIVASTAVA]

Hi Robert


Can you so a dd to the disk and then do a restore from that file ?


This would need at least the data size on the disk ?


Manoj Srivastava

[James R. Ferguson]

Hi Robert:

Four hours *does* seem a might long.

When 'fbackup' starts to transfer a file from disk to tape it notes the timestamp of the file on disk. When the transfer to tape has completed, 'fbackup' examines the timestamp again. If it has changed, the tape copy is marked "bad" and a new copy (from disk) is started again for the file in question. This process will be repeated until a static timestamp is seen or have been exahusted. The default is five tries. The problem is that tape is consumed for each copy transferred. During a subsequent 'frecover', the bad copies of the file must be traversed and skipped.

The lesson here is that attempting to copy non-static files consumes tape and makes 'frecover' run longer if bad copies need to be skipped.

Regards!

...JRF...

[harry d brown jr]

JRF, that's why I asked how much and how long, because if it was backing up a large file or many large files that was/were open and still being written to, then it was "thrashing" the tape.

Robert, I sure hope this was only a test of the "emergency broadcasting system"!


live free or die
harry

[Bill Hassell · Accepted solution]

Sounds like you are not using a config file. This will cause massive delays in getting data stored and recovered! 70 Gb should be done in just a couple of hours or so, and getting to the last file on the tape should take just a few MINUTES if you are using a DDS or DLT drive.

The purpose of the config file is to tell fbackup to use record sizes and setmarks that are appropriate for DDS or DLT. Here is an example of a config file appropriate for newer drives:

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

frecover should now take a few minutes.