bgaspers Posted January 3, 2003 Report Share Posted January 3, 2003 I'm running the workgroup version of Retrospect on Mac OS X Server 10.1.5. Backup of this machine, an OS 9 machine, and a Windows machine all went fine. Backup of the data partition for a PowerBook running 10.2.3 also went fine. However, I've run into problems verifying the backup for the system partition for the PowerBook. Twice so far, the backup has proceeded fine, but the verify apparently hangs on the first file it encounters in the root directory. In addition, Retrospect appears completely unresponsive on the server. Any ideas on what is going on here? I'm running the 5.0.540 client on the PowerBook and the 5.0.238 version of the application on the server, along with RDU v3.2.104. This is backing up to a VXA-1 Firewire drive with the latest firmware. TIA, Brett Link to comment Share on other sites More sharing options...
AmyJ Posted January 6, 2003 Report Share Posted January 6, 2003 In reply to: but the verify apparently hangs on the first file it encounters in the root directory. Are there any error messages in the operations log? What happens if you backup subvolumes on the client machine? Is the problem specific to this single file on the root level of the drive? Link to comment Share on other sites More sharing options...
bgaspers Posted January 6, 2003 Author Report Share Posted January 6, 2003 Actually, I'm not sure this particular file is the problem. What is puzzling is that the backup will completely finish, but the verify then just sits there. BTW, this particular volume has about 149,000 files in the backup; I don't know if this is an issue. This is also the only 10.2 client I have on the network. There are no errors in the log, although I've had to force-quit Retrospect after it has sat there for hours in this state. The VXA-1 drive has the amber forward arrow illuminated like it is still recording, but there is obviously no recording going on. Once I force-quit Retrospect, the VXA-1 drive goes into format recovery. Another thing is that my daily backup server script still backs up and verifies this volume, although if I look in the backup set contents, there are two sessions entered for this volume. One shows the 149K files, while the other is apparently the daily backup set incremental backup with 51 files. I'll give the subvolume backup and verify a try and see if that is successful. Link to comment Share on other sites More sharing options...
bgaspers Posted January 8, 2003 Author Report Share Posted January 8, 2003 OK, I tested out backing up subvolumes on the client machine (about 77K files, for 4.3GB). This worked fine. Moreover, I have a daily backup script that then came along and did a normal (incremental) backup to backup and verify the rest of the files that weren't backed up in the subvolume run. So it apparently isn't an issue of a particular file hanging the process. Not that it ever was, since all the files got backed up, the verify just didn't take place on this particular volume. Any other ideas here? I guess I'll try another complete backup to see if this problem still crops up. Link to comment Share on other sites More sharing options...
ghoffman Posted January 9, 2003 Report Share Posted January 9, 2003 Brett, I believe I have experienced the same problem that you have described. In my case: It is not Verify that is failing. In the execution status window, I see "Updating catalog..." when Retrospect freezes. The problem has occurred even when Verify is disabled. I have the impression that Retrospect stays in the "Closing..." state for an extra long time when it is about to freeze in "Updating catalog...". I have not timed this, however. When Retrospect is frozen, the "beachball" cursor is displayed. Also, I have observed several times that Retrospect was using nearly 100% CPU ('top' command) when it was frozen due to this problem. In my experience, the problem seems to occur with large volumes (large # of files/large # of megabytes) and/or large numbers of files to backup (during a recycle backup). It has only happened while backing up client volumes - never on a local volume. Backing up volumes by subvolumes seems to avoid the problem. (I have never had a subvolume backup fail.) Some of my oldest, reproducible occurrences of the problem were helped by either running Disk First Aid for Mac OS 9 on the volume, or by rebuilding the volume using Carbon Copy Cloner to copy the content to another volume and then back again. This problem is not in general reproducible on my system. I can go for weeks with no problem and then - boom - the backup freezes. Then after recovering from the freeze, no problem again for weeks. My configuration: Mac OS 10.2.1 Retrospect 5.0.238 w/RDU 3.2.104 G4 450 DP w/256MB Adaptec 2930CU SCSI interface w/1.1.0 driver VXA-1 drive w/2D9D firmware Clients are: . iMac 500 w/OS 10.2.3 & client 5.0.540 . iMac 266 w/OS 10.1.x & client 5.0.528 . PM 6500 w/OS 9.1 & client 4.3 This problem has occurred many times, going back 6+ months to when I first started running Retrospect 5 on Mac OS X. Many different versions of Mac OS X and Retrospect have been involved. This problem has occurred using two different VXA-1 tape drives. I have been running some backups on Mac OS 9 using Retro 4.3 throughout this period with no problems. Glenn Link to comment Share on other sites More sharing options...
ghoffman Posted January 9, 2003 Report Share Posted January 9, 2003 Brett, I would like to pick at a few things you said, since they do not match my experience with these failures. In reply to: What is puzzling is that the backup will completely finish, but the verify then just sits there. 1) Did you see the "Comparing" line in the Operations Log following the "Copying" line? I never see the "Comparing" line when Retro freezes. 2) What does the Execution Status Window show? Does it go thru all the stages - Closing, Updating catalog, Locating, Comparing - before the freeze? In reply to: Once I force-quit Retrospect, the VXA-1 drive goes into format recovery. 3) You do have to power the VXA-1 drive off and on to get it drop out of write (the amber forward arrow) and begin format recovery, right? I do. 4) After force-quitting Retrospect, do you also find it necessary to reboot the computer to perform further operations with the tape drive? Glenn PS: what size tapes are you using when the backup fails? I am using V10's. Link to comment Share on other sites More sharing options...
bgaspers Posted January 9, 2003 Author Report Share Posted January 9, 2003 Glenn: In reply to your posts, here is some more information. One thing to note is that this is the first time I've experienced this particular problem and it also coincidentally happened after I upgraded this client to 10.2.3. Here are some answers to your points: 1) Yes, I do see the "Comparing" line in the log. Interesting thing I just noticed: in a normal operation, the log says "Copying ...", then "Connected to [client]", then "Comparing ...", yet in the cases where the verify froze, the "Connected to [client]" line is missing, but the "Comparing ..." line is still there. Hmm, smells buggy to me. 2) I haven't been looking at the window when it reaches the end of copying and moves onto the verify through these steps, so I can't say. 3) Right. 4) I think I've been able to continue without rebooting, but I can't remember offhand. Have you used the CLI vxaTool? In some cases, it has returned an error in connecting to the drive, even when Retrospect seemed to have no problems with it (and the backups proceeded without incident). I'm using V17 tapes. When these problems first cropped up, I did run OS X Disk Tool on the volume (showed no errors) and corrected permissions, to no avail. I haven't tried the CCC route yet. How about DiskWarrior? Did that do anything to help? Thanks, Brett Link to comment Share on other sites More sharing options...
ghoffman Posted January 11, 2003 Report Share Posted January 11, 2003 In reply to: this is the first time I've experienced this particular problem and it also coincidentally happened after I upgraded this client to 10.2.3. I agree, your problem and mine do not have the same history, and based on the further points of comparison below, it appears we have different problems. Sigh. In reply to: 1) Yes, I do see the "Comparing" line in the log. Definitely a different point of failure. I never get this line. In reply to: 4) I think I've been able to continue without rebooting, but I can't remember offhand. I definitely must reboot. Retrospect cannot see the drive otherwise, and the vxaTool throws an error "e00002be - Couldn't create a plug-in interface" until I do. In reply to: Have you used the CLI vxaTool? In some cases, it has returned an error in connecting to the drive, even when Retrospect seemed to have no problems with it (and the backups proceeded without incident). In my experience vxaTool will throw an error e00002be anytime after Retrospect has been launched and has made at least one access to the tape drive. Quitting Retrospect will allow vxaTool to again do its thing. Force quitting Retrospect will not - the operating system does not seem to clean up the state of the I/O interface in this situation, only a reboot will do that. In reply to: How about DiskWarrior? Did that do anything to help? I don't have DiskWarrior. I was using Carbon Copy Cloner to accomplish the same thing as DW. Glenn Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.