Jump to content

shadowspawn

Members
  • Content count

    215
  • Joined

  • Last visited

Everything posted by shadowspawn

  1. Irena asked: Are these hangs always when writing to this tape? and Are you able to reproduce the hang with another tape? Last night I had two hangs while "Copying", both to the same tape. I have not reproduced this hang with a different tape, and have not yet tried the same tape again. (I will tonight.) Irena asked: What if you remove the RDU; speed reduction aside, does this affect the hang at closing? Yes indeed, and probably the problem during "Closing" is not a hang after all, just a long delay. After struggling to reproduce the problems of last night, I got serious and ran a recycle backup and then an incremental to two different tapes, using no RDU, RDU 2.6, and RDU 2.7, for a total of 12 backups. The time taken is dominated in every case by the tape management. An incremental backup takes about 55 s. (6 tests, 4553 KB each) The first backup using no RDU takes 1:30 (2 tests, 5917 KB each) The first backup using RDU 2.6 or 2.7 takes about 4:10 (4 tests, 5917 KB each). In that final case, almost exactly three minutes of that time is spent with "Closing" displayed in the progress dialog in Retrospect (and the CPU usage at about 100%). For now I'll stick to my claim of a hang observed during "Copying" and report further on that, but would like to downgrade my "Closing" obervations to just a surprisingly long delay and a small whinge about Retrospect using all the CPU doing nothing interesting. :-)
  2. Dave asked: John, what exactly do you observe that leads you to the above conclusion (regarding CPU usage)? Terminal "top -u" shows "LaunchCFMA" (truncated) using all the CPU. Killing the corresponding process number kills Retrospect. Terminal "ps -aux" shows this process number is relevant to Retrospect, and is in fact the only process running with a path of the Retrospect folder: /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Retrospect 5.0/Retrospect/Contents/MacOS/AuthenticateUser.app/Contents/MacOS/../../../Retrospect (My personal theory for the CPU usage is that Retrospect uses a lot of unthrottled polling of the hardware, and that when it is waiting for the hardware to respond, tends to use all the available CPU. But it is just a theory.)
  3. I have just had four hangs in a row during "Closing", twice with RDU 2.6.106 and then twice with RDU 2.7.102, backing up to a VXA SCSI drive. I started off with two hangs during "Copying" but have moved on from there. (Details in "Retro Frozen" thread.)
  4. Darn darn darn. While reproducible problems are good for identifying the problem, they are bad for actually getting a backup completed. (Having discovered Edit, I'll make this the last reply to myself for tonight!) Using the same backup files and tape each time, I just got the hang during "Closing" four times in a row, twice using RDU 2.6.106 and twice using RDU 2.7.102. It isn't iTunes (I have not it running for a while now). As before, Retrospect is responsive other than using all the CPU and making no progress. Each "Closing" hang so far, the forward light on the VXA drive is solid orange, and the drive chunks every so often. Killing Retrospect three times in succession in the "Closing" stage has not required rebooting to see the backup drive again (unlike my previous experience with hangs during "Copying"). Update: Rebooted, cleaning tape, recycle on backup set, new tape. Backup worked. Try recycle on backup set again, but insert old tape. Backup hung on "Closing" although this time tape did stop going forward, center green light flashed, then tape drive stuck on solid green forward. Clicking Pause and the Resume in progress window changed status to "Rewinding" and then backup completed normally.
  5. Retrospect version 5.0.205 Retrospect Driver Update, version 2.6.106 Ecrix VXA-1; version 2959; driver Ecrix VXA DC (5.01) PowerMac G4 Dual 450 MHz, 384 MB RAM SCSI card; name ADPT,2930CU; model ADPT,1686806-04; ROM# 4.0, revision 3 This is the first time I have ever had this particular problem twice in succession. Just tried a backup of different files to a different backup set, and got the hang again this time during "Closing" between the backup and verify. (Once is happenstance, twice is coincidence, three times is enemy action, Goldfinger, Ian Fleming.) About to reboot and try again again. I do have iTunes running, which I do not normally... More to follow...
  6. > But for the couple hours or so it's been totally stuck. It says > it has 287.4MB (3 files) to go, and the number never changes. The > little cursor sprockets are rotating and the "forward" light on > my tape drive (VXA) is lit. But there is no actual backup progress occuring. I have had this happen a few times, and it just happened to me on one client, and after a kill and reboot and repair catalog, happened again for a local backup. I associate this particular hang with Retrospect CPU usage going to 100%, and I always end up rebooting to get the backup drive available again. Before I reboot, a few diagnostics of the "live" hang: 1) Progress dialog shows "Copying". None of the numbers show any signs of progress. 2) Retrospect using all available CPU time. 3) This time the VXA drive is apparently idle, center green light on, but I don't think this is always the case. 4) Retrospect is still responsive. I can shift the progress window, open and close the disclosure triangle, show and hide the log window, pause and resume the backup. 5) Stopping the backup changes the progress text to "Canceling execution" but the CPU usage continues at essentially 100%, and Retrospect is now unresponsive. After over five minutes further of CPU usage, killed Retrospect. Retrospect Server 2.0.205 VXA-1 SCSI drive Adaptec 2930CU more details to follow after reboot...
  7. > I've always thought that the client licenses were for clients, > not for the servers. That was true prior to Retrospect 4.2, with Retrospect 4.2 and higher the license codes are server based. I am guessing you upgraded from an older version? This may not fit in very well with your previous backup setup - ouch! http://www.dantz.com/index.php3?SCREEN=lmcommonq > It still should have let me log in the first 100 clients correct? Yes, and it sounds like this worked when you did a clean install at least. I am not sure whether it is still technically possible to use your previous setup (with clients being backed up from multiple servers). It would be worth connecting to a client from two servers that have functional licenses to check for sure, your first install does sound broken.
  8. Does this only happen with one client, or more than one? Is the client running ASIP? Assuming it is only one particular client, and that you are not running ASIP on the client, it is likely a problem has shown up on your client that is unrelated to upgrading Retrospect. Do the usual trouble-shooting on the client, like running Disk First Aid, trying a backup with just the minimum system extensions active (plus Retrospect), trying a backup using a clean-install of Mac OS. If you get stuck try the knowledge base or ask again, and someone will have more suggestions. I had a different problem when I upgraded, also on a dual-G4, but could scan the client running Mac OS 9.0.4 using both 4.3A and the 5 client. In my case the trouble-shooting showed that the hard drive is now faulty.
  9. I had reduced my indefinite Net Retry scenario to an occasional problem by excluding one particular client from the backups, this client always caused the problem. Finally had a chance to take over the computer. A backup over a direct cross-over ethernet cable showed the same problem. Disk First Aid reported no problems. Used the 519 troubleshooting guide and tried Test in Drive Setup, within seconds it reported an unrecoverable error. A local backup confirms that the hard drive is faulty! So as usual Retrospect was the first thing to detect a problem. Of course I still don't think the server should block on a bad client, but one step closer to everything working. :-)
  10. The latest version of Retrospect is 5.0.205, if you are not using that, then upgrading would be worthwhile. And some more questions: What are you trying to back up? (Local disks, or Retrospect Clients, or both?) When it is la-la land, is it burning the CPU? (Do a top -u in Terminal and take a look at what percentage of the CPU Retrospect is using.) Inquiring minds need more clues. :-)
  11. > I am using Retrospect 5.0.205 with the 2.6.106 driver update on Mac OS X. Retrospect Express Backup does not support tape drives. That eliminated, moving right along... > I have changed cables, restarted, powered up/down my VXA, etc. All with > the same results. [...] Can someone help? Given it shows up in system profiler, and you have tried sensible things, a Retrospect reinstall looks a likely step. Before or after, here is a paranoid order to do things: 1) VXA drive disconnected from computer and off. 2) Reboot Mac. Login. Do not launch Retrospect yet. 2) Turn on VXA drive, still disconnected from computer. Wait thirty seconds. 3) Connect VXA over firewire. Wait thirty seconds. 4) Launch Retrospect. Cross fingers. (The reboot is to make sure things are back to clean state, firewire is designed to support hot plugging so again work from clean state, Retrospect scans for devices on launch so launch it after drive available.)
  12. > Retro 5.205 is setup on a G4 733 (OS X) to back 3 other computers and > itself all running Mac OS X. The backup script continually stops w/the Net Retry. Suggestions: 1) If it is always one client, try troubleshooting that client. I have one client I can not backup right now, it always stalls after simple fixes, and the user is not ready for extreme measures right now. 2) If it is every client, it might be your server, or your network. Try backing up from a different computer. My basic understanding is that the Net Retry dialog indicates a problem with your network communications, which you can troubleshoot. The indefinite stall on the Net Retry is presumably a bug in Retrospect, but you still have a problem worth troubleshooting irrespective of the bug. There are some exhaustive suggestions for troubleshooting 519 errors in the KnowledgeBase which will give you some good ideas.
  13. > I'm not familiar with IS-IT, so some instructions would be helpfull, Open Terminal (in the utility folder of the Applications folder). Type into the Terminal window (or copy and paste), and add a space on the end: ls -lT (ls is the List command, the flags are for Long format with complete Time, those ambiguous 1lI letters are L's.) The trailing space is so we can easily put in the filename or folder to do the listing for. Go to a file you are interested in using the Finder, and drag and drop the file (or folder) onto the Terminal window. Terminal will put the full unix path of the file on the end of the current line. Just switch back to Terminal and hit Return, you'll see something like: [p188:~] john% ls -lT /Users/john/ia5mac.zip -rw-r--r-- 1 john staff 30536944 May 13 17:08:08 2002 /Users/john/ia5mac.zip > To me that indicates positivley that the file has not changed, > and retrospect 5.0 is identifying the modification time incorrectly. Since you are mounting the server using a different operating system, and from other reports I understand the modification date only wanders by seconds, I am still interested in verifying what the file system thinks is happening. (I haven't scoured the forum so apologies if someone already checked this.)
  14. pnorton wrote: > My question is, is this an Appleshare problem under OS X, or is > Retrospect recording the wrong time information? Good question! CharlieRieger wrote: > And since the finder under OSX doen't show a change, that narrows it down to Retrospect. My finder does not show seconds for the modification time in the Get Info window, are you certain the Finder does not also believe the file modification date has changed? Try checking the modification date of a file including the seconds through some means independent of Retrospect, such as using "ls -lT" in Terminal. (I can give more explicit instructions if you need them.) Check the mod time before you even launch Retrospect, then check the mod times reported by Retrospect, and then check the mod time again after you quit Retrospect if you note a difference.
  15. > Does anyone else find Dantz's tech support policy unfair? (NB: new customers do get free tech support.) I also don't like paying for an upgrade, and getting no free personal technical support. However, I've been taking a look at other companies I deal with. Some are like Dantz and only offer personal support for new customers. Some do support paid upgrades, although for a shorter period than a new customer. Some have unlimited (and often poor) technical support. Perhaps no free personal technical support for upgrades is actually best because it keeps the upgrade cost as low as possible? I have no complaints about the quality of the free support, or the quality of the personal technical support. Trouble is, it doesn't feel fair having just paid money and not getting any personal support! The current policy has certainly got the forums off to a busy start... ;-)
  16. > And the $1400 cost in addition to the $350 we paid for the > server upgrade is way out of line. For goodness sake people, get a grip. You are upgrading 200 clients at an average cost of $8.75, with the server upgrade included, and 50 licenses to spare. Do you use any other commercial software that costs so little to upgrade?? Having some of the upgrade cost based on the number of clients just plain makes sense. I paid the same $350 for a 40 client system, and I felt this was pretty reasonable for mission critical software that is used company wide. Just a month prior to that I paid $179 just to add 5 clients, getting 100 licenses for my $350 seems a pretty good deal! > For the time being we'll stick with Retrospect 4.3 but as more OSX > clients come online we'll be looking for something else. Paying in advance hurts sure, but all of your clients are eventually going to shift to Mac OS X, and they can switch over without additional cost and with minimal effort. Just my opinion,
  17. > Can someone tell me what "dev.c-1047" is? The message probably refers to the source code for Retrospect itself (e.g. a file called dev.c, line 1047), not to a unix device. The source code contains an "assertion" that some condition is true, and you saw the message because you have something unusual going on. You typically only see messages like this when something very unexpected happens (like in the Princess Bride, inconceivable!), assertions are not usually seen by the customer since all of the likely errors are covered with more informative messages and/or recovery code. > Any suggestions? Try backing up just one folder, both to a file backup set, and to the VXA drive. There might be something wacky about your files, or something wacky about your VXA drive, you want to try some variations to narrow down the problem.
  18. With Retrospect 5 on Mac OS X, both CDs and mounted disk images are being included in my client backups. Is anyone else having this problem, and if so, is there a workaround for now other than using "Selected Volumes" in the client configuration dialog? Details: I am using "Client Desktop" in the client configuration dialog. In older versions of Retrospect the Client Desktop excluded CDs, and Page 88 of the current Retrospect User's Guide suggests this is still the intended behaviour: Client Desktop resolves to all volumes local to the client computer, except for floppy disks, shared volumes (such as file servers), read-only volumes (such as CD-ROMS), and empty volumes. It is on Mac OS X clients that I have noticed the issue. Retrospect Server 5.0.205, Retrospect client 5.0.528, Mac OS X 10.1.4 on client and server. The clients include a Blue&White G3 and a 800 MHz G4. I haven't surveyed other client computers or operating systems yet.
  19. Are you running Mac OS X? Files and folders with names beginning with a period (".") are not visible from the Finder. I had a quick look on Apple's support pages and found something to get you started: Article ID: 106589 Mac OS X: Folders With Names That Begin With a Dot Disappear From Finder
  20. I perform backups matching all the details you gave, without having such problems. Three suggestions: 1) Check for screen-saved or similar running on client. 2) Was that poor performance over a significant sized backup? When Retrospect scans 4 GB to backup 2 kB, the performance figures are not representative of the work going on! 3) Reboot client. Sometimes these sorts of problems are due to some transient wacky situation that never happens again.
  21. I don't have an answer, and have similar problems, but some suggestions: 1) Turn off speed threshold, it can currently cause problems backing up X clients. http://www.dantz.com/index.php3?SCREEN=knowledgebase_article&id=832 2) For general network troubleshooting, you might find some ideas in the comprehensive nasty network problem (519 error) guide. http://www.dantz.com/index.php3?SCREEN=tn415mw
  22. Current version of ntpd do not cope with your network settings changing, say connecting to the work network at work, and then dialing up over ppp at home. (i.e. Nothing to do with Retrospect!) Click Set Time Now in: System Preference > Date & Time > Network Time when you are going to be connected for a while, and the drift file might get initialised sensibly sometime later.
  23. I recently used Retrospect to do a duplicate on the server of about 9 GB from a folder on a firewire drive to a folder on an internal drive, and it worked perfectly. I have had problems similar to what you describe when doing a copy in the finder, because I copied the folders in the hard drive and missed everything on the desktop. I don't think you can make this mistake in Retrospect, but I mention it in the unlikely event you managed to do something similar when comparing the before and after.
  24. dhwagner asked: > I thought that the VXA firewire drive --at least early versions--was > basically a SCSI drive with a firewire adapter. Is this incorrect? You thought right, in fact the initial VXA firewire packages were sold with an external SCSI-firewire adaptor. I got one at a good price when the built-in firewire VXA drive shipped. Thanks for the comments and links Irena. The company I work for produces data acquisition devices for use over SCSI and USB. We also decided not to officially support adaptors, there was just too much variation in behaviour.
  25. My problem clients have always been Mac OS 9 so far. One client in particular stalls the backup every time. Dual 450 MHz G4, Mac OS 9.0.4, client 5.0.198. Client has always been shutdown into the Retrospect client so far, I have not yet tried a backup while the system is up. Had a dream run with 48 hours of almost continuous network backups, went home, and five minutes after I left the bad client got to the top of the list. 26 hours later Retrospect gave up with a 519 network error. Client was still top of list. 10 hours later, Retrospect gave up at script stop time. Client was top of list for another script. 2 hours later I suspect someone rebooted the client, although the log shows another 519 error. I will eventually get this client working (already tried reinstalling client, disk repair software next on list, then the full 519 trouble shooting guide), but I think the server should behave better too. :-) I am tempted to set the minimum transfer speed, but since the backup never starts this may not help, and this may also introduce problems with the Mac OS X clients. (Server is currently dual 450 MHz G4, Mac OS X 10.1.4, Retrospect 5.0.203, backing up to VXA tape drive over firewire with Microtech scsi/firewire adaptor.)
×