Frank N Berry Posted January 22, 2008 Report Share Posted January 22, 2008 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) Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 28, 2008 Report Share Posted January 28, 2008 Quote: 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 This is a very popular library. This type of error is usually caused when the hardware is failing to "locate" the next section of blank media on the tape for the next backup. It could be caused by device communication errors, dirty tape heads, corrupt backup set, damaged tapes. If you have changed cables, cleaned tape heads, changed tapes and tried a different Mac, and the error still happens with a fresh set of tapes, then the hardware may be failing to do a "locate". Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 28, 2008 Report Share Posted January 28, 2008 Um, Robin, I suggest that you review the following parallel thread, which indicates that the problem is fixed by reverting to RDU 6.1.11.101: http://forums.dantz.com/ubbthreads/showflat.php/Cat/0/Number/105714/an/0/page/0#Post105714 Russ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 28, 2008 Report Share Posted January 28, 2008 I can say for a fact that the VXA drivers did not undergo any changes from the 6.1.11.101 to the current driver update. Why reverting the RDU worked, I am not sure but the VXA code itself is unchanged. Quote Link to comment Share on other sites More sharing options...
Frank N Berry Posted January 28, 2008 Author Report Share Posted January 28, 2008 That's odd, because we ran multiple tests with data sets to 200 GB and everything worked fine. After troubleshooting with Tandberg, they basically verified that the loader and drive were working fine. So with CallMeDave's suggestion, we stepped back to each RDU after the current one and tested the problem. It gave the same Sync error until we used 6.1.11.101. We've rebooted and even went back up to the latest RDU to see if there was some other issue at play, but each time we used the latest RDU, it failed and each time we used 6.1.11.101, it worked. I'm curious if other users (like John from the other thread) are having the same issues. We certainly want to RMA this loader if it's wonky in any way... Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 29, 2008 Report Share Posted January 29, 2008 Quote: I can say for a fact that the VXA drivers did not undergo any changes from the 6.1.11.101 to the current driver update. Why reverting the RDU worked, I am not sure but the VXA code itself is unchanged. While you may earnestly believe this, Robin, may I respectfully suggest that someone at EMC actually test this? Every time in the past four months or so that David or I have suggested that people having problems with recent RDUs regress to earlier ones, that has usually fixed the problems. Just as strongly as you believe that there were no changes that should cause these errors in the recent RDUs, I believe that there is something changed in the recent RDUs beyond what you believe has changed. Perhaps it's a different library against which the RDU was linked or a header file that changed, perhaps it's a case of the released code not matching the compiled version of the source at EMC. Offered in the sense of a constructive suggestion. Russ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 29, 2008 Report Share Posted January 29, 2008 I asked my hardware team to look into what everyone is reporting. Clearly downgrading the RDU is working for at least Frank, but I just don't see what we would have changed to cause this. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted February 1, 2008 Report Share Posted February 1, 2008 Okay, I have egg on my face. We did make an RDU change specifically for VXA performance (no one told me) that is probably causing some users trouble. Our original testing did not see this problem but we will try to figure out what is going on so we can fix it in the next RDU Release. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted February 1, 2008 Report Share Posted February 1, 2008 Thanks, Robin, for the info. I think you may also want to have the programmers carefully review all changes subsequent to RDU 6.1.11.101 because that's when some other issues started on other (non-VXA) fronts, too. Russ Quote Link to comment Share on other sites More sharing options...
happy Posted February 11, 2008 Report Share Posted February 11, 2008 Hello all! I'm having the exact same problem described in this thread when using Retrospect 6.1.138 with a Tandberg Storageloader library (VXA-320 firewire). I don't mind going back to 6.1.11.101. However, I don't know where to download it. Can anyone help? Thanks!! Quote Link to comment Share on other sites More sharing options...
rhwalker Posted February 11, 2008 Report Share Posted February 11, 2008 Quote: I don't mind going back to 6.1.11.101. However, I don't know where to download it. Can anyone help? The entire RDU history and release notes for each version, with links to download each version, are here: http://kb.dantz.com/article.asp?article=7886&p=2 Russ Quote Link to comment Share on other sites More sharing options...
rhwalker Posted April 1, 2008 Report Share Posted April 1, 2008 Robin, In your post two months ago: RDU changes break VXA-320 you revealed that you had learned that RDU changes were made for the VXA-320 that inadvertently caused it to stop working, and Exabyte users have been reverting to RDU 6.1.11.101 to work around the issue. Today an updated Mac RDU was announced: RDU 6.1.14.101 announced but there is no mention of whether the VXA-320 issue was addressed. Was it? Russ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted April 1, 2008 Report Share Posted April 1, 2008 We wanted to get the VXA fix into this release, but didn't have time. We are still working on it and plan to release another RDU to address VXA issues. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted April 1, 2008 Report Share Posted April 1, 2008 Thanks from an Exabyte user. I would much rather wait and have a well-tested RDU than have something rushed out in a hurry. Russ Quote Link to comment Share on other sites More sharing options...
macmesch Posted July 8, 2008 Report Share Posted July 8, 2008 Is this issue fixed by now? We have a VXA-3a Tape Library connected via Firewire to an XServe with 10.5.4 und run constantly into "error 205", which makes Backups impossible(Versions 6.1.126 tested) :confused: Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 8, 2008 Report Share Posted July 8, 2008 I may have a fix later today. Check back into the forum later. Quote Link to comment Share on other sites More sharing options...
Frank N Berry Posted July 9, 2008 Author Report Share Posted July 9, 2008 Wow, this thread is still alive. I came back to check on this since we've been using the old RDU without problems until recently. I think there might have been some changes relevant to this with the X.5.4 update. Like most, we had to update our Server to X.5.4 to resolve some SMB issues, but it appears that now we're having lots of weird stability issues with Retrospect. I see that there's a new version out as of 6/30 and we're contemplating whether to update to it. Are the VXA fixes part of this release? Should we revert to the old RDU that's been working? Or should we wait? The issues we're having with our loader is that it will work most of the time and then suddenly a week or so later it will just stop communicating properly. That is to say that Retrospect is waiting on the drive to load or unload a tape while the loader just says 'Ready' on its LCD screen without any activity. I can verify this on two different X.5.4 Servers with different Tandberg VXA-320 Storage Loaders. The only solution is to Force Quit Retrospect (since it is totally unresponsive) and restart the server (hoping we don't kernel panic)... Any ideas? Thanks! Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 10, 2008 Report Share Posted July 10, 2008 We are putting the final touches on a new RDU specifically for VXA 320 issues. It will be released soon. Quote Link to comment Share on other sites More sharing options...
macmesch Posted July 10, 2008 Report Share Posted July 10, 2008 Does this mean, with Mac OS X 10.5.3 and RDU 6.1.11.101 you managed to do Backupps with the Tapeloader? We wanted to do the System Updgrade from 10.5.3 to 10.5.4 due to some Permission issues, but put it on hold now. Quote Link to comment Share on other sites More sharing options...
macmesch Posted July 10, 2008 Report Share Posted July 10, 2008 Sounds promising, what timerange is here used for the expression "soon"? :boxie: Quote Link to comment Share on other sites More sharing options...
macmesch Posted July 10, 2008 Report Share Posted July 10, 2008 Which Version of Retrospect do you use? We just tried 6.1.126 with RDU 6.1.11.101 which froze Retrospect and led to a kernel Panic while trying to access the Firewire Port A Quote Link to comment Share on other sites More sharing options...
Mayoff Posted July 14, 2008 Report Share Posted July 14, 2008 Hi, This issue has been fixed with the driver update we released on Friday. This driver update is included with the latest 6.1.230 application installer. http://download.dantz.com/archives/Retro-EN-6_1_230.dmg Quote Link to comment Share on other sites More sharing options...
macinrack Posted July 17, 2008 Report Share Posted July 17, 2008 Curious to know if a real fix has been found yet. I have spent too many hours over the past few weeks trying to find a solution, and I have begun looking at solutions other than Retrospect. I have used Retrospect for, oh, an eon or so, and have never, ever had such issues. If there is going to be a fix anytime soon, I sure would like to know about it before I go purchase something else. All the force-quits I must perform for the "not responding" Retrospect are freaking out my x-serve and repeatedly causing a gray screen of death, disrupting the entire office several times per day as I run through this maze. Sorry, my sense of humor on this issue was lost sometime last week. If this is a problem with the Tandberg hardware, please advise so I may chase the appropriate folks. Tandberg 320 1 month old intel x-serve, up to date Retrospect .230 with the driver update Yes, I have disconnected and reconnected everything,re-powered everything, exported all the tapes and then re-imported them, I have recreated preferences, yada yada. I am fresh out of ideas. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted July 17, 2008 Report Share Posted July 17, 2008 Could you please report the specific RDU version given in your log? ("with the driver update" is not good enough). Quote Link to comment Share on other sites More sharing options...
macinrack Posted July 17, 2008 Report Share Posted July 17, 2008 I am uncertain, but it is the very latest and correct update as verified by tech support, several times. I am not at that location right now, and wont be until Monday, at which time I must have a working solution. My intention today, working from home, was to look for that solution. It's increasingly obvious to me that this is unsolvable on my end, short of different backup software. However, Tandberg is not answering their phones right now (permahold for close to half an hour), so I cannot even get a good answer on that front at the moment. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.