>> Right. Because there's a million and one gatchas to watch out for, and 
>> you've somehow covered them all with just a simple shell script.
> 
> It's really not all that hard. :-)  The tools are there.  If you don't 
> want them, then fine, but it's based off of someone who wanted to back 
> up several hundred desktop machines that had never been backed up onto a 
> couple of central servers over the course of a couple of weeks, so, 
> yeah, it handles a lot.
> 
> Look at robocopy, for example, and you'll see it'll mirror an entire 
> directory tree including junctions and auditing properties and 
> everything else, including network failures, it'll run and watch for 
> some number of changes and redo the backup when it gets there, etc.
> 
> Then look at vshadow and see how it'll take a snapshot of a running 
> drive and expose it under a different letter.
> 
> Of course it can fail. It's not going to fail silently without you 
> knowing it.

Oddly enough, I *have* looked at robocopy. I couldn't get it to work 
reliably enough.

I wrote a DOS script using xcopy to try to back up some PCs over the 
network. That wasn't reliable enough. So then I switched to using 
robocopy. That *still* wasn't reliable enough. So then I wrote a Tcl 
script to do it. Still had problems. Moved to Haskell. Mostly worked, 
but still occasional problems.

The backup scan ran as an AT job. Every now and then, there would be a 
network glitch or somebody would turn off the PC or something, and the 
script would hang with the network drive still mapped. Next day, the 
script bombs out because the drive is still mapped. Of course, it's 
mapped under the system account which runs AT jobs, you the only way to 
unmap it is to run an AT job to unmap it. That's once you kill the hung 
Tcl instance using Task Manager.

And don't even get me started on how absurdly difficult it is to write 
DOS scripts that handle failure properly...

The next stage of course would be to run a component on the remote 
machine to do the scan for modified files locally, and compress the data 
before sending it over the network... but I never got to that part 
because we have *real* backup software now. Backup software that works 
reliably.

>> In a giant database file. (It wouldn't surprise me if it's a JET 
>> database...)
> 
> That would be messy, but I'm guessing that vshadow tells exchange and/or 
> jet to flush their changes so at least you get a consistent and correct 
> file in the backup. (That's the sort of thing that I was saying UNIX 
> doesn't make trivial, even tho you can copy open files.)

Using the BackupExec agent for Exchange, backing up or restoring 
mailboxes or even individual emails is no harder than backing up a 
regular file. Try doing that with a DOS script...

(Then again, they charge you enough ****ing money for that thing!)

>>> The tools are there to do this. They're not that hard to understand.
>>
>> Sure. It's called professional backup software. And it costs lots of 
>> money. Because they can..
> 
> If you're going disk-to-disk, it doesn't cost all that much.

Possibly. I haven't investigated it much.

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

Post a reply to this message