Jump to content

punga

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About punga

  • Rank
    Occasional Forum Poster
  1. 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
  2. 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
  3. 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
  4. Quote: By "this" do you mean the same logged crash that Alan reported in the first post of this thread: I'm not onsite with any of my clients (I'm a consultant who supports a number of different studios and workgroups) where this happened to, so I'll need to investigate further. However, I just noticed this morning my client was turned off. Turned it back on, but that appears to wipe the retroclient.log, so the next time it happens, I will check before re-enabling the client. BTW, in some of the cases that I've seen this happen, Airport could not have been a factor because there is no card installed in the machine or no wireless network on site. In my case, my Powerbook has an Airport card, but I need to check the log the next time my client turns itself off. Thanks, Shawn
  5. Quote: Have you every moved the client application from its default location? That can cause this problem. No, in all cases the client is left in its installed location /Applications. Any other suggestions? I set up the other suggestion for the speed threshhold in preferences. That makes sense and I will see how it works. Thanks for your help, Shawn
  6. 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
  7. 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
  8. You could just turn off the notification for "Notify After Backup" in the client preferences on each workstation. Shawn
  9. Any solutions to the client disabling itself issues? I've tried the applescript mentioned above and it does not work. Also, in some of the workstations I'm seeing this on, there is no airport card or network so it can't be related to wireless network. Problem machines range from powerbooks to G5's running 10.3.9 and 10.4.4. And regarding the Net Retry errors, this issue is still not resolved under the latest client (Oct 2005 release). I started a separate thread regarding it here: http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Number=66743&page=0&view=collapsed&sb=5&o=&fpart=1 In my opinion, this isn't a client issues since where I've seen the issue crop up, it's been a user leaving the network and Retrospect backup server not wanting to give up looking for it. Shouldn't Retrospect be able to give up after a set amount of time and move on if a client is not available after, say, 5 minutes? It used to under older versions.
  10. 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
  11. After speaking with my client further, it turns out they had a power outage just before these problems occured. I'm going to run the cleaning tape, have them recycle the offending tape see how it goes. Thanks for your help, Shawn
  12. While onsite at a client, I was asked why after months of using 2 tapes did the backup need a third tape last week. Upon looking through the log, I came across some interesting log entries for one of the clients on the network (400mhz/G4, OS 9.2.2, Retro Client 5.0.201 over TCP/IP): While scanning volume Steve ll, File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:, bad name length: 0 Folder Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:eucharistic congress::, bad name length: 0 Folder Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:eucharistic congress::, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:eucharistic congress::, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:M093/ArchWash/web/kb:COMMUNICATIONS:text:, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2002:02-11-02 Auxbishops update:, bad name length: 0 File Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2002:02-11-02 Auxbishops update:, bad name length: 0 6/26/2003 2:01:44 PM: Comparing Working Files on Heidi… File “Database”: different modification date/time (set: 6/26/2003 1:17:22 PM, vol: 6/26/2003 1:58:44 PM), path: “Working Files:Documents:Microsoft User Data:Identities:Main Identity:Database”. File “Database Cache”: different modification date/time (set: 6/26/2003 1:17:24 PM, vol: 6/26/2003 1:54:54 PM), path: “Working Files:Documents:Microsoft User Data:Identities:Main Identity:Database Cache”. File “Messages”: different modification date/time (set: 6/26/2003 1:16:52 PM, vol: 6/26/2003 1:54:52 PM), path: “Working Files:Documents:Microsoft User Data:Identities:Main Identity:Messages”. File “Schedules”: different modification date/time (set: 6/26/2003 1:51:55 PM, vol: 6/26/2003 2:02:16 PM), path: “Working Files:Documents:Microsoft User Data:Identities:Main Identity:Schedules”. Can't read file “12-28-01 update aux-bishops”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:12-28-01 update aux-bishops”. Can't read file “12-28-01 update aux-bishops”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:12-28-01 update aux-bishops”. Can't read file “12-28-01 update aux-bishops”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:12-28-01 update aux-bishops:12-28-01 update aux-bishops”. Can't read file “text”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2001 and before:M093/ArchWash/web/kb:COMMUNICATIONS:text:text”. Can't read file “02-11-02 Auxbishops update”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2002:02-11-02 Auxbishops update:02-11-02 Auxbishops update”. Can't read file “02-11-02 Auxbishops update”, error -43 (file/folder not found), path: “Working Files:jobs:*MAINT BACKUPS:www.adw.org:resources 2002:02-11-02 Auxbishops update:02-11-02 Auxbishops update”. 6/26/2003 2:03:51 PM: 10 execution errors. Completed: 14 files, 118.0 GB Performance: 3347.0 MB/minute (6579.1 copy, 28,530.2 compare) Duration: 00:12:10 (00:02:39 idle/loading/preparing) There are 2 very curious entry above: the first set of errors refering to "bad name length: 0"; and the more disturbing entry at the end: "Completed: 14 files, 118 GB." This is obvoiously wrong, since neither the drive (40GB) being backed up or the tapes (Ecrix VXA) have that kind of capcity. There are entries further down the log dealing with trouble reading the tape: Trouble reading: “2-Week 2 (new tapes)” (306060), error 206 (drive reported a failure: dirty heads, bad media, etc.). Trouble reading: “2-Week 2 (new tapes)” (306060), error 206 (drive reported a failure: dirty heads, bad media, etc.). Bad backup set header found (0x7479696d at 78,622,314). Bad backup set header found (0x5349543d at 78,622,348). Bad backup set header found (0x48524546 at 78,622,362). Bad backup set header found (0x30003fda at 78,622,631). Bad backup set header found (0x40f0f923 at 78,622,644). Bad backup set header found (0xf2a07047 at 78,622,663). Bad backup set header found (0x2bf2e3d2 at 78,622,686). Additional error information for device "Ecrix VXA DC" [2:3], Sense > f0 00 03 00 00 00 01 18 00 00 00 00 11 00 00 00 00 00 33 00 00 08 08 00 89 91 (ECRIX |VXA-1 |2B7B) But I don't know if this is related to issues I mentioned earlier. The server is a Beige G3 266mhz running 9.2.2. The VXA drive is terminated and connected by itself to an Adaptec 2930 SCSI card. Retrospect is ver 5.0.203. Any ideas on what caused this and what can I do to prevent it in the future? TIA, Shawn Punga shawn@studio405.com ;doh
×