Linux Client (v6.0.143) not responding

[Malcolm McLeary]

Hi Guys,

 

 

 

Finally got my copy of Retrospect Multi Server 6.0 and installed the Linux client. The first complete backup of my server to VXA went well, but a later backup to CD was not so good.

 

 

 

With about 24MB remaining to backup it stopped and eventually logged an error -519 (network communication failed). Now if I look for the client on the network I get an error -505 (backup client reserved). Further having a look at whats happening on my server I find retropds.22 appears to be very busy doing nothing ... taking 97.6% of my cpu time. This does not look good.

 

 

 

Not sure if it helps, but ...

 

 

 

[root log]# cat retropds.log

 

1031106702: fetFileSpec: unexpected EOF on "/home/log/httpd/home-access"

 

1031113473: ServWait: headerValid = 1, curHdr.code = 0

 

1031113473: Assertion failure at resplib/servicelib.c-311

 

[root log]#

 

 

 

Having a look at what the client thinks its state is;

 

 

 

[root client]# ./retrocpl

 

Server "Qube3 - Kraken":

 

Version 6.0.143

 

reserved by BEASTIE for Immediate Backup

 

back up according to normal schedule

 

currently on

 

readonly is off

 

exclude is off

 

1 connections, 1 authenticated

 

[root client]#

 

 

 

Perhaps I should kill it, increase the logging level and try again.

 

 

 

Also what happened to the documentation for the linux client?

 

 

 

I can't find much detail in the hard copy v6.0 manual ... lucky I still have all the info supplied during the extended beta trial.

 

 

 

Cheers, Malcolm

[Malcolm McLeary]

 

 

Just to update my original post ... the problem has occured twice more. Each time Retrospect gets a 519 and the client is observed to be "reserved" and consuming about 98% of the cpu time. On the first occassion I was unable to stop and start the client so I was forced to kill it and reboot the machine. The 2nd time I was able to stop and start the client, but this morning I had to resort to kill and reboot.

 

 

 

Although top reports retropds.22 as consuming 98% of my cpu, other services are available.

 

 

 

I have been running the release version for a few weeks now and the pattern which is ermerging is that failure occurs during the compare of large (i.e. multi GB) recycle backups. Daily normal backups appear to happen without incident.

 

 

 

Typcally 519s can be caused my many things as backups "stress" all components of a system. In this case I believe its the client which is having the problem as it ends up consuming CPU cycles achieving nothing.

 

 

 

Anyone else observed similar problems?

 

 

[rgliebe]

I have a similar problem with a Sun Ultra 5 running Solaris. I checked to make sure that everything that is required by Retrospect is properly installed. I cannot figure out why the client remains reserved and in use after the backup finishes. The only way to free it up is kill the process and restart it. Until Dantz addresses these types of problems and problems with full restores, I have to continue using Legato to back up our UNIX based servers.

[merrisr]

I've run into several similar or related issues. I don't think that the CPU utilization is the problem - my linux clients peg at 99+% utilization even when no backup is running (though I've resolved that by setting their nice to 19). But the client reserved issue is very annoying. I've gotten that with linux and windows clients, and the user's guide and Dantz tech support both say the same thing - you have to reboot both systems. Well, that's not cool since I'm backing up a number of 24/7-type boxes, so I can't just go around rebooting them whenever I want. With linux that's not a big deal - I can just kill the processes and manually restart the client, but I haven't figured out how to clear the reserved issue for windows machines - restarting the service doesn't do it.

 

Rhian Merris

merrisr@saic.com