Log shipping backs up the transaction log on the primary, copies the files to a secondary and restores them there on a schedule. It runs as three SQL Agent jobs: the backup job on the primary, and the copy and restore jobs on the secondary. It is available in Standard Edition.

Good points and limitations

• Simple and reliable, and it works between different editions and across sites.
• The secondary can be left in STANDBY (read-only) for reporting between restores.
• No automatic failover. Failover is a manual process, and applications must be repointed.
• Data loss up to the backup interval plus copy and restore delays.
• Any log backup taken outside log shipping (a native or DPM log backup) breaks the chain and the restore job starts failing.

Check status

EXEC master.dbo.sp_help_log_shipping_monitor;

Compare time_since_last_backup, time_since_last_copy and time_since_last_restore with their thresholds. status = 1 means a threshold has been breached.

SELECT secondary_server, secondary_database,
       last_copied_file, last_copied_date,
       last_restored_file, last_restored_date, last_restored_latency
FROM msdb.dbo.log_shipping_monitor_secondary;

Common failures

• Copy job fails: the SQL Agent service account on the secondary cannot read the backup share.
• Restore job fails with an LSN error: a log backup was taken outside log shipping. Find it in msdb.dbo.backupset on the primary, then restore it manually on the secondary WITH NORECOVERY (or STANDBY), or reinitialise from a full backup.
• Restore job skips files in STANDBY mode: users are connected to the secondary. Tick ‘Disconnect users in the database when restoring backups’, or schedule restores outside reporting hours.

Failing over to the secondary (NEEDS APPROVAL)

• Disable the backup, copy and restore jobs.
• Run the copy and restore jobs one last time so every available log backup is applied.
• If the primary is still reachable, take a tail-log backup WITH NORECOVERY and restore it on the secondary WITH NORECOVERY.
• Recover the secondary:

RESTORE DATABASE [YourDB] WITH RECOVERY;

• Fix orphaned users (see Orphaned SQL Logins), then repoint the applications. Rollback: none once the secondary is recovered; log shipping has to be set up again in the other direction.

From my SQL Server DBA handbook.