> I may be wrong here, but NFS was designed originally as 
> a connectionless protocol, 

Actually it was written as a *stateless* protocol. Every transaction was
(and still is to a certain degree) atomic and shouldn't rely on the
previous transaction. It is perfectly acceptable to have a stateless
protocol be connection oriented. HTTP is a perfect example of this.

> In a NBU environment if that should happen, it 
> potentially hang and hang until failure occurs and a 
> blocking of your backup window.  Ultimately you will 
> pay the price of incomplete backups.

>From *nix's perspective loosing an NFS drive is akin to loosing a disk. If
a disk were to fail fails, NBU can't do it's work either. But, in a proper
NFS environ, this would be HA and it going down wouldn't be an issue.

So unless the network transport fails, or a disk dies, there shouldn't be
an issue with timeouts. This is the *exact* same kinds of issues that SANs
based storage has to deal with. If the transport dies, then you're SOL.

> Alternatively, one may use hard mounts (as I know them 
> to be called) which will NOT wait when a NFS filesyetem 
> should become unavailable, but will terminate the 
> connection.

Hard mount behavior is to do the waiting. Soft mounts on the other hand
will return an error and possibly corrupt data. From the Solaris man page
for mount_nfs

soft|hard      Return an error if the server  does  not
                         respond,  or  continue the retry request
                         until the server responds.  The  default
                         value is hard.

> written to the mount point and not the NFS filer you 
> want it to.  

That will *NEVER* happen as the filesystem has been mounted over. In unix,
once something is mounted, it doesn't disappear unless it's told to
explicitly via a umount.

        -- Cheers
        -- James