What is this error? MapMacError: unknown macintosh error -2110

[ajemutt]

Hi all!

 

I've just installed Retrospect 8.1 (build 626) on a Mac Mini (server hardware) running Snow Leopard 10.6.2 (NOT the server OS, regular Snow Leopard)

 

I've created a script to backup 4 LAN machines to a Drobo, and it seems to work OK, EXCEPT for one Macbook Pro which has Snow Leopard installed (the other 3 machines are a mix of Tiger and Leopard)

 

It seems to be able to scan all the files on the Snow Leopard machine, but once it starts to copy them, it chokes and goes onto the next client.

 

I keep getting the following errors, neither of which are listed in the KB or can I find any ref on the forums (actually the error -1002 IS listed in an OLD OLD OLD article about Ret for Windows relating to MacOS9 volumes)

 

anyways, here is the error:

 

- 1/9/2010 8:48:01 PM: Copying Macintosh HD on Doonesbury 7.0

MapMacError: unknown macintosh error -2110

> Scanning incomplete, error -1002 ( unknown Mac OS error)

 

Any insights? I was specifically told by the sales folk that I needed to upgrade to 8 so I would be able to backup a Snow Leopard machine.

 

thanks!

 

AJ

 

 

[rhwalker]

Have you tried backing the Snow Leopard LAN client up to a different destination not on the Drobo? That might provide an insight into the cause of the bug.

 

Also, what version of Retrospect client is on the Snow Leopard LAN client that doesn't work? On the Leopard and Tiger LAN clients that do work?

 

Russ

[ajemutt]

Hi Russ,

 

I just connected a blank 750GB USB hard drive to my Retrospect Server (the Mac Mini), formatted the drive, threw away retrospect and it's preferences and application support files, restarted the machine, re-installed Retrospect 8, restarted again and reset the PRAM, and built a new script to backup ONLY the problem client onto the new USB drive.

 

I then got the same error as before.

 

[rhwalker]

Ok. That's valuable information because it eliminates the Drobo as the problem, and indicates that that problem is with the Retrospect client on the Macbook Pro running Snow Leopard.

 

threw away retrospect and it's preferences and application support files, restarted the machine, re-installed Retrospect 8, restarted again and reset the PRAM

I don't think that this was necessary.

 

Once again, as I asked upthread:

 

Also, what version of Retrospect client is on the Snow Leopard LAN client that doesn't work? On the Leopard and Tiger LAN clients that do work?

[ajemutt]

I'm currently running 6.3.027 on all clients, which is the version of the client that came with 8 when I downloaded it.

 

thx!

 

 

A

 

 

[ajemutt]

Hi again,

 

I just updated to problem client to 6.3.028, which is the latest available from the website, restarted the client and attempted the backup again. I got the same error.

 

Since those errors are not listed or properly described in th KB, do you know what they actually mean?

 

thx!

[rhwalker]

I just updated to problem client to 6.3.028, which is the latest available from the website, restarted the client and attempted the backup again. I got the same error.

 

Since those errors are not listed or properly described in th KB, do you know what they actually mean?

No. Because there is no manual and no KB documentation on this error, you will need to contact EMC Retrospect support to figure out how to move forward. Your problem sounds like it is beyond the help available in these user-to-user forums. Working with EMC support, they may be able to document the bug well enough with your help so that it can get fixed. Here is the contact information:

Contact EMC Retrospect support

 

Russ

[ajemutt]

Hi again,

 

After calling support, it was suggested that the only thing the problem could be was Retrospect choking on a corrupted file on the client.

 

I ran the latest version of Disk Warrior, and it found a few minor screwy things, which it repaired.

 

The one thing it didn't repair was in my Library/Parallels folder, where DW said I had a folder with 1027(!) nested folders. I dug out the folder, and did a "Get Info" on it, the Mac OS stated that there were 55 items enclosed, so I'm confused as to which was accurate... I dug about 20 layers down before giving up and just trashing the folder.

 

I then went back to Retrospect, where it seemed to be able to get through an entire scan without choking (it had been chocking around 60GB on a rive with 200(ish)GB of data on it)

 

Anyways, after it finished the scan, Retrospect went to start copying the client drive, and then it was unable to find the client and threw error -530 at me.

 

I tried the script again, same error.

 

I went to the finder, where my client machine clearly shows up on the network, and I can log into it that way.

 

I went back into Retrospect and the source menu, and deleted the client, and tried to re-add it, and Retrospect no longer sees ANY client machines to add as sources.

 

I restarted the Retrospect server machine, and the client machine. Still throwing the same error.

 

I'm now going to uninstall and reinstall both client and server software in hopes that this resolves the problem, but even if it does, Is this amnesia on the part of the server a common happening?

 

 

thx!

 

 

[rhwalker]

Is this amnesia on the part of the server a common happening?

Well, understand that Retrospect 8 is a complete rewrite. The code is a bit immature, and the error recovery routines are not very robust. As each of these bugs are reported to EMC and hopefully addressed, it will get better.

 

Russ

[Maser]

If it were me (and I had the time), I'd probably set up some "Favorite Folders" and try to isolate where the problem is.

 

(You seem to be indicating you are backing up the *entire* client?)

 

Break down the backup to subsets of the folders on the disk and see if that shows you any better results.

 

If it still acts up, it may help you isolate where Retrospect truly is choking.

[CallMeDave]

So seem to be two completely independent issues being reported, or just a miscommunication.

 

1- "DW said I had a folder with 1027(!) nested folders"

 

If DiskWarrior reported a problem and the Finder showed different information, I'd go with Disk Warrior and suspect a problem with the disk's directory.

 

"I dug about 20 layers down before giving up and just trashing the folder."

 

[color:red]Did you then run DiskWarrior AGAIN[/color] and get a clean bill of health?

 

2- "Retrospect no longer sees ANY client machines to add as sources.

 

"I restarted the Retrospect server machine, and the client machine. Still throwing the same error."

 

The above two are in the present tense, leaving this reader confused.

 

- Engine host machine did not see any clients.

- Engine host machine was restarted.

- Were clients then seen?

 

If the issue is still (again) specific to the one client, please make that clear.

 

The Original Post states that the scan completes and files begin to copy, yet the error is "[color:purple]Scanning incomplete[/color]." Do you actually see any file count for copied files before it chokes?

 

Having confirmation that DiskWarrior was happy after deleting the one suspicious folder would probably be the best next step for online support.

 

 

Dave

[ajemutt]

Hi everyone,

 

thanks for the responses!

 

TO try and clarify:

 

After deleting the folder with that Disk Warrior identified as being nested at 1027, I restarted the problem client, and then tried to run the Retrospect backup script I created for that client alone.

 

After scanning approx 200GB and getting ready to copy, the green ball icon to the side of the source turned into a grey one, and Retrospect was unable to find the client.

 

I went to the finder to see if the client was still visible on the network, and it was.

 

I then went into retrospect and tried to see if I could access the client through the add source dialogues, and not only was the problem client gone, but Retrospect was unable to see the other 3 machines on the network that had clients installed and turned on.

 

I then uninstalled retro on the server machine and threw out the relevant files in the Library, restarted the server machine and reinstalled retrospect. I then also threw away the client and reinstalled as well (note to EMC- please give us an 'uninstall' option in the installer again. It's a pain to have to keep fishing around in the library!)

 

After doing all this, the Retrospect server was unable to see ANY clients on the network.

 

Note: This same 'amnesia' happened the other day as well. An uninstall, restart and re-install resolved that problem then.

 

I then went home and got a good nights sleep. When I came in this AM, I once again uninstalled retrospect and threw out the relevant library files, restarted and reinstalled.

 

Upon re-adding the client in Retro server, building a new script to back up the single problem client and running that script - it SEEMS to be working OK now, but it still has to chew through 150GB more, so I don't expect to know if it's worked until tomorrow AM.

 

My main concern at this point is how often Retro server simply forgets all the clients and is unable to see any of them on the network to re-add. Specifically, I'd like to know what prefs to throw out so I don't have to dump *everything*

 

 

thanks!

[Maser]

How are you adding the clients? By browsing for them, or by hostname? Do the clients get a static IP address? Or is the IP address dynamic and changing?

 

I've only ever added clients by hostname (static IP address) and that's worked well for me over the years. I've heard people still have issues with browse-added clients, so, YMMV.

 

Also, are the clients running any kind of firewall that *might* be blocking the Retrospect engine from seeing them? (Doing a port scan from the engine machine to the client to look to see if port 497 is open would tell you this...)

[rhwalker]

TO try and clarify:

 

After deleting the folder with that Disk Warrior identified as being nested at 1027, I restarted the problem client,

At this point you should have re-run Disk Warrior until you got a clean bill of health. Did you? Not good to continue anything else until you have done that. A filesystem that has become wound upon itself, with a messed up inode list and messed up free list, is junk. I'm not sure I would trust the data even after you get past the Disk Warrior success point because you may have dumped "mystery garbage blocks from space" in the middle of data for files. There's no way to tell if this has happened. With humongous sized disk drives, it's hard to find all of those mystery garbage blocks from space.

 

I then uninstalled retro on the server machine and threw out the relevant files in the Library, restarted the server machine and reinstalled retrospect.

Nope. Need to know you have a healthy filesystem before you start writing ANYTHING to the drive after you threw out the "relevant files in the Library". See above. Start over.

 

I then also threw away the client and reinstalled as well (note to EMC- please give us an 'uninstall' option in the installer again. It's a pain to have to keep fishing around in the library!)

See the client uninstaller script that Robin Mayoff posted here:

Unofficial Retrospect Mac Client Uninstaller Script

 

Russ

 

[CallMeDave]

At this point you should have re-run Disk Warrior until you got a clean bill of health. Did you?

Damn that Central time zone; FusionBB shows your posting time as half an hour later then my computer's clock!

 

Didn't I ask that question in red? Maybe next time I'll use all caps.

 

 

I then uninstalled retro on the server machine and threw out the relevant files in the Library, restarted the server machine and reinstalled retrospect...

I once again uninstalled retrospect and threw out the relevant library files, restarted and reinstalled.

An uninstall, restart and re-install resolved that problem then...

Did you also stand in a bucket and slaughter a goat? Drastic measures such as restarting, and even more drastic measures such as uninstalling/reinstalling have their place only after trying less intrusive things.

 

(note to Russ; the possible MGBFS were on the client, not the Engine host machine)

 

it SEEMS to be working OK now, but it still has to chew through 150GB more, so I don't expect to know if it's worked until tomorrow AM.

This is where Russ' "nope" should go. Without assurances that the Source's filesystem is healthy I wouldn't be satisfied with a backup even if it completed without error. But that's just me (and my data).

 

See the client uninstaller script that Robin Mayoff posted here:

 

Here's a company that figured it out; include the AppleScript inside the installer package with an easy to find clickable link right in the installer window:

 

[rhwalker]

At this point you should have re-run Disk Warrior until you got a clean bill of health. Did you?

Damn that Central time zone; FusionBB shows your posting time as half an hour later then my computer's clock!

 

Didn't I ask that question in red? Maybe next time I'll use all caps.

Yea' date=' but when the original poster replies and goes on without addressing this critical point, I thought that repetition might help. Could be a color-challenged computer screen (or user).

 

Did you also stand in a bucket and slaughter a goat? Drastic measures such as restarting, and even more drastic measures such as uninstalling/reinstalling have their place only after trying less intrusive things.

Like the rubber chicken waving with the Boole and Babbage chant.

 

(note to Russ; the possible MGBFS were on the client, not the Engine host machine)

Sorry. Blinded by the goat blood.

 

Then the "Nope" belonged instead after the step:

 

I then also threw away the client and reinstalled as well

It's unhealthy to make filesystem changes (delete, create files, reinstall) on a filesystem that is wound upon itself.

 

Russ

[ajemutt]

Hello all, sorry for the late update, being the boss + IT guy means I have to sometimes put the IT part down for a few days to catch up.

 

Here is my update:

 

I *******DID******** run Disk Warrior a 2nd time after throwing away the troubled directory, and all got a clean bill of health.

 

 

I then created a new script on the server, ran it, and now I no longer get any errors for that client.

 

Unfortunately, Retrospect only backed up 417MB on a drive that has over 200GB on it.

 

I had 3 other clients on this script, and all 3 others backed up seemingly fine.

 

I called into support, and they told me to remove the script and source client from the server, restart the Retrospect Engine in the prefs panel, and re-add the client and make a new script.

 

I did those, but after restarting the engine, Retrospect was unable to add or even see any clients to add. I tried adding by IP address, and Ret was able to then see the client, but when I tried to add it, it just went nowhere.

 

I restarted the Engine again in prefs pane, and was then able to see and add clients.

 

I then created a new script with only the problem client, and now I'm getting mixed signals from Retrospect:

 

In the activities window, there is a yellow WARNING triangle on the left hand side next to the log entry for this attempt, but the summary says "execution completed successfully" and the log lists no errors, yet it's still only backing up a tiny fraction of what's on the client drive.

 

Note for todays attempt, I only had the problem client in the script.

 

Thanks for the ideas folks, I appreciate it!

[CallMeDave]

Retrospect only backed up 417MB on a drive that has over 200GB on it.

 

- Are you running any Rules against the backup?

- Are you also backing up other computers' (veeeery similar) volumes to the same Media Set?

[ajemutt]

Hi Dave,

 

"All Files' is checked under Rules. No other sources or volumes are being backed up in this current set.

 

yesterday, I ran a script with 4 Sources, the 3 other clients backed up just fine, but this one Snow Leopard machine continues to be a problem child.

 

(maybe I should arrange for that sacrificial goat right about now, eh)

 

 

Any idea how to find out what the yellow warning triangle represents since there was no error actually listed in the log?

 

thx!