Up
through SQL Server 2000, this meant making a solid backup plan, documenting it, and
testing it. You could also use clustering to mitigate certain scenarios, such as hardware/
application failures or operating system errors.
As you??™ve seen, SQL Server 2005 introduces a number of new technologies that you
can apply to disaster recovery. Not only do you have new options, but you can also combine
those options in interesting ways that will fundamentally change the way you think
about disaster recovery. You??™ll still always need to back up databases, but now you can
mix that with clustering, database mirroring, or using database snapshots for user or
process disasters. A creative combination can result in an extremely well-protected
database.
Unfortunately, all of these additional technologies go for naught without actual disaster
recovery planning??”that is, documenting, testing, and practicing. Disaster recovery
planning should be considered an ongoing process, constantly reevaluated and adjusted
to meet new requirements. It??™s not a static project to be completed. Instead, it??™s a DBA??™s
ongoing job responsibility.
Pages:
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493