Mayoff Posted January 25, 2008 Report Share Posted January 25, 2008 Thanks for the info Camps13 Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted January 25, 2008 Report Share Posted January 25, 2008 Quote: Using the terminal, I compared the / with with a new, fresh and working 10.5.1. Then I removed all files, on the bugus MacBook Pro, that where not on the working machine. Well, that's a tantalizing bit of information! Sure wish you kept a list of what you removed; any chance of that? Looking at the list of files on the root of an affected client (although not one that I have access to in order to test) I see our old friend <.hotfiles.btree>, which has been implicated in backup problems in some other software programs around The Google. If I had a machine that was exhibiting this problem (and that I was free to test with, even if it meant mucking it up) I'd try deleting this file (perhaps while the machine was running, or perhaps while booted from some other volume) and trying to scan with Retrospect again. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted January 28, 2008 Report Share Posted January 28, 2008 Quote: Looking at the list of files on the root of an affected client (although not one that I have access to in order to test) I see our old friend <.hotfiles.btree> Never mind. My associate, who had a machine experiencing this error, just found success by uninstalling the client software, forgetting the client from Retrospect, then reinstalling and logging the newly installed client in. The .hotfiles.btree and timemachine.plist files are still on the root level of his drive, unchanged from last week when the machine was unscannable. As I write, he's up to 400 files without error. He made no other changes other then via the Retrospect OS X Client installer. Quote Link to comment Share on other sites More sharing options...
brendanu Posted January 31, 2008 Report Share Posted January 31, 2008 OK, time to wade into this discussion as I've been experiencing the 519 communication error as well. ----------- SETUP ----------- Retrospect Server Retrospect Backup v6.1.138 PowerMac Dual G4 1Ghz Mac OS X 10.3.9 (all patches made) 1.5GB RAM Adaptec 2930U SCSI Card Client Machine (only client being backed up) Retrospect Client v6.1.130 PowerMac Dual G5 2.0Ghz Mac OS X Server 10.5.1 (all patches made) Backup Drive Sony TSL-9000 Autoloader DDS3 Tapes SCSI ------- SITUATION ------- My backup regime hasn't been working for quite sometime (over Xmas break) as the hard drive on the Retro server machine was failing and causing lockups. I have just done a clean install of 10.3.9 onto a fresh disk now, and ran the previous version of Retrospect v6.1.126 (?). All was setup to run, the client connections and backup sets were confirmed, but when I tried to do the backup I was coming across the 519 Communication error in the logs. The worst part though was that the Mac OS X Server which it was backing up was dropping all of its filesharing clients, and automatically rebooting. Checking back through the logs, it seems that the error has been there for sometime and may coincide with when the Fileserver was upgraded to Mac OS X 10.5 or 10.5.1. Example log entry: Quote: ? Retrospect version 6.1.126 automatically launched at 27/11/2007 8:00 PM + Normal backup using Daily Backup at 27/11/2007 8:00 PM To backup set KTS Backup Set B… - 27/11/2007 8:00:19 PM: Copying projects on ETG-SERVER-2… 27/11/2007 8:00:19 PM: Connected to ETG-SERVER-2 Trouble reading files, error 519 (network communication failed). 27/11/2007 8:09:15 PM: Execution incomplete. Remaining: 235 files, 249.3 MB Completed: 62 files, 113.0 MB Performance: 27.4 MB/minute Duration: 00:08:56 (00:04:49 idle/loading/preparing) - 27/11/2007 8:09:20 PM: Copying rhino-backup on ETG-SERVER-2… 27/11/2007 8:09:20 PM: No files need to be copied. 27/11/2007 8:09:31 PM: Execution completed successfully. Duration: 00:00:11 (00:00:11 idle/loading/preparing) - 27/11/2007 8:09:32 PM: Copying rhino-home-zope on ETG-SERVER-2… 27/11/2007 8:09:32 PM: No files need to be copied. 27/11/2007 8:12:56 PM: Execution completed successfully. Duration: 00:03:24 (00:03:24 idle/loading/preparing) - 27/11/2007 8:12:58 PM: Copying svn on ETG-SERVER-2… 27/11/2007 8:12:58 PM: No files need to be copied. 27/11/2007 8:13:13 PM: Execution completed successfully. Duration: 00:00:15 (00:00:15 idle/loading/preparing) 27/11/2007 8:13:14 PM: Execution incomplete. Total performance: 26.5 MB/minute Total duration: 00:12:54 (00:08:39 idle/loading/preparing) Quit at 27/11/2007 8:14 PM At this point I checked that I had the latest version of the Retro software on both client and server, client was ok, but server had 6.1.138 available so I updated that. I then tried the backup again, but got the same problem...ie. 519 communication error, and the Mac OS X Server shutdown and rebooted. Quote: ? Retrospect version 6.1.138 launched at 30/1/2008 2:23 PM + Retrospect Driver Update, version 6.1.13.101 + Normal backup using Daily Backup at 30/1/2008 2:25 PM To backup set KTS Backup Set A… - 30/1/2008 2:25:58 PM: Copying projects on ETG-SERVER-2… 30/1/2008 2:25:58 PM: Connected to ETG-SERVER-2 Trouble reading files, error 519 (network communication failed). 30/1/2008 2:49:16 PM: Execution incomplete. Remaining: 38265 files, 38.9 GB Completed: 694 files, 910.5 MB Performance: 48.9 MB/minute Duration: 00:23:18 (00:04:43 idle/loading/preparing) - 30/1/2008 2:49:18 PM: Copying rhino-backup on ETG-SERVER-2… 30/1/2008 2:49:18 PM: No files need to be copied. 30/1/2008 2:49:32 PM: Execution completed successfully. Duration: 00:00:14 (00:00:14 idle/loading/preparing) - 30/1/2008 2:49:34 PM: Copying rhino-home-zope on ETG-SERVER-2… 30/1/2008 2:49:34 PM: No files need to be copied. 30/1/2008 2:53:04 PM: Execution completed successfully. Duration: 00:03:30 (00:03:30 idle/loading/preparing) - 30/1/2008 2:53:06 PM: Copying svn on ETG-SERVER-2… 30/1/2008 2:53:06 PM: No files need to be copied. 30/1/2008 2:53:27 PM: Execution completed successfully. Duration: 00:00:21 (00:00:21 idle/loading/preparing) 30/1/2008 2:53:28 PM: Execution incomplete. Total performance: 48.7 MB/minute Total duration: 00:27:29 (00:08:48 idle/loading/preparing) At this point I checked the forums, and after reading this thread, went with the suggested reinstall of the Retro client on the Mac OS X Server 10.5.1 machine. I did an uninstall, made sure there was no pref files etc hanging about. Installed the Retro Client 6.1.130 and then made sure the client was reconnected to the Retrospect Server and that the Volumes were reset. I tried another immediate backup with the exact same results as before...ie. 519 communication error in the retro logs, and the Mac OS X Server 10.5.1 shutdown and rebooted. Final log: Quote: + Recycle backup using Daily Backup at 30/1/2008 3:57 PM To backup set KTS Backup Set B… 30/1/2008 3:57:34 PM: Recycle backup: The backup set was reset - 30/1/2008 3:57:34 PM: Copying projects on ETG-SERVER-2… 30/1/2008 3:57:34 PM: Connected to ETG-SERVER-2 Trouble reading files, error 519 (network communication failed). 30/1/2008 4:15:36 PM: Execution incomplete. Remaining: 38373 files, 39.2 GB Completed: 1477 files, 846.2 MB Performance: 64.7 MB/minute Duration: 00:18:02 (00:04:58 idle/loading/preparing) - 30/1/2008 4:15:36 PM: Copying rhino-backup on ETG-SERVER-2… 30/1/2008 4:15:43 PM: Execution completed successfully. Completed: 138 files, 3771 KB Performance: 44.1 MB/minute Duration: 00:00:07 (00:00:02 idle/loading/preparing) - 30/1/2008 4:15:45 PM: Copying rhino-home-zope on ETG-SERVER-2… 30/1/2008 7:17:02 PM: Execution completed successfully. Completed: 261241 files, 10.1 GB Performance: 57.9 MB/minute Duration: 03:01:17 (00:03:14 idle/loading/preparing) - 30/1/2008 7:17:11 PM: Copying svn on ETG-SERVER-2… 30/1/2008 7:19:15 PM: Execution completed successfully. Completed: 4742 files, 84.9 MB Performance: 48.0 MB/minute Duration: 00:02:04 (00:00:18 idle/loading/preparing) 30/1/2008 7:19:19 PM: Execution incomplete. Total performance: 58.2 MB/minute Total duration: 03:21:41 (00:08:32 idle/loading/preparing) Sorry for the long winded reply, but I know you want as much detail as possible. It seems the common factor on this thread is Mac OS X 10.5.1 on the Retro client side. I just did a check for the retropds files and I have retropds.22 and retropds.24 inside the client package contents. Hope this helps. Cheers Brendan Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted January 31, 2008 Report Share Posted January 31, 2008 Quote: I've been experiencing the 519 communication error as well But it doesn't sound as if your experience is the same as what this thread has been tracking. What's different is that Retrospect appears to successfully scan the Source volume (projects on ETG-SERVER-2) before giving up 15 minutes or so later. I don't know what sort of speeds your DDS3 drive can sustain, but you're showing pretty dismal performance rates that might indicate some other network communication problems unrelated to the client scanning issue reported up-thread. I also don't see from your log entries where the server is rebooting; none of your log examples show an aborted execution. david Retrospect version 6.1.126 automatically launched at 27/11/2007 8:00 PM Normal backup using Daily Backup at 27/11/2007 8:00 PM To backup set KTS Backup Set B… 27/11/2007 8:00:19 PM: Copying projects on ETG-SERVER-2… 27/11/2007 8:00:19 PM: Connected to ETG-SERVER-2 Trouble reading files, error 519 (network communication failed). Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 31, 2008 Report Share Posted January 31, 2008 You never mention what RDU you are using, but some things can be inferred from your logs. There have been so many odd things with recent RDUs, and because your problems started around the time that later RDUs were released, could you install RDU 6.1.11.101 (one of the last-known problem-free RDUs) and give that a shot? Your Retrospect 6.1.138 seems to be running the problematic RDU 6.1.13.101; your Retrospect 6.1.126 doesn't seem to be running any RDU, but it may be because Retrospect 6.1.126 refuses to load RDU 6.1.13.101 Who knows? One thought I have upon seeing this thread is that RDU 6.1.13.101 (and some earlier versions subsequent to 6.1.11.101) may have some rare code patch that raises processor priority to a level that blocks time-critical interrupts. That might explain: (a) how it could affect network communications; ( how it could cause the VXA-320 corruption errors that people are seeing; © why Robin insists that no VXA code changes were made. It would all be consistent. Just a thought. Robin, you might check this possibility. Russ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted January 31, 2008 Report Share Posted January 31, 2008 While it is true that DVD-R support was lost a few RDU's ago, the ONLY changed made to the RDU since that time has been the addition of new device support. Why this happened is a long story that I won't get into in the forum. I don't even think the Mac RDU has the ability to make changed to how Retrospect communicates on the network. Quote: One thought I have upon seeing this thread is that RDU 6.1.13.101 (and some earlier versions subsequent to 6.1.11.101) may have some rare code patch that raises processor priority to a level that blocks time-critical interrupts. That is a big stretch. I don't think the RDU has anything to do with changes in CPU activity levels. Changes made to the RDU are very isolated. Adding support for a device will have no impact on how the RDU interacts with the other Retrospect functions. Even if the backup to a storage device gets really slow, the network should be able to handle it and a 519 should not be reported. I have not read most of this thread, but I can say that 519 errors are almost always something in the environment. A very simple test is to get an ethernet cable and directly connect two computers (no routers, hubs or anything else). If the problem goes away, then you have a network issue. If the 519 continues then you may have an Ethernet problem, firewall problem, problem reading the source disk or even a conflict with other software on the computer. Keeping 519 troubleshooting simple is the best way to find the cause. Is the 6.1 client perfect, no it isn't. This is why we will be releasing the beta for the universal client in a few weeks. Quote Link to comment Share on other sites More sharing options...
brendanu Posted February 11, 2008 Report Share Posted February 11, 2008 CallMeDave Thanks for pointing me in the right direction. I tracked the issue down to a firmware problem on the SATA card that connected the disks in the server. After I updated the firmware on the card Sonnet Tempo -X eSATA8 (updated to firmware v2.1.2) all was good. It seems as though the large amount of traffic reading from the drive duing a backup was causing a kernel panic on the server. Thanks again Brendan Quote: Quote: I've been experiencing the 519 communication error as well But it doesn't sound as if your experience is the same as what this thread has been tracking. What's different is that Retrospect appears to successfully scan the Source volume (projects on ETG-SERVER-2) before giving up 15 minutes or so later. I don't know what sort of speeds your DDS3 drive can sustain, but you're showing pretty dismal performance rates that might indicate some other network communication problems unrelated to the client scanning issue reported up-thread. I also don't see from your log entries where the server is rebooting; none of your log examples show an aborted execution. david Retrospect version 6.1.126 automatically launched at 27/11/2007 8:00 PM Normal backup using Daily Backup at 27/11/2007 8:00 PM To backup set KTS Backup Set B… 27/11/2007 8:00:19 PM: Copying projects on ETG-SERVER-2… 27/11/2007 8:00:19 PM: Connected to ETG-SERVER-2 Trouble reading files, error 519 (network communication failed). Quote Link to comment Share on other sites More sharing options...
pendragon Posted February 23, 2008 Report Share Posted February 23, 2008 I don't know whether this is related, but I am also seeing 519 errors about half the time our server's mail disk is scanned. The particulars: Retrospect backup server 6.1.138, Mac OS 10.4.10 on MDD G4 2x1.25 GHz wth 2 GB of RAM, VXA-320 through ATTO UL3D Mail server: client 6.1.130, Mac OS Server 10.3.9 on MDD G4 2x1.25 GHz with 2 GB of RAM (not the same machine), 3 striped 36 GB 10K SCSI drives through ATTO UL4S form the volume that has the problem. There are about 2M files in about 1000 folders on this volume. There are three other volumes on this system that are much larger, each containing at least as many files, but we never have problems with them. There are no firewalls and this is on a GbE network with no traffic during the backups. The mail server is Cyrus, which means there is a file for each email. Because incoming emails can keep extending a directory, the file system directories tend to get fragmented very quickly. There are some single directories containing 100,000+ files. My speculation, based on multiple observations, is when the client gets to scanning any one of these large directories, the Retrospect server almost immediately goes into "Net Retry" mode. If the client is able to open/scan the directory fast enough, communication will be restored and the scan will continue. On some of the largest fragmented directories, if the open/scan takes too long, the Retrospect server times out with the 519 message. When we can, we tarball the entire disk and restore it to a fresh filesystem. This immediately cures the 519 problems until the directories get fragmented again. This also cuts the time to perform a fsck on the mail drive from about an hour to a few minutes, and the time Retrospect requires to scan the drive, before starting a backup, from 3 hours to 30 minutes. But within a month or so the delays start building again. Our problem may be that the Retrospect client blocks when opening a huge, fragmented directory (I also see this at the command line level when I navigate through the filesystem). During this time there is no network communication and a "Net Retry" countdown begins. If the open doesn't complete before the server times out, the session fails. If there is some truth to this, it would be nice if the client could somehow advise the server with keep-alive traffic that it is busy. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted February 23, 2008 Report Share Posted February 23, 2008 Quote: Retrospect backup server 6.1.138, Mac OS 10.4.10 on MDD G4 2x1.25 GHz wth 2 GB of RAM, VXA-320 through ATTO UL3D There is a known bug with VXA-320 that was inadvertently introduced with RDU 6.1.13.101, and you don't say what RDU you have. Try reverting to RDU 6.1.11.101, see what happens. This would be an interesting bit of data. FYI, we have an Exabyte VXA-2 1x10 1u PacketLoader (SCSI) attached to our ATTO UL4D in our Xserve G5 server / mail server, now at Mac OS 10.4.8 Server, and I have never seen this error when backing up our network of iMacs. But you raise some interesting points; we don't have the deep folder structure on our clients that you do, and our clients are always backed up while at the Login window. Russ Quote Link to comment Share on other sites More sharing options...
pendragon Posted February 23, 2008 Report Share Posted February 23, 2008 Unfortunately I just tried RDU 6.1.11.101 per your suggestion and got the dreaded 519 error. This probably isn't surprising because the problem occurs in the scan; the tape is never touched. I really think there is an issue with the client going dark when it opens a giant directory. It may even be the system call to read the directory that stalls. I can see the hard drive lights flashing away on the client, while the backup server is doing a Net Retry. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted February 23, 2008 Report Share Posted February 23, 2008 Does the same thing happen if you define a subvolume that eliminates that giant directory so that it isn't scanned? Sounds like you may have identified the bug. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted February 23, 2008 Report Share Posted February 23, 2008 I know many people are on a 519 bug hunt, but I REALLY do not want this forum to lose sight of the fact that a 519 is a real error caused by real network problems. The current Retrospect client isn't perfect but in the MAJORITY of cases (millions of computers) it works great and a 519 is just a 519. An actual network failure. I know lots of people just want to point fingers at the software, but you also need to review and seriously look at the network/computer environment. Review http://kb.dantz.com/article.asp?article=6308&p=2 for specifics on this error. Shortly after the new forum is released, we will release the beta of the Universal Retrospect Client. I know we keep saying "a few weeks away"...We have been waiting to publish the new forum since the beta will be supported via the forum interface. Quote Link to comment Share on other sites More sharing options...
pendragon Posted February 24, 2008 Report Share Posted February 24, 2008 Quote: Does the same thing happen if you define a subvolume that eliminates that giant directory so that it isn't scanned? Sounds like you may have identified the bug. I can easily backup subvolumes that do not include the giant directories. I really don't know how many of these there are, but from a quick look there are likely more than 20 of them. Quote: I know many people are on a 519 bug hunt, but I REALLY do not want this forum to lose sight of the fact that a 519 is a real error caused by real network problems. The current Retrospect client isn't perfect but in the MAJORITY of cases (millions of computers) it works great and a 519 is just a 519. An actual network failure There are many non-Retrospect causes for 519 errors, but I would not want EMC Insignia to lose sight of the fact that some of us are having very serious problems that we have not seen before. I have been using Retrospect for nearly 15 years on a wide variety of platforms and network configurations. I have not experienced 519 problems like this. I should mention that when Retrospect is in "Net Retry" mode, I can successfully ping, ssh, copy files or just about any network operation I want between the two machines involved. The client is simply dead to the world when it opens a huge directory. By running the backup several times in a row, the Net Retries happen EXACTLY at the same file and folder counts in the scan. I have directly connected the two machines with a single cable. I have substituted different machines and different NICs. My problem is not network related. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted February 24, 2008 Report Share Posted February 24, 2008 Let me take back what I said above. A 519 isn't always caused by network problems. It is often caused by problems on the source you are accessing. This is one of the items covered in the document I recommended reading. I always like to ask "is this one client or more then one client?" This is a giant forum thread containing posts from a lot of different people, and not all of them have the same problem. My post was not really directed at Pendragon, but the many readers who have contributed to this thread. I want to make sure all causes are considered. Quote: Net Retries happen EXACTLY at the same file and folder counts in the scan The Retrospect Client itself isn't smart enough to know how many files it has scanned or how many GB. If a scan consistently fails at the EXACT same spot, then I agree it isn't a random network problem. It sounds to me like something very specific can not be read from the hard disk. This usually is a bad sector or file corruption on the disk. While you can scan folders that don't contain the giant directories, you need to define the subvolume contained in the giant directory that is being accessed when the failure happens. I know the Retrospect Client doesn't work as well as we would like and bugs do exist (like the client turning itself off), this is why the new client will have a long beta cycle so users can help us make the client the best possible. You can get on the beta list at list.dantz.com Quote Link to comment Share on other sites More sharing options...
pendragon Posted February 24, 2008 Report Share Posted February 24, 2008 Quote: If a scan consistently fails at the EXACT same spot, then I agree it isn't a random network problem. It sounds to me like something very specific can not be read from the hard disk. This usually is a bad sector or file corruption on the disk. While you can scan folders that don't contain the giant directories, you need to define the subvolume contained in the giant directory that is being accessed when the failure happens. I know the Retrospect Client doesn't work as well as we would like and bugs do exist (like the client turning itself off), this is why the new client will have a long beta cycle so users can help us make the client the best possible. You can get on the beta list at list.dantz.com I have used Retrospect for 15 years because it has proven reliable and robust; it has also saved my skin more than once. My intent is to ensure I can keep running it. I would not be surprised if I have a very isolated issue. In all honesty I believe we are dealing with Apple's somewhat mediocre filesystem, HFS+. If you start out with a directory containing a small number of files, keep expanding it a little bit at a time and do this over and over again, more often than not the physical directory will get scattered all over the disk. When HFS+ is requested to provide the directory contents, it can take a long time to read all of the little pieces. Sometimes minutes. There is no bad sector nor a corrupted directory, just a fragmented directory. It is an artifact of users who recieve large amounts of mail and do limited housekeeping. When I open such a directory in Finder, it will block for quite sometime and give me the technicolor pizza. If I do a ls in Terminal, I have to wait a long time, too. My guess is the Retrospect client is simply blocked on a system call, during which time the backup server hears nothing. During a Net Retry I can access email on the volume being scanned with very normal response times. If the client machine was brought to its knees, trying to recover a bad sector or untangle a corrupted filesystem, this would not be possible. All the client needs to do is make a non-blocking call or use a separate thread so the Retrospect server can patiently wait. I don't have a lot of options. Defragmenting directories like these is not for the faint-hearted. I recreate the filesystem once or twice a year, which temporarily cures the problem. The nasty part of the issue is if I can't get a backup from Retrospect, I risk losing the whole thing. I can backup parts and pieces of the volume, but with at least 20 huge directories buried 10-20 levels deep, this is not a pragmatic task. It still leaves the huge directories in an un-backed-up state. At the moment I am planning to move the volume over to a Linux system with a filesystem more appropriate to the task. I just want a clean backup before doing the move. I would be happy to try the beta client and will look into getting on the list early next week. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted February 24, 2008 Report Share Posted February 24, 2008 What do you consider to be huge directory? Do you have folders with millions of files (within a single folder) or do you have a huge number of files spanning over multiple folders or is it just a lot of GB. Understanding the file structure may help us to better understand the type of failure you are seeing. I know I have seen issues on Mac and Windows when a single folder contains a giant number of files. The file systems often just can't handle a huge number of files in a single folder Quote Link to comment Share on other sites More sharing options...
pendragon Posted February 24, 2008 Report Share Posted February 24, 2008 Quote: What do you consider to be huge directory? Do you have folders with millions of files (within a single folder) or do you have a huge number of files spanning over multiple folders or is it just a lot of GB. It's hard to absolutely correlate a specific directory to a scan failure, as Retrospect does not identify which directories it is scanning. I have isolated a few directories, each containing 100-200K files that regularly cause 519s. There are however a number of directories, each containing 10-100K files, that also have trouble. The size of the files are almost all in the 1-5 KB range. The problem is not just the directory size. In fact if I tarball the volume, reinitialize it and explode the tarball back, the scans scream and the problems disappear for a couple of months. This process effectively defragments the directories until they begin to extend and fragment with newly added emails. The Net Retries and 519s soon follow. If you want to replicate the problem, I would suggest creating 1,000 folders, not all at the same level. Put 1,000 files each into 90% of them and 10,000 files each into the remaining 10%. Now start randomly adding one file at a time to half of the big directories. You probably should also occasionally add a file to the 95% other directories. By the time the largest directories get up to 100,000 files, you'll probably see longer Retrospect scans, probably a few Net Retries and maybe some 519s. That's a reasonable approximation to our email volume's usage pattern. To be complete, we have this on a striped array with three 10K SCSI drives. We did this to buy time with Retrospect and got a couple of years. Now we are lucky to get a scan to complete 5% of the time. Each scan takes 3-4 hours for less than 2M files. I'm seeing the same problems brewing at another installation with a single drive. Quote Link to comment Share on other sites More sharing options...
file82 Posted March 18, 2008 Author Report Share Posted March 18, 2008 Ya, that will be good if the log able to show which was the last file it scanned before getting the error. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted March 18, 2008 Report Share Posted March 18, 2008 If you having odd network issues with backup, I would suggest downloading the Universal Client beta to see if things work better for you. If the old and new client report 519 errors, then I would probably point toward the traditional causes of a 519 and not Retrospect specifically. Quote Link to comment Share on other sites More sharing options...
jmedley Posted March 18, 2008 Report Share Posted March 18, 2008 Hi, I have been having the same network failure problem with OS 10.5.1 and 2. The more people that upgrade the more computers that don't get backed up. I was able, on the first one, to connect and divide the backup into sub-volumes to get it to work. Now the problem is worst because I can't connect to divide the backups into sub-volumes on the latest updated machines. This problem exist only on the intel machines running OS X 10.5.1 and 2. The machines range from a 17 and 20" iMac, Mac Pro, and a MacBook Pro. Here is a copy from the log .... (which doesn't tell me anything) 3/7/2008 2:33:52 PM: Connected to Foo's Computer -3/7/2008 2:33:52 PM: Copying Foo's Desktop Computer on Foo's Computer… Scanning incomplete, error 519 (network communication failed) You mentioned a universal client beta, and I'm willing to try anything at this point. Can you tell me where to download it at? Thanks, Jim Quote Link to comment Share on other sites More sharing options...
Mayoff Posted March 18, 2008 Report Share Posted March 18, 2008 http://forums.dantz.com/showforum.php?fid/99/ http://forums.dantz.com/portal/index.php? shows the same info Quote Link to comment Share on other sites More sharing options...
rhwalker Posted March 18, 2008 Report Share Posted March 18, 2008 Jim, Could you please provide a little more information about your client computers? I've looked at your three prior posts and this one, and you have never said how much memory is on any of the computers, only that you are backing up rather large (1 TB) drives. You may be having a simple "insufficient memory" issue, whether because the computers have insufficient RAM or whether they have sufficient RAM, but not RAM that Retrospect can use because of its PPC code heritage (being interpreted under Rosetta). MacOS 10.5.x, with its abundance of eye candy, uses more RAM than 10.4.x (which itself wanted a bunch). Rosetta complicated things in that it imposes its own memory limits on interpreted PPC code, and Rosetta also gobbles up a bunch of RAM itself for its interpreter and its interpreted / dynamically compiled code cache. It would be useful information to have some configuration specifics about your machines. If the problem is that Rosetta is pushing things over the edge with the added memory needed by MacOS 10.5.x, then a Universal Binary client will help eliminate that issue, but it will not address the underlying problem of a huge amount of files being sorted / backed up at once by the client from a huge disk. You may be seeing an artifact of a system that is thrashing, such that the client cannot respond as fast as Retrospect server wants because it is being paged to death. Russ Quote Link to comment Share on other sites More sharing options...
mburlison Posted April 4, 2008 Report Share Posted April 4, 2008 Okay. So I've been having a similar problem and would like to run a few things buy the guys also experiencing the "net retry" and 519 errors. I'm using Retrospect server version 6.1.138 with driver update version 6.1.14.101. All 10 of my clients are version 6.1.130. They are all running OS X 10.5.2 and about 6 of them have been migrated from G4 iMacs running Tiger. I use a Backup Server script and let it run every night between 10pm and 7am. Every machine was backing up beautifully except for one (previously migrated) Intel iMac. I read through all of the previous posts and thought my best bet would be to compare the root dir with that of another Intel iMac that had been migrated. In doing so, I came across 2 invisible files that seemed suspect to me. The first was a file named ".mdt-stamp" that had a Last Modified date of 2002. I deleted it. Then there was the hidden alias "dev" and it had a modified date of Dec. 17, 1903. Upon trying to access it, Finder says that the alias is incorrect and gives me the option to fix it. I canceled. This alias was of course locked, however, after trying to access it, the modified date changed from Dec. 17, 1903 to September 3, 2007. ??? Long story long...the backups are working now. I'm not sure if deleting the ".mdt-stamp" file did it, or if it was just attempting to access the "dev" alias. Or if all this is just coincidence and I haven't fixed anything. I will let it run a few more times and post back to let you guys know if it continues to work. In the meantime, can any of you check to see if your problem machines have similar files in the root? Let us know. Thanks. Michael Quote Link to comment Share on other sites More sharing options...
fivearrows Posted April 14, 2008 Report Share Posted April 14, 2008 (edited) I'm having 519 errors and I'm getting pretty frustrated. I wasted $100 on Retrospect Desktop because it worked great in the old days. Now I can't even get a backup, and of course you can't return software.... Anyway, here's my setup. The backup server is a minimac with 10.3.9. The clients are both intel-based with OSX 10.4.11, one MacBook and one iMac. I have used both 6.1.138 and 6.2.222 beta2 on the server, each time with the corresponding latest client version (6.1.138 and 6.2.222 beta2). I rebooted the client between versions. I've turned off screen savers and, I believe, all the energy saver options that might apply. The exception is putting the drive to sleep, but it shouldn't go to sleep when it is actively scanning or being backed up. Backup is to an external firewire drive connected to the minimac. I've tried network connectivity via wireless, wired hub from Verizon FIOS, and wired NetGear hub with only the minimac and macbook connected. I suppose I could try writing to DVD to see if it behaves any differently. I hesitate to do that, though, since the 6.1 Express version I used to use on the minimac took like 40 minutes to erase each and every DVD even if it was already blank. Oh, and don't bother pointing me to the "help" page for 519 errors. I've seen it and tried the steps with no luck. I'm very frustrated that I cannot call for support on a brand new product without throwing more good money after bad. So how about it, Dantz / EMC / Insignia? Can you help me or am I just another "happy" customer? Edited April 14, 2008 by Guest Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.