As for almost any thing in the world, there are some trade offs you need to deal before deciding what is the appropriate approach.
First thing is to evaluate your business and infrastructure to elaborate a risk management plan (disaster recovery and business continuity plan are items inside this one). Answerig questions like
- "What is the money loss if the website goes of for 10 minutes? For 1 hour? 12 hours?"
- "What is the reputation loss?"
- "What are the major impacts other financial and reputational?"
- "How much data can I recover? Are there an redundancies for database? For the server?"
- "Will configuration management and versioning help me out? How well are they?"
Other than this, you need to plan disaster recovery in some levels. If it is webserver crash, a cracker invasion, a flood/earthquake, national backbone failure, a powerdown...
As you can see some risks can just be mitigated, some will demand a lot of work, and some you just can't act directly.
After all evaluations, you can determine which tests would you do and how often. Whenever a point change, you should test it actively, eg, if you buy a new server, you should test the power down, a crash... When everything is pretty the same but data on database, a fortnightly or monthly backup test is enough (if risk management allows it). Major corps usually simulate this once a quarter, as well as everything else.
Just one point... you should work on automating what is possible to automate. If your risk management plan points that going out implies in a massive loss, then makes sense to speed up through automation as much as possible to minimize that impact.