For awhile now, things have been getting very stable, very reliable and the workloads of managing data are even beginning to split. Some of the management is being done by outside folks, some by automated processes and, overall, things run extremely well.
It’s led to a bit of a strange trend in systems we’ve been reviewing. “Strange” because it seems so foreign, but not really strange because it really does make sense. That trend is one of not setting up recovery processes. Not having reporting on performance, or monitoring or other essentials in place for database systems. The reasoning we typically receive is that things are stable, they work and they continue to work without intervention. “Oh, silly. It’s not like the old days where you were constantly recovering your database!“
While I guess I get the sentiment, it makes my head explode a bit. I mean, there’s more to recovery than the fact that the server exploded and no longer exists. For example:
- Recovering from a developer error
- Recovering from a security issues (hackers, illicit access, goofs)
- Providing for discovery against your database
- Legal issues
- Compliance issues
- Reporting
- Restorations when a user goofs
There are many things that can go wrong with data. Providing for a tried and true path to recovery is part of the game IMHO. I realize that even these things happen less frequently than in the wild-wild-west of the days gone by (trying not to sound olde here).
BUT, the flip side of this is that data IS the business. Data IS the decision basis. It’s the foundation and core of so many things. I’ve even seen where databases on the whole needed to be restored to more than one specific spots in time, then validations run, then reporting and analysis, and comparisons of data. All in the hopes of establishing the “chain of evidence” for specific data held in those systems.
Knowing how to put together such an effort, let alone recovering from a data breach, security issue or simply bug in the company’s application(s), is something that should be top of mind for any SQL Server data professional. Really, for any data professional.
Just because it’s stable today, and probably tomorrow, doesn’t mean we should be looking the other way. Rather, we have more tools and more responsibility now than ever before to safeguard, make available and make productive the data systems we watch over.