Frank N Berry Posted January 24, 2008 Report Share Posted January 24, 2008 (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. Thanks! 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 6.1.13.101 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 6.1.13.101 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 More sharing options...
CallMeDave Posted January 24, 2008 Report Share Posted January 24, 2008 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 6.1.3.101; maybe stepping back a few revs closer to this might make a difference. http://kb.dantz.com/article.asp?article=7886&p=2 Link to comment Share on other sites More sharing options...
johncwelch Posted January 25, 2008 Report Share Posted January 25, 2008 I'm seeing this too, on a G4 Xserve, same versions of retrospect, tape library and drive updated to most current firmware. I'm hesitant to backgrade the RDU, since the 6.1.13.101 is what ships with 6.1.138 Link to comment Share on other sites More sharing options...
CallMeDave Posted January 25, 2008 Report Share Posted January 25, 2008 Quote: I'm hesitant to backgrade the RDU, since the 6.1.13.101 is what ships with 6.1.138 It's not a problem (or I wouldn't have suggested it!). Dave Link to comment Share on other sites More sharing options...
Frank N Berry Posted January 27, 2008 Author Report Share Posted January 27, 2008 CallMeDave, Thanks very much for that suggestion. We've completed testing and it appears that the RDU from two revs back (6.1.11.101) 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 (6.1.13.101--comes with latest Retrospect 6.1.138) so that other users won't be bitten by this gotcha. Link to comment Share on other sites More sharing options...
Mayoff Posted January 28, 2008 Report Share Posted January 28, 2008 John, what version of the Mac OS are you using? Link to comment Share on other sites More sharing options...
johncwelch Posted January 29, 2008 Report Share Posted January 29, 2008 Quote: John, what version of the Mac OS are you using? The Backup Server is Mac OS X Server 10.4.11 Link to comment Share on other sites More sharing options...
johncwelch Posted January 29, 2008 Report Share Posted January 29, 2008 Quote: Quote: I'm hesitant to backgrade the RDU, since the 6.1.13.101 is what ships with 6.1.138 It's not a problem (or I wouldn't have suggested it!). Dave Indeed it is not. Backgraded to the older RDU, and it's running smoooooth. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.