Jump to content

Scanning my server hard disk craps out -- any suggestions?

Maser

Recommended Posts

Maser Newbie

Maser

Posted
Posted

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...

Link to comment
Share on other sites
Maser Newbie

Maser

Posted
  • Author
Posted

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!

Link to comment
Share on other sites
CallMeDave Newbie

CallMeDave

Posted
Posted

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?

Link to comment
Share on other sites
Maser Newbie

Maser

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Maser Newbie

Maser

Posted
  • Author
Posted

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?

Link to comment
Share on other sites
Maser Newbie

Maser

Posted
  • Author
Posted

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...

Link to comment
Share on other sites
rhwalker Newbie

rhwalker

Posted
Posted

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.

Link to comment
Share on other sites
GMRMacBackup Newbie

GMRMacBackup

Posted
Posted

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.

Link to comment
Share on other sites
  • 2 weeks later...
GMRMacBackup Newbie

GMRMacBackup

Posted
Posted

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.

Link to comment
Share on other sites
CallMeDave Newbie

CallMeDave

Posted
Posted

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

Link to comment
Share on other sites
GMRMacBackup Newbie

GMRMacBackup

Posted
Posted

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.

Link to comment
Share on other sites
CallMeDave Newbie

CallMeDave

Posted
Posted

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

Link to comment
Share on other sites
Maser Newbie

Maser

Posted
  • Author
Posted

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...

Link to comment
Share on other sites
  • 2 weeks later...
rhwalker Newbie

rhwalker

Posted
Posted

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.

Link to comment
Share on other sites
helmsc Newbie

helmsc

Posted
Posted

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)

Link to comment
Share on other sites
helmsc Newbie

helmsc

Posted
Posted

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.

Link to comment
Share on other sites
rhwalker Newbie

rhwalker

Posted
Posted

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

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...