Error -36 during catalog write

[danpoarch]

I'm trying to decifer where to go next with an error that I'm getting in Retrospect 6.1.238 on a 8x2.8Ghz MacPro [intel of course], running 10.5.8. I have two LTO Ultrium 3 drive libraries connected. The object is to migrate everything off the old drive onto the new drive. Everything is connected via an Atto UL5D.

 

I can use each drive successfully. The new drive has executed a full backup of the local server drive as a test, and the previous drive has continued making its daily backup routine.

 

HOWEVER... The tapeset on the new drive fails to write to it's catalog on every attempt to transfer data from the old tapesets to the new tapesets [using the Tools/Copy/Transfer method]. It seems to forget where the catalog is after the error, then the catalog has to be rebuilt from tape. I can't use 'rebuild' as it fails too. Thus, I can initiate a 'transfer,' watch it move about 3-6GB of data and then it will fail when updating the catalog.

 

The vexing part about all of this is that it DID write 80GB worth of data during an Immediate Backup of the server's boot volume. So the catalog works, just not during a Transfer.

 

Log entry:

+ Executing Backup Set Transfer at 10/14/2009 2:38 PM

To backup set OffsiteArchive…

 

- 10/14/2009 2:38:52 PM: Transferring from LTO Archive 1…

Can't save catalog, error -36 (i/o error, bad media?).

10/14/2009 3:05:48 PM: 1 execution errors.

Remaining: 35649 files, 40.7 GB

Completed: 55659 files, 36.0 GB

Performance: 1386.9 MB/minute

Duration: 00:26:56 (00:00:24 idle/loading/preparing)

 

So, after numerous permissions repairs on the OS side, and numerous catalog rebuilds and failed attempts at the above transfer... Does anyone here have any ideas?

[rhwalker]

What version of Retrospect do you have?

 

Retrospect 6.1.[color:red]238[/color]

there is no such version, I suspect a typo.

 

First, because Retrospect 6 is a dead product, it's unlikely that there will be any fixes.

 

However, that said, I wonder if this isn't an interaction between the two tape drives, perhaps the error is being reported wrong.

 

Have you tried (are you able?) to put the tape drives on different channels of the UL5D? Only reason I ask is that we saw an odd bug with Retrospect 6 that was only solved when we put the tape drive on its own channel of our UL4D, away from disk drives (Retrospect was occasionally causing a transfer complete interrupt to be dropped for a RAID 1 mirror drive of the boot volume, causing the system to hang).

 

That's not what you are seeing, but I wonder if it couldn't be related in some odd way.

 

See if you get the same results if the drives are on different channels of the UL5D.

 

Russ

[danpoarch]

My mistake, the Retrospect version is 6.1.230.

 

The drives are indeed on separate channels already. I may bring in another UL5D to see if keeping them on separate cards helps the process by forcing them to build a bridge. Seems to make no sense, but that might just be the logic it needs.

[rhwalker]

If they are on separate channels, then bringing in another UL5D won't change anything.

 

You are chasing a different problem.

 

Attacking it from the catalog side, are the catalogs (old, new) on the same disk volume?

 

Might be wise to save the catalog away during tests.

 

One other thought, you haven't mentioned which RDU (Retrospect Driver Update) you have installed, or if you have any RDU installed. Just something to check.

 

A workaround, since the drives seem to be working, would be to have an intermediate disk backup set if you've got spare storage floating around. Transfer from one drive to the disk backup set, then from the disk backup set to the other drive.

 

Russ