This section covers worst practices which, believe it or not, are quite common in the world of DR. You should read each vignette and avoid the scenario.
Taking a VMware snapshot of a server is only good as long as the snapshot is retained. As it ages, the differences tracked consume an increasing proportion of storage. This can slow down the server as well.
Being able to restore a server image is of limited use if the database images cannot be rolled back to the same point in time. Having a server rollback without a database rollback can lead to an inconsistent and inoperable farm. That is because the database schema needs to be in a valid range supported by the server software.
The PowerShell scripts can be viewed as an inexpensive way to build a comprehensive backup of databases and servers, but if they are home grown they will need to be clearly documented and they will not be supported by a 24 hour support line.
If there is only one SharePoint farm, there's no place to test changes. Any production change, no matter how safe it is assumed to be, can wreak havoc on a farm. Any release needs to be tested in an isolated test environment prior to deployment to production.
Examples of SharePoint disasters that can corrupt a production environment include:
Running out of disk space during a recovery. This is not always easy to estimate because temporary files are constantly created
A deployment or uninstall leaving non-functional references in
web.configOrphaned feature references
Under-sizing a server can be a cost-effective strategy, until it fails. Insufficient storage can cause a hard-failure. Insufficient resource, such as RAM, can cripple a SharePoint farm. At the very least, be sure to test any undersized hardware.
This section, lists some oversights in SharePoint DR plans that IT should know what to do with. We aren't just talking about storing all the DR documentation in SharePoint, we are talking about the very technology that is being recovered.