I agree that keeping documentation up-to-date is an absolute pain in the arse but when you need it and it isn't there you are in trouble.

I work for a company that specialises in information mapping.  Rather than write four sides of A4 prose they try and condense it to a diagram and a set of bullet points.  I'd be shot on sight if they heard this over-simplification of it.

The problem with maintaining disaster recovery documentation is one of investment.

• Investment in time.
• Investment in tools to do the job.
• Investment in training.

If I browse around this site there are various scripts to automate the various SQL Server admin tasks and even one to blast DBCC SHOWCONTIG info into a database table.

I believe that it is not beyond the wit and wisdom to develop a tool that will maintain the bulk of the disaster recovery documentation.

I also work with content management systems.  Rather than building pages of information they tend to allow authoring of blocks of re-usable text.  This tends to have versioning and including localisation facilities.

If the money was invested in such a system for use as a disaster recovery tool then the job of updating the disaster recovery information would be much simpler.  Unfortunately the attitude is no-one got a pat on the head for putting in a better admin system.

Oh, rule one of disaster recover.  The first machine to recover is the one with the disaster recovery documentation on it.