I am not sure what you want to do, but this sounds like a bad idea. The performance cost that comes with updating two databases simultaneously compared to the benefit you have from it when once in who knows how often the server goes out.
Consider this, you constantly need to connect to two servers to insert or update data. If one is down the attempt will take a few seconds and then fail, at which point your two databases will be out of sync. To fetch data you could look at one database, but if the server it is running on is down an attempt will still take several seconds before trying the other database. If the problem is client sided (and if you have a stable server it usually is) then you could have a gazillion databases, but you wouldn't be able to connect anyhow!
What you need is a backup plan for whenever your main server crashes or someone deletes the database. You can schedule backups in SQL server. How often it needs to backup is up to you.
I am not very familiar with this, but you could take a look at
this[
^].
It should also be possible to backup only that which has changed since your last backup. This way backups will stack and together you will have your complete database backed up without having the performace hit of a full database backup.
This is all pretty advanced though, and if you are new to SQL server I suggest you Google around, read a book and draw your own conclusions.
Hope that helps :)
Submit an article or tip