Summary

Log shipping is fairly easy to configure in contrast to data replication or SQL clustering. It also doesn't have many hardware or operating system restrictions other than requiring Enterprise Edition of SQL Server. Log shipping is a good option because it not only provides high availability, but also ensures your data against hardware failures. In other words, if one of the disks on the source (primary) server stops responding, you can still restore the saved transaction logs on the destination (secondary) server and upgrade it to a primary server, with little or no loss of work. Additionally, log shipping does not require that the servers be in close proximity. And, as added benefits, log shipping supports sending transaction logs to more than one secondary server and enables you to offload some of the query processing and reporting needs to these secondary servers.

As indicated earlier, log shipping is not as transparent as things like fail-over clustering because the end-user will not be able to connect to the database for a period of time and users must update the connection information to the new server when it becomes available. And remember, from a data synchronization point of view, you are only able to recover the database up to the last valid transaction log backup, which means that your users may have to redo some of the work that was already performed on the primary server. It is possible to combine log shipping with replication and/or fail-over clustering to overcome some of these disadvantages. Your particular HA requirements may be very well supported with a log shipping model.