Recovery Testing: The neglected child of QA

Recovery testing is the neglected child of Quality Assurance.  This can be true for many reasons, often software testing is done dynamically, where defects are found and tracked.  These defects are gathered, dispatched and repaired, but what about unforeseen defects?  Testing to a high confidence level is often expensive, and most systems settle for confidence somewhere in the mid to high ninety percentile range, however, in the event of a total software failure, can the system rebound?  Recovery testing looks at this very issue, and tries to ensure that any unforeseen failures are limited and recovered from gracefully.  The different types of recovery testing are cold spare, hot spare and automatic fail over.  Each of these three styles of recovery testing should bring up an exact duplication of the service, whether it be a web application or a database so that the user is effected as little as possible and the problem is potentially gone unnoticed.  The best way to ensure that recovery testing goes smoothly is to perform frequent backups and experimental failover to make sure that the backup system is prepared, however this is often a nuisance to larger companies that pride themselves on having strong uptime percentages.  Though these two needs are of equal importance, recovery testing gets put off in favor of consistent uptime.  What could be the reasoning for not testing a recovering system?  Perhaps coding compilation is done overnight and would severely inhibit work