This was the first time we decided to make our own funny music video to go along with the song. An early effort, of course. Please note the Guitar Hero guitars the band is playing, along with the rusty guitar set. (It makes an appearance in another video.)
One of the things we learned over time was that the video ALSO needs to be funny. I think we accomplished that with this one.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
Fans of my books and websites may not be aware of my music parody hobby, partly because I never put them all in one place. So I recently uploaded all of them to Youtube, and am going to post them here as separate articles.
This was the very first one we did, and we didn’t have the budget to do a full video production. I wrote the lyrics, the very talented Lindsay Romney did the vocals, and her brother did the music and mixing. For the video, we used sections of Lady Gaga’s video and inter-spliced it with sections of other videos.
There is a French portion, since the original song had a French portion. It simply says “I want my files or I’m going to get fired,” in French. (Or something like that.)
I hope you enjoy this one. There are more (and better) videos to come.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
Magnetic devices make mistakes; the only question is how many mistakes will they make. I was presenting a slide a while ago that listed the Bit Error Rates (BERs) for various magnetic media, and someone decided to take issue with it. He basically claimed that it was all bunk and that modern-day magnetic devices don’t make mistakes like I was talking about. He said he had worked several years in businesses that make disk drives, and that there was essentially no such thing as a bit error. I thought I’d throw out a few other thoughts on this issue and see what others think.
Note: The first version of this post referred to Undetectable Bit Error rate vs just Bit Error Rate. The more common term is just BER. But when it’s UBER, the U apparently refers to unrecoverable, not undetectable.
He said that all modern devices (disk and tape) do read after write checks, and therefore they catch such errors. But my (albeit somewhat cursory) knowledge of ECC technology is that the read after write is not a block-for-block comparison. My basic understanding is that a CRC hash is calculated of the block before the write, the write is made, the block is read back, the CRC is calculated on what was read back, and if they match all is good. HOWEVER, since the CRC is so small (12-16 bits), there is a possibility that the block doesn’t match, but the CRC does match. The result is an undetected bit error. (This is my best attempt at understanding how ECC and UBERs work. If someone else who has deep understanding of how it really works can explain it in plain English, I’m all eyes.)
There was a representative in the room from a target dedupe vendor, and he previously worked at another target dedupe vendor. He mentioned that both vendors do high-level checking that looks for bit errors that disk drives make, and that they had found such errors many times — which is why they do it.
I once heard Stephen Foskett (@sfoskett) say that he thinks that any modern disk array does such checking, and so the fact that some disk drives have higher UBERs than others (and all are higher than most tape drives) is irrelevant. Any such errors would be caught by the higher level checks performed by the array or filesystem.
For example, an object storage system (e.g. S3) can product a high-level check on all objects to make sure that the various copies of the object do not change. If any of them show a change, it would be flagged via that check, and the corrupted object would be replaced. It’s a check on top of a check on top of a check. ZFS has similar checking.
But if all modern arrays do such checks, why do some vendors make sure they mention that THEY do such checking, suggesting that other vendors don’t do such checks? Unless someone can explain to me why I should, I definitely don’t agree with the idea that UBERs don’t matter. If drives didn’t make these errors, they wouldn’t need to publish a UBER in the first place. I somewhat agree with Stephen — if we’re talking about arrays or storage systems that do higher-level checks. But I don’t think all arrays do such checks. So I think that UBER still matters. What do you think?
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
It seems to me that source dedupe is the most efficient way to backup data, so why is it that very few products do it? This is what I found myself thinking about today.
Source dedupe is the way to go
This is my opinion and always has been. Ever since I first learned about Avamar in 1998 (when it was called Undoo). If you can eliminate duplicate data across your enterprise – even before its sent – why wouldn’t you want to do that? It saves bandwidth and storage. Properly done, it makes the backups faster and does not slow down restores. Its even possible to use dedupe in reverse to speed up restores.
If properly done, it also reduces the CPU load on the client. A typical incremental backup (without dedupe) and a full backup both use way more compute cycles than those that are used to generate whatever hash is being used to do the dedupe.
You save bandwidth, storage, and CPU cycles. So why don’t all products do this?
Inertia
Products that have been around a while have a significant code base to maintain. Changing to source dedupe requires massive architectural changes that can’t be easily added into the mix with an existing customer. It might require a “rip and replace” from the old to the new, which isn’t what you want to do with a customer.
Update: An earlier version of the post said some things about specific products that turned out to be out of date. I’ve removed those references. My question still remains, though.
No mandate
None of the source dedupe products have torn up the market. For example, if Avamar became so popular that it was displacing the vast majority of backup installations, competitors would have been forced to come up with an answer. (The same could be true of CDP products, which could also be described as a much better way to do backups and restores. Very few true CDP products have had significant success.) But the market did not create a mandate for source dedupe, and I’ve often wondered why.
Limitations
Many of the source dedupe implementations had limitations that made some think that it wasn’t the way to go. The biggest one I know of is that restore speeds for larger datasets were often slower than what you would get if you used traditional disk or a target dedupe disk. It seemed that developers of source dedupe solutions had done that venerable sin of making the backup faster and better at the expense of restore speed.
Another limitation of both source and target dedupe – but ostensibly more important in source dedupe implementations – is that the typical architectures used to hold the hash index topped out at some point. The “hash index,” as it’s called, could only handle datasets of a certain size before it could no longer reliably keep up with the backup speed customers needed.
The only solution to this problem was to create another hash index, which creates a dedupe island. This reduces the effectiveness of dedupe, because apps backed up to one dedupe island will not dedupe against another dedupe island. This increases bandwidth usage and the overall cost of things, since it will store more data as well.
This is one limitation my current employer worked around by using a massively scalable no-SQL database – DynamoDB – that is available to us in AWS. Where typical dedupe products top out at a 100 TB or so, we have customers with over 10 PB of data in a single environment, all being deduped against each other. And this implementation doesn’t slow down backups or restores.
What do you think?
Did I hit the nail on the head, or is there something else I’m missing? Why didn’t the whole world go to source dedupe?
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
The answer is absolutely yes, and anyone who thinks you don’t need to do so should not be put in charge of your data. Also, anyone who thinks I’m saying this just because I work for a company that backs up Office365 should read this blog post from seven years ago when I basically said exactly the same thing: Cloud services need to be backed up.
I was reading a spiceworks thread on this topic and was shocked at some of the anti-backup recommendations I saw there. One person pointed to TechEd article that talks about how redundant the storage is for Office365. That has absolutely nothing to do with this topic. That’s the equivalent of saying “I have RAID, so I don’t need backups.”
I saw another post where someone explained that the recycle bin is sufficient for “oops” recovery needs, and that vendors just try to scare people with things like rogue admins to get them to buy their products. He/she went on to say nothing like that had every happened to them, so… It’s not just rogue admins, people. There are all sorts of things that can corrupt your entire datastore that can only be addressed via a good third party backup solution.
Backups aren’t included
Take a look at the feature page for Office365. You will find that backups aren’t included. The references to data protection features are more about loss prevention and things like that. They have nothing to do with recovering corrupted data.
MCSE Brian Posey points out that “the Office 365 service-level agreement addresses availability, not recoverability.” So if you or someone else messes up your Office365 data, Microsoft is under no obligation to help you.
MCSE Experts think so
Microsoft MVP Brien Posey says that “you might not have as many options for restoring your data as you might think. As such, it is critically important to understand your options for disaster recovery in an Office 365 environment.”
“Microsoft says they also perform traditional backups of Office 365 servers. However, those backups are used for internal purposes only if they experienced a catastrophic event that wiped out large volumes of customer data…”
He also points out that there is no “provision for reverting a mailbox server to an earlier point in time (such as might be necessary if a virus corrupted all the mailboxes on a server).”
You can delete your primary & secondary recycle bin
A lot of people talk about using the recycle bin to recovery accidentally deleted or corrupted folders. It is true that it can keep such items for up to 90 days, depending on your settings. However, it is also true that a well-meaning or malicious person can easily clean out both the primary and secondary recycle bin. And a malicious person would indeed do just that.
Litigation hold doesn’t protect public folders
Some say that litigation hold protects you from such things. It keeps a copy of most messages forever; however, it does not protect public folders. Someone could easily delete everything in a public folder and then empty the recycle bin, and you would no recourse if you did not have a third-party tool.
Litigation hold has no separation of powers
An important concept in many environments is the separation of powers between a person like the Exchange admin, and a backup person. That protects the organization from rogue admins doing very bad things and then covering them up by deleting the backups as well.
But litigation hold has no such protection. Office 365 administrators could (rightly or wrongly) assign themselves eDiscovery Manager rights and have full access to search and export from Exchange mailboxes, SharePoint folders, and OneDrive locations. They could even modify the Litigation Hold policies. One way to describe this is that it helps a good person to do the right thing, but it does not stop a bad or incompetent person from doing the wrong thing.
The OneDrive restore feature is all or nothing
The OneDrive restore feature is a bit puzzling. It can only restore things that are in the recycle bin, and it is all or nothing. Meaning you have to restore the entire OneDrive system to a single point in time; you cannot just restore parts of it. That has to be the most worthless restore I’ve ever heard of.
You need to backup Office365
You need to backup Exchange, OneDrive, and Sharepoint. Microsoft isn’t doing it for you, and the features that protect you against accidents do not go far enough. Look into a third-party solution, such as what my employer (Druva) provides.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
Disaster recovery experts do not agree whether you should have one-and-only-one recovery time objective (RTO) and recovery point objective (RPO) for each application, or two of them. What am I talking about? Let me explain.
In case you’re not familiar with RTO & RPO, I’ll define them. RTO is the amount of time it should take to restore your data and return the application to a ready state (e.g. “This server must be up within four hours”). RPO is the amount of data you can afford to lose (e.g. “You must restore this app to within one hour of when the outage occurred”).
Please note that no one is suggesting you have one RTO/RPO for your entire site. What we’re talking about is whether or not each application should have one RTO/RPO or two. We’re also not talking about whether or not to have different values for RTO and RPO (e.g. 12-hour RPO and 4-hour RTO). Most people do that. Let me explain.
In defense of two RTOs/RPOs (for each app)
If you lose a building (e.g via a bomb blast or major fire) or a campus (e.g. via an earthquake or tsunami) it’s going to take a lot longer to get up and running than if you just have a triple-disk failure in a RAID6 array. In addition, you might have an onsite solution that gets you a nice RPO or RTO as long as the building is still intact. But when the building ceases to exist, most people are just left to their latest backup tape they sent to Iron Mountain. This is why most people feel it’s acceptable to have two RTOs/RPOs: one for onsite “disasters” and another for true, site-wide disasters.
In defense of one RTO/RPO (for each app)
It is an absolute fact that RTOs and RPOs should be based on the needs of the business unit that is using any given application. Those who feel that there can only be one RTO/RPO say that the business can either be down for a day or it can’t (24-hour RTO). It can either lose a day of data or it can’t (24-hour RPO). If they can only afford to be down for one hour (1-hour RTO), it shouldn’t matter what the cause of the outage is — they can’t afford one longer than an hour.
I’m with the first team
While I agree with the second team that the business can either afford (or not) a certain amount of downtime and/or data loss, I also understand that backup and disaster recovery solutions come with a cost. The shorter the RTO & RPO, the greater the cost. In addition, solutions that are built to survive the loss of a datacenter or campus are more expensive than those that are built to survive a simple disk or server outage. They cost more in terms of the software and hardware to make it possible — and especially in terms of the bandwidth required to satisfy an aggressive RTO or RPO. You can’t do an RPO of less than 24-36 hours with trucks; you have to do it with replication.
This is how it plays out in my head. Let’s say a given business unit says that one hour of downtime costs $1M. This is after considering all of the factors, including loss of revenue and damage to the brand, etc. So they say they decide that they can’t afford more than one hour of downtime. No problem. Now we go and design a solution to meet a 1-hour RTO. Now suppose that the solution to satisfy that one-hour RTO costs $10M. After hearing this, the IT department looks at alternatives, and it finds out that we can do a 12-hour RTO for $100K and a 6-hour RTO for $2M.
So for $10M, we are assured that we will lose only $1M in an outage. For $2M we can have a 6-hour RTO, and for $100K we can have a 12-hour RTO. That means that a severe outage would cost me $10M-11M ($10M + 1 hour of downtime at $1M), or $6M-$12M ($6M + $6M in downtime), or $100K-$12M ($100K + 12 hours of downtime).
A gambler would say that you’re looking at definitely losing (spending) $10M, $6M, or $100K and possibly losing $1M, $6M or $12M. I would probably take option two or three — probably three. I’d then put $9.9M I saved and make it work for me, and hopefully I’ll make more for the company with that $9.9M than the amount we will lose ($12M) if we have a major outage.
Now what if I told you that I could also give you an onsite 1-hour RTO for another $10K. Wouldn’t you want to spend another $10K to prevent a loss greater than $1M, knowing full well that this solution will only work if the datacenter remains intact? Of course you would.
So we’ll have a 12-hour RTO for a true disaster that takes out my datacenter, but we’ll have a 1-hour RTO as long as the outage is local and doesn’t take out the entire datacenter.
Guess what. You just agreed to have two RTOs. (All the same logic applies to RPOs, by the way.)
If everything cost the same, then I’d agree that each application should have one — and only one — RTO and RPO. However, things do not cost the same. That’s why I’m a firm believer in having two complete different sets of RTOs and RPOs. You have one that you will live up to in most situations (e.g. dead disk array) and another that you hope you never have to live up to (loss of an entire building or campus).
What do you think? Weigh in on this in the comments section.
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
One of the most valuable resources your company has it probably not being backed up properly – if at all. Like a lot of cloud services, the ability of salesforce customers to recover from big mistakes or a malicious attack is a bit overstated. Let’s take a look at that.
Big, bad update
Say, for example, that someone wants to change how phone numbers are stored in Salesforce. (I know this because I wanted to do this once with a large number of records.) Let’s say they are tired of the inconsistent way phone numbers are stored and want to go to a standard format. They have chosen to get rid of all parentheses and spaces, and just use dashes. (800) 555-1212 becomes 800-555-1212.
They download a CSV of all the salesforce IDs and accompanying phone numbers. They do their magic on the phone numbers and change everything to dashes. But they accidentally sort one column, completely disassociating numbers with Salesforce IDs. They then update every single one of your leads with incorrect phone numbers. Little by little, salespeople notice that some phone numbers are wrong and fix them. But it’s days before they realize that it was this update that broke everything.
This would also be a great way for a salesperson to get even with your company for not giving him the bonus he wanted. Download a bunch of records, do a quick sort on only one column, then use data loader to upload nonsense back to salesforce.
Recycle bin cannot fix updated records
The recycle bin contains deleted records, not updated records. So fixing even a few mistakenly (or maliciously) updated records is not possible with the recycle bin. It can only fix things if you accidentally delete records – as long as it’s not more records than what can fit in your recycle bin. (The number of megabytes of storage you have X 25.)
You really need to back up Salesforce
Without an external salesforce backup, you are literally one bad update away from being forced to use their “recovery service,” which may be the worst service ever. It’s so bad they don’t want you to use it. They call it a “last resort,” and tell you it’s going to take 6-8 weeks and cost $10,000. And after six weeks, all you have is a bunch of CSV files that represent your salesforce instance at a particular point in time. It will be your job to determine what needs to be uploaded, updated, replaced, etc. That process will be complicated and likely take a long time as well.
Please look into an automated way to backup you Salesforce data.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
No one knows for sure whether backups are going to be included in the right to be forgotten (RTBF). Even the GDPR ICO isn’t being entirely clear about it yet. But that hasn’t stopped people from expressing very strong opinions on the subject.
I’ve now written several articles on this topic, and I’ve seen a variety of responses to my comments so far, especially comments to The Register article that Chris Mellor wrote that mentioned my articles. The ones that crack me up are the people that are absolutely sure about how GDPR works – even if the ICO isn’t. This is especially true when they’re trying to sell me something to fix a GDPR problem. Be wary of GDPR fear mongers trying to sell you something.
Just in case you’re wondering, even though I work at a data management as a service (DMaaS) vendor, I’ve got no axe to grind here. I’m aware of no products in this space that have a stronger GDPR story than Druva, so I have no reason to convince you this isn’t a problem. (We are able to help you find files that match certain parameters, and can help you delete them from backups. Like everyone else, however, we are not yet able to delete data from within a backup of a structured database. I am still unaware of any products that solve this problem.)
My only goal here is to start a conversation about this difficult topic. That I’ve clearly done. So I’m going to keep talking about it until we know better.
Experts abound
There are what I would call the “GDPR purists,” whose position sounds something like “what part of forgotten do you not understand?” Clearly these people feel that backups and archives are included in the RTBF, and they really don’t care how much it would cost a company to comply. Most importantly, they’re certain any companies not agreeing with them will be out of compliance and subject to huge fines.
I also get comments that are completely opposite of that, where people are certain that backups are not (and will not be) included in RTBF requests. While my opinion is that these people are closer to what is likely to happen, they are just as dangerous as those who are certain they are wrong.
It’s all conjecture
The only thing I know for certain is that anyone who says they “know” the answer to this question is definitely wrong. Consider what happened when Chris Mellor contacted the ICO for his article. It does seem at first that their response seems to favor the “definitely included” folks. They said, “Merely because it may be considered ‘technically difficult’ to comply with some of its requirements does not mean organisations can ignore their obligations.”
The ICO knows that the RTBF is going to be hard (even without the backup part of the problem), and they want you to know that you can’t just say “erasing every reference to a given person is really hard” as a defense for not doing it. Don’t even think about trying that one, they’re saying. They need everyone to know they mean business.
But I also don’t think we’re talking about technically difficult; we’re talking technically impossible. After 25 years of experience in this field, I can easily say it is technically impossible to erase data from inside a structured database inside a backup without corrupting the backup. Almost all backups are image based, not record based. Even if you could identify the blocks pertaining to a given record inside a database, deleting those blocks would corrupt the rest of the backup. You literally cannot do that.
I also want to say that the idea that you would restore every copy of the database you have, delete the record in question, then re-backup the database is simply ludicrous. And you would do that every time you got such a request? That’s just nonsense. Besides the fact that the process would be so expensive that it would be cheaper to pay the fine, there’s a huge risk element to the process. That means that it places you in possible violation with another part of the GDPR — that you must be able to safely restore personal data that was deleted or corrupted. (A mistake in the process could corrupt all backups of every database.)
There is another proposed solution of converting your backups to archives by scanning & indexing them, and then deleting the backup tapes. This process sounds interesting until you learn it doesn’t solve the problem I keep bringing up – personal data stored inside an RDBMS. So it might help, but it’s not a full solution to the problem.
My opinion is that erasing all references to a given person in your production system – while also having a process in place to make sure said person never “resurrects” from the backup system – accomplishes the goal of RTBF without placing the backup data at risk or attempting to do the impossible. If Vegas had odds on this topic, that’s where I’d place my bet. I think the ICO is going to say that as long as data is not being used to support any current business decisions, and isn’t directly accessible to production systems, it can be excluded from the RTBF process. But you need to have a process to make sure it never comes back.
No one knows for sure, though, and that’s my point. Anyone who tries to tell you they know the answer for sure either has no idea what they’re talking about, is trying to sell you something, or both.
The ICO says they’re going to make it clearer soon
The ICO could have said “backups are included. Period.” (in their comment to Chris’ article.) They didn’t. They said “The key point is that organisations should be clear with individuals as to what will happen to their data when their erasure request is fulfilled, including in respect of both production environments and backup systems. We will be providing more information on backups and the right to erasure soon.”
I for one am looking forward to that guidance.
What do you think?
I’m really curious. Anyone else want to make a guess as to how this all shakes out?
What about this? Do you think that adopting a wait-and-see approach is risky? Should you spend millions now even if we’re not sure how this is going to end up?
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
In my continuing series of challenges with backup with the General Data Protection Regulation (GDPR), I thought I’d look at snapshots, and the unique problem they present. They may be even more problematic than traditional backups.
Note: This article is one in a series about GDPR. Here’s a list of articles so far:
In these previous posts I have defined what the GDPR is and how it applies to your company. I’ve also discussed whether or not backups are included when someone asks to be “forgotten” via a “right to be forgotten” request in the GDPR. As I discussed here, here, and here, I do not believe that companies are going to be able to delete such data from their backup systems, nor do I think that the GDPR is going to require them to do it. (But we just don’t know for sure until the ICO clarifies their position.)
The idea is two-fold. The first part is the backups aren’t being used to support any current decisions, nor are they accessible via standard IT systems and queries. The second part is that it’s simply not possible today to delete data from a backup like that.
But what about snapshots?
Someone asked about this on twitter. Snapshots are visible to regular IT systems and could be used to support current decisions. For example, NetApp snapshots appear under the ~snapshot subdirectory of the volume they are protecting. They may not be in the normal path of things, but a user could easily search and access them. It’s kind of the point of how snapshots work.
But guess what? Snapshots are read-only by design. You don’t want people to be able to delete data from your snapshots if you’re using them for backup. But since they’re accessible via a standard IT process, are they now considered primary data?
Out of curiosity, I reviewed the NetApp whitepaper on how they handle this issue, and it was unclear when it got to the part of actually forgetting the data. It mentioned that you couldn’t delete something if you didn’t know where it was, but it didn’t really go into how you would selectively delete something from a snapshot once you found it.
I’m not picking on NetApp here. I’ve always been a fan. I’m simply saying that – like backups – selectively deleting data from snapshots goes against their nature. And I’m pointing out that because they are accessible as regular IT data, they might not get the pass that I believe backups will get.
What is your plan for snapshots?
Have you discovered GDPR RTBF and how it relates to snapshots at your company? Has your storage vendor given you any guidance as to how to solve this problem? Is there a GDPR “back door” that you can selectively use to delete data from a snapshot? Do you want to use it, considering you could corrupt the thing you are using for backup?
I’d really love to hear from you on this.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
I’m doubling down on my opinion that the GDPR is not going to be able to force companies to “forget” people in their backups – especially personal data found inside an RDBMS or spreadsheet. Let me explain.
Disclaimer: I’m not a lawyer. I’m a data protection expert, not a legal expert. I’ve read the GDPR quite a bit and have consulted a lawyer about my thoughts, but this should not be considered a legal opinion. Just thinking out loud here.
Note: This article is one in a series about GDPR. Here’s a list of articles so far:
If a company is storing personal data on employees, customers, or prospects, that data will not be inside a discrete file for that customer. For example, Amazon does not have a single Excel spreadsheet or database called “Curtis Preston’s data.” There is a customer database, purchasing database, browsing database, etc, and my data is many rows within these databases.
This is the way it is at all companies around the world. Personal data is stored inside files and databases that also store other personal data. It’s built into most filesystems to be able to search the content of all files, and it’s definitely built into RDBMSs to search their content. Therefore, to comply with a GDPR data portability request or a RTBF request with online data should be relatively straightforward. Difficult, yes, but it’s simply a matter of identifying where personal data is stored and providing a process for searching it and expunging it if requested. Backups, however, are a whole different thing.
Backups just store what they’re given
This is important to understand, especially when we are talking database backups. With few exceptions, backup products are handed an object and some metadata about that object. They don’t control the content or format of the object, nor do they have any knowledge what’s inside it.
That object could be a spreadsheet, the latest RMAN stream of data from Oracle, or the results of a dump database command from SQL Server. It’s just an object with some metadata. The backup product might be told what type of object it is, such as an RMAN stream, so it can know how to process it. For example, it might deduplicate an Oracle RMAN stream different than a spreadsheet file.
But – and this is the important part – rarely does a backup product know anything about what’s inside that object, beyond what the metadata says. This is especially true of RDBMSs. A few products have done some extra effort to scan certain file types, such as spreadsheets, so they can provide “full text search” against those files. But, this is absolutely the exception, and I’m not aware of any that do that for relational databases. Nor am I sure they could even do that, given that the personal data is already packed.
In addition, the object that backup software is handed is often just a block or few that was changed in a file, VM, or database since the last time it was backed up. They might not even know where that block fits inside the whole, nor do they have the info to figure that out.
MS Office files have structure
Let’s assume we solve the above problem. The backup software would have to unpack the file, extract the personal data in question, then repack the file. For example, a Microsoft Office is actually a .ZIP file with some XML files inside of it. The backup software would have to unzip the .ZIP file, take the appropriate data out of the XML file, then rezip the file – all without making the file unreadable when it saves it again.
Relational databases have more structure
Relational databases have the concept of referential integrity. When the database is open, this is not a problem when you delete record X. It will automatically delete any references to record X so there aren’t any referential integrity problems. It will also update any indices that reference those references. Easy peasy.
That’s impossible to do when the database is a bunch of objects in a backup. First, it requires the backup software to know much more about the format of the file than it needed to know before. It then would need to be able to delete a record, any references to that record, and any indices referencing that record, and it would need to do that for every RDBMS it supports. I just don’t see this being a good idea.
Clean on restore
The first idea – as discussed in my last few blog posts – is for there to be a process to track any data that needs to be deleted (e.g. any records of Curtis Preston w/birthday of 01/01/01, at IP address 1.1.1.1, etc.), and then delete them on restore. Today this will need to be a manual process, but as has already been mentioned, it could be built into the backup software itself. It’s a monumental task, but it’s much easier to open, read, and write a file when it’s in a filesystem. And it’s much easier to run some SQL commands than it is to learn the internal structure of a database.
Just stop using your backups as archives!
This whole problem is caused by people keeping their backups far longer than they should. If you used backups for restores of data from the last, say, 90 days, and then used archive software for data older than that – this would not be a problem. Everything I mentioned above doesn’t pertain to archives. Archives by design are given information, not blobs of data.
They are given emails and records from a database, not a backup stream from the database. Yes, they are also given files like spreadsheets, but they are expected to parse those files and get the data inside. It’s part of the design. An archive systems is also given far fewer objects to parse, so it has time to do all that extra parsing and storing.
Maybe GDPR will be my friend and help me stop people from storing their backups for 10 years. I can dream.
What do you think?
I think this is a big problem, and I don’t see any solutions on the horizon. Does anyone else see this as any different? Your comments move the discussion forward. Anyone?
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.
Interested in Backups?
Do you like my blog? Subscribe to my email newsletter
or Twitter DM broadcast.
