Pre/Post backup commands on Unix clients 1

[tapesnail]

Windows 2000 server with Arcserve 11.1 backs up assorted Windows, Novell, and Unix clients. On one of the Unix clients I need to coordinate backups of one file system with the successful completion of dump file processing. I have a script which checks dump status and returns a code which will signal the backup to proceed if everything is OK.
But, I can not seem to authenticate with the client to allow the prebackup script to run. Instead, I see this warning in the activity log no matter what account attempts to run the command:
W3073 01/20/2005 07:57:01 AM 33 Unable to logon as user. (USER=root, EC=Logon failure: unknown user name or bad password.

This is followed by an error code (E9003) about the script not running and then the backup proceeds, regardless of the dump file state.

Been through all the CA literature regarding this feature(what there is of it) and I've seen some old posts here from people with similar issues, but no answers to their problem. Am I out of luck as well?

 

[mtnathan]

If you just run the batch file / script, does it run fine?

 

[vschumpy]

Pre/post runs on the local host server, not on the remote client agent.

 

[tapesnail]

Vschumpy, thanks for getting back to me. I'd already figured that out within a day or so of the original posting and have been meaning to update this (for quite a while), but you beat me to it by a few days.
We've had Arcserve on several windows and Netware systems for years, but never doing cross-platform or networked backups, so I hadn't run into this particular set of "features(?)" before.
Once I got past my brain-cramp, I was able to get the proper remote signaling set up between the Windows backup server and the unix clients in hardly any time.

Prior to Arcserve, I'd been a long time user of Legato Networker in very large environments, so this experience was kind of like trading in a Ferrari for a moped. Of course that "moped" is a LOT easier to afford. And THAT was the original reason for consolidating the backups onto one system in the first place!

 

[vschumpy]

I used Legato a long time ago, and when I used it, it was very much a UNIX geeks delight (or that was the way I saw it anyway). Me being a NetWare and on-off Windows geek at the time I hated it. Besides, I was too busy fixing ARCserve NetWare database problems and trying to work out btrieve SMP issues at the time

Good to hear you got sorted in the end.

 

[jcdlm92]

Hello tapesnail,

In an earlier post, you say "I was able to get the proper remote signaling set up between the Windows backup server and the unix clients in hardly any time".

I need to make sure that ArcServe waits for some Unix jobs to be completed before collecting files. Right now, the only solution proposed by my IT department is to schedule backups a few hours after the expected script completion.

Can you explain to me how to do that or point me to the correct source (documentation or web)?

Thanks in advance.

 

[elanor]

Hi jcdlm92!
Check the Administrators Guide. It should have information about the options available, including the Run Before Job option (I think that's what it's called). I'm pretty sure that's where the info is.
Hope that helps!
Elanor

 

[tapesnail]

Hi jcdlm92,

The best way for Arcserve to "wait" for the unix clients is to have the unix clients initiate the backup jobs themselves, using the Arcserve commmand line utility 'ca_qmgr.exe' (refer to the administrator's guide on the command line tools). You'll need to set up some sort of remote command facility, like rsh, rcmd, or ssh to allow the clients to run the command, either directly or from within a wrapper script or batch file.
Implementing that solution can take some effort, though. Sometimes a LOT of effort, as I found out later.
When I wrote my initial reply about fixing the issue, Arcserve was running on a Windows 2000 server box. Our Unix servers are required to run SSH (Secure Shell) for remote access security purposes and rcmd, rsh, etc. are specifically disallowed. Installing and configuring SSH and using SSH public key authentication (no password required) on Win2000 server was almost trivial and took less than a day.

Getting SSH public key authentication to work on Windows 2003 Server, however, was another matter entirely! Windows 2003 is a much more "secure" platform than 2000 and many of the mechanisms that worked fine in NT and Win2000 function differently or not at all. It took a few miserable days of effort to figure out, but was worth it in the long run. I don't have to pore over job logs doing timing analysis to make sure jobs are running at the right time. Please refer to the OpenSSH website (

http://www.openssh.org)

for information on SSH. A lot of people have similar needs and what I discovered for myself over those few days is described in the support newsgroups there, though you might have to dig a little for it.

That being said, your IT department's proposed solution is certainly a workable alternative under the right circumstances... provided the set of conditions you're running the backups under doesn't change.
It's easy to set up and saves them the grief of implementing SSH, if they don't have it already. The biggest drawback is that it is open ended. You'll have to pay close attention to the backup activity logs and monitor them over time to ensure the backup jobs initiate at the proper time.
Increases in backup data volume, script processing time, network traffic, and backup schedule changes can make "the easy way out" a maintenance nightmare.

Hope I helped. Good luck with whichever approach you decide to take.