top of page

DR a simulated disaster # 2

  • Adam Thurgar
  • Nov 12, 2018
  • 1 min read

In part 1 of "DR a simulated disaster # 1", I blogged about a simulated DR with reduced staff. That was a stressful day. Recovering from the one day DR was also a monumental task in itself. Having a DR plan and practicing it is one thing, but reverting back to your production system after a DR is another type of plan, often overlooked. Luckily no code changes had been made, but what about the data.

Production needed to be resynched from DR. Some of this could be done by automated methods, but some systems had to have the data re-entered manually, not ideal.

The whole event was a real eye opener to not just IT, but the business as well, about how hard a good DR and reinstatement plan is and how it constantly needed to be reviewed, updated and if possible tested (even in isolation). What plans do you have to reinstate your systems after a DR? Could you also do that with a skeleton staff?


 
 
 

Recent Posts

See All
Cardinality estimator

Recently I was asked by a software vendor to review a particular query that ran in under a second on a SQL Server 2014 installation at a...

 
 
 
Index fragmentation

A law firm client, occasionally has issues with their legal software, that is provided by the global leader in this field. The response...

 
 
 
Deleting large amounts of data

I had a client call me about wanting to delete a large amount of data from their database. They knew what tables they wanted to delete...

 
 
 

Comments


bottom of page