Jump to content

Onstream fw30 failing with error 105 on verify


Recommended Posts

It sounds like I'm far from the only person with this problem, so I'll add my voice to the chorus. I'm running version 5.0.238 with RDU 3.1.105 (a bit old, I know, but the subsequent updates haven't had anything relevant to my drive). My OS version is 10.2.5. The drive heads are clean.

 

I actually hadn't seen this problem until today, but this was the first time my backup spanned more than one tape. The file copying phase ran fine, but the verify phase failed with the second tape, immediately after inserting it. I ran a new backup with a new tape, and the same thing happened. I tried to run a separate verify, and again, the same thing happened.

 

Anybody had any luck solving this one?

 

As a side note, it surprises me that Retrospect immediately terminates the operation on a media error like this. Having written tape handling software myself, it seems to me that it ought to retry a few times first rather than just erroring out immediately, especially when retrying the entire operation involves re-verifying the first tape again, a process that takes hours to complete.

Link to comment
Share on other sites

When this happens to me, I just delete/erase the last tape. (I have the same Onstream fw30) and re-do a back-up. I presume, that this will then only back-up the files that were on this tape. It then writes and verify's just fine.

 

On a secondary note. Has anyone spoken to Onstream recently? Or heard anything about them? My drive is faulty and when I reported it to them a few weeks ago, they said they'd replace it. However since then I've heard nothing. I've tried phoning the UK help, the Netherlands help, Netherlands Sales, etc. without any luck. I've also e-mailed the Netherlands help + sales and the US sales. Nothing. Anyone know if they've gone out of business or something?

 

regards Paul

Link to comment
Share on other sites

Quote:

When this happens to me, I just delete/erase the last tape. (I have the same Onstream fw30) and re-do a back-up. I presume, that this will then only back-up the files that were on this tape. It then writes and verify's just fine.

 


 

I don't think that's the case - I don't think retrospect is quite that smart. In particular, when you erase a piece of media, but not the backup set it belongs to, I don't think it marks the files that were on that piece of media as not backed up in the catalog. Unless every file that was on the erased tape was subsequently changed so that it would need to get backed up again, I suspect that you're missing some files in your backup set.

 

When you re-do your backup, it sounds like you're forcing conditions that make the new backup fit on one tape, so you don't trigger this tape handling bug, which is what I think this is.

 

Link to comment
Share on other sites

Quote:

I don't think that's the case - I don't think retrospect is quite that smart. In particular, when you erase a piece of media, but not the backup set it belongs to, I don't think it marks the files that were on that piece of media as not backed up in the catalog. Unless every file that was on the erased tape was subsequently changed so that it would need to get backed up again, I suspect that you're missing some files in your backup set.

 


 

Actually, it looks like I'm wrong, Retrospect is this smart. I'd like some reassurance from a Dantz employee that doing this will product a consistent and complete backup set, though. I'm testing this workaround myself right now, and I'll post anything new I learn from it.

 

Thanks for the suggestion, Paul.

 

Link to comment
Share on other sites

Okay, too bad I can't delete the above post, because I have to return to my earlier claim. Although the backup appeared to run and verify successfully when the second tape was erased as Paul suggested, a subsequent verify of the whole backup set failed in a big way. The first tape verified as it always had, and I didn't get an immediate error 105 as before, but this instead:

 

Bad backup set header found (0x37ab993a at 16,462,866).

Backup set format inconsistency (12 at 16463121)

Bad backup set header found (0x06f00000 at 16,464,720).

Backup set format inconsistency (4 at 18559761)

Backup set format inconsistency (4 at 20656657)

1005 files were not verified.

5/17/2003 3:32:32 PM: 6 execution errors.

 

Link to comment
Share on other sites

A bad backup set header message means that Retrospect encountered a missing or damaged file header which contains information such as the file's name and size. See the following KB article on troubleshooting bad backup set headers:

 

 

 

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27863

 

 

 

Error 105 was reported by many users with the release of 10.2.2 (might have been 10.2.3), and in almost every case, the problem was resolved with the 10.2.4 update. That you are seeing error 105 and bad backup set headers would tend to indicate that there is a hardware problem or device communication issue. Standard troubleshooting as outlined above is applicable.

 

 

 

 

Link to comment
Share on other sites

I only see the backup set header message if I follow the procedure described by Paul earlier in this thread, not if I attempt to backup in a normal way. However, I tried repeating Paul's procedure with different tapes, and the verify failed with _precisely_ the same message, i.e. at exactly the same address. That's hugely statistically unlikely if this really was a media or hardware problem rather than a retrospect bug.

 

Also, note that I was running 10.2.5 (now updated to 10.2.6 and, not surprisingly, the problem remains), so my error 105 is clearly not due to the general problem with firewire tape devices in earlier versions of Jaguar. Please review my original post, at the top of this thread for the primary problem. I'll lay odds that you'll be able to reproduce this problem yourself if you attempt a backup yourself that spans more than one tape.

 

By the way, I followed the standard troubleshooting procedures as documented in that knowledge base article before posting to the forum the first time.

 

Link to comment
Share on other sites

Quote:

I tried repeating Paul's procedure with different tapes, and the verify failed with _precisely_ the same message, i.e. at exactly the same address. That's hugely statistically unlikely if this really was a media or hardware problem rather than a retrospect bug.

 


 

Could you post exactly what message you got, instead of just noting that some address was the same?

 

And please, instead of noting that you did the same thing as what someone else did (when they did not provide a step-by-step example) could you provide a step-by-step example of exactly what you did?

 

Bug reporting is easy, but it requires some attention to detail before it can do anyone any good.

 

Dave

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...