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.
turning windows client on/off via script
Background: A lot of our backup clients are computers that get used for data acquisition. Data acquisition can be adversely affected when Retrospect starts reading a lot of data off the hard drive ;-) The users generally know when the backups are coming, but they don't always remember. I'd like to give them a way to automatically script turning the Retrospect client off at the beginning of an experiment, and to turn it back on at the end (or, more likely, at the next reboot). It's pretty obvious how to do this with the Mac clients via Applescript. It's not obvious to me how to do this with the Windows client. All the scripting discussion I can find seems to have more to do with launching scripts from Retrospect. It doesn't really matter what form these take, as long as it could be called from perl or a .bat file I'd be happy. steven -- Steven Karel, Ph.D. Biology Department, Brandeis Univ, MS 008 415 South St Waltham MA 02454-9110 TEL 781 736 3104 FAX 781 736 3107 -- -- 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: turning windows client on/off via script
The users generally know when the backups are coming, but they don't always remember. I'd like to give them a way to automatically script turning the Retrospect client off at the beginning of an experiment, and to turn it back on at the end (or, more likely, at the next reboot). It is possible to go to the Win clientAccess and name these files as private. That way they won't get accessed. hth, 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: turning windows client on/off via script
The users generally know when the backups are coming, but they don't always remember. I'd like to give them a way to automatically script turning the Retrospect client off at the beginning of an experiment, and to turn it back on at the end (or, more likely, at the next reboot). It is possible to go to the Win clientAccess and name these files as private. That way they won't get accessed. The issue is probably the performance hit when the backup is running, rather than simultaneous access to the files. -- John Gee[EMAIL PROTECTED] Dunedin, New ZealandProgrammers live in interesting times... -- -- 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: turning windows client on/off via script
I'd like to give them a way to automatically script turning the Retrospect client off at the beginning of an experiment, and to turn it back on at the end (or, more likely, at the next reboot). The issue is probably the performance hit when the backup is running, rather than simultaneous access to the files. Ah, then I have two ideas if this is the case. 1) Give the user priority in the client. This may give enough bandwidth to the client while still getting backed up. Or maybe... 2) Make a separate backup server script for those data gathering machines. This way, they'll get a warning that the backup is about to start. The user can answer with "ok" or they can answer with a delay till x time (or for x minutes...I can't recall which it says). This way they'll have the option of delaying the backup till their machine is free. Would that work better for you? 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: Force use of tape (was Re: SCSI Voodoo strikes...(continued))
Hi again, I only received one response to the email below about 102 errors disappearing after restarts...so if anyone else has any light to shed it would be appreciated. Since I posted we have found that if IE crashes (which it does extremely frequently on the backup) machine then we will always get the 102 error unless we restart first. However, this is not the only cause of the problem... How do you know? Have you tried never running IE on the computer? If the problem goes away after a restart, there's definitely something corrupting your system over time. If the computer is a dedicated backup system, disable all unnecessary extensions and control panels and don't run IE to see if it happens again. ... when Retrospect gives us the 102 error it assumes that the current tape cannot be used and asks for a new one next time the backup runs, even if the tape appears to be less than half full... So, is there any to force Retrospect to keep using that tape? I don't know of a way to get Retrospect to append to that tape, but you can certainly get Retrospect to use the tape by either setting the tape as missing or erasing the tape. In either case, Retrospect will recopy the files already on the media and continue to fill the tape. HTH, Craig -- -- 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: Force use of tape (was Re: SCSI Voodoo strikes...(continued))
At 9:00 PM -0800 26/11/00, Craig Isaacs wrote: Hi again, I only received one response to the email below about 102 errors disappearing after restarts...so if anyone else has any light to shed it would be appreciated. Since I posted we have found that if IE crashes (which it does extremely frequently on the backup) machine then we will always get the 102 error unless we restart first. However, this is not the only cause of the problem... How do you know? Have you tried never running IE on the computer? If the problem goes away after a restart, there's definitely something corrupting your system over time. If the computer is a dedicated backup system, disable all unnecessary extensions and control panels and don't run IE to see if it happens again. It will always fail if IE has crashed (any maybe even if it has run) but sometimes it will fail if IE has not been run (eg over the weekend). Unfortunately the backup machine is used as a workstation during the day so we can't strip it down (at least not completely - we are in the process of trying to get rid of much as possible). ... when Retrospect gives us the 102 error it assumes that the current tape cannot be used and asks for a new one next time the backup runs, even if the tape appears to be less than half full... So, is there any to force Retrospect to keep using that tape? I don't know of a way to get Retrospect to append to that tape, but you can certainly get Retrospect to use the tape by either setting the tape as missing or erasing the tape. In either case, Retrospect will recopy the files already on the media and continue to fill the tape. HTH, Craig So far we have only got to the stage where we are using 1 tape per set (we haven't brought all the clients online yet because of the problems we are having). In that case I assume reseting the catalog is equivalent to your suggestions. We were hoping to avoid having to re-copy all the data already on the tape because of the difficulties getting our G4s backed up (519 errors, see separate thread). 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.
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.
