Jump to content

Recommended Posts

Background:

 

A network backup had quit with a 212 Erased Media error.

 

Following the manual, I tried the -verify- operation to check the tape.

The first member of the backup set verified just fine.

The member which was in the drive when the Erased Media error occurred verified partially. Retrospect then sat and eventually said it was Resynchronizing (slow...). This lasted overnight. I then aborted the verify.

 

Upon looking in the log, I found that errors from verify such as

 

Code:


Trouble reading: “2-StatGroup A [005]” (201), error 206 (drive reported a failure: dirty heads, bad media, etc.).

Trouble positioning: “2-StatGroup A [005]” (201), error 206 (drive reported a failure: dirty heads, bad media, etc.).


I cleaned the drive and tried the above verification again. It got stuck in the same spot again, and had to be aborted.

 

Bugs/Strangenesses & Questions

  • When I tried to stop the verify operation, retrospect got stuck on 'ejecting tape' for an hour, so I force-quit it.

    Upon starting Retrospect, it could no longer see the tape drive.

    Only by turning off the tape drive and turning it back on again would it appear as a device to Retrospect.

    Even when the device was invisible to Retrospect, it was present according to the Apple System Profiler.

     

    Question: Is this an indication of trouble with the tape drive, or is Retrospect failing because it is getting confused by return messages from the tape drive?

     

  • While composing this message with the possibly bad tape in the tape drive, Retrospect happily started the Backup Server and started writing to the supposedly bad tape.

     

    Questions:

    Is the tape really bad?

    Could the 'erased media' error have been caused instead by a network problem or a user shutting of the client in the midst of a backup?

Configuration

  • Dual 800 Quicksilver

  • Mac OS X 10.2.6

  • Retrospect 5.0.238 for Workgroups backing up several MS Windows clients.

  • VXA-1 Tape Drive (recent replacement for a drive which went bad)

 

Thanks for any and all tips.

 

Bill

Link to comment
Share on other sites

Bill,

 

Please provide some more info about your system:

What revision of the Retrospect Driver Update (RDU)?

Is the VXA-1 SCSI-Narrow (50 pin), SCSI-Wide (68 pin) or FireWire?

If SCSI, what SCSI interface card (vendor and model) are you using?

What revision of interface card driver are you using?

What is the VXA firmware revision?

 

I cannot authoritatively answer your questions, but you asked?

 

Is the tape really bad?

I have had somewhat similar circumstances. I continued to use the tape and encountered no further problems with the tape that I could attribute to the original event.

 

Two things you could do to provide some reassurance:

Run a verify on the tape now that further backups have been written to the tape. If you cannot read the tape to verify it, then your backups are not going to be useful.

You could re-catalog the entire backup set. This would be more reassuring to me than a verify, because the regenerated catalog will represent all the files that could be found on the tape. The original catalog is all the files that were put on the tape - which might not be retrievable.

 

On the subject of what to do with your original problem of verify getting stuck at the point of where the backup had failed: I have recovered from a similar situation by re-cataloging the backup set and stopping the re-catalog before it got to the bad spot. I made note of how many files / bytes at the point verify failed, then stopped the re-catalog before it got to the same counts.

 

Another way to recover is to just tell Retrospect to forget the second (defective) member of the backup set. Retrospect will re-backup anything that was on that menber, using a newmember.

 

Glenn

 

PS: how did your older VXA-1 drive fail?

 

The fan control circuit of my original VXA-1 failed after 22 months of ownership. The fan would spin briefly at power on, but then remain motionless. The drive would abort the backups when it overheated. The new drive has no control circuit - it spins continuously. Tech support says that is the way they work now.

Link to comment
Share on other sites

Glenn,

 

Quote:

Please provide some more info about your system:

What revision of the Retrospect Driver Update (RDU)?

 


3.5.104

Quote:

 

Is the VXA-1 SCSI-Narrow (50 pin), SCSI-Wide (68 pin) or FireWire?

 

 


firewire

Quote:

 

What is the VXA firmware revision?

 

 


2EAE

 

Quote:

Run a verify on the tape now that further backups have been written to the tape. If you cannot read the tape to verify it, then your backups are not going to be useful.

 

 


 

I panicked when I saw it was writing to a possibly bad tape, and stopped the server. Since the swap to the other backup set would happen on the next day, I haven't put anything useful on the possibly bad tape. I'll try a small one-shot backup and see what happens when I bring the tapes back on-site. Recataloging sounds like a good idea, also, though since there is only about 40MB of stuff on the possibly bad tape, I think I'll tell Retrospect to forget that it exists and erase it.

 

Quote:

S: how did your older VXA-1 drive fail?

 


 

It just died at the young age of 8 months. No particular cause. The Ecrix tech support said that he had seen odd behavior with the firmware revision I had, and thought a new version of firmware would fix things up. Unfortunately enough, though, the error condition couldn't be cleared.

 

Thanks for the tips,

 

Bill

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...