Jump to content

Execution Error on Tail of Every Backup I have ever done!!


Recommended Posts

Hi Guys,

 

I have just moved over to an Intel machine with Retrospect. From a previous Power PC system. I am using a iPBridge to access the S4 tape drives. And the Xtend San ATTO drivers. Worked flawless for years except the odd batch of media supplied by quantum.

 

So all the files are recovered except for the very last one on the backup tape. This is repeatable across all backups. The file appears to be there and there appears to be no file size difference. But in my case most of these are quicktime movies in excess of 10Gb each. So a little tricky to extract the image data and reprocess. Painful.

 

Any advice would be greatly appreciated. Am in the process of setting up a Power PC system again.

 

Curious.

 

Rodney

Link to comment
Share on other sites

HI Thanks for getting back to me so quickly.

 

It's a very ambiguous error:

 

"- 15/10/2008 10:29:47 PM: Restoring from BVSC T1 O…

File “BVCA01 First Half.mov†appears incomplete, path: “BVSC Tape 1/Quicktimes/BVCA01 First Half.movâ€.

16/10/2008 4:29:02 AM: 1 execution errors.

Completed: 82 files, 609.6 GB

Performance: 1759.6 MB/minute

Duration: 05:59:13 (00:04:32 idle/loading/preparing)"

 

Any help would be greatly appreciated.

 

I have pulled these files before with no such errors.

 

I am in crazy land trying to figure it out.

 

Cheers

 

Rodney

Link to comment
Share on other sites

Hi Dave,

 

So far I have migrated from Power PC architecture to Intel. The network has remained the same. So we are now running under Rosetta. The machine is still on system 10.4.11

 

I have ordered the update to the iSCSI initiator to see if there are any problems within the xsan environment.

 

The connection to the S4 drive has remained the same. A Atto iPBridge 1500. I have tried restoring to a SanMAN raid, which has remained the same. As well as hard drives across the network. The interesting thing is that if the last file on the archive is 1Mb it comes up with the same error. In most cases I have a work around to recover the data without having to extract images from the seemingly corrupt files. its interesting to note that we also use a mxf structure to retain some of our images and although these backups come up with the same message there is obviously a redunancy within its file structure to allow the images to be extracted in a seamless fashion.

 

My only real issue is I don't want this hanging around for ever. And I have hundreds of S4 tapes which would literally take a year to pull off and restore.

 

I have had tape issues before which been due to degrading tape. Even though its supposed to be good for 100,000 reads. But it tends to clog the heads of the drive and then reports this issue back. And it has never happened at the tail so consistently.

 

Is there anything else I can through in the air?

 

And thank you very much for taking the time to help.

 

Rodney

Link to comment
Share on other sites

Your problem leads me to my own question that may be relevant:

 

When Retrospect writes to a tape, it writes until it gets to the end of the tape. Obviously, it can't see the end of the tape coming, so it will be in the middle of writing the last file.

 

Does anyone (Robin?) know how Retrospect then handles the transition to the next tape member? Does it ignore the partial file on the previous member and begin writing the file from the beginning on the new member? Or does it continue to write data, creating another partial file on the new member, and then stitch the two halves together when restoring?

 

Either way, it would seem that, in your configuration, Retrospect is failing to handle the restore of the partial file from the end of the tape as it normally would do. What kind of a restore are you performing? Does Retrospect not ask for the next tape member in the backup set so that it can continue the restore?

Link to comment
Share on other sites

having written a number of tape drivers in my youth, I can tell you the usual way this is handled. The physical EOT marker is placed a good distance (it's a spec) before actual EOT so that the driver, upon encountering physical EOT, doesn't write too far past EOT (which would cause the tape to come off the reel). When a driver encounters EOT, it is supposed to either do a space reverse file (so that it backs up over the last previous file mark) and then write two file marks in a row, which indicates logical EOT, or else, if a short file can be tolerated by the program, to write two file marks to indicate EOT and EOF. In other words, the logical EOT can be a short (very short) distance past the EOT detection on the tape. Oh, by the way, the EOT strip is not sensed by the heads, but by an EOT sensor that is ahead of the heads. This is why it all works. Clear?

 

How Retrospect handles this I do not know.

 

Russ

Link to comment
Share on other sites

Hi Twickland,

 

I have always found that Retrospect handles multiple tape back ups poorly. Admitedly I conducted these tests a couple of years ago. But I was finding that about every fourth or so back up failed at an EOT boundary.

So not being a technical guru I just put in place a practice of not going across tapes. Just setting up multiple individual archives and this has worked well.

 

Rodney

Link to comment
Share on other sites

So not being a technical guru I just put in place a practice of not going across tapes. Just setting up multiple individual archives and this has worked well.

 

So what do you do when you're performing a backup and come to EOT with Retrospect requesting a new member? Do you just cancel out of the backup?

 

If so, the last file that Retrospect was attempting to write to the tape would, of course, be incomplete. By rights, that incomplete file shouldn't be indexed in the catalog, but not having ever done this myself, I can't confirm how Retrospect actually handles that situation. However, your experience in finding incomplete files at the end of each tape/Backup Set (and here I'm assuming that you're using the old Dantz term "archive" in lieu of the currently-used term "Backup Set") suggests that perhaps Retrospect doesn't handle the cataloging of an aborted tape backup as well as it should.

 

I have always found that Retrospect handles multiple tape back ups poorly. Admitedly I conducted these tests a couple of years ago. But I was finding that about every fourth or so back up failed at an EOT boundary.

This doesn't sound right. I wonder if you may have been experiencing hardware problems with your setup.

 

We have used tape backups (DDS and LTO) for over 15 years with many different computers, host bus adapters, and tape drives, and have never experienced any trouble adding tape members to a given backup set. (There was a bug once where Retrospect would lose communication with a Mac client at EOT boundary if link encryption were enabled, but I suspect you're talking about something different.)

Link to comment
Share on other sites

Hi Twickland,

 

At that stage I was backing up to DLT 8000's.

 

All I meant was that we calculated the file sizes to be backed up and organised them so they would fit into a single logical tape unit. And at the time this was convenient as we weren't using an auto loader.

 

Also our backups are project based so that also made sense.

 

So when we had intermittent issues with execution errors at the end of tape it was not great hassle just to stop the old practice which at that time didn't involve a great percentage of projects. And now with the S4 800Gb it just become best practice for us to do project based backups.

 

Our data storage rates are relatively low. We are around the 10 - 15 TB a month. So its all been good till the migration last week.

 

And even then just painful as it came at a point when retrieval from a back up was required.

 

Keep well.

 

Rodney

Link to comment
Share on other sites

I have always found that Retrospect handles multiple tape back ups poorly. Admitedly I conducted these tests a couple of years ago. But I was finding that about every fourth or so back up failed at an EOT boundary.

So not being a technical guru I just put in place a practice of not going across tapes. Just setting up multiple individual archives and this has worked well.

We've been doing tape backups (and only tape backups) since 1992, DAT back then without autoloader and VXA-2 now with autoloader, always SCSI. Never have seen this problem in over 16 years with Retrospect.

 

Russ

Link to comment
Share on other sites

Hi Guys,

 

Thanks for all your help. Didn't really want an anti Retrospect thing. I am only reflecting on my experience with Retropect. I am still very happy with the product and given we are supposedly in for a new version all is looking good.

 

For Me. There is something happening in the transition to Intel. I re-installed a Power PC retropect workstation and the files turned up as they should.

 

So I have my files but still confused as how to move forward.

 

Thanks once again everybody.

 

Cheers

 

Rodney

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...