We support both Asyncronous or Syncronous mirroring.  WIth syncronous
mirroring the data is written to the target first, so the source will
have to wait for the target write to complete before the write is
committed on the source.  This guarantees no data loss.  Obviously
there is a performance penalty for syncronous replication and it is not
recommended across WANs.  Even storage based syncronous replication
will have some pretty hefty requirements when it comes to the type of
connection they require and the latency it can tolerate.

The alternative is Asyncronous replication, which takes a copy of the
write and sends it across the wire (keeping write order integrity),
however it lets the original write complete without delay.  This is the
preferred method of replication across a WAN, although in the event of
an unexpected failure, you could lose whatever is in queue, which is
generally at most the last write.  The benefit is that the source
server does not receive a performance penalty and this option works
just fine over a T1 with high latency.

Failover to the target site and failback for SQL server is automatic
and generally in the 30-45 second range, and this includes not only
data recovery, but starting SQL, recovering an IP address or doing DNS
update, and starting any third party app as well.  The mirroring is
automatically reversed once the original host comes back online and
just the data that has changed since it was offline is then sent back
to the original server.  Once the mirror is back in a mirroring state,
it is as simple as clicking on a button in the GUI to bring the
original primary back online.

When you say that with Hitachi or SRDF that the DR site is up
immediately, you mean the data, not the applications, correct?  Storage
based replication is only concerned about the data, not the
applications.  Once the data is recovered, you are still left with the
job of recovering the data.  One of my customers was trying to do DR
for Exchange with storage based replication, and was having a very hard
time with it (http://www.itreseller.com/pr/6434).  When he learned
about SteelEye LifeKeeper, he didn't believe that something so
inexpensive would work so much better than the solution he spent
100's of thousands of dollars on.

SteelEye Data Replication runs as a Windows filter driver, below the
file system.  Being at that layer means we take very little system
resources, maybe 1% CPU and minimal RAM.  Disk activity is only
increased during the initial sync when the data needs to be read from
disk.  After a mirroring state is reached, the disk on the source is
not impacted.  The only time you will see any additional load on the
system is if you turn on data compression.  Even at the highest level
of compression, on a single processor pentium 4 system you will see at
most a 15% CPU utilization increase.  Compression is only required if
your rate of change exceeds the capacity of the WAN link.  A T1 can
handle a rate of change of about 650 MB per hour with no compression.
Beyond that, you will need compression.