Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12

Versions of Disaster Expand / Collapse
Posted Tuesday, January 13, 2009 11:52 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, January 15, 2016 1:04 PM
Points: 31, Visits: 346
Isn't this what change management requests are for. To keep track of what and when things are being done. Yes the data might be on the system that crashed that is why a hard copy is kept is a safe location. Keeping up with documentation is the worst part of the job. However, it is also one of the major parts of the job.
Post #635716
Posted Tuesday, January 13, 2009 12:01 PM



Group: General Forum Members
Last Login: Monday, August 29, 2016 1:09 PM
Points: 13,999, Visits: 9,728
I read a story about a shop that kept point-in-time restore data for all applications on all servers, throughout their history. They could restore any retired server, into a virtual environment, exactly as it had been on the particular day they needed.

One day, this became crucial for legal reasons, and they restored an old server into a virtual environment, with the databases and so on exactly as they had been on the critical day. And nobody could remember what the admin passwords had been, so the data might as well have not existed.

True or not, it was an amusing read. If true, I'm sure it was not so amusing to the people involved.

There are easy ways around that issue in SQL Server, of course.

As for keeping server version data, that's easy enough to do, but it isn't quite automatic. Good point, since it could very well matter when doing a restore.

Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #635723
Posted Sunday, September 15, 2013 6:45 AM

SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 4:00 PM
Points: 9,824, Visits: 11,895
Getting too paranoid about installing updates in case you have to reconstruct some time in the future is not a good idea; it will completely destroy any development and release method that involes incremental release and/or incremental deployment and/or incremental maintenance. As someone else alrady pointed out, courts will usually be sympathetic if you can show that have followed acknowleged (industry standard) best practice and done your best if something needs to be reconstructed for legal reasons and you can't do it successfully. Using ITIL or something similar will ensure that you have records of what version was where when, because you need them for more than just legal reasons. Those records should include things like passwords or a copy of your password safe or equivalent (old passphrases for that safe should be kept in a secure physical safe - if you discard them you are probably dead in the water), encryption keys (only those held in password-protected format outside the database), platform patch state, and application patch state as well as stuff about the hardware modification state; the software components installed (platform, middleware, and application) should be kept in there installed forms along with all updates. That will mean that you can always get back to a past point in time, provided you can produce or simulate the required hardware.

Very few shops indeed actually do this. None that I've ever worked in did it properly, but in many cases QA of software changes included checks that behaviour of existing functionality with old data was no different betwen old and new versions. Of course such checks will rarely be 100% comprehensive, but they can in almost all cases be thorough enough to provide a 99.999% certainty of no change. Then there are changes part of whose purpose is to change the behaviour of existing functionality with old data (as opposed to adding separate new functionality) and there version records are indispensible. But again they aren't always kept for more than a year or two, so in real life most people are not prepared for a sudden requirement to reproduce some ancient history. I suspect that while the editorail will make people think about this, and make some people who are already trying to have the reversion capability think hard enough that they improve their methods, it will have little or no lasting effect on the majority of people who just can't be bothered with a requirement to recover anything from more than a couple of months back (obviously people in some industries can't legally be part of that majority).

Post #1494879
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse