Jump to content

Retrospect 6.1.138 and VXA-320 Firewire loader - out of sync errors

Recommended Posts

(Sorry to be posting this again to a different forum, but after speaking with the hardware mfg, it appears that the issue may be with Retrospect. Are there any other users out there that's using this drive in a Firewire configuration? Any success? I am going to contact EMC tech support about this but was hoping that there were other folks out there with this setup? Thanks!)



We've been using Retrospect on our servers for years without major issue, however our new tape loader is giving us problems which we can't narrow down to either the hardware or Retrospect.


The issue is that as soon as Retrospect moves from the first source to the second, it throws up the 'catalog out of sync' error. So if we have 20 items (local folders on the server, network clients, AFP shares, etc) all defined in a backup script, when it runs that script, it will fail when moving from the first source to the second. It doesn't matter what that source is (local folder on a secondary volume, AFP volume, Home folder, network client, etc.) nor does it matter what size the first source is from our tests. As soon as it finishes backing up the first source, verifies it, then right after it moves to the second source, it will throw up the error. We've tried creating a new Backup Set on different drives/locations, running a recycle backup (instead of normal), running Tools > Repair > Update Existing to the catalog per the error directions, etc. all with the same results---the first source works and the second source (and therefore all subsequent sources) fail.


We've run tests on the tapes with the Exabyte/Tandberg CLI tools and they pass. We've erased our X23 tapes completely with Retrospect, used a new X23 tape, used the vxaTool to write VXA-320 headers, etc. All do not fix the above problem. Doing a restore (after fixing the catalog) shows us that it did in fact back up the first source fine. We've tried the using first source sizes as small as 50 MB and up to 5 GB---it still fails after the first source verifies and the second begins. By the way, the above configuration works fine with our older Exabyte VXA-2 Firewire-800 packetloader (1x10) with the exact same servers and files being backed up. We've tried creating new sources on the newer test system (backing up two dummy folders of random files) and essentially using a default install/configuration with the same problem.


I wanted to see if there any known Retrospect issues with this drive before I escalated support to Tandberg for the drive (or get an RMA). If anyone else has any hints/ideas/suggestions, we'd really appreciate it. The below lists our tested configurations. Currently Retrospect is on the G4, but we are going to migrate it to the MacPro so getting it to work on that would be better.




PowerMac G4 MDD 1.25GHz, 2GB RAM

Mac OS X.3.9 Server

80 GB boot drive with 70 GB free

Retrospect 6.1.126

Retrospect 6.1.138 with Driver Update

Exabyte/Tandberg VXA-320 Firewire-800 packetloader (1x10) with latest firmware V13220

-attached via FW800 to FW400 cable to built-in FW400 ports.

-also tried SIIG FW800 PCI card and FW800 cable.


MacPro 2.8GHz Quad Core, 2GB RAM

Mac OS X.5.1 Server

320 GB boot drive with 315 GB free

Retrospect 6.1.138 with Driver Update

Exabyte/Tandberg VXA-320 Firewire-800 packetloader (1x10) with latest firmware V13220

-attached via FW800 cable to built-in FW800 port (tried front and back)

Link to comment
Share on other sites

Have you tried falling back to an earlier RDU? There have been reports of problems with the updates over the last year, maybe an older one will work.


It appears that support for you device was first added to; maybe stepping back a few revs closer to this might make a difference.



Link to comment
Share on other sites



Thanks very much for that suggestion. We've completed testing and it appears that the RDU from two revs back ( was the first one to support our VXA-320 Firewire loader AND solves the problem for us. We had the same hesitation that John C. Welch had, but it works fine. Note to anyone with a VXA-320 drive, make sure that you erase your X23 tapes with Exabyte/Tandberg's vxaTool BEFORE you use it in Retrospect or you won't get the full capacity that a VXA-320 drive affords since (as mentioned elsewhere in these forums) X23 tapes are formatted with VXA-2 headers by default for compatibility.


Hopefully EMC will fix the current RDU ( with latest Retrospect 6.1.138) so that other users won't be bitten by this gotcha.

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.

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.

  • Create New...