Re: G4s and error 519 - AN UPDATE
Here's an oddity. I used to get a lot of 519 errors when I had DAT tape changers, but since switching to DLT I hardly have any problems and the problems I do have are directly related to the end users machine. I ran DLT on a mixed 10BaseT with Hubs and switches for about 6 months before I moved to a new building and have 10/100 switched (Cisco 5500's) network. All of the machines I back up now are 100BaseT full Duplex. The Mac I was doing the backups on is a 9600/G4-450. The machine I am currently doing the backups on is a 7600/G3-250. I built a cable to connect the external DLT drive to the internal SCSI bus. because the internal bus is SCSI-2 Fast (10MB/sec) while the external connector is only SCSI-2 (5MB/Sec). The speed difference between the two machines only dropped 2-3MB/min on average (averaging about 100MB/min). The 7600 is a good combination. Low volume Filemaker Server during the day, Retrospect backups at night. One of the previous messages indicated the problem occuring on a 10T network, otherwise I'd suspect the (presumably OT) problem might be getting exposed by the higher throughput now that the G3 backup machine is on 100T, as the G4 has always been. Can anyone else confirm seeing the problem on a 10T only network? Absolutley - we see it on a 10T unswitched network that can be as slow as...insert your favourite cliche here... that said it does seem to fail more often when there is less overall network traffic (ie the middle of the night) and the throughput is higher. No 519s using AppleTalk (and I have checked and all the G4s have different node numbers so that is not the problem in our case) Our backup machine is 7300/180 with an AdvanSys UltraWide SCSI card to a Sony DDS-4 drive. Adrian Smith -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ Search: http://www.mail-archive.com/retro-talk%40latchkey.com/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519 - AN UPDATE
We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart (sleep and waking seems to restore it as well). Back in November I started a thread on problems we were having getting G4s to backup over our 10Mb Ethernet network... Just to update everyone, we have found that switching the clients to AppleTalk rather than TCP/IP has eliminated all the errors we were experiencing (As suggested by Brooks Peters in the thread "G4 Client's OT Wiped Out by Backup via TCP/IP"). The backup is not as quite as fast (say 40 MB/min vs 50) but it does work. A timely thread! I just today moved our DAT drive (HP SureStore DDS-3 external) from one machine to another, and copied all the Retrospect stuff to make it the new machine. I've immediately got this 519 error backing up my own G4. The old Retro backup machine was a beige G3-266 desktop, motherboard 10T Ethernet, running 9.0.4. The new machine is a beige G3-300 desktop, Asante 10/100 card, 9.0.4, and using a Miles Bluenote SCSI card instead of the motherboard SCSI port. My G4 machine is a 400Mhz "Yosemite" (AGP graphics) version. I haven't been having problems with it until the move. One of the previous messages indicated the problem occuring on a 10T network, otherwise I'd suspect the (presumably OT) problem might be getting exposed by the higher throughput now that the G3 backup machine is on 100T, as the G4 has always been. Can anyone else confirm seeing the problem on a 10T only network? Our other two G4 machines are the older 400Mhz "Yikes" motherboards (PCI Graphics) from the original introduction, and so far I haven't seen 519 errors from them. We just got two new 533Mhz G4s, with 9.1, and I'll see if they have a problem, or if 9.1 makes the problem go away on the AGP G4, and post the results here. -- David Oberst/NWT Bureau of Statistics/Yellowknife, NWT, Canada [EMAIL PROTECTED][Explore Canada's Arctic] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ Search: http://www.mail-archive.com/retro-talk%40latchkey.com/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519 - update of the update
Just to update everyone, we have found that switching the clients to AppleTalk rather than TCP/IP has eliminated all the errors we were experiencing (As suggested by Brooks Peters in the thread "G4 Client's OT Wiped Out by Backup via TCP/IP"). The backup is not as quite as fast (say 40 MB/min vs 50) but it does work. A timely thread! I just today moved our DAT drive (HP SureStore DDS-3 external) from one machine to another, and copied all the Retrospect stuff to make it the new machine. I've immediately got this 519 error backing up my own G4. We have 519's like a rash when backing up over a mixed 10/100 network using 3Com SuperStack 10/100 autoswitching hubs. Backup server is a beige G3 266 tower with a DDS-2 DAT drive. 519's are the order of the day with the one G4 machione. It has work files on an external 12 Gb FireWire drive and I think we've only once had an error-free backup. Changing to AppleTalk did not help in any way. Some days most machines (20+) give a 519 which makes me think network or backup server. I am going to test a Cisco Catalyst Switch (with Spanning Tree turned off) and see what happens. Regards -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ Search: http://www.mail-archive.com/retro-talk%40latchkey.com/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519 - update of the update
On 2/20/2001 6:45 AM, "Nicholas Froome" wrote: We have 519's like a rash when backing up over a mixed 10/100 network using 3Com SuperStack 10/100 autoswitching hubs. Backup server is a beige G3 266 tower with a DDS-2 DAT drive. Take a look at the autosensing on the Macs. There is an update on the Apple site that forces either 10 or 100 and doesn't allow the autosensing to happen. This has cleared up many network issues. Pam -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ Search: http://www.mail-archive.com/retro-talk%40latchkey.com/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519 - AN UPDATE
Back in November I started a thread on problems we were having getting G4s to backup over our 10Mb Ethernet network... Just to update everyone, we have found that switching the clients to AppleTalk rather than TCP/IP has eliminated all the errors we were experiencing (As suggested by Brooks Peters in the thread "G4 Client's OT Wiped Out by Backup via TCP/IP"). The backup is not as quite as fast (say 40 MB/min vs 50) but it does work. Now if we could just nail the problem we are still having with the tape drive and 102 errors we would be all set... Adrian PS We have not tried any of the G4s with TCP/IP and OS9.1 yet. I would be interesting to know if 9.1 fixed the problems but as it ain't broke... At 4:19 PM +1100 22/11/00, Adrian Smith wrote: Hi all, We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart (sleep and waking seems to restore it as well). This seems to be the problem that was addressed by the "Ethernet Update 1.0" and our network does seem to come close to the type of network described in the Apple TIL on the subject. HOWEVER, installing the Ethernet Update doesn't fix the problem, although it may have made it a little better (the backup SEEMS to get a bit further). So, does anyone know how complete a fix the Ethernet Update was? Are there reports of G4s still having network problems? Does anyone have any suggestions for a workaround? Any other suggestions as to the cause? We have had zero problems backing up an iMac, a beigeG3 and an LCIII but the three G4s (and my Powerbook (firewire) which we just tested) seem to fail almost every time... Thanks Adrian -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ Search: http://www.mail-archive.com/retro-talk%40latchkey.com/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
On Tue, 28 Nov 2000, David Ross wrote: If you look at how ethernet works, most of time anything you do will mask errors. EtherNet has error recovery built in. So an undemanding transfer, such as a Finder copy, will tend to get through, errors or not. It's those programs that really hammer the network, like a backup program trying to keep a tape at speed, that tend to fail. Here's something to consider as a *possible* cause for 519 (and other Ethernet) errors: We have several new G3 and G4 servers that connect directly to high-end switches via six-foot certified Cat 5e patch cables. When these computers boot, and the switch ports are set to auto-negotiate, both ends *always* come up full duplex. However, if a patch cable is briefly disconnected (or power is removed from the switch), the switch port comes back up at *half* duplex. A duplex mismatch can be invisible at low to moderate traffic loads on a given connection, but at high loads the connection breaks down with massive numbers of errors. Accordingly, on switch ports connected to servers we force the duplex setting to full (which probably has little or no throughput improvement over half duplex, because of limitations in the Mac OS). YMMV, Mark E. Ingram [EMAIL PROTECTED] (also [EMAIL PROTECTED]) -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? Yet. I copy large files from one machine to another, but that never fails Yet. That's taking a rather simplistic approach that my experience so far does not support. I've had no known network failures of any kind - except Retrospect. To simply say that I will have one day is dodging the issue. If you look at how ethernet works, most of time anything you do will mask errors. EtherNet has error recovery built in. So an undemanding transfer, such as a Finder copy, will tend to get through, errors or not. It's those programs that really hammer the network, like a backup program trying to keep a tape at speed, that tend to fail. I've seen what you describe multiple times and it's always turned out to be a system or network problem, not a Retrospect problem. Not that that made it any less frustrating. But I have learned that a repeating problem being reported by Retrospect means I have a problem somewhere that I'll have to solve at some point. While not an expert, I have been using retrospect since about 90, starting with those "incredibly" reliable TEAC 60MB tapes. 30 sites later, I've still not found anything better. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 6:53 AM -0600 24/11/00, Don Foy wrote: I want everything perfect for a backup, since a less than perfect backup is absolutely useless. That one byte it missed and didn't tell me about may have been in the middle of a file that could cost me several thousands dollars. I agree, but in that case I'd expect file transfers around my network to be producing useless files since 1 byte lost will affect those just as much as in a backup. My point is that this is simply not happening. If I can throw a 600+ Mb file from one machine to another, then IMO Retrospect ought to be able to back it up without falling over. That's not a fault of Retrospect, but a feature, the way I see it. Hmmm. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 12:52 PM -0600 24/11/00, Pam Lefkowitz wrote: So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? Yet. I copy large files from one machine to another, but that never fails Yet. That's taking a rather simplistic approach that my experience so far does not support. I've had no known network failures of any kind - except Retrospect. To simply say that I will have one day is dodging the issue. If it is a SCSI problem, then shouldn't Retrospect report it as such? I've not found 519's to be SCSI issues. They are network issues. And almost always hardware. If you're experiencing 519's on multiple servers then I'd take a hard look at the infrastructure in place. Somewhere there is a "frayed" cable or a port/switch/router/hub that's either failing or getting ready to fail. Well here's another take on the 519 errors. Can SCSI errors generate a 519 or not? Anyone know for sure? Backup software should the most reliable software in use on the network, yet Retrospect is the only software that consistently fails to do what it is supposed to. This *is* the most reliable software in use on your network. And, in addition, it is probably the most useful network assessment tool you have as well. If Retrospect is telling you that you have a network problem...you do (or will) indeed have a network problem. Consider looking at it as more than just backup software...consider looking at it as a diagnostic tool. Better than any other tool out there for finding hardware problems. No, sorry but that's nonsense. Everything else runs 100% reliably - except Retrospect. Maybe it is finding little network niggles that exist, but all the other network software manages to work despite this. If Retrospect could report the problem, but continue to get the backup done then that would be OK. Retrospect is NOT a network diagnostic tool. If it was then it should at least tell me where the fault lies, not just report some nebulous 'network communication error'. It does run correctly and it does run reliably. How can you say that when I am reporting that it is the ONLY network product that fails to complete the task for which it is expressly designed to do? Maybe you have a different understanding of the word "reliable". Look, I don't want to bash Dantz here, but these responses show that some users just blindly follow the dogma that Retrospect is perfect and the fault lies elsewhere. Well I'm sorry, but if I bought a car and the wheels kept falling off and the manufacturer insisted it was not their fault, it was the road surface, yet although the road was a bit rough, no other cars were losing their wheels, I'd say that the fault lies with the manufacturer who should to look at how they could stop the wheels falling off their car even on bumpy roads. It would also appear that I'm not the only one whose wheels keep falling off... -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Hi Ken, The members of this list who are suggesting that your 519 errors are due to something other than a problem with Retrospect are not doing so because they "blindly follow the dogma that Retrospect is perfect," it's because they have found it themselves to be true...for some of them, even after being *certain* that there was a problem with Retrospect. One particular user that comes to mind, Travis Morgan, had complained of 519 errors for months. Because nothing else was giving him problems, he was fairly certain that the problem was a bug in Retrospect. Well, here's what he finally discovered (quoted from his Nov 5, 1999 post): Turns out that Virex 5.9.1 (and Virex 6.0) tries to scan the MRJ 2.x (Macintosh Runtime for Java) files when the backups are occurring so the Retrospect backup has to wait while the machine is done scanning those files. The reason for the long delay is because the MRJ files are compressed and I have Virex to scan compressed files. After turning off "Scan Compressed files" on my problematic machines, I haven't seen a 519 error ever since. WAH! Reliable means one thing, Ken--you can restore with confidence. Network communication errors limit Retrospect's reliability (that's why it reports the error and moves on to the next task). Sure, Retrospect isn't a diagnostic tool, but it is a canary in a coal mine; it will find problems that don't show up otherwise. Nevertheless, those problems are every bit real, and you will need to track them down and eliminate them to guarantee the reliability of your backups. Please read and follow our Tech Note on troubleshooting 519 errors. http://www.dantz.com/index.php3?SCREEN=tn415 If you need help with any of the procedures, please contact our tech support department. (925.253.3050) I know these errors can be difficult to track down--I've done it myself. So hang in there, call us if you need to, and have a little faith in what we're telling you. Best regards, Eric Ullman Dantz Development Ken Gillett [EMAIL PROTECTED] wrote: Retrospect is NOT a network diagnostic tool. If it was then it should at least tell me where the fault lies, not just report some nebulous 'network communication error'. How can you say that when I am reporting that it is the ONLY network product that fails to complete the task for which it is expressly designed to do? Maybe you have a different understanding of the word "reliable". Look, I don't want to bash Dantz here, but these responses show that some users just blindly follow the dogma that Retrospect is perfect and the fault lies elsewhere. Well I'm sorry, but if I bought a car and the wheels kept falling off and the manufacturer insisted it was not their fault, it was the road surface, yet although the road was a bit rough, no other cars were losing their wheels, I'd say that the fault lies with the manufacturer who should to look at how they could stop the wheels falling off their car even on bumpy roads. It would also appear that I'm not the only one whose wheels keep falling off... -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
I'm having the same type of problem with a lone G4 on a small network. The other systems there, a blue G3, a beige tower G3 plus a clone and a 6100, all seem to get backed up without fail. I tried replacing the 10Bt hub with a Linksys 10/100 hub thinking that would do the trick. It seemed to let the backups go a little longer, but supposedly the G4 is failing again to get backed up. Has anyone tried putting a new NIC into a G4 instead of using the on board ethernet as a way to resolve this problem? Todd Reed On 11/24/00, Glenn L. Austin emailed about "Re: G4s and error 519": So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? I'm sure that it does hit the network hard, but IMO it should be written to cope with that. It should not the task of the customer to swap NICs or hubs or whatever until one is found that works. If a NIC will connect with the network then Retrospect should be able to use it. I can understand your frustration, having been on the "other side" with some products that I've worked on. In my case, in *every* case, the software that I wrote uncovered hardware and system problems that, when corrected, solved other "nagging" stability problems that the users had just accepted. In my opinion, I doubt that the problems don't affect anything else -- more likely is that the problems that are occurring are minor enough that nobody has reported them. That being said, there apparently are some G4 machines that have some problems with their ethernet interfaces. -- Glenn L. Austin Computer Wizard and Race Car Driver [EMAIL PROTECTED] http://www.austin-home.com/glenn/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 9:02 AM -0800 26/11/00, Eric Ullman wrote: he was fairly certain that the problem was a bug in Retrospect. I hope you understand that is NOT what I have been suggesting. I need to finish rebuilding my network then I can give it a good testing with a variety of backup servers, MacOS9 (X when available), Windows NT and 2000 and similar clients. We'll see what happens then. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
I'm having the same type of problem with a lone G4 on a small network. The other systems there, a blue G3, a beige tower G3 plus a clone and a 6100, all seem to get backed up without fail. [snip] Just another data point: We have 7 G4's here (early PCI to newest AGP) on our network here on along with 35 or so other Macs and PCs (all 100BT, almost all of them switched with HP switches) and the only time we get 519 errors with any of the machines is when they are shut down or have crashed (backing up to a WinNT/DDS4 box and a MacOS 9 DDS2 box). There was on user who was running some kind of "Reminder" program that would put up modal dialogs and give us a 519, but otherwise no problems here. Good Luck! -- -Steve --- Steve Axthelm Mudpuppy Studios [EMAIL PROTECTED] 503.227.1775 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Adrian. The termination problem was on the client, which is an ASIP server. It just took out that particular client. However, if there is a termination problem on the Retrospect 'server' then I guess you could see 519 errors. It sounds like you need to talk with the folks at Retrospect in person. Their tech support is second to none and they can help better when you call. Don on 11/23/00 10:55 PM, Adrian Smith at [EMAIL PROTECTED] wrote: If you are having 519 errors, there is a problem in your setup, either hardware, software or network. You most likely either have a SCSI problem (which was the case the last time I had a 519, termination problems), Don, what were the other symptoms when you had the termination problem? Did it take out the whole backup or just specific clients? Unlike Ken, we have no problem with server Mac and in our case it is only the G4s that have the problem and only the CLIENT drops the network connection. The backup Mac is fine and can go on to back up the other clients. The client will regain the network after a restart or sleep. It sounds just like the symptoms of the problem that was supposed to fixed with the Ethernet update, expect that the Ethernet update doesn't fix it and when I went and checked the details (TIL 25147) it doesn't actually seem to be the same problem. Adrian Don Foy [EMAIL PROTECTED] Webmaster and Network Manager Herald-Citizen Cookeville, Tenn. http://www.herald-citizen.com Personal email: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
on 11/23/00 2:09 PM, Ken Gillett at [EMAIL PROTECTED] wrote: So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? I'm sure that it does hit the network hard, but IMO it should be written to cope with that. It should not the task of the customer to swap NICs or hubs or whatever until one is found that works. If a NIC will connect with the network then Retrospect should be able to use it. I'll let the Dantz folks respond to this charge, since they have heard it before, but when I did my job and got the network and clients working right, Retrospect worked right. It is the best trouble-finding tool out there. I know that if Retrospect works, everything else will. That's not a fault of Retrospect, but a feature, the way I see it. I want everything perfect for a backup, since a less than perfect backup is absolutely useless. That one byte it missed and didn't tell me about may have been in the middle of a file that could cost me several thousands dollars. Don Don Foy [EMAIL PROTECTED] Webmaster and Network Manager Herald-Citizen Cookeville, Tenn. http://www.herald-citizen.com Personal email: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? I'm sure that it does hit the network hard, but IMO it should be written to cope with that. It should not the task of the customer to swap NICs or hubs or whatever until one is found that works. If a NIC will connect with the network then Retrospect should be able to use it. I can understand your frustration, having been on the "other side" with some products that I've worked on. In my case, in *every* case, the software that I wrote uncovered hardware and system problems that, when corrected, solved other "nagging" stability problems that the users had just accepted. In my opinion, I doubt that the problems don't affect anything else -- more likely is that the problems that are occurring are minor enough that nobody has reported them. That being said, there apparently are some G4 machines that have some problems with their ethernet interfaces. -- Glenn L. Austin Computer Wizard and Race Car Driver [EMAIL PROTECTED] http://www.austin-home.com/glenn/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? Yet. I copy large files from one machine to another, but that never fails Yet. If it is a SCSI problem, then shouldn't Retrospect report it as such? I've not found 519's to be SCSI issues. They are network issues. And almost always hardware. If you're experiencing 519's on multiple servers then I'd take a hard look at the infrastructure in place. Somewhere there is a "frayed" cable or a port/switch/router/hub that's either failing or getting ready to fail. Backup software should the most reliable software in use on the network, yet Retrospect is the only software that consistently fails to do what it is supposed to. This *is* the most reliable software in use on your network. And, in addition, it is probably the most useful network assessment tool you have as well. If Retrospect is telling you that you have a network problem...you do (or will) indeed have a network problem. Consider looking at it as more than just backup software...consider looking at it as a diagnostic tool. Better than any other tool out there for finding hardware problems. I like Retrospect and simply want it to run correctly and of course reliably. It does run correctly and it does run reliably. Dantz just doesn't market all its features apparently. Wouldn't it be odd for them to put this out as a networking tool that does backup too? Better that it does the backups right and gives you the value add of being a kickin' proactive diagnostic as well. It's all in how you view it. :-) Besides, if you use this added value to your advantage and find the failing segment before it fails you will be a hero, get a raise, get a promotion, a nice Christmas bonus, maybe conquer the world. OK, I got a little carried away...maybe you won't get a promotion. Pam -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 8:00 PM -0800 11/22/00, retro-talk wrote: We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart (sleep and waking seems to restore it as well). This seems to be the problem that was addressed by the "Ethernet Update 1.0" and our network does seem to come close to the type of network described in the Apple TIL on the subject. HOWEVER, installing the Ethernet Update doesn't fix the problem, although it may have made it a little better (the backup SEEMS to get a bit further). I have the same problem with a G4/500 (single processor). Dantz tech support suggested I turn on link encryption (to slow down the backup). That didn't help. They then suggested it was the fault of a router. I moved the G4 to various ports on my Asante FriendlyNet 8+2 to no effect. I tried both 10Mbps ports and 100 Mbps ports, both half and full duplex. No effect. Tried a 10Mbps hub instead of the Asante switch. No effect. I switched Retrospect host machines. No effect. I've tried various backup devices (VXA, DDS, CD-RW), no effect. Software is Mac OS 9.0.4, everything up-to-date, and Retrospect 4.3. I don't have this problem with any of the other 9 machines I back up, and this machine is the only G4. I'm backing up a 27MB internal hard drive on this machine, divided into 4 partitions, roughly sized at (usable space) 2MB, 8MB, 13.5MB, and 2MB. When doing a full backup, the failure usually occurs on the 3rd partition. By running 3 or 4 incrementals after a full backup, I can usually get through the entire drive. Most incremental backups after that are usually small enough to success, but not always. -- Bob Boonstra mailto:[EMAIL PROTECTED] http://www.windmillsw.com -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 4:02 PM + 22/11/00, Nicholas Froome wrote: We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart I have continually experienced this with both Mac and NT clients ever since I started trying to backup over the network. The only way I can get a backup to complete is to turn verification off, then it seems to be ok. But with it on, it loses the connection at some time and the server Mac must be restarted to get any sense out of its network connection. I am trying to run QuickDNS and IPNetRouter on this 8100 and I do not consider this should be impossible, but even if Retrospect does complete I invariably suffer network troubles afterwards until it is restarted, e.g. I cannot access the DNS, or the machine simply doesn't route any more. I have always believed in Retrospect, but I must say that I am sorely disappointed by this. It seems as if its use of TCP/IP on the Mac is really flaky, nothing should be able to pull down the OT stack like that. I intend to try this with Retrospect on an NT (well 2000) server and see if that can work reliably, but IMO it should work on the Mac and I don't see why I should have to dedicate a machine to this task. Actually, I've no idea if that would be any better anyway. Just what is the 519 error, what actually occurs that causes Retrospect to report it and how come it requires a restart of the Mac in order to get its network running again? At 5:27 PM + 22/11/00, Nicholas Froome wrote: How much data are you backing up? Is the problem intermittent? Does it happen on any other machines? As a percentage, what proportion of the backups (of the G4s) fail? 100% with verification on. In a client's setup we found the problem (error 519) to be apparently unrelated to anything. It would occur on almost every machine at some point, after a few Mb had been copied or after copying 5 Gb out of 5.2 Gb, independent of machine OS, independent of date or time, and all the backups were being done overnight when there was no other network traffic. This is very much my experience. I just cannot understand why NOTHING else has ever given any network error here, yet Retrospect has so much trouble. I'm sure the data that Retrospect writes to tape is good and it's never failed to restore anything I've asked, but that was before I tried network backups. It does seem to be a recurring problem as it regularly crops up on this list. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
on 11/23/00 6:50 AM, Ken Gillett at [EMAIL PROTECTED] wrote: Just what is the 519 error, what actually occurs that causes Retrospect to report it and how come it requires a restart of the Mac in order to get its network running again? Before the guys at Dantz get back from the holiday, I'll let you in on a little secret 519 errors are some of the most common. They are not caused by Retrospect, just found by it. Retrospect is very demanding. It requires that everything be right in your machine and network setup (Imagine that). If you are having 519 errors, there is a problem in your setup, either hardware, software or network. You most likely either have a SCSI problem (which was the case the last time I had a 519, termination problems), a system incompatibility (sometimes a corrupt system or mismatched components (like OS 8.5 with ASIP 5 (that was pretty stupid)) or a network problem (replace those old hubs with switches, which creates more potential problems). Dantz has an in depth technical not on 519 errors at: http://www.dantz.com/index.php3?SCREEN=tn415 Good hunting. BTW, why are we all at our computers this morning? Isn't this supposed to be a holiday? Don Don Foy [EMAIL PROTECTED] Webmaster and Network Manager Herald-Citizen Cookeville, Tenn. http://www.herald-citizen.com Personal email: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Before the guys at Dantz get back from the holiday, I'll let you in on a little secret - 519 errors are some of the most common. They are not caused by Retrospect, just found by it. Retrospect is very demanding. It requires that everything be right in your machine and network setup (Imagine that). If you are having 519 errors, there is a problem in your setup, either hardware, software or network. You most likely either have a SCSI problem (which was the case the last time I had a 519, termination problems), a system incompatibility (sometimes a corrupt system or mismatched components (like OS 8.5 with ASIP 5 (that was pretty stupid)) or a network problem (replace those old hubs with switches, which creates more potential problems). I've always said that if you tried to design a network stress-testing tool you'd end up with Retrospect... It is obviously trying to max out everything, all the time, and will find problems wherever they lie. If 519 is, at it seems to be, a generic error, then how do we find the cause(s)? It seems to me that they present a problem only if their frequency undermines the successful completion of a backup. On a setup (as I described) that can't complete a Recycle or Incremental backup on one day, a 519, leading to one machine not being backed up, can't be considered a problem - unless it fails again the next day. Yes I'd like to fix every problem on the client's network, but it isn't financially viable to do so. So what is the best methodolgy for finding the problem? The Dantz TIL is useful but does not address this. One thing that is always common is the backup machine, backup device and the network. If a 519 can be caused by local, backup server-related cause such as a termination problem, as well as client-related problems, then the error message is useless for fault-finding. So where to start? BTW, why are we all at our computers this morning? Isn't this supposed to be a holiday? Only for that small percentage of people in the world who live in the USA... -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
If you are having 519 errors, there is a problem in your setup, either hardware, software or network. You most likely either have a SCSI problem (which was the case the last time I had a 519, termination problems), Don, what were the other symptoms when you had the termination problem? Did it take out the whole backup or just specific clients? Unlike Ken, we have no problem with server Mac and in our case it is only the G4s that have the problem and only the CLIENT drops the network connection. The backup Mac is fine and can go on to back up the other clients. The client will regain the network after a restart or sleep. It sounds just like the symptoms of the problem that was supposed to fixed with the Ethernet update, expect that the Ethernet update doesn't fix it and when I went and checked the details (TIL 25147) it doesn't actually seem to be the same problem. Adrian -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
At 10:34 AM -0600 23/11/00, Don Foy wrote: Before the guys at Dantz get back from the holiday, I'll let you in on a little secret - 519 errors are some of the most common. They are not caused by Retrospect, just found by it. Retrospect is very demanding. It requires that everything be right in your machine and network setup (Imagine that). If you are having 519 errors, there is a problem in your setup, either hardware, software or network. You most likely either have a SCSI problem (which was the case the last time I had a 519, termination problems), a system incompatibility (sometimes a corrupt system or mismatched components (like OS 8.5 with ASIP 5 (that was pretty stupid)) or a network problem (replace those old hubs with switches, which creates more potential problems). Dantz has an in depth technical not on 519 errors at: http://www.dantz.com/index.php3?SCREEN=tn415 So Retrospect reports errors that it finds in the network setup that doesn't affect ANYTHING else? If these errors existed then why does nothing else complain? I'm sure that it does hit the network hard, but IMO it should be written to cope with that. It should not the task of the customer to swap NICs or hubs or whatever until one is found that works. If a NIC will connect with the network then Retrospect should be able to use it. I copy large files from one machine to another, but that never fails so how come Retrospect falls over - badly. You mention SCSI problems, but don't indicate if this was related to the server of client. In fact I don't know if the 519 error is client induced or resides solely in the server. Since this can occur with all the clients it points to the server, but this is the third Mac I've tried it on If it is a SCSI problem, then shouldn't Retrospect report it as such? Backup software should the most reliable software in use on the network, yet Retrospect is the only software that consistently fails to do what it is supposed to. I like Retrospect and simply want it to run correctly and of course reliably. -- Ken G i l l e t t _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart (sleep and waking seems to restore it as well). This seems to be the problem that was addressed by the "Ethernet Update 1.0" and our network does seem to come close to the type of network described in the Apple TIL on the subject. HOWEVER, installing the Ethernet Update doesn't fix the problem, although it may have made it a little better (the backup SEEMS to get a bit further). Disable the OT AutoPush extension and try again - worked for us! Have you got TCP/IP set as active and "Load only when needed" unchecked - I thought so.. Unfortunately, we don't have the OT AutoPush extension to disable. And yes, TCP/IP is active and "Load only when needed" is unchecked... Adrian -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Adrian We are having problems backing up G4s over the network. Basically, they ... Disable the OT AutoPush extension and try again - worked for us! Have you got TCP/IP set as active and "Load only when needed" unchecked - I thought so.. Unfortunately, we don't have the OT AutoPush extension to disable. And yes, TCP/IP is active and "Load only when needed" is unchecked... Mmmm. OK, check the connection speed and duplex setting to the hub/switch in Apple System Profiler. If it's 100Base-T try setting it down to 10Base-T for the backup and see what happens then. There's an unsupported tool to do this - check the Apple site. How much data are you backing up? Is the problem intermittent? Does it happen on any other machines? As a percentage, what proportion of the backups (of the G4s) fail? In a client's setup we found the problem (error 519) to be apparently unrelated to anything. It would occur on almost every machine at some point, after a few Mb had been copied or after copying 5 Gb out of 5.2 Gb, independent of machine OS, independent of date or time, and all the backups were being done overnight when there was no other network traffic. The only thing I concluded was common to the each failure was the backup server Mac and the network. I disabled OT Autopush one one machine - the worst affected - and the occurrence of 519s dropped to be average. The client has so much data to backup that an ovenight backup won't get all the data on the network, so I rationalised that one error 519 per night was acceptable. Backup Server would then prioritise that machine the next night - and we haven't seen any cases of the same machine erroring out on successive nights. Not exactly problem solved, but problem minimised. Regards -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Mmmm. OK, check the connection speed and duplex setting to the hub/switch in Apple System Profiler. Hmm, You know, this one got me. I was not aware of any program that would get speed and duplex on a Mac. I just checked Apple System Profiler (version 2.4.4) and it don't show me. Maybe this works only on Apple cards? I have an Asante 10/100 NIC. Thanks, Matt -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
Mmmm. OK, check the connection speed and duplex setting to the hub/switch in Apple System Profiler. Hmm, You know, this one got me. I was not aware of any program that would get speed and duplex on a Mac. I just checked Apple System Profiler (version 2.4.4) and it don't show me. Maybe this works only on Apple cards? I have an Asante 10/100 NIC. ASP only works on Apple Cards. It's under System Profile:Network Overview Try switching to the Apple NIC - why would you want to use an Asante one? The built-in NIC is 10/100.. See if the Apple NIC reduces 519s. Regards -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
I'm a different person than who brought up the initial issue. I was asking this for my information. Thanks! The Macs I have are older and they do not have the 10/100 built in. Beige G3/300 and a 9600/G4-450. Mmmm. OK, check the connection speed and duplex setting to the hub/switch in Apple System Profiler. Hmm, You know, this one got me. I was not aware of any program that would get speed and duplex on a Mac. I just checked Apple System Profiler (version 2.4.4) and it don't show me. Maybe this works only on Apple cards? I have an Asante 10/100 NIC. ASP only works on Apple Cards. It's under System Profile:Network Overview Try switching to the Apple NIC - why would you want to use an Asante one? The built-in NIC is 10/100.. See if the Apple NIC reduces 519s. Regards -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
Re: G4s and error 519
matt barkdull wrote: Mmmm. OK, check the connection speed and duplex setting to the hub/switch in Apple System Profiler. Hmm, You know, this one got me. I was not aware of any program that would get speed and duplex on a Mac. I just checked Apple System Profiler (version 2.4.4) and it don't show me. Maybe this works only on Apple cards? I have an Asante 10/100 NIC. The Asante software has that capability. -- Best Regards, Chuck Hornish, KF6YBC Narnia Information Systems, Inc. Fountain Valley, California 92708 USA Voice: 714-963-7742 FAX: 714-593-5808 mailto:[EMAIL PROTECTED] Delivering precisely defined database solutions since 1992. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
G4s and error 519
Hi all, We are having problems backing up G4s over the network. Basically, they get part way through the backup and then Retrospect looses the connection. The problem seems to be at the G4 end as once this has happened they have lost network connectivity until the next restart (sleep and waking seems to restore it as well). This seems to be the problem that was addressed by the "Ethernet Update 1.0" and our network does seem to come close to the type of network described in the Apple TIL on the subject. HOWEVER, installing the Ethernet Update doesn't fix the problem, although it may have made it a little better (the backup SEEMS to get a bit further). So, does anyone know how complete a fix the Ethernet Update was? Are there reports of G4s still having network problems? Does anyone have any suggestions for a workaround? Any other suggestions as to the cause? We have had zero problems backing up an iMac, a beigeG3 and an LCIII but the three G4s (and my Powerbook (firewire) which we just tested) seem to fail almost every time... Thanks Adrian -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives:http://list.working-dogs.com/lists/retro-talk/ For urgent issues, please contact Dantz technical support directly at [EMAIL PROTECTED] or 925.253.3050.
