Jump to content

Recommended Posts

I have been backing up a SnapServer with 9GB of data for most of the day. It's set up as an AppleShare server... as far as I can tell it's communicating by AppleTalk over the Ethernet... It was averaging 21MB per minute. 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.

 

 

 

There are no other users of the SnapServer.

 

 

 

I don't know what to do now. Obviously something's wrong.

 

 

 

Help!

 

 

 

Gary

 

 

Link to comment
Share on other sites

I found a thread here about crashes to the AppleShare server... I should point out that the AppleShare server clone running on the SnapServer has NOT crashed, because I can access the SnapServer through the Finder on my main machine (the one running retrospect). The only problem is that there is no progress -- other than that everything APPEARS as if it were fine -- which it obviously isn't.

Link to comment
Share on other sites

I am now trying to cancel the backup run, but the cancel itself is frozen. The status dialog says "Canceling execution..." is just remaining in that state; the tape drive forward light is still on.

 

 

 

Looks like I'm going to have to kill retrospect.

 

 

 

I hope this isn't how reliable I can expect retro to be!

Link to comment
Share on other sites

OK, I killed retrospect (with "Force Quit") after waiting 15 minutes for the Cancel request to complete.

 

 

 

A few minutes later the tape drive's forward light is still on. But there's no sound of tape movement, and there hasn't been in hours.

 

 

 

Maybe the problem is the VXA hardware rather than the AppleShare setup? It's connected with Firewire. My machine is a PBG3 running OS X 10.1.4.

Link to comment
Share on other sites

It's hard to tell if you don't try the operation again. First, you need to be sure that Retrospect has been set up to automount the volume, as described in the Readme file. Next, try the operation again - does it hang at the same place?

 

 

 

If so, try to eliminate the Snap! from the equation - try backing up a similar amount of data from the local computer if possible. This can be helpful in determining if the problem is with the network connection or server, or if it is a hardware problem with the drive or drive communication.

Link to comment
Share on other sites

"First, you need to be sure that Retrospect has been set up to automount the volume, as described in the Readme file."

 

 

 

I hadn't done that. I either didn't notice it in the readme or forgot about it.

 

 

 

Today, I set up the automount, and tried to recreate the catalog. It chugged away for 11.1 megabytes but for the last few hours it has said "resynchronizing (slow)" and nothing more has happened.

 

 

 

What does that mean??

Link to comment
Share on other sites

In reply to:

If so, try to eliminate the Snap! from the equation


 

Heck, I'd try and eliminate the vxa from the equation! Seems like lots of folks are having problems with 'em.

 

 

 

Try and create a File Backup Set onto your OS X machine and see if Retrospect works as expected. Then you can know if the added hardware is causing the problems.

 

 

 

Dave

Link to comment
Share on other sites

The Resynchronizing message usually means that there is damage to the tape (search the Knowledgebase for details). This is probably a result of force quitting the backup last time.

 

 

 

Try backing up on a brand new tape, and try backing up only the local drive. Same behavior? If not, do a backup to that same tape of the server. Then what happens?

Link to comment
Share on other sites

  • 3 weeks later...

> 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...

 

 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

In reply to:

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


 

This is the first time I've read on the Forum that Retrospect itself is using all the CPU cycles. There have been other reports of the pitond process (the Retrospect Client), but never the application.

 

 

 

John, what exactly do you observe that leads you to the above conclusion (regarding CPU usage)?

 

 

 

Dave

Link to comment
Share on other sites

John,

 

 

 

I went thru very much the same problem last Friday: twice the backup had hung during "Closing".

 

 

 

I updated from RDU 2.6 to RDU 2.7 and on the next two tries, success. And for the record, three backup sessions run under Mac OS 9.1 / Retro 4.3 worked flawlessly to the same VXA drive (so I "know" it is not a hardware problem. ;)

 

 

 

What I did notice is that you are not running the latest firmware for the VXA-1 drive: 2B7B is what I have in mine.

 

 

 

There was one special condition during my failures: the humidity was unusually high at the time, but has gone down significantly since. It might or might not have been a contributing factor.

 

 

 

Glenn

 

 

 

My system:

 

PM G4 Dual 450 256 MB

 

Adaptec 2930CU with latest driver (don't have the number: thinking 1.1)

 

VXA-1 SCSI with firmware V2B7B

 

Retrospect version 5.0.205 w/RDU 2.7.102

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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. :-)

Link to comment
Share on other sites

In reply to:

 

 

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

 


 

Do the card and the drive have the same pin configuration? It seems to me that the drive might be 68 pin while the card is 50? That was one of Dantz' first warnings relating to OS X and SCSI devices...

 

 

 

Dave

Link to comment
Share on other sites

Thanks Glenn, I will look into updating the drive firmware.

 

 

 

Thanks Dave, the drive and SCSI cards have the same pin configuration.

 

 

 

My backup last night failed with:

 

Trouble writing: “6-Zeta” (3818428416), error 102 (trouble communicating).

 

so I am no closer to confirming whether the "Copying" hang is a real problem or just a symptom of other issues.

 

 

 

I'll post again here with anything relevant to the "Copying" hang, now for some SCSI trouble-shooting...

Link to comment
Share on other sites

Short version:

 

Got the "Copying" hang again. I am not any closer to identifying the issue, but at least it wasn't my imagination. :-)

 

 

 

 

 

Longer version:

 

I swapped the SCSI card (to an Adaptec 2906) and the SCSI cable and used a different VXA-1 drive and a new tape.

 

 

 

Tried backing up one troublesome dual-G4 450 MHz client running Mac OS 9.2.2, which now has a new hard disk and clean system install. Indefinite Net Retry, which has been an ongoing problem with this client ever since upgrading to Retrospect 5.

 

 

 

Booted the client into Mac OS X 10.1.5 and ran the backup. Backup progress stalled showing 432 M remaining, 24.9 G completed, at the end of the backup pass and before the verify pass. Interestingly the tape rewound to the start, and then sat idle. The Retrospect Server user interface stayed responsive for about twenty minutes, I was able to expand the progress window, open the log window etc. LaunchCFMApp was using all available CPU. After about twenty minutes the user interface stopped responding, LaunchCFMApp continued to burn the CPU. The client user interface continued to show the client in use by the server until I killed the server.

 

 

 

Rebooted with no changes to setup, and was able to run the backup to completion.

 

 

 

(My wild speculation is that the hang during "Copying" is due to a network or SCSI communication problem, and the server does not recover, like the indefinite Net Retry dialog.)

Link to comment
Share on other sites

  • 3 weeks later...

Short version:

 

Got a hang during "Comparing" today, progress showing 464 M remaining, 2.0 G completed. Backing up a windows client, client has not crashed and shows no signs of problems. Tape unwrapped about two hours previously, had been used for two backups before the one which hung. VXA drive connected over firewire.

 

 

 

Of some interest, after doing a Tools > Repair > Update Existing,

 

I looked in Reports > Contents,

 

and the client I was backing up has 2.6 G of files listed for that last backup.

 

 

 

Does this suggest that the backup actually ran to completion?? I am grasping at straws a bit, but supposing that the progress dialog had not updated for some time (which I have seen happen), and Retrospect hung trying to do the end-of-tape thing (which I have seen apparently happen), then this is a somewhat different problem than hanging in the middle of writing normal data to tape.

 

 

 

Details:

 

Retrospect (aka LaunchCFMApp) using 100% CPU, coloured spinning cursor when switch to Retrospect, no change for over ten minutes. No Net Retry dialog visible.

 

 

 

Retrospect Server 5.0.205

 

Retrospect Driver Update, version 2.7.102

 

G4 DP450 MHz, Mac OS X 10.1.5, 384 MB RAM

 

 

 

VXA Drive connected over firewire using Microtech SCSI/firewire adaptor that shipped with the VXA drive (sold as a firewire package). This is a different VXA drive than the one I was using in my other reports in this thread.

 

Ecrix VXA-1 version 2B7B

 

 

 

Client is Windows 2000, client version 5.6. Never had a problem with this particular client computer client in previous backups.

 

 

 

Right now I am using an almost completely different setup from when I started with Retrospect 5 (computer, cables, VXA drive, network switches) and am still having intermittent problems like this. I look back with wistful memories on years of reliable unattended backups, and hope that those days will come again.

 

 

Link to comment
Share on other sites

In reply to:

Right now I am using an almost completely different setup from when I started with Retrospect 5 (computer, cables, VXA drive, network switches)


 

But it's still a vxa drive, and it's still OS X.

 

 

 

Perhaps the upcoming years of reliable unattended backups won't start until Apple fixes things in the operating system that simply don't work right today.

 

 

 

For example, I'm still amazed that any single process can show in the terminal as using 100% (or more) of the cpu when tcsh and top need processor cycles too!

 

 

 

Dave

 

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...