Search code examples
asp.netsql-serverweb-applicationsrecoveryfailover

What's your disaster recovery plan?

And what would you recommend for an ASP Net web application, with a not so large SQL server database (around 10Gb)?

I was just wondering, is that a good idea to have an Amazon EC2 instance configured ready to host your app in an emergency?

In this scenario, what would be the best approach to keep the database updated (log shipping? manual backup restore?) and the easiest and fastest way to change the dns settings?

Edit: the acceptable downtime would be something between 4 to 6 hours, thats why i considered using the Amazon ec2 option for its lower cost if compared to renting a secondary server.

Solution

  • Update - Just saw your comment. Amazon EC2 with log shipping is definitely the way to go. Don't use mirroring because that normally assumes the other standby database is available. Changing your DNS should not take more than 1/2 hour if you set your TTL to that. That would give you time to integrate any logs that are pending. Might turn on the server once a week or so just to integrate logs that are pending (or less to avoid racking up hourly costs.)

    Your primary hosting location should have redundancy at all levels:

    • Multiple internet connections,
    • Multiple firewalls set to failover,
    • Multiple clustered web servers,
    • Multiple clustered database servers,
    • If you store files, use a SAN or Amazon S3,
    • Every server should have some form of RAID depending on the server's purpose,
    • Every server can have multiple PSUs connected to separate power sources/breakers,
    • External and internal server monitoring software,
    • Power generator that automatically turns on when the power goes out, and a backup generator for good measure.

    That'll keep you running at your primary location in the event of most failure scenarios.

    Then have a single server set up at a remote location that is kept updated using log shipping and include it in your deployment script (after your normal production servers are updated...) A colocated server on the other side of the country does nicely for these purposes. To minimize downtime of having to switch to the secondary location keep your TTL on the DNS records as low as you are comfortable.

    Of course, so much hardware is going to be steep so you'll need to determine what is worth being down for 1 second, 1 minute, 10 minutes, etc. and adjust accordingly.