Maser Posted August 13, 2007 Report Share Posted August 13, 2007 So, after working fine for a while, my instance of Retrospect (current app build, current driver update file) is crapping out when it scans my new intel Xserve (4G RAM, dual xeon 2.66). I'm running Retrospect on the server -- this isn't a client scan. If I scan the server hard disk, it will hit a certain point, and then the program quits. I thought I had tracked it down to one specific folder (which I then .zipped and deleted the original data), but then all that happens is the scan continues farther and then craps out at another point. Suggestions? Problem with running Retrospect on an Intel box? This probably goes along with the other issue I reported where my console.log file is chock full of "malloc" statements when scanning my "data" folders on my server... I'm open for suggestions here. I can manually scan/backup critical folders at this point, but I'm looking not to have to change my scripts to limit what I back up... Quote Link to comment Share on other sites More sharing options...
Maser Posted August 13, 2007 Author Report Share Posted August 13, 2007 And the really odd thing? If I find a folder containing data that makes Retrospect die when I scan that folder as a "subvolume", if I move everything out of the folder to another folder and scan *that new folder*? It scans it fine. I think Retrospect is either having a problem running on an Intel mac, or on a Mac with 4G RAM or something... This is the same data that was on my 2G RAM G5 Xserve a week ago. :-/ Suggestions would still be helpful! Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted August 13, 2007 Report Share Posted August 13, 2007 Quote: if I move everything out of the folder to another folder and scan *that new folder*? It scans it fine. - By "everything" you are certain that no invisible files were left behind? - If you re-populate the problem folder with a single data file, will the program crash? > This is the same data that was on my 2G RAM G5 Xserve a week ago. :-/ - How did you move the data? - Have you run file/disk utilities on the volume(s) affected? Quote Link to comment Share on other sites More sharing options...
Maser Posted August 13, 2007 Author Report Share Posted August 13, 2007 Dave asks... - By "everything" you are certain that no invisible files were left behind? Fairly certain. I did a finder drag-copy from one server to another of the data portion of the server. I then ran a command to delete all the .DS_Store files on the data volume (recently -- not initially) - If you re-populate the problem folder with a single data file, will the program crash? No! I can do things like: Move all the subfolders out of the "crashing" folder and put folders back in "sections" (ie, folder names "A-E", "F-M", etc...) Will not crash until it gets to a set of 3 folders beginning with "P". Thought it was those folders. Put everything else back in. The folder doesn't crash. Put each of the "P" folders into the "crashing folder" one at a time. Scan the "entire" folder again. Doesn't crash! Arrange the folders "by name" (in icon view). Rescan the folder -- crashes. ARGH > This is the same data that was on my 2G RAM G5 Xserve a week ago. :-/ - How did you move the data? Stopped all services on the "old" server except AFP and booted off all users. Did a "drag copy" of the data from the old server to new folders (same name) on the new server) - Have you run file/disk utilities on the volume(s) affected? Disk Utility says no problems... ARgh. Quote Link to comment Share on other sites More sharing options...
Maser Posted August 13, 2007 Author Report Share Posted August 13, 2007 Here's also why I think it's a Program error. My data folder (which when I scan the whole thing it craps out)... If I make a "subvolume" of every folder in that folder, I can do a preview scan of a series of folders (ie, "O" through "W"). Each scan brings up a preview window of the subvolumes. But if I scan the problematic "W" folder only? Retrospect crashes. This appears to be some kind of memory bug in the app. Is there some way to force how much RAM Retrospect uses under Rosetta? Quote Link to comment Share on other sites More sharing options...
Maser Posted August 13, 2007 Author Report Share Posted August 13, 2007 Fixed it... Reset *all* my data folder permissions and the entire hard disk now scans correctly. Why? You got me. However, my "console.log" file is still chock full of these: Retrospect(363,0xa000eca0) malloc: *** vm_allocate(size=1543507968) failed (error code=3) Retrospect(363,0xa000eca0) malloc: *** error: can't allocate region Retrospect(363,0xa000eca0) malloc: *** set a breakpoint in szone_error to debug Once it hits my data folder. Something is still wrong with the program and I'm still looking for clues there. I have to purge my "console.log" file on restart so it doesn't fill the drive with these commands... Quote Link to comment Share on other sites More sharing options...
Maser Posted August 15, 2007 Author Report Share Posted August 15, 2007 ARgh. The stupid problem returned. I fixed the permissions -- the backup ran correctly at night as expected. Next day? Retrospect dies scanning the entire drive again. Something is wrong somewhere. Grr. Quote Link to comment Share on other sites More sharing options...
I12BPhil Posted August 20, 2007 Report Share Posted August 20, 2007 I am having this same problem. When I back up the boot drive, it works. When I try to back up our 2.5TB array it begins to scan the files, then immediately quits. No errors, nothing. Just stops. I tried repairing permissions to no avail. Any suggestions? Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted August 20, 2007 Report Share Posted August 20, 2007 As noted in another thread, this is apparently an 10.4.10 bug with ACLs. Use the special build that does not copy ACL information and it should backup the data without crashing. Sorry, no link to the special build. But <Search> is your friend. Dave Quote Link to comment Share on other sites More sharing options...
rhwalker Posted August 20, 2007 Report Share Posted August 20, 2007 Quote: As noted in another thread, this is apparently an 10.4.10 bug with ACLs. Use the special build that does not copy ACL information and it should backup the data without crashing. Sorry, no link to the special build. Hacked Retrospect workaround for ACL bug Quote: But <Search> is your friend. Yea, the magic search phrase is intel acl Enjoy. Quote Link to comment Share on other sites More sharing options...
GMRMacBackup Posted August 28, 2007 Report Share Posted August 28, 2007 I, too, am having the 'Scan and fail' issue on a brand new Intel Xserve, but it only appears to happen when it is indexing an actively shared drive. I have my XServe Raid split into Active and Offline volumes, each night the Active volume is copied to Offline and then Offline is backed up to an LTO3 throughout the day. During the 'Mirror' phase of our backup, ACL modded Retro scans approximately 75% of Active and then fails. The application just drops out without an error or crash screen. My current workaround is to copy Active to Offline with a clone application and, so far, the backup of the Offline volume has proceeded normally. Even with a non-universal version of Retro the transfer rate is almost 3000MB/min to tape. Quote Link to comment Share on other sites More sharing options...
GMRMacBackup Posted September 7, 2007 Report Share Posted September 7, 2007 Progress update: It's been about a week and I am thinking about switching back to the standard version of Retrospect. The disk>disk>tape scenario is working well as long as I use a third party application (PsyncX) to perform the initial disk to disk clone. With Retrospect backing up an offline (and unshared) volume it works very well. There appears to be some compatibility issues with the way the OSX Server application and Retrospect function on an Intel XServe. I fervently hope Retrospect is upgraded/renovated soon for the Mac, it's an exceptionally good program that is getting a little dated. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted September 7, 2007 Report Share Posted September 7, 2007 Quote: There appears to be some compatibility issues with the way the OSX Server application and Retrospect function on an Intel XServe Yep. There is indeed a compatibility issue with OS X on Intel when Access Control Lists are used. That's pretty much the basis of this entire thread, as well as others here on the Forum. Your new configuration works because the cloned disk you are using as your Source does not have ACLs enabled, and thus is not effected by the OS bug that causes Retrospect to fail. Dave Quote Link to comment Share on other sites More sharing options...
GMRMacBackup Posted September 11, 2007 Report Share Posted September 11, 2007 I figured that was the case, it's not an ideal solution but it works for me. The alternative of not backing up is out of the question and I hope it offered Maser a temporary fix. How 'temporary' this fix is depends on how much support EMC is willing to provide their Mac community. At present the functionality of the program does not coincide with their product description on the EMC website of providing 'automated' and 'reliable' backup. All I can do is hope there is a patch or upgrade to the Retrospect application soon. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted September 11, 2007 Report Share Posted September 11, 2007 Quote: The alternative of not backing up is out of the question and I hope it offered Maser a temporary fix. No, Steve has gobs and gobs of data to backup. Cloning to a freestanding filesystem before backing up probably won't be a solution for him. > How 'temporary' this fix is depends on how much support EMC is willing to provide their Mac community This is an Apple bug. EMC can only work with the Mother Ship as any independent software vendor can, by logging the bug in Radar and providing any additional information Apple might find useful. Dave Quote Link to comment Share on other sites More sharing options...
Maser Posted September 12, 2007 Author Report Share Posted September 12, 2007 yes -- this works for me as a temporary fix (since my name came up again.) ACLs -- I can just keep in a text file (basically) should I need to restore something again. The raw data backup is ultimately what is the most important to me and the "no-ACL" version is currently sufficing (but I'll know what to test as soon as 10.4.11 is released... Quote Link to comment Share on other sites More sharing options...
helmsc Posted September 24, 2007 Report Share Posted September 24, 2007 I just got an Apple Xserve with Retrospect and mine craps out even with the "No ALC" version. Any other ideas? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 24, 2007 Report Share Posted September 24, 2007 Quote: I just got an Apple Xserve with Retrospect and mine craps out even with the "No ALC" version. There is no such version. Perhaps a typo? What version are you running? (6.x.y - what are x and y?) Did you follow the complete instructions in the following KB article? Retrospect KB article re ACL bug workaround See especially the last sentence. Quote: Any other ideas? Can you provide any facts? You have not indicated what version of Retrospect you are running, what Retrospect Driver Update version you are running, what Mac OS X server version you are running, what your hardware configuration is, what the error messages / log notices are, etc., etc. Can't help you without facts. Quote Link to comment Share on other sites More sharing options...
helmsc Posted September 24, 2007 Report Share Posted September 24, 2007 Sorry, I meant the No ACL version. The about window shows version 6.1.131 I got to the in progress window by repairing my pemissions but it does not backup the first byte of data. Also I did uncheck that ACL option in the preferences. Mac OS X Server 10.4.10 Dual 2.66GHz Xeon Exabyte 1x10 Packetloader (Firewire) Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 24, 2007 Report Share Posted September 24, 2007 RDU version? Is there any other firewire device on the Exabyte firewire chain? Have you updated firmware in the Exabyte drive and autoloader? There are recent updates. Any error messages in the log? Quote Link to comment Share on other sites More sharing options...
helmsc Posted September 24, 2007 Report Share Posted September 24, 2007 RDU is version 6.1.6.100 (via "Get Info") No other firewire devices. Firmware for drive and autoloader were updated Friday. No obvious errors in console.log or system.log The autoloader LCD does show "D: Writing..." for about 5 minutes then goes back to "D: Ready" the whole time Retrospect "Immediate Backup" window shows "Please wait" and never backups a single file and stays on zero K. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 24, 2007 Report Share Posted September 24, 2007 Quote: RDU is version 6.1.6.100 (via "Get Info") No other firewire devices. Firmware for drive and autoloader were updated Friday. No obvious errors in console.log or system.log The autoloader LCD does show "D: Writing..." for about 5 minutes then goes back to "D: Ready" the whole time Retrospect "Immediate Backup" window shows "Please wait" and never backups a single file and stays on zero K. Ok, this is a completely different issue than the one the original poster was having. You don't provide any indication that your computer has crashed, only that no files are backed up. First, your RDU is very old. The current version is 6.1.11.101. Here is history of all RDUs with links to all versions: Retrospect RDU version history You might retry with a more current RDU. Quote: Firmware for drive and autoloader were updated Friday. To what versions? Finally, you might try Exabyte diagnostics (vxaTool) on your drive to verify that it works. Exabyte tools and utilities russ 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.