SQLServerCentral / Editorials / SQLServerCentral.com / Versions of Disaster / Latest Posts

RE: Versions of Disaster

GSquared — Tue, 13 Jan 2009 12:01:08 GMT

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.

RE: Versions of Disaster

FFalcon1961 — Tue, 13 Jan 2009 11:52:00 GMT

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.

RE: Versions of Disaster

Steve Jones - SSC Editor — Thu, 18 Dec 2008 17:23:12 GMT

Typically the version differences don't prevent the restore of a db, however they can affect the functionality.I used to track this daily, mainly to make sure devs and others didn't change boxes without permission

RE: Versions of Disaster

Benjamin Lotter-629969 — Thu, 18 Dec 2008 11:04:33 GMT

We have implemented an SQL Server instance inventory systems which consists of an SSIS polling mechanism and a centralized database repository. Among the many things we track on a daily basis is the SQL version and build.

RE: Versions of Disaster

DCPeterson — Wed, 17 Dec 2008 12:32:56 GMT

This is just one reason why change control is SO important. If you have a method of testing and documenting all changes made in your enviornment then it becomes pretty simple to look at the date of the backup file and match that with the state of the server at that point in time.

RE: Versions of Disaster

David Reed-223505 — Wed, 17 Dec 2008 09:58:12 GMT

A little operational maturity goes a long way. If you're following MOF or ITIL, you're already keeping track of all these "little" details and should be able to reconstruct your environment from the logs to line up with those backups.Having years and years of backups is a start, but...That said, I don't think I've ever seen an operational shop (even in large enterprises) above a maturity level of ~2.5.

RE: Versions of Disaster

Charles Kincaid — Wed, 17 Dec 2008 09:05:18 GMT

[quote]I really don't have a great recommendation on how to handle this other than build some automated system that tracks the current build number on a daily basis, perhaps even putting it in each database. [/quote]Put it [b][i][u]in[/u][/i][/b] the database? :laugh: You mean the one we CAN'T restore?How about a central database to store all your version data and history? If you want to make it independent of SQL Server version issues try MySQL. Or :shudder: Access. Excel does not have any version problems. :Whistling: Maybe a Text file. Wait, there's all that UTF-8 and Unicode business. I know! PUNCH CARDS! [sub]Where are those 15 dozen boxes of blanks? Ahh, back of the car for weight in the snow. Everything is good for something.[/sub]Side bar: Why did they think the stand up comedian committed suicide? He [b]killed[/b] [u]himself[/u].Seriously though, reading legacy formats is, and likely always will be, a challenge. Just the other day a legacy application that has been running flawlessly for years went belly up. It threw errors talking about "linked tables". The guy working the issue asked me, "What the heck are linked tables?" The client had to dig to find the Access CD and actually install it on the machine in question. Access pointed to two different MySQL databases and some tables on the AS-400. One of the MySQL tables was corrupt and needed a table repair.

RE: Versions of Disaster

hnhaney2 — Wed, 17 Dec 2008 07:42:33 GMT

VM ware or some other Virtual PC. is the Key to Backware Capablity.Make a Virtual PC Copy of the computer at Install with just App. -No Data-Kepp Virtual PC Patched and Update the Same as the Rest fof the Servers.Back up after Each Patch and Update Cycle.Then when the problems come you can roll back the Virutal PC to the Time Needed.

RE: Versions of Disaster

CraigYellick — Wed, 17 Dec 2008 07:39:53 GMT

If you accept that disk space is very cheap relative to the cost and hassle of recreating your server environment, you can snap a copy as a virtual machine.We run all our servers as virtual machines and can back them up while they're running. Copies of the backups can be handed to developers to test changes on what was, until just a day or two ago, the current production system.Even if you don't run your server as a virtual machine, you can still make a copy of it as a VM.However, I'm not kidding about requiring a liberal attitude about disk space. The image files are in the tens+ Gb range and sometimes much higher. Keeping track of dozens of copies requires some advance planning.-- Craig Yellick

RE: Versions of Disaster

george sibbald — Wed, 17 Dec 2008 05:03:56 GMT

Of course the version of SQL is recorded in the errorlog at startup, and in the event of an instance crash these logs will likely still be there.Just in case as part of my DR processes I script out the server configuration, including the latest errorlog plus explicitly the SQL version using:select convert(nvarchar(10),serverproperty('productlevel'))select @@versionThis is then offsited to another server and tape.SQLdiag is a good little tool to run once in a while to give a good picture of the OS as well, but I do rely on the server admins to maintain doco on server builds.

RE: Versions of Disaster

EdVassie — Wed, 17 Dec 2008 04:52:12 GMT

If you are talking about software versions, do not forget about the Windows patch level, the AV control file level, etc, etc ad almost infinitum. Then we get into hardware versions - it is actually possible to obtain a working 10-year old server that has the same hardware build as the environment we are supposed to reproduce.My understanding is that the law does not mandate us to record the exact details of the software used on our servers on any given day. Legal process may ask us to show to the best of our ability how a particular piece of software worked at a given point in time, but it does not ask us to do the impossible.If a reconstruction of a crime, etc, is done, effort is made to use clothing, actors, etc that match as closely as known to the actual event. But very seldom does the legal process care if the the weather is a bit warmer,colder, cloudier, etc than the actual event. The same precedents have to apply in computing.A legal adversary may try to get penalties applied if the requested environment cannot be reproduced en every detail. It is the job of your own lawers to show that reasonable care has been taken in reproducing the environment, and it is as close to the original environment as it is reasonable to be. If the opponent is not asking for every detail (including the hardware) they seriously weaken their case that you are negligent in what you have been able to do. Any judge worth their office will accept that people cannot do the impossible. If you have complied with standard practice in your industry then you have a strong defense.You just need to convince your own lawers about all of this...

Versions of Disaster

Steve Jones - SSC Editor — Tue, 16 Dec 2008 17:37:19 GMT

Comments posted to this topic are about the item [B]Versions of Disaster [/B]