SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

GDPR – After the restore

I joined in on an interesting conversation the other day on twitter. It was about some unusual ramifications of GDPR (The EU General Data Protection Regulation). In case you haven’t heard of GDPR (maybe you’ve been offline for the last few months?), the GDPR is some rather sweeping security regulations for the data of anyone from the EU. Yes, that means if you aren’t in the EU but have the DATA about someone in the EU, you are affected. Does this include the UK? Well, I guess we will see.

However, back on topic, one of the things we discussed briefly was what about backups? Are they covered? If a customer requests their data be removed then what do we do about backups from before the removal? Well, as non-lawyers and non-experts, we decided that the backups are probably ok. However, if you have to restore the database for whatever reason, then you are absolutely going to have to re-run the delete scripts that removed the data.

Ok, no problem. We change our procedures to save every GDPR related script and when it was run. Then whenever a restore is done we check for any of those scripts that were run since the point in time of the restore.

Simple right? Well, there are some pretty important ramifications. What happens to your RTO (Recovery Time Objective or How long do I have to get this data back online in case of an emergency)? It’s going to go up, possibly not by much if your scripts are quick and hopefully automated. But if you have to manually review the list of scripts, and/or they take a while to run, this could add time.

Even more importantly, Do those scripts contain protected data? If your delete script uses some sort of public identification number (something equivalent to the US’s SSN) in order to remove them then can you save that script? Again, not a lawyer, not an expert, but I’m going to guess no. This does mean that in the Natural vs Artificial Keys argument the artificial keys side just got a big bump. Because to be honest, I’m going to want to play it safe with anything to do with the GDPR.

Summary: Your processes need to change.

  • Scripts that are run to remove data for the GDPR need to be saved.
  • After any restore any of the scripts run after the point in time of the restore need to be re-run.
  • When building the scripts you need to make sure you aren’t using any form of protected information to identify the data to be deleted.
  • Oh, and check your RTO

Final warning. I am NOT a lawyer. I am NOT an expert. Talk to your legal team, read the GDPR requirements. Take this stuff seriously.


My name is Kenneth Fisher and I am Senior DBA for a large (multi-national) insurance company. I have been working with databases for over 20 years starting with Clarion and Foxpro. I’ve been working with SQL Server for 12 years but have only really started “studying” the subject for the last 3. I don’t have any real "specialities" but I enjoy trouble shooting and teaching. Thus far I’ve earned by MCITP Database Administrator 2008, MCTS Database Administrator 2005, and MCTS Database Developer 2008. I’m currently studying for my MCITP Database Developer 2008 and should start in on the 2012 exams next year. My blog is at www.sqlstudies.com.


Leave a comment on the original post [sqlstudies.com, opens in a new window]

Loading comments...