Jump to content

Intel 10.5.1 retrospect network communication error


Recommended Posts

Just to update. I looked at the invisible files (via Onyx) at the root level, deleted a couple that had 2005 dates. I then deleted my subvolumes and ran the backup. It was fine. It has since run twice and it scans and backs up. Sorry but I didn't document the deleted files.

 

All seems to be working for now.

Link to comment
Share on other sites

  • Replies 141
  • Created
  • Last Reply

Top Posters In This Topic

Quote:

I afraid i dont want to take the risk of deleting wrong file and break the system

 


 

That's a healthy fear. Mucking about with invisible files at the root level of an OS X install should _not_ be done unless you know exactly what you're doing.

 

More information is going to be needed to figure this one out for Retrospect users.

 

 

Dave

Link to comment
Share on other sites

Just to clarify, the last modification date of the files I deleted was 2005 not a creation date. My logic was any necessary file there would have a newer date. One was an old NAV file but I don't remember the other. Maybe I just was lucky but all is well.

 

I'm not even sure that was the problem, could something in Retrospect or the catalog change by creating the subvolumes and running a backup even though the subvolumes were then deleted so the full volume is backed up?

Link to comment
Share on other sites

I was unable to fix the issue so I used the subvolume approach: I created a Group and defined all the subvolumes under the user's main disk, then added all these subvolumes into the group and selected the group as the backup source and backed up the group - It worked! What I don't know is which subvolumes I really didn't need to define or if this misses anything or how messy the restore will be if needed. I'm also not sure if the files at the main hard disk level get backed up with this approach - I'll have to test and see...

 

Any comments on this approach are welcome. It seems to just be an extension of backing up by subvolumes but a bit more efficient - one backup operation as opposed to many. Due to other problems with Leopard, I may be downgrading these users to Tiger which is another way to avoid the issue!

 

Thanks!

 

Tim Sachi

Link to comment
Share on other sites

Quote:

What I don't know is which subvolumes I really didn't need to define or if this misses anything or how messy the restore will be if needed.

 


 

With this method you would need to define all of the volumes you want to back up.

 

As for restore, you will _not_ be able to restore a bootable volume this way. The only way Retrospect can restore a bootable volume is if the Snapshot is of the root level of the boot volume.

 

There have not been enough reports here to figure this out online. More data is needed.

 

 

Dave

Link to comment
Share on other sites

Obviously, I need to define volumes I want to back up but some volumes it lists are things like .volumes and .usr and I'm not sure what they contain and what benefit they would be to backup.

 

This problem is very consistent and repeatable for me. I would guess everyone that upgrades client(s) to Leopard running Retrospect 6 and doing network backup (I haven't tried a direct connection) will have this issue. As more Retrospect users upgrade to Leopard, the issue will be more prevalent and thus hopefully be fixed by the company

 

Does anyone out there doing Retrospect network backup with version 6 NOT have this issue with Leopard clients?

 

In that vein, I hope that the company will fix the problem; otherwise the software will become essentially useless for me!

 

Any suggestions for alternate network backup software for Macintosh?

 

Tim Sachi

Link to comment
Share on other sites

Quote:

Does anyone out there doing Retrospect network backup with version 6 NOT have this issue with Leopard clients?

 


 

I think this is an important question, although "this issue" is not well defined in this thread.

 

For example, going up-thread looking for specifics, I find no complete and accurate Operations Log information provided by any of the effected posters. Post 104390 states:

* 12/5/2007 3:30:48 AM: Connected to Mark Johnson’s Computer

* 12/5/2007 3:30:48 AM: Copying Macintosh HD on Mark Johnson’s Computer…

* Scanning incomplete, error 519 (network communication failed)

 

But that's not the order that these activities show up for either a Scripted or an Immediate backup. And while it may be a small detail, anytime I see any inaccuracy in a report I become suspicious of all aspects of that report.

 

Seeing a full Log snippit, from Retrospect launching through the communications error, would be a helpful addition to the thread.

 

After that, hearing from users who are successfully backing up the root level of Leopard clients would certainly be informative.

 

 

Dave

Link to comment
Share on other sites

I thought my inital explanation was quite clear: "I am having the exact same problem on 2 new Mac Pro clients I just got that came with Leopard (OS X 5.1). I updated the Retrospect program (running on an Intel Mini 10.4.11) to the latest version (6.1.138) and the 2 new Mac Pro clients to the latest (6.1.130). When I attempt a backup on either of these, it appears to be connected at first listing "Scanning: 1 folder, 0 files" but then quickly goes to a "Net Retry" message and eventually times out with a 519 (network communication failed) error message in the log. All my other clients (still on 10.4.x) still work for backup and these 2 clients worked before I upgraded them to the new Mac Pros that came with Leopard. They were previously on 10.4.X"

 

However, here is a copy/paste of the log from startup to after the error message comes up:

 

Quit at 12/19/2007 2:23 PM

 

 

? Retrospect version 6.1.138

launched at 12/19/2007 2:23 PM

+ Retrospect Driver Update, version 6.1.13.101

Error!!! Scanning incomplete, error 519 (network communication failed)

 

As you can see, the log is essentially worthless.

 

Some other facts:

The Net Retry message is as follows:

 

Net Retry... Stop

 

Jennifer at XXX.XX.XXX.XX

 

Note: Actual IP address not shown for security reasons

This Net Retry message lasted almost 4 minutes before displaying the following error:

 

Error!!! Scanning Incomplete, error 519

(network communication failed) OK

 

I've learned that I need to let it Net Retry... until I get that error message and not try to stop it or it locks the client from future access (Clientt Reserved message) until I go to the client and turn off and on the client

 

What other info do you need?

 

Thanks!

 

Tim

Link to comment
Share on other sites

Quote:

As you can see, the log is essentially worthless.

 


 

Hmmm. The log information you provide certainly looks different then every log entry I've reviewed.

 

There is no entry for what Retrospect is attempting to actually do, such as:

 

Retrospect version 6.1.126

launched at 12/19/2007 9:14 AM

+ Retrospect Driver Update, version 6.1.11.101

 

+ Normal backup using Foo_Script at 12/19/2007 9:16 AM

To backup set Foo_File_Backup_Set…

 

 

or

 

 

+ Executing Immediate Backup at 12/19/2007 9:21 AM

To backup set Foo_File_Backup_Set…

 

 

I also notice is that this log information is at odds with what was provided by the original poster (file82). Which suggests that "I am having the exact same problem" was not an accurate statement.

 

- Could you describe more completely what you saw that you reported as:

...first listing "Scanning: 1 folder, 0 files"

 

Where was the information about scanning provided?

 

I would not expect Retrospect to start to scan anything without first putting an entry into the log that it was about to try and do so.

Link to comment
Share on other sites

Sorry, if I used the word "exact". I did not mean to imply that the logs matched exactly but I was having all the same symptoms and results. After all, no two things are ever exactly alike in all respects so I guess that statement could never be accurate.

 

The "Scanning" and "Net Retry..." messages came up in the dialog box on the screen.

 

As you should know, I have no control over what Retrospect puts in the log, unless there's some preference I'm unaware of. I literally copy/pasted the log text into my previous post.

 

That all said, I have news to report: It started working now for no apparent reason. The last several times I tried it, It did succeed in scanning the files and proceeded to start backing up the files; however, that only means the problem is intermittent which will make it that much more difficult to solve! I typically do unattended backups over the weekend so I can't afford to have it happen then as it will stall the backup process at that point, but I guess I could put these users as the last to be backed up in the sequence.

 

Thanks!

 

Tim

Link to comment
Share on other sites

Quote:

The "Scanning" and "Net Retry..." messages came up in the dialog box on the screen.

 


 

It might help if you provided a more step-by-step account of exactly what you are doing, and exactly what you see when you do it. There are various sorts of dialog boxes, so "the dialog box on the screen" isn't specific enough to understand what you're seeing.

 

- I know the "Net Retry" dialog box well; how does the "Scanning" dialog box compare in its size and shape?

 

- Was this an Immediate Backup?

- When you click on Backup, what do you see?

 

When I do an Immediate Backup, the first thing that I see when I click "Backup" is the "Immediate Backup" window goes grey, and the cursor changes to the rotating gar icon. During this point, the client machine has launched the retropds.23 process which walks the file tree. This can take a very long time if there are a lot of files; during that time, no dialog box is displayed in Retrospect.

 

After that, the larger "Immediate Backup" window is replaced by the smaller "Immediate Backup" progress window, which shows file counts, times, etc.

 

Do any of these things happen on your problem machine(s)?

Link to comment
Share on other sites

The Scanning dialog box is the same size, shape, position window as the Net Retry Window. It appears that the Scanning Message just changes to a Net Retry message in the same window but it may be actually a new window that comes up in its place faster than can be perceived. Unlike what you are describing, after the Immediate backup dialog box turns gray, this scanning dialog box immediately displays on the screen and (when things are working) you can watch it count the files and folders as it finds them: For example, the dialog box appears as follows:

 

Sanning...

Macintosh HD on Betty Stop

 

xxxxx folders, xxxxxx files

 

The xxx's are constantly changing

 

This changes to a message about xxxxx folders being updated and then goes back to the immediate backup window to start the backup...(but again, this is when things are working)

 

When things aren't working, you just get the Scanning... message dialog box for a few seconds listing 1 folder and 0 files and then it goes to Net Retry... message (in the same dialog box apparently) and after several minutes, the error message (in a new dialog box) pops up as described previously. The only option is to click OK which aborts the attempted backup, which isn't making progress anyway!

 

Thanks!

 

Tim

 

 

 

 

 

This is not immediate backup dialog box

 

Yes, I'm doing immediate backups to test but scripted backups result in the same error. I never get

Link to comment
Share on other sites

After connecting a monitor to my server (800 MhZ QuickSilver G4, Mac OS X 10.4 Server, Retrospect 6.1.138, RDU 6.1.11.101) I am able to completely scan the root level of my iMac CoreDuo, OS X 10.5.1, Client 61.1.30 with no net retry.

 

So this is not an inherent software compatibility issue.

 

The information provided so far paints a confusing mix of symptoms.

 

* The Operations Log appears incomplete, where there is no indication of what operation Retrospect is beginning before it logs the communication error.

 

- Do the log entries for the successful client operations contain lines about "copying" and "connecting?"

 

* The problem is showing on two specific machines that share an OS version. But then the problem goes _away_ on both of these machines, then it comes back on both of them. That might have suggested that the issue is not the client, but the Retrospect machine. However, the Retrospect machine is able to successfully scan other client computers, which points back to the two specific problem machines. Round and round we go!

 

- Do the two machines share any other common attributes that might be missing from my simple test bed? How much RAM in the MacPros? How are they connected to the network, etc? Any specific software installs on these machines that is not installed on other machines? Have there been TimeMachine hard drives connected?

 

- If you preflight an Immediate Backup, and click "Files Chosen," do you get the stall after 1 file?

 

(note that if you can connect via ssh (using Terminal.app) you can kill/restart pitond (the Retrospect OS X Client process) from the comfort of your own machine, so you don't have to visit the client hardware and disturb the user)

 

Another user in another thread provided an anecdote that /.com.apple.timemachine.supported caused a problem with client access from Retrospect. His/her accounting did not convince me, but it might be worth a try to delete that file (which would likely be recreated if/when needed, or perhaps could be recreated by the "defaults" utility) and test.

 

 

Dave

Link to comment
Share on other sites

For now, I'll attempt to do a full backup every so often and hopefully get it to work at least once for each Leopard client and each of my backup media (2 X 250GB external hard disks) so I have a "skeleton" of each client disk on each backup media for restore if needed.

 

For unattended backups, I've organized the Leopard client's hard disks to have only folders at the main hard disk level and only a couple folders besides the standard folders (Library, System, Users, Applications). In Retrospect, I've defined these folders (sub-volumes) and created groups (1 group per Leopard client) to contain them. I then select these groups as sources for my unattended backup instead of the Leopard clients' hard disks. Hopefully, this will be sufficient for restore if needed.

 

Anyway, that's my plan until the problem gets fixed by EMC Insignia, if ever!

 

Thanks!

 

Tim Sachi

Link to comment
Share on other sites

Here is a copy/paste of the log for a "successful" immediate backup attempt followed by 2 other attempts that each gave an error. Actually, I was doing this from my laptop (PowerBook G4) and trying to backup to a backup file on the laptop but there wasn't enough space so the backup stopped (but it was successful as far being able to scan the client):

 

? Retrospect version 6.1.138

launched at 12/19/2007 3:14 PM

+ Retrospect Driver Update, version 6.1.13.101

 

+ Normal backup using Jennifer C at 12/19/2007 3:15 PM

To backup set Backup Set C…

 

- 12/19/2007 3:15:36 PM: Copying Macintosh Jennifer on Jennifer…

12/19/2007 3:15:36 PM: Connected to Jennifer

Not enough space for selected files.

About 49.5 G more required.

12/19/2007 3:31:43 PM: Execution incomplete.

Remaining: 763697 files, 61.4 GB

Completed: 0 files, zero KB

Performance: 0.0 MB/minute

Duration: 00:16:07 (00:15:54 idle/loading/preparing)

 

Quit at 12/19/2007 3:31 PM

 

 

? Retrospect version 6.1.138

launched at 12/19/2007 3:57 PM

+ Retrospect Driver Update, version 6.1.13.101

Error!!! Scanning incomplete, error 519 (network communication failed)

Error!!! Scanning incomplete, error 519 (network communication failed)

Quit at 12/19/2007 4:06 PM

 

I was actually attempting backups from 2 different computers simultaneously (but not accessing the same client simultaneously) acting as the backup server, my PowerBoook G4 laptop and an Intel based Mac Mini, both on 10.4.11. When I noticed it started to work from my laptop backing up one of the Leopard clients (Jennifer, the one in the log above). I immediately attempted to back up the other Leopard client (Grecia), from the Mac Mini to an external hard disk; that backup succeeded totally; however, later on it stopped working again, from either backup server to either client.

 

I restarted Jennifer's computer and had her not start to use any apps until I could attempt a backup but the backup still failed with the same communication error.

 

As mentioned, these are my only clients on Leopard but they also have apps that most others don't have, namely the Adobe InDesign Suite of programs (InDesign, Illustrator, Photoshop, etc.). I have recently installed this Suite on my computer, but that is the backup server so I doubt it will fail; however, I did install it on another client iMac G5 running 10.4.11. Not an Intel Mac and not on Leopard but if it starts to fail on backup, that may point to InDesign.

 

Both these Mac Pros have 5GB RAM and I have not connected any Time Machine hard drives. The users do, however, use file sharing between them to access each other's files. They are connected to our campus Ethernet - a very fast (1Gb) Ethernet and have static IP addresses. All of our computers are connected this way.

 

Please give me more specific info about that kill/restart command (exact syntax). That sounds useful!

 

As for the /.com.apple.timemachine.supported file, I was hesitant to delete a file a new nothing about and wasn't sure if it would be auto-recreated or not. I may try this though...

 

I won't be able to try your pre-flight Immediate Backup suggestion until I return to work next Wed.

 

The fact that it worked suddenly for both clients and from both backup servers at the same time (for an hour or so) makes me suspect something in the network connection, as if a network firewall was up most of the time but happened to be down for an hour or so, then went up again; but all the non-Leopard clients continued to work. Also, others on this thread are having essentailly the same issues.

 

I just recalled that I did turn Appletalk on on one of the clients attempting to solve a printer issue. I think I left Appletalk on so I wonder if it may be related to that, although, I only did this on one of the clients. Just grasping at straws!!

 

Thanks!

 

Tim

Link to comment
Share on other sites

None of the software you mention are a problem, nor is the fact that AppleTalk is enabled.

 

The machine does have more then 4 Gigs or RAM, which might mean nothing at all, but it's more then the Intel/Leopard tester I used (I've got my own straws to grasp on this end).

 

I still believe that the absence of any Log entry that shows a connection to the machine is the most relevant hint we've got. It just seems as if Retrospect doesn't get as far as actually talking to the machine.

 

When you start your backup, does retropds.23 launch on the client? Use ssh to connect to the machine, and use the 'top' utility to watch processes that launch.

 

In fact, if you visit Configure->Clients->YourClient->Configure... and then click on the Configure tab, retropds.23 will launch on the client. And when you click OK or Cancel, retropds.23 will then die on the client.

 

So it might be interesting to know if, when the Scan window first shows up, retropds.23 (which is responsible for providing actual filenames to Retrospect) has even launched on the effected client(s).

 

"pitond" is the unix process that represents the "On" radio button of the Retrospect Client.app program, and it lives at:

/Applications/Retrospect Client.app/Contents/Resources/pitond

It needs to be run as root. If you need help with Bash or other shells, I'd direct you to any of the helpful resources at other places on the internets.

 

Dave

Link to comment
Share on other sites

I now seem to be suffering from possibly the same problem and I'll try to add a data point.

 

Machine #1 acting as Retrospect Backup host:

G5 2x2Ghz, 3+GB RAM, 10.5.1, Retrospect 6.1.138

 

Machine #2 (backup fails), a Retrospect client that is causing the 'Net Retry' on Machine #1:

24" iMac Core 2 Duo, 2.4 Ghz, 10.5.1, 4 GB, Retrospect client 6.1.130,

'pitond' (PPC code) is running, client indicates 'On' button checked and shows a message that is being used by 'root'.

Local 'Time Machine' is enabled.

 

Initial backup of this machine appears to have completed successfully but subsequent incremental backups have all failed with a 'Net Retry' dialog showing. At this time I haven't waited for the net try to time out.

 

Machine #3 (backup succeeds):

G4 iBook, 10.5.1 <1GB, Retrospect client 6.1.130, no problems

No local 'Time Machine'.

 

So in my case, my only Intel-based Mac is failing but all ppc machines are working. Maybe this will help.

 

Good luck

 

note: edited to add 'Time Machine' info

Link to comment
Share on other sites

I haven't been able to spend much time on this lately but I did get a successful backup of one of the clients again last night. I then tried both clients this morning. The client that worked last night appeared to be working again (it proceeded to scan past the 1 folder, 0 files message) but the other client is again getting the Net Retry/Communication error. I had the user read the status message in the Retrospect client app while I attempted to do the backup and she said it first said "Connected" and then "In Use by Root for Scanning" which remained until the scanning gave up (error message at backup server) and the Status message changed backed to "Ready." I recall that if you abort the scanning before getting that message, the client gets stuck on "In Use by Root for Scanning" and prevents subsequent access from the server with the message "Client is Reserved" until you stop and start the client inside the client app.

 

Just another 2 cents worth from me...

 

Tim Sachi

Link to comment
Share on other sites

Quote:

Before you attempt to run the backup to Machine #2, does the Status field of the Retrospect Client application show "Ready"?

 


 

Yes, machine #2, the client, initially says "ready". As the backup initiates, the next message on machine #2 says "in use by root".

Meanwhile machine #1, the host, is getting the "net retry" dialog.

 

RickB

Link to comment
Share on other sites

i'm having the same issue.

 

it seems quite reminiscent of the ACL/rosetta problem

 

before attempting to backup the client, the client is in "ready" state (pitond is running)

 

when the server attempts to backup the client, i get the usual backup/defer dialog on the client, then pitond pegs one of the CPUs, but no retropds processes startup that i can see. during this time the server is in a "Net Retry" dialog (on top of the initial Scanning... 1 folders, 0 files dialog)

 

during this the retrospect client status says "in use by root"

 

after 3-4 minutes, the server gives up with a scanning incomplete, error 519

 

the client then says "ready" in the status line

 

 

(there have been some times when the client is "connected" and attempts to turn off the client resulted in it remaining in that status--i had to kill pitond in order to turn off the client, so that i could turn it back on and into the "ready" state)

 

hal

Link to comment
Share on other sites

All of sudden client is backing up ok but I don't know why.

The only change that I am aware of is that I toggled the "No ACL's" preferences option.

Since then, several backup scripts have run successfully with the "No ACLs" option unselected after initially toggling this option.

 

I haven't been able to recreate the failure yet.

 

Maybe someone else can try this the "No ACL" option to see if it helps them.

Both host and client are running on 10.5.1. Client is on Intel iMac and host on G5 2x2.

 

rickb

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...