Net Retry hang ups

[punga]

I'm seeing the same problem at serveral clients whom I support and am unable to resolve:

 

Problem: remote clients (laptops) running various flavors of OS X 10.3 and 10.4., using the latest Retro client 6.107, downloaded after October. If the client leaves the network (as laptops are prone to do) while being backed up by Retro 6.1.126 Workgroup using the backup server feature, the server stalls with a "Net Retry" dialogue and never gives up looking for the client. This prevents the backup from moving on to other clients in the backup server script as well as preventing the nightly backup script from launching. Retrospect will get stuck in this condition for days or weeks if left unattended.

 

I know it's not a network connectivity issue because these same clients are backed up with no issues if left on the network long enough. Retrospect used to be smart enough to give up if a client disappears, but for some reason all versions of 6 have given me this same problem. Again, I have seen this at multiple sites, so I can safely rule out particular network issues. Even if that were the issue, Retrospect should know to give up at some point. To make matters worse, Retro won't pickup where it left off if the client comes back on line the next day; I could live with that at least.

 

Am I missing something? Or is this one of the bugs that Dantz/EMC refuses to acknowledge and blames on shakey network conditions?

 

Thanks,

 

Shawn Punga

[punga]

Bump...

 

Anyone have any ideas?

[punga]

Are the Dantz moderators silence on this subject a sign that they don't want to touch this issue because they don't know or don't want to acknowledge yet another issue with Retrospect?

 

Come on Dantz, step up to plate and give me something to work with. I'd hate to move away from Retrospect because of this and other issues, like client software that magically turns itself off on various machines, yet is not considered a bug.

 

Enquiring minds want to know.

 

Shawn

[CallMeDave]

Quote:

---

Are the Dantz moderators silence on this subject a sign that they don't want to touch this issue because they don't know or don't want to acknowledge yet another issue with Retrospect?

 

---

 

Not likely. The Dantz moderator is probably silent on the issue because this is a community Forum, and not Dantz Tech Support.

 

Retrospect is certainly supposed to move on after a Client machine looses network connectivity. I've tested it in the past and it worked as expected.

 

If this were a wide ranging issue, we'd probably see at least _somebody_ with the same experience add to the thread (given the 40 page views as of this writing). Anyone? Bueller?

 

- Are you able to recreate this issue at will?

- Is there anything common amoung the physical network connections at the "multiple sites?"

 

Have you opened a support incident with Dantz about this? With serveral clients whom you support, I would think that it would be prudent for you to involve the software publisher in your quest to solve the problem.

 

Dave

[punga]

Quote:

---

- Are you able to recreate this issue at will?

 

---

 

In some cases, yes. Sorry for being so general, but I've seen the issue at at least 3 different sites and sometimes the details blend together. Here's a log entry from a client whom I visited Friday, where I found they had not been backed up in 2 weeks because it was because it was stuck on one laptop who disconnected whe the user left:

- 1/11/2006 5:43:10 PM: Copying Kip on Kip Patrick…

1/11/2006 5:43:10 PM: Connected to Kip Patrick

Trouble reading files, error -24001 (user canceled).

1/27/2006 2:40:54 PM: Execution stopped by operator.

Remaining: 4412 files, 2.4 GB

Completed: 5357 files, 3.1 GB, with 0% compression

Performance: 0.1 MB/minute

Duration: 380:57:44 (62:15:27 idle/loading/preparing)

 

Now, you would think that after 200 hours, that retrospect should give up on this client. Regardless of what kind of network issues there may be. Instead, the application sat with a Net Retry dialogue until I sat down at it 3 weeks later.

 

And when I checked in this morning remotely to respond here, the Net Retry box was back and the log said this:

1/28/2006 1:59:32 PM: Copying Kip on Kip Patrick…

1/28/2006 1:59:32 PM: Connected to Kip Patrick

Trouble reading files, error 519 (network communication failed).

2/1/2006 9:08:49 AM: Execution incomplete.

Remaining: 11592 files, 6.9 GB

Completed: 758 files, 272.1 MB, with 0% compression

Performance: 0.1 MB/minute

Duration: 91:09:17 (14:58:38 idle/loading/preparing)

 

Again, sitting for 91 hours trying the same laptop. Now, I know there may be a network issue to investigate since it's happened to the same user (I haven't observed this behavior with other laptops in this office, but it could just be coinidence). However, the issue here is not the network connectivity, but why does Retrospect continue to try and reach a laptop that has left the network. I know this user did not spend the weekend at the office and takes his laptop with him when he leaves. There should be a way to tell Retrospect to give up after a certain amount of time. It's why I posted the question.

 

Quote:

---

- Is there anything common amoung the physical network connections at the "multiple sites?"

 

---

 

Other than Macs using OS X in 10/100 ethernet environments, no. Some are using Netgear hubs, others using Assante and other brands.

 

I haven't contacted Dantz support because based on my past experience with them, they'll claim it's a network issue and tell me to start replacing hubs and cables (user is wireless in the case). And, I or my clients, shouldn't have to pay an incident charge to resolve a deficiency in the application. The reason I came here is because I have seen Dantz people responding to issues on these forums and hoped they could help.

 

Shawn

[rhwalker]

Quote:

---

Are you able to recreate this issue at will?

 

---

Yes. We have one legacy component of our accounting system that only runs on OS 9 (won't work in Classic), so we have an OS 9 computer on our network to do that one accounting function at the end of the day. One easy way to recreate the Net Retry hang is to shut down a Mac OS 9 client (Retrospect Client 5.1.157, Wait on Shutdown checked) from the Finder to the Retrospect screen saver (Finder: Special > Shutdown) while the scanning is taking place over the network from our server, then shut down from the Retrospect screen saver. We've just learned that Retrospect is fragile, and schedule the backups during the night when there is no activity on the clients. It happened with Retrospect 6.0, and continues with Retrospect 6.1.

 

Configuration on the server running Retrospect Workgroup:

Retrospect 6.1.126 with RDU 6.1.2.102

Xserve G5 single processor 2.0 GHz 2 GB RAM, Mac OS Server 10.4.4 (also happened on 10.4.3)

Tape backup to Exabyte VXA-2 1x10 1u PacketLoader LVD SCSI-3 with ethernet admin

VXA-2 firmware 210B, autoloader firmware A10B, ethernet admin firmware V10E0A (all latest)

ATTO UL4D dual-channel SCSI card (driver 3.50, firmware 1.50 - latest)

Network is 10/100BaseT through a Netgear FS726T switch with 1000BaseT to Xserve.

The OS 9 client machine is an old 8100/100 running Mac OS 9.1.

 

Never saw this in Retrospect 2.1 through 4.2 on ASIP 4.x through 6.x; it's something new with Retrospect 6.x on OS X Server.

 

Russ

[natew]

Hi

 

Open the special tab and option click on the preferences button. You can set a speed threshold that will force Retrospect to give up if the transaction speed gets too low.

 

Nate

[punga]

Quote:

---

Open the special tab and option click on the preferences button. You can set a speed threshold that will force Retrospect to give up if the transaction speed gets too low.

 

---

 

This method did not work. I just checked in and backup server was stuck on a client (displaying Net Retry...) from Feb 6. I had set the threshold to 5 MB/minute. The log shows it the performance at .1 MB/minute. I've dropped it down to 1 MB/minute but I have a feeling that using this method does not work.

 

Any other suggestions?

 

Thanks,

Shawn

[mapski99]

Have you tried disconnecting another wired or wireless user from the network right after initiating a backup?

 

just to test out whether it's Kip or anyone who disconnects.

[punga]

In the location I described, the issue appears when any of 4 or 5 different users leave the office. There is no consistancy across the board other than someone who leaves the network while backup server is attempting to back them up. It just never gives up. The log files above were provided as typical examples, but I have witnessed it happening to all users in the office with portables.

 

Shawn

[thecomputerguy]

Just to lend some support to Shawn's complaint, I too have seen this same issue at two different sites. It's always with a laptop that leaves the network during a Retrospect backup. It'll hang my Macintosh backup servers(both running 6.1.126) until I come behind and cancel the 'Net Retry'. Doesn't matter if it's a Windows or a Macintosh laptop. Fortunately, I visit each of my sites once a week and can address the problem when it happens. It would be nice though, for this issue to be investigated further by Dantz. I really think it's a problem with Retrospect Server.

[rhwalker]

I don't think that Retrospect Server has to be involved. We only do scripted automated backups from our Xserve G5, backing up all the clients on the network (and itself). I can cause the net retry hang at will on a Mac OS 9 client by shutting down the Mac OS 9 client from the bouncing Dantz cube screensaver while the Retrospect network scanning is happening for that client.

[CallMeDave]

Quote:

---

I can cause the net retry hang at will on a Mac OS 9 client by shutting down the Mac OS 9 client from the bouncing Dantz cube screensaver while the Retrospect network scanning is happening for that client.

 

---

 

Important question: If you shut down the Mac OS 9 client from the bouncing Dantz cube screensaver while Retrospect is doing some client operation _other_ then scanning (backing up or comparing), does the same net retry hang up occur?

 

Dave

[cce]

I'd like to add my voice to this complaint; as I posted in the "Networking and Clients" section, I have the same problem. Due to a networking error, one of the clients backed up by my office's Retrospect server often disconnects mid-backup. The Net Retry sometimes reconnects, but the connection either cuts out again or goes so slow that it takes days to complete. I need the server to give up automatically so it can get on with other backups. The underlying problem is certainly a networking error, but I need Retrospect to handle this error more gracefully.

[rhwalker]

Quote:

---

Important question: If you shut down the Mac OS 9 client from the bouncing Dantz cube screensaver while Retrospect is doing some client operation _other_ then scanning (backing up or comparing), does the same net retry hang up occur?

 

---

Dave, I'm out of town this week and can't test this, but I will when I get back. Actually, I should have stated more precisely that I can get it to hang at will if I shut the Mac OS 9 client down while the bouncing cube screensaver is doing its jerky motion indicating that Retrospect client is being accessed during the backup cycle. I don't recall whether it is precisely during the scanning or backup or compare. I believe that it is during the scanning, because our OS 9 networked client is only used to run one legacy accounting data transfer program at the end of the day and nothing really changes (maybe only a file or two), so the backup and compare go very fast. But I will check when I get back in town next weekend.

 

Russ

[ALFAntioch]

I started getting excited when I read this post, because it saved me the time of writing it myself. It is EXACTLY the issue I have been having. I have two servers, running the latest Retrospect Server version 6.1.126. They BOTH exhibit this identical behavior. In fact, this morning, I arrived to find Backup Server #1 trying to do a Net Retry on one power book - client v 6.1.107 (it was half done when the person pulled the plug and left), and Backup Server #2 was doing a Net Retry on a different power book - client v 6.1.107 (it, too, was partially done when the user pulled and left, as it was the end of the day). So, none of my scripts ran during the night on either server. When I came in, I disabled the backup server, and now I have hours and hour of catchup to do.

 

I got very disappointed when I saw there were no additional posts, or resolutions.

 

As that was posted months ago, are there any suggestions now? Besides not running the server.

 

Thanks, ALF

[chrisric]

I too will add my voice to this thread...

 

I have the exact same issue described directly above only I have 12 Xserves and it has happened on all of them.

 

Can a Rep. from Dantz/EMC advise if this issue is being investigated?

 

Thanks.

 

-Chris

[CallMeDave]

Quote:

---

Can a Rep. from Dantz/EMC advise if this issue is being investigated?

 

 

---

 

 

This Forum is not EMCInsignia tech support; it is a community space for Retrospect users to help each other, with some participation by some EMCInsignia employees.

 

With the current base price of an XServe being $3,000, I find it odd that a server administrator with minimum $36,000 invested in iron wouldn't run to the telephone to spend $75.00 to open a support incident for a problem they're having with a critical bit of software.

 

Personally, I've closed the lid on numerous Powerbooks while they were being accessed by Retrospect, and in each case/test the program reported a network communication error and moved on to its next task.

 

Since your milage varies; you should contact the company for help with your configuration.

 

Dave

[chrisric]

Dave - I'd like to argue but you are right...

 

I will log a case with EMC and will post the results here.

 

Cheers,

-Chris

[rmcken]

So did anything come of this? Or do we all have to hop on the phone and call tech support (good for emc, perhaps). We are having the same problem and it is reproducable. The client seems to have to drop off the network at just the right point in the server backup for it to hang, but if you hit that point it will wait forever.

[CallMeDave]

Quote:

---

The client seems to have to drop off the network at just the right point in the server backup for it to hang, but if you hit that point it will wait forever

 

---

 

This seems to be correct; recent attempts to reproduce this has resulted in some successes and some failures.

 

Backup Server scripts appear to be more likely to get stuck then regular scripts. But without a doubt, sometimes the program times out in about 4 or 5 minutes, and sometimes it keeps trying forever.

 

Dave

[chrisric]

I had given up on the forums coming back... Anyway.

 

I called EMC and they couldn't find my support details but they helped me all the same! Thank you EMC.

 

The fix they told me about is more a workaround than anything else but it has been working for me.

 

Bring up the "Retrospect Directory" window, select the "Special" tab, hold down the "Option" key and click on "Preferences"

 

Click on "Client", I have a "1" in the box which works for me but others may want to fine tune it to suit their network.

 

Thanks.

 

-Chris

[CallMeDave]

Sadly, the "Execution performance threshold" secret preference is only respected during file copying. While Retrospect is scanning a volume, this setting is ignored.

 

Similarly, the backup server script Client Execution "Speed threshold" option is only checked once at the first connection to each client.

 

Neither of these provides a fail safe way to prevent infinite Net Retry hangups.

[punga]

This issue continues to vex my firm at various sites (we support mostly small design studios). However, one common thread when the net retry begins to happen is: G5s. In most cases the clients will have a mixed network of G4s and G5s, but only the G5s will have this problem during a regular script execution (as opposed to a back up server, where it is mostly G4 laptops of some variety).

 

Anyone come across any other clues. Obviously, Insignia doesn't seem to take this issue seriously as even those who have paid to talk with their tech support and not found a resolution. Insignia, are you listening? (and please spare me the rants about this being a forum for the Retrospect community to share experiences. I know they read these threads and would do well by their long standing customers to provide some help besides "Check your network connections and pay us $75 to talk to you on the phone).

 

Shawn