Remember Y2K? When the millennium changed on January 1, 2000, clocks continued ticking, both digital and analogue. Contrary to the general public’s concern, the vast majority of computers did not crash, nor did the world stop turning. Was it the careful planning, the countless updates and patches or the millions of dollars spent that saved the world from an IT meltdown? Not really. It was the fact that most software engineers knew better than storing years as double digits instead of four digits. Hence why countries that spent very little on getting their systems Y2K-ready (like South Korea) were as equally unaffected as countries that invested significant amounts of money (like the US) on preventing the Y2K bug that never materialized.
May 25, 2018 – also known as GDPR day. In reality, GDPR had been passed as legislation over 2 years ago and all companies that deal with EU personal data, have had plenty of time to plan for its implementation. The influx of policy change emails asking for consent and urging users to opt-in are a wake up call (especially since more than 80% of emails are coming from services that I thought I unsubscribed from already…).
The reality is that most users will not be affected, for better or worse, once GDPR comes into effect. And the reason is simple, the same engineers that knew how to deal with the Y2K bug (by coding the correct date format in the first place), wrote the books that trained the next generation of engineers to write software today. Sound engineering principles such as keeping data secure (no weak encryption algorithms or plain-text passwords!), keeping logs of where data is stored and who has access to it, are the pure foundation of modern software development. Now, will things still possibly go astray? Of course they will, but that’s why we have software that keeps software engineers honest.
Take the example of shadow copies of data. A customer database can be secured three ways from Sunday: access keys stored in a key vault, residing on separate servers from app servers, and all unnecessary ports closed using a firewall. However, what happens when a copy of that database (a backup) is restored on another server? What happens when a DR exercise finishes and nobody deletes the backup, leaving in effect a replica of all your customer data? Replace the above example with, testing, failover, marketing exercise, etc., and there is a chance that your data exists in more than one place.
What happens when a user requests to be forgotten? Well, you better know where all the copies of his or her user data reside, and this is where Movere can help.
During the discovery phase, Movere not only inventories each SQL server, but it also catalogues each database, its age, size and usage in order to help users identify copies of their data.
By applying filters such as “Include System Databases = No”, with just a few clicks users can narrow down on the databases that have identical copies (see example below: database WSS_Content has 3 copies, on 3 separate servers!)
Also, by applying Tags, servers can be flagged as Production/Test/QA or split by Geo-location (a built-in default feature of Movere), split by Application, and by any other dimension that is valuable to the user. When a mismatch is found (i.e. same database, present on 3 different servers (Prod/Test/QA) or in 3 different countries (US/UK/Canada), corrective steps can be taken.
This is just one of the many examples of how data about other data (metadata) can help you spot a potential issue before it becomes a real issue.
For more information, contact us here