Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mac OS X client backup via scheduled group 2

Status
Not open for further replies.

ravashaak

Technical User
Nov 23, 2003
104
US
I'm attempting to backup a Mac OS X client to my networker server. We've purchased the clientpak for Mac, and it's authorized (admittedly it was the first time I had registered a new module of any sort on a networker server). The client will backup successfully when manually initiated from the client by use of the SAVE command. However, when backup is initiated via a scheduled group, the backup always fails with the following results:

--- Unsuccessful Save Sets ---

* balrog:All 1 retry attempted
* balrog:All Connection timed out

--- Successful Save Sets ---

medusa.ag235.horde.net: index:balrog level=9, 101 MB 00:00:15 5 files

There's no network firewalling between the client and backup server. I am fairly certain (tho not 100%) that there's no software firewalling on the client that would prevent the backup (I'm no Mac expert, but our Mac admin saw nothing that he could say would block the backup. However, we both agreed that it appears as if things are being blocked clientside...somehow.

My server is a Sun E450 running Solaris 8, Legato Networker version 6.12. Client networker version is 6.13.

Thanks in advance for any advice!

 
Is the listener running on the client? If not, the host cannot respond although you can do a successful manual backup (running save at the remote client).

I've never installed a Mac client but the doc should tell you. Usually, the binary is called nsrexecd(.exe)
 
I checked the running processes on the client. Somehow the daemon had stopped (but I had verified them as running before performing other tests in the past). In any event, I restarted the daemons. Then I issued the following command (per the manual):

ps -aux | grep nsr

The output was as follows:

root 417 0.0 -0.0 15188 372 ?? Ss 21Nov03 0:00.20 /usr/sbin/nsrexecd
root 419 0.0 -0.0 15152 272 ?? S 21Nov03 0:00.38 /usr/sbin/nsrexecd
root 6504 0.0 -0.0 15096 272 ?? Ss 7:42PM 0:00.02 nsrexecd
root 6505 0.0 -0.0 15096 504 ?? S 7:42PM 0:00.00 nsrexecd

Is the nsrexecd process what you are referring to as the "listener"? I'm assuming that's what you mean. In any event, after my above efforts, group backups for said client still fail.
 
nsrexecd is the daemon that runs on the client.


First, follow tech bulletin 299 on how to check and verify network connectivity between the backup server and the client:

LEGATO TECHNICAL BULLETIN 299: IP Naming in Heterogeneous Environments (UNIX | NT | NetWare | Windows 95)


Afterwards, try manual backups from the Mac client:

save -vv -s (backup server) -b (pool name) (file name)

Be careful, the pool name is case sensitive.

If manual backups fail, look to see what messages are generated.


From the backup server, run a backup in verbose mode:

savegrp -pvvv -c (Mac name) -l f (savegroup name)

If it fails, look at the output to determine point of failure.
 
If you had restarted Networker, then why are two nsrexecd processes been running since Nov 21?

I suggest you shutdown NetWorker on the Mac, verify that all nsrexecd processes are gone, then restart NetWorker. Then follow my previous post.
 
First of all, thanks to you guys for replying.

At present, I've noticed that the RPC portmapper is not running on the Mac. I suspect this to be cause of my troubles. I intend to test this at work tomorrow, time-permitting.
 
hi,

I am backing up OS 10.2 clients succesfully, I had to change the /etc/hostconfig file with the line for the RPCServices from automatic to yes, this starts the portmapper each time the system starts.

Mark
 
Well,

Backups for my Mac clients are finally running via savegrp!
It looks like the rpc portmapper being in an "off" state was
the root cause of the problem. After enabling the rpc portmapper to run at startup, scheduled backups run without an apparent hitch.

Thanks Wallace88. Your post pointed me to the bulletin, which led me to the rpcinfo command, which led me to my solution. And thanks to mlmmilkyway. Your post would have identified the problem outright for me had I read it before going into work today.

So, thanks everybody! You made me look a little bit better in the eyes of my boss...and that never hurts!
 
you're welcome... and thanks for marking my post as a being helpful. :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top