>>>> The backup scan ran as an AT job.
>>>
>>> I'm assuming you mean it ran at the server to pull files, rather than 
>>> at the client to push files. Might be better to switch that around.
>>
>> Yeah, that would mean that all the directory scanning would be local 
>> rather than remote. Probably a lot faster that way.
> 
> You'd still have to compare against the server, so that part is likely 
> the same either way. Unless you're going to trust the last time it ran.

You could keep a local cache of what was successfully sent to the 
server. But I was actually thinking more of having a component running 
at both ends and a custom communications protocol rather than SMB...

>> Because that's the only way to specify the logon credentials for the 
>> remote system.
> 
> net use \\xyz\pdq hispassword /user:xyz\hisusername

...that does something?

>>>> mapped under the system account which runs AT jobs, 
>>>
>>> Why? Tell AT to run it as a different user.
>>
>> There are other AT jobs running, of course...
> 
> Tell "at" to run *your* job under a different user ID. Not "at" itself.

As far as I know, this is impossible.

>> Robocopy can't copy a file, it says "I can't copy this file" and exits. 
> 
> Uh, no. Do a "robocopy /?" and look at the retry options section. What 
> would you have it do if the files it's backing up are on a PC that 
> someone turns off?

All you can really do is exit, and log the fact that something went wrong.

And then there are other issues, like file access permissions or files 
being locked. (Real backup software can get around these - although 
whether you want to backup locked files is another matter...)

>> Now the script has to do something about this.
> 
> There isn't a lot it can do except look at the exit status of robocopy 
> and send you a message if it failed.

Heh, yeah, I never did get as far as figuring out how to send alerts 
when it fails...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message