Orchid XP v8 wrote:
> 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...

You could do that, yes. Not with shell scripting, mind.

If you go that route, I'd suggest you look at the USN functions, so you can 
actually iterate through all the changes to the local disk to figure out 
what you have to send.

>> net use \\xyz\pdq hispassword /user:xyz\hisusername
> ...that does something?

Sure. For example,
   net use \\thatmachine\c$ adminpass /user:thatmachine\administrator
will log you into the administrative share on "thatmachine".

Or do it the "right" way, and have the backup run as a domain user with 
permissions to log in to the appropriate shares. That's what domains are for.

>> Tell "at" to run *your* job under a different user ID. Not "at" itself.
> As far as I know, this is impossible.

Then have your job switch user IDs after it gets started, if you need to.

> And then there are other issues, like file access permissions 

Put your backup user in the backup operator group. That's what it's for.

> or files being locked. 

Make a VSS snapshot. That's what it's for.

How do you think "real" backup programs get around it?

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

Or log it into a file you check until you figure it out. Easiest would be to 
generate a Windows event for the event log, then have the event log software 
notify you.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message