I assume you are concerned about hardware failure and not accidental data loss due to stupid user error... as replication would pull that error through to the replicated DB in any case.
If i'm correct, yeah mirroring and clustering would be a great option. The one i'm busy evaluating though is SQL Azure. To quote their high availability notes:
"The service replicates multiple redundant copies of your data to multiple physical servers to maintain data availability and business continuity. In the case of a hardware failure, Windows Azure SQL Database provides automatic failover to optimize availability for your application."
More here:
http://msdn.microsoft.com/en-us/library/windowsazure/ee336230.aspx
and more importantly, here:
http://blogs.msdn.com/b/jackgr/archive/2011/10/22/high-availability-on-the-azure-platform.aspx
Just something else to consider as it takes much of the pain of setting up replication away. Pretty damn impressive the way they do it.
Reading more into it now, this looks interesting:
"Replication
SQL Azure exposes logical rather than physical servers. A logical server is assigned to a single tenant, and may span multiple physical servers. Databases in the same logical server may therefore reside in different SQL Server instances.
Every database has three replicas: one primary and two secondaries. All reads and writes go to the primary, and all writes are replicated asynchronously to the secondaries. Also, every transaction commit requires a quorum, where the primary and at least one of the secondaries must confirm that the log records are written before the transaction can be considered committed. Most production data centers have hundreds of SQL Server instances, so it is unlikely that any two databases with primary replicas on the same machine will have secondary replicas that also share a machine."
