> > > This is what was called NTBACKUP since NT 4.0.
> > This was merely an agent to shutdown exchange services for the
> time taken
> to backup the critical files which were locked for writing by exchange
> server.
>
> I don't know for older versions, but at least beginning on exchange 5.5 on
> nt 4.0, ntbackup did ONLINE BACKUPs, it didn't shut down anything.

When I worked with exchange 5.5, I used both Veritas and ARCServe products.
In both these cases you needed to purchase the additional agents for
exchange.
Exchange has numerous services which go to make up the entire suite and the
agent negotiated with each one in turn, depending on their dependencies, and
stopped the service, backedup the file and started that service again. If
you didn't have the correct agent, you would see in the backup log, numerous
files which were omitted from the backup because they were locked out. You
could achieve the same result by timing a batch file before the backup to
net stop all the exchange services in order of dependence, doing the backup
and another batch file would net start each of those services again in
reverse order.
Things may have changed but that's how it was in 1997-9.

>
> > It IS a problem - a real one. Don't confuse DB server
> transactions and the
> way the FB engine writes and reads from the file under it's sole control
> iwht wht the OS does when it copies a file. They are not reading
> the file in
> the same way. The OS only knows disk sectors while the db engine knows db
> pages as well.
> > The only way NTBACKUP would work successfully all the time is for it to
> have an "agent" which stops the fb server while it copies the gdb
> file, then
> starts the fb server again.
>
> No, I think you don't understand the point of volume shadow copies.
> Volume shadow copies (from a semantic point of view) clone all files
> atmoically. The database server can continue working on its version, the
> shadow copy has it's own. For the very short period of time, the
> os requires
> for instantiating the volume shadow, all accesses are stalled.

You're still talking about having to copy the file. Cloning automatically is
nothing more than copying... no? This copying is triggered by something and
this something is usually the timestamp changing when the fb server has
gained access. The shadow service is watching for this trigger. So FB
connects, shadow kicks in and starts copying.
on small databases, this "short time" is tolerable or not noticeable. For 3
Gb files, this time is long enough even on fast disks to cause FB to throw
an exception due to lack of access to the file.
You're right - I don't know the exact nature of shadow but if it's copying a
live db, I don;t lie it and wouldn't recommend it. It can do what it likes
to word documents.

errm - I don't suppose you are referring to the FB server shadow function
are you? that's not what I'm talking about. I'm talking about Disk Shadowing
in the Server2003 OS.

Alan