- Host: Steve Stedman / Derrick Bovenkamp
- Topic: Transparent Data Encryption
- Recording Date: May 16th, 2025
- Need TDE help? https://stedman.us/talktde
- Listen on Spotify!
Stedman SQL Podcast Season 2 Episode 18 TDE
In this episode of the Stedman Solutions SQL Server Podcast, Steve Stedman and Derrick Bovenkamp explore Transparent Data Encryption (TDE) in SQL Server and its role in protecting sensitive data.
TDE encrypts data at rest, helping safeguard against unauthorized access to database files. It uses AES-256 encryption and is now available in SQL Server Standard Edition, making it more accessible than ever. However, TDE does not encrypt data in memory or during transmission—SSL or TLS is required for that layer of protection.
Steve and Derrick walk through how to set up TDE, including creating the master key, certificate, and database encryption key. They also explain why it’s essential to regularly back up these keys and certificates to ensure recoverability.
They discuss performance considerations, how TDE typically does not significantly impact database size or speed, and the importance of testing changes in a non-production environment before going live.
Watch Episode 18 Here
Podcast Transcript
Steve Stedman 00:15
Hey everyone, and welcome to this week’s Stedman SQL podcast. I’m your host, Steve Stedman, and today, Derrick is joining me as a co-host. This is season two, Episode 18, or our 31st episode. So far, we’re going to be talking about transparent data encryption on SQL Server. And this is one of those things that I think can be a little bit scary at first, and then once we get it in place, it’ll give you a sort of feeling of security. So, I think there have been so many data breaches that transparent data encryption is just so important to get it in place.
But first off, before we jump into that. Did you catch our May 1 2025, podcast episode on RCSI. This was the last episode that Derrick was on with me, and one of our most popular recent episodes on Read Committed Snapshot Isolation level, maybe this one will be as popular as that one was. All right. So the goals for this episode are really to kind of explain what TDE is and why it matters, and to walk through the setup, management and best practices and just share some real world tips and pitfalls, because we’ve done a lot of these recently.
Derrick Bovenkamp 01:34
I look forward to it. So I think let’s, let’s dig into kind of what TDE is, and we’ll, we’ll explain why it’s important, and you know what, what we use it for, and how it works. So, you know, first thing is TDE, or transparent data encryption is built into SQL Server, and it’s Microsoft’s way to hit that data at rest requirement that so many of us have in different industries and healthcare, banking, and you know, quite frankly, just about every industry now wants to have the data that’s written to disk and at rest encrypted. And TDE is how you do that with SQL Server.
Steve Stedman 02:19
And I think that a key thing about that the at rest that really protects against the unauthorized access to the physical files, meaning, without TDE, if someone gets a hold of an old backup file, they can restore it and have access to all your data. But with TDE, if you get access to a backup file, you can’t restore it without the right certificates, or the right pieces in place, the right keys in order to do that.
Derrick Bovenkamp 02:45
That’s correct, yep. And that’s an important, important thing to remember. And we’ll, we’ll touch on here as we get deeper into under the hood. But you need to have those things, or you cannot restore it, period. You know, there’s not a workaround to be able to restore it if you do not have those things.
Steve Stedman 03:05
One of the things that transparent data encryption, or TDE does not do, or I guess a couple of things it doesn’t do, is one, it doesn’t encrypt the data in memory, and it does not encrypt it during transmission, meaning, from the connection between the application server or your desktop and the SQL Server. TDE does not help with the encryption at that level. That’s SSL and TLS type settings to help with that, that’s a whole different conversation. Also, TDE is not a replacement for column level encryption or specific access controls, because anyone who can get to the database can see, can see the data in the database. It’s basically making sure the data is encrypted when it’s on disk, so that people can’t get access to that.
Derrick Bovenkamp 03:54
Yeah, and I think that’s really important to touch on, Steve. The name obviously there is transparent, so it’s transparent to the application and other things. So you can about do it in any situation where you’re using SQL server without worrying about applications or things that are connected to it. But it is important not to forget the things that you mentioned about, like what’s in transmission between the SQL Server in the application.
Steve Stedman 04:21
It just reminds me, just, I think was just yesterday or the day before, we were on a call with a client talking about this, Derrick, and one of the questions they ask is they said, I’m using this application. We’ll just call it application x, because it really doesn’t matter what application it is, but they’re using application X, and what will that application still work if we’re using transparent data encryption. Yeah, everything should work fine. The only thing is that there might be a slight performance difference there, but that’s usually pretty negligible at that point. So as far as how applications talk to the database, by turning transparent data encryption on, it doesn’t change anything at all with that. Yeah, so let’s talk a little bit about how this TDE architecture works, or under the hood. Derrick, what’s going on when we say we’re going to turn on Transparent Data Encryption?
Derrick Bovenkamp 05:10
That’s a good thing to touch base into. And you know, Microsoft actually has a great support article on this, and we can link out to it and actually show the data architecture image that they have, but, but at the very top, you have the Windows operating system level data protection API, and that’s going to encrypt your service master key that SQL server creates. It’s called a SQL Server instance level master key that that gets created at SQL Server Setup, and then you, from then on, create master database level, master key and back that up. And then that’s what actually protects your certificates and your database encryption keys. And those are the things that you actually need to keep you can kind of replace the stuff above, but you need to have that certificate that you’ve created and then the password that you use to back the certificate up. Because if you, if you don’t have that, you can’t get, can’t get that database restored, and it’s that certificate that protects the database encryption key which allows you to access the database. So kind of going from the database level back up, you’ve got the database is encrypted. The database encryption key is what allows you to access that a certificate encrypts that key. So that’s what allows you to access the key. The database master key, encrypts the certificate, the SQL Server instance key, encrypts the master key, and then your backup to the operating level data protection API. So that sounds really complex, but we’ll dig into it here. It’s, it’s, it’s not as hard as it sounds to set up.
Steve Stedman 06:59
So when we talk about what’s actually being encrypted, we talk about just turning TDE on through some of the steps you’ve talked about there. But what? What files are we actually seeing that are different once we turn TDE on?
Derrick Bovenkamp 07:15
The very first thing that happens when you turn TDE on is the temp database. The TempDB gets encrypted, and that’s the that’s the data files and the log files of TempDB that are encrypted. Then after that, you’re encrypting your user databases, and you can choose which ones to encrypt. You do not have to encrypt them all, but the ones that have the proprietary data or the data that you want to keep secure, those ones you’re encrypting the data file itself and the log file that goes with that database.
Steve Stedman 07:50
What about the backup files? Are those encrypted also?
Derrick Bovenkamp 07:55
Yes, they are. And that’s kind of the cool thing with TDE, is it’s automatically encrypting this backup files with the same encryption key that your database is encrypted as.
Steve Stedman 08:04
So it seems like TDE is really like a lock safe where only SQL Server has the key to open that up, Open that safe when we’re looking at your data files. So, yep, okay. Well, this is one of those things. When we talk about the keys, we’ll probably say it about six more times before we’re done with this episode, but we want to make sure we’re always backing up those certificates and private keys to avoid being locked out.
Derrick Bovenkamp 08:26
Yes, yeah, and then that year that you have them. So we’ll talk a little bit about that when we get to best practices. But yes, we’re going to hit that multiple times that you back those up. Another thing to touch base on is, is, how are those files encrypted? And SQL Server is using AES, the Advanced Encryption Standard, so that’s secure. And that, that’s one of those reasons why, that you can’t just, you know, crack that encryption and get access to it.
Steve Stedman 08:55
And you know, that seems to meet the requirements for any audit that we’ve been part of, whether it was healthcare, HIPAA, or financials, or even some Department of Defense related stuff that we’ve done in the past that they all seem to accept that AES as the de facto standard there.
Derrick Bovenkamp 09:14
Yeah, and I think it’s important for people to realize, you know, TDE used to be just for kind of those major institutions because it required enterprise SQL Server Enterprise, and now, now it doesn’t require enterprise. You can do it with your SQL Server Standard. So you know, used to be Steve, when I started working with you, very few customers were doing TDE, and now, almost every customer we talked to want they either are doing TDE or they want to do TDE.
Steve Stedman 09:44
Yeah, absolutely. Like, 10 years ago, everyone knew they needed to do encryption. And we’d talk to them and say, well, we want to do TDE. And say, Okay, well, you need to upgrade to Enterprise Edition of SQL Server. Oh, what’s that going to cost? Oh, well, that’s too much money. Say, Okay, well, maybe we won’t do TDE yet. And then in SQL Server 2019 that’s when Microsoft changed the rules on or changed the offering as to what’s included in and in it. And TD is included on 2019 with all versions where, prior to 2019 it was only in the enterprise edition. So a lot of people are finding that it’s easier to make that upgrade to 2019 than it is to shell out extra money to upgrade to Enterprise Edition. Plus, I mean, given this 2025 right now, if you’re on 2019 you should really be thinking about up. Or if you’re older than 2019 on your SQL Server version, you should probably be thinking about upgrading sometime soon.
Derrick Bovenkamp 10:42
Yeah, for sure. The other limitation that used to be out there, and it did affect some customers, is it, is it used to be that your backups were the same size of the database. You didn’t get any compression on those and then after that, you could get compression, but you had to do tweaks to get the best kind of compression. And now you know, 2019 and newer, especially 2022 Microsoft is pretty much resolved that where your backup still get really great compression with TDE. And that’s because what happens is it reads the data off the disk, it unencrypts, it compresses it, and then re encrypts it as it’s writing it to the data file. And yes, it does have a little bit of a performance hit on the SQL Server, but all the new Intel and AMD processors have acceleration, where they can do AES encryption really fast. So unless somebody is just at the very limits of what their SQL Server can do. Nobody usually notices any problem with PD.
Steve Stedman 11:43
And you know, with that too, Derrick, I mean, most of the time your IO is your bottleneck on that, not your CPU on doing the work to do the encryption. So usually, what we see is that what you save in the IO by having that compression work may be making up for some of the extra load that’s being put on your CPU by doing the encryption itself, so and the compression itself. Should we talk a little bit about what it takes to set up? If I’m gonna sit down and I’ve got a database that I want to secure, what do I need to know to go and make that happen right now?
Derrick Bovenkamp 12:22
The very first thing that you want to do is you want to kind of go see if you have TDE in place. And we have, we have some scripts that will put up on our website that shows you how you can see if TDE is in place. But next thing you want to do is create that master key. And once you’ve created the master key, then you’ll back that up and make sure that you keep that password. Now, usually don’t you need that master key ever again, but it is best practice to back it up. So we’ll create the master key, and then we’ll move on to what I call step two. And step two is actually the certificate setup. So in step two, you will create a certificate, give it a name. You can also give it a subject, which is like a description. But there’s a lot of the times this is where you have to choose, like, how your how you’re going to manage your certificates. Are you going to have one certificate for all the SQL servers in the company? Are you going to have a certificate for every server? Are you going to have a certificate for every database? Or the last one that we see the most common is they’ll kind of do by database type. So we’ll have customers that, hey, certain databases with this application get this key, or, sorry, this certificate, certain databases of another application get another certificate.
Steve Stedman 13:48
But you have to think about that. Yeah, so with that certificate, then Derrick, I mean, one of, one of the biggest pains I’ve ever dealt with is going out to a certificate authority and purchasing certificates. Does that? Do we have to do any of that with this process?
Derrick Bovenkamp 14:00
You do not, you can actually, you, you actually just create it right on the SQL Server.
Steve Stedman 14:04
Okay, so we don’t need to be going to purchase a certificate anywhere. We’re just using SQL Server created certificates.
Derrick Bovenkamp 14:13
So yes, you use a SQL Server created certificate, and after you create that certificate, then you back up the certificate, and you’ll get three files. When you back it up, you’ll get this, the certificate itself. I usually call it, it’s a dot, sir, C, E, R, and then you’ll get the key that goes with it, dot key file, and then the password that you use to encrypt that key and you cannot lose so that’s three things right there. That’s the certificate, the key and the password. You cannot lose any one of any one of those, or you cannot restore your databases to a different SQL Server.
Steve Stedman 14:50
Yep. Okay, so we’re cruising through this process. We’ve created that master key, we’ve created a certificate, and then what? And we’ve just backed up that certificate. Then what are we doing next?
Derrick Bovenkamp 15:01
Next thing that we want to do is we’re going to create a database encryption key, and that’s what that does, is that associates the certificate with the database. And that’s where you choose your algorithm. I usually do AES, 256 256 bit AES. So you choose your algorithm and you you create that database key that associates it. Now, one thing to remember here and we recently, I guess it wasn’t recently. Time goes by really quick, but we did have a customer kind of bit by this is once that key is created, even though TDE is not enabled, your backups are kind of encrypted, and you need that certificate to restore those backups. So we create the database encryption key, and then we actually turn encryption on in that database, and when, when you turn encryption on, SQL will slowly go through, read, read the files off the desk, rewrite them back to the disk as encrypted. And that can take anywhere between a couple of seconds and hours. You know, we’ve, we’ve seen tech customers, it’ll take overnight to do the encryption.
Steve Stedman 16:17
Okay? So then that enabling it, and if we’re waiting overnight for that to happen, does that really cause any problem on the system while we’re waiting for that to finish encrypting?
Derrick Bovenkamp 16:29
You know, it does not the database still works. It’s still active. You are you do have an increased IO load on the system, because it has to read all that off a disk and write it back to disk. So you do have increased IO load. So I usually do it at a time of low activity, which is, you know, usually at night, but it the database still works. It just maybe it’s a little bit slower.
Steve Stedman 16:51
So just to kind of recap that, then, I mean, you’re going to go, create the master key, create the certificate, back up the certificate, create the database encryption key, enable TDE, and then wait for it to finish encrypting depending on the size of database, that may take a little while, like overnight.
Derrick Bovenkamp 17:09
Yeah, and this is where you don’t want to get too greedy, do one database at a time, and don’t do them all at a time, because you’re going to really increase that IO load on your server if you’re trying to do them all at once, good
Steve Stedman 17:20
point. And who knows. I mean, you do one and you find out that you’ve got plenty IO and it fully gets encrypted in an hour. Maybe you try two of them or three of them and see how it goes after that. So an important thing here, too is you want to make sure you’re going to test that restore process on a non production server or on a different server, making sure that you’ve got all the right bits and pieces so that when you do that restore, you know it’s going to work. You don’t ever want that first, first restore of a TDE database to be an emergency restore. You want to make sure you do it when you’ve got time to make sure you’ve got everything in place.
Derrick Bovenkamp 17:50
And that’s really important, Steve, you hit on a very important part that I want to expand on. So don’t just test a restore back to the same SQL Server that did the backup, because that SQL Server has the certificate on there. So it’s just going to restore, like every other restore of an unencrypted database. You want to take it, take it to a server that is either never had TDE on it, or a different server that doesn’t have that certificate. So you can prove that you can restore the certificate and then restore the database.
Steve Stedman 18:23
Yep, definitely important points there. So I think, I mean, if I was going to do this, I mean, would I jump in and start with my production system, or would I go, would it be worth going and doing it in a dev or test environment?
Derrick Bovenkamp 18:36
I definitely go do it in your dev and test environment first, make sure you’re comfortable with it before you before you do it to prod and you know, Microsoft has some pretty good documentation out there, but, you know, that’s where I kind of want to plug our services. We’ve done this to almost every customer that we work with. We either help them maintain their TDE or we help them set up, t, d, e. So we’ve got a set of scripts where we can go do this very quickly. We’ve done it so many times that we’ve got everything where you just have to plug in the names and the values and the passwords and this, you know, we can, we can help you set that up very quickly. And, you know, remove that stress of having to figure it out yourself.
Steve Stedman 19:22
And we can also give you that peace of mind that it’s been done correctly. Because if it’s your first time ever doing it, I know I didn’t really believe it the first time I ever did it, to know that it was really, really working correctly, but we know how to check it and we know how to monitor it, which kind of leads us into that whole managing and monitoring going forward on, like, a day to day basis. Let’s say we turn this on and then two weeks from now, or two months from now, is there anything different that we need to deal with, that we need to check in or follow up with on this?
Derrick Bovenkamp 19:53
You know, one of the things that we like to do, and we do in our monitoring, is we monitor when that. That certificate was last backed up. And we actually recommend kind of semi regular backups of the certificate. And that’s just because, you know, things do happen. People lose those certificates. People lose those passwords that they use to back up their certificate with. So just like you back up your database regularly. We read back up the certificate regularly too, just to make sure that you have it, if you need to restore it, or when you need to restore it, is actually the better part of that.
Steve Stedman 20:32
Yeah, and that’s one of those things that we seem to continuously bring up a quarter after quarter with our managed service customers, is making sure, have you got the A recent backup of those, of those keys and certificates so that you can get them you can do the restore if you have to, and it’s just a good thing to check regularly. And that’s why practicing restores to somewhere besides your primary SQL server are a good place to do it.
Derrick Bovenkamp 20:57
Yeah, a couple other things I want to touch base on there. Microsoft does have SQL Server does have the ability that you could rotate the certificates. So that is important. If you need to rotate the certificate, you can rotate it to a new certificate again. That does take a little bit of time, because it’s got to read it and write it back to desk, but you can rotate it without downtime. It’s just going to be a little extra load on the system. You also these certificates do expire. Now, the good news is, your database doesn’t stop working. And you can use this. You can use a expired database, and, you know, that’s, that’s kind of like our expired certificate, and that’s kind of the old joke of you know, the shoemakers child, you know, there’s this my personal SQL Server. I have expired certificates, and you can use them, and they work fine, but you also have the ability to rotate those out and keep one that’s not expired, especially if your security policy dictates that you rotate certificates. And there are some people that we work with it. They do have policies that those certificates are rotated at a regular basis.
Steve Stedman 22:05
Yeah, that’s a great point. And you know, a use case for rotating certificates was a few years ago. I was working for a company where we would regularly be taking the TD encrypted production database and copying it over to the dev environment, and then once it got copied over to the dev environment, there were a bunch of things that went through and got sanitized in there, like social security numbers and whatnot. But what we did when we did that is we, after we brought it down, restored it with the right certificates. We then swapped the certificates out, or rotated them so that just because somebody had access to the dev environment at that point, it didn’t mean they had access to the same keys that we had in production, so we made sure that we cycled that or rotated it so that it would end up with a different key in the development environment.
Derrick Bovenkamp 22:53
And another example is we have another customer that we worked with that sometimes has to send backups to another vendor, and we usually help them rotate it after they’ve sent that backup, because they’ll send that backup the certificate and the password to restore it, so that vendor can do their restore of that database. And then after that happens, we’ll usually help them rotate their certificates so that vendor doesn’t have access.
Steve Stedman 23:21
Rotate it on the production server, sort of the opposite of what I was doing, to rotate it on the development server that way. You know, you’ve got a fresh one there every time, too. Yeah, I like that.
Derrick Bovenkamp 23:30
Steve, I think you have a horror story of somebody who didn’t back up their certificate.
Steve Stedman 23:36
I think that’s one of those that we get a lot of calls from prospective clients. And I want to point this out. This was not a client that we managed regularly, but just like when we deal with corruption or ransomware, there’s always somebody that we get a call from that is in a world of hurt that we cannot help. And yeah, client, they called up. They needed help restoring their backups. They’d turned on TDE some time ago, and they had never backed up any of their certificates. So they were at the point that, after commiserating with them for maybe about a half hour, trying to find out what they had access to and what they didn’t have. I just had to share with them that they didn’t have any way to get it back. Their data was just gone. And I think that that’s one of those things that as first time using TDE, yeah, people forget, and we like to do everything we can to make sure that we don’t forget. And by testing those restore procedures that will make help you prove out that you’ve got all the right pieces you need if you’re restoring to another server. So on that, what about overall performance impact? I mean, am I going to be concerned that maybe I don’t have enough CPU or IO to turn on TDE? Derrick?
Derrick Bovenkamp 24:59
You know, it is something to think about, I would say in the great majority of the cases, No, you shouldn’t be concerned. But if your SQL Server is already really slow or old, maybe you have upgraded to 2019, or newer, but it’s on really old hardware, or you running into performance issues already, it is something to think about, like, hey, let’s look at that and make sure that it we’re not going to make the problem worse. Now, in most cases, no, but it is something to just keep in the back of your mind.
Steve Stedman 25:32
And then, how about some of the common like real world use cases of type of environments like HIPAA or PCI or things like that. I mean, any, any good examples you want to share on that?
Derrick Bovenkamp 25:45
You know, HIPAA is a big one. I work a lot in the healthcare industry, and we work with all the healthcare customers, so data at rest is important for everyone. And again, that’s where it used to be different. It used to be kind of healthcare and banking, and now everybody is very concerned about data at rest, encryption and making sure, hey, if somebody gets a hold of this backup file, can they restore it so you any data that is sensitive you want to make sure that you are encrypting it with TDE, that could Be a cloud hosted SQL Server, even an on prem hosted SQL Server, if somebody got a control of that or not control the SQL Server, but control of those files, you want to make sure that they can’t read them.
Steve Stedman 26:32
So let’s say we’ve got, I guess it doesn’t matter if it’s a cloud based or on prem, but let’s say we’re sending our backups over to like Azure Blob Storage, and do I need to worry about anything differently if I’m sending those backups off site somewhere like that.
Derrick Bovenkamp 26:47
You know they are encrypted with that same AES encryption. So as long as you’re not storing the certificate, the key, the password, all with the database, you’re okay. I have seen people do that, and that’s like exactly what you don’t want to do is now you’ve stored everything with the backup. So yes, it’s encrypted, but anybody can grab all of those and decrypt it. So you want to make sure again, and I don’t know how many times we can hammer this is that you have all of those things, but just not stored all together.
Steve Stedman 27:21
Just like your car and your car keys. You want to make sure that you well. Now it’s probably just a key fob these days, but you’ve got your car keys, and if you leave your car keys in your car, and you leave your car unlocked on the street, you should, probably shouldn’t be too surprised if it gets stolen. But if you bring your car keys in your house, and even if your car is parked on the street at night, probably not going to get stolen.
Derrick Bovenkamp 27:43
Yeah, it’s good analogy, Steve.
Steve Stedman 27:45
I think there’s a lot of other security measures that people consider too, and I think it’s a best practice to consider things like the always encrypted, which is really encrypting data when it’s being transferred over the connection between servers, and then row level security is a whole different thing as well. And the I mean, really, there’s no one of these that is the fix for everything. And I think the key is coming up with the right thing for what you need for your environment, and it’s usually a combination of one or more. But the other thing is, you want to make sure you document that certificate management process. Document it in a way that if somebody else is reading those documents, that they’re able to go and do that restore what happens if you’re on a flight halfway across the world to go on vacation in Fiji one day? And DBAs do get vacations once in a while, but usually they don’t go smoothly because they need help. But document it in a way that if somebody else has to do it while you’re in Fiji, that they’re able to succeed at that rather than having to call and ruin your vacation. And then you want to do a regular audit too, of who has access to those certificates and the keys, because, I mean, just like who has a key to your house or a key to your car, I mean, you want to make sure that you haven’t left it somewhere at a restaurant or whatever. Restaurant or whatever, I mean, with car keys. That is not your certificates here, but just you want to keep an eye on it. Know who has access to what, and that’s where. If you think maybe there’s too many people that have access to it, maybe you cycle the or rotate the keys there, so you start out with some fresh ones.
Derrick Bovenkamp 29:19
yeah, that’s a really good point Steve is to think about, don’t just think about TDE as a checkbox. So you’re not doing this to check off a requirement that your insurance company has, or you have to be HIPAA or PCI. Think about it as part. It’s one tool in the toolbox, so you want to encrypt that data and rest. Okay, great. Make sure you know who has access to the keys. Like you said, make sure you know who has access to the server. Make sure that’s limited down. Give people the least access that they actually need to do their job as part of the total security structure. You. And don’t just treat it as, oh, I have TDE on. I don’t have to think about anything else.
Steve Stedman 30:04
Okay, so I think is there anything else before we kind of start to wrap it up here that we want to cover? Derrick, I think we’ve gone through a lot. No, I don’t have anything else right now. So if we could summarize some key takeaways here, what would you how would you summarize things?
Derrick Bovenkamp 30:22
yeah, TDE is great. It is definitely something that you should look at setting up once you get the hang of it. It is fairly straightforward, but making sure that you have managed those certificates and those backups and the passwords that go with them is absolutely critical. I think we’ve said it about 10 times during this presentation, so that’s very important. And in the smartest thing of all, always, always tested a non production environment first. Don’t just go to your most critical application and just turn it on.
Steve Stedman 30:56
So at this point, I think I’d like to ask the question to our listeners that if you’re not using TDE, why are you not using it? And there’s a lot of different answers to that. It might be that you’re on an older version of SQL Server, you need to upgrade first, or maybe you just didn’t know what it takes to get it going. Or maybe you need some help. Can help in those cases. But it’s one of those things that since SQL Server 2019 there really is almost no reason to not use it. It’s just, it’s such an important thing. Last week’s episode, we talked about ransomware. And part of the thing when people get hit with ransomware is they’ve got to recover, of course, but you never quite know what those people stole when they when they were in your system, encrypting things. And if you know it’s all encrypted at rest, you know that even if those ransomware people got a hold of your backup or a data file, that they can’t access it without those keys. Yep, super important. So one of the questions that comes up a lot on this is, what is the impact on of TDE, on the database size? I mean, am I going to expect that I see a drastic change with the database size?
Derrick Bovenkamp 32:05
That’s not what I’ve seen usually. Usually it’s right around the same size. And the backups as well. Again, that used to be a real issue with backups is we actually had a customer that was running an older version of SQL Server, and their backups were huge because it was the full size of the database. And then we’re getting in compression, and then we upgraded them to the latest version, and the backups had really good compression after that.
Steve Stedman 32:32
Yep, yep. You know, whenever anybody first talks starts talking about or asking us about TDE, that’s where I always want to talk about backups and make sure they know that on older versions of SQL Server, you’re going to have bigger backups, and you need the newer versions to get around that. So yep, all right, well, I think that kind of wraps up the whole TDE conversation. Thanks for coming on the podcast today, Derrick, I appreciate it.
Derrick Bovenkamp 32:58
Yeah. Thank you everybody for listening. Great time talking with you about TDE today. Steve, I know I’ve kind of become our resident expert on TDE and set it up for any interested customer. So you know, if you’re, if you’re interested in getting us, getting our help installing TDE, you know, please reach out to us and we’d be happy to work with you.
Steve Stedman 33:18
Absolutely. And if you do need help, just visit Stedmansolutions.com and from there, you can schedule a free 30 minute consult to talk to one of us about what we can do to help out there. So come back and join us next time, next time, we’re going to be talking about how to treat your SQL server right without a full time DBA and some things that you can do to put yourself in a better position on that, and remember that all of our episodes are available on YouTube and on Spotify. And the shortened URLs, they don’t seem very short, but Stedman.us/podcastYouTube will get you to the YouTube channel. Stedman.us/podcastSpotify will get you to our Spotify account. And if you just go to Stedmansolutions.com and click on the podcast link, you can see all of the episodes that we’ve done over the last couple of years.
So I think that wraps things up. Thanks for listening and thanks for joining me today. Derrick, have a great day. Thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it, and if you want more information, more videos like this, click the subscribe button and hit the bell icon so that you can get notified of future videos that we create.