- Host: Steve Stedman / Shannon Lindsay
- Topic: Testing Restores
- Listen on Spotify!
- Recording Date: June 10, 2025
Stedman SQL Podcast Season 2 Episode 20 Testing Restores
Steve Stedman and Shannon Lindsay discuss the importance of testing SQL Server backups weekly. Steve emphasizes the risks of untested backups, including potential data loss and longer restore times. They highlight the need for consistent testing to ensure recoverability and compliance with regulations like HIPAA and GDPR. Steve shares a case study where a 1.5 TB database was restored due to endpoint protection issues, avoiding significant downtime. They recommend automating restore processes, using tools like Database Health Monitor, and maintaining a documented runbook. Shannon suggests consulting Stedman Solutions for expert guidance on backup and recovery strategies.
Podcast Transcript
Steve Stedman 00:00
Hey everyone, and welcome to this week’s episode of The Stedman SQL Server podcast. This week, we’re going to be talking about why you should be testing your restores of your backups weekly, and how to do it. I’m Steve Stedman, host of the podcast, founder of Stedman solutions and creator of Database Health Monitor, and I do a whole lot of SQL Server consulting.
Shannon Lindsay 00:39
I’m Shannon Lindsay, co host of the Stedman SQL podcast, here to just kind of ask the right questions.
Steve Stedman 00:47
I always appreciate those questions. So this is season two, Episode 20 or overall, our 32nd episode since we started the podcast last year.
Shannon Lindsay 00:59
Yeah, and especially with summer coming up, we’re gonna not do it every week, but we’ll do every other week podcast episodes, live streaming. You can watch those on YouTube or on Spotify, and we’ve got a couple short links for those of stedman.us/podcast/YouTube and stedman.us/podcastSpotify.
Steve Stedman 01:26
All right, well, let’s kind of jump into it a little bit. I mean, one of the things that I have the hardest time with is when somebody calls me possible new customer, they need help, and then I find out there’s nothing that I can do to help, and they want help, but they don’t have the right stuff to get help. And one of those things, one of those things that puts me in that position, is when something has gone bad with their database, but they don’t actually have any backups. And sometimes they people think they have backups, and we look and we find out they don’t. Other times they know they don’t have backups, and they’ve just been winging it, you know, so and when that happens, I don’t know that’s one of the more challenging parts of my job is to have to tell someone that it’s not that I can’t fix it, it’s that nobody can fix it because you don’t have a backup available, and so let’s jump into the topic. So with the topic being testing your restores weekly, and how to do it, this is important. And one of the things that I’ve always talked about, and it used to be that I’ve got the class, backup and recovery class that I built, and I originally called it the backup class, but then I realized it was more about restoring or recovering than it ever was about backups. And the key here is not whether you ran backups, because lots of people think they’ve run backups, but knowing that you can actually restore them.
Shannon Lindsay 03:00
What do you think are some of the highest risks of not testing those backups?
Steve Stedman 03:04
Well, I think the biggest risk is not knowing that they’re going to work. I mean, until you’ve actually tried it and know that you can recover your backups, you don’t really know that you’re gonna be able to get anything out of them. It might just be some big file there that doesn’t give you anything good. The other thing that might be is you might find out that when you do restore those that it takes a lot longer to restore than what you think. I mean, what if your expectation is you can be able to restore your backups in like, 30 minutes in any crisis, but really it turns out to be six hours. Well, one of the more uncomfortable positions to be in is when you have a manager looking over your shoulder saying, When is it going to be done? And you’re doing that restore of the backup, and you’re just waiting for it to finish. So weekly testing is really a game changer in order to be able to go through and confirm that your backups are good. I think with this, this is one of those things that we do with all of our clients, and we want to make sure that when our clients have an issue, that we can always restore from backup.
And the only way to do that for certain is to test those earlier today, I was on a call with one of our monthly managed service clients, and we were working through that restore process, and we took two databases off of their production environment, and we did a quick restore into their dev environment and confirmed that, yes, absolutely everything can get there. And it did work correctly. So yeah, these are important things to do on to kind of the why the weekly Restore is critical, and it’s one of those things that I always look at, how much can you afford to lose, and how much of or how would your business be impacted if you lost that? So for instance, we do a lot of database corruption repair and some of the and I’m not afraid to admit this, but I’ll say some. The most expensive work we ever do. Most expensive for the client is corruption repair on a database that doesn’t have good backups. Anytime someone comes along with a corrupt database and they’ve got really good backups, that significantly cuts the cost, because there’s a lot more options, or a lot more ways to get those databases back. But yeah, I think that we’ve seen where good backups can completely get you around a corrupt a corrupt database and avoid a costly repair.
Shannon Lindsay 05:30
Yeah, can untested backups fail?
Steve Stedman 05:35
Oh, yeah, absolutely. And I think that I and I’ve seen this where, let’s say you’re backing up to somewhere in the network and there’s something wrong. And I’ve seen it happen with endpoint protection, where the endpoint protection is actually scanning all of the IO and making changes to things, and I’ve seen it where backups have been corrupted because of that, things like incomplete transaction logs. Well, more specifically, not incomplete, but missing where, let’s say you’ve got to replay 15 transaction logs get you up to a point in time. Well, if one of those transaction logs is missing in the middle, you might think you’re gonna be able to get them all back, but you’re not gonna be able to get back past that point in time where that transaction log is missing from or bad backup settings, like I saw one. Gosh, these poor people, they thought they had all their backups configured correctly, but all they had actually configured was to backup system databases so their master and their model and their MSDB databases were being backed up, but none of their actual user databases were being backed up. They had, they checked on the SQL Server Agent, they saw it was being backed up all the time or regularly, but they did not actually have any backups of their own data. Yeah, untested backups can be a big issue.
Shannon Lindsay 06:53
Are there compliance requirements for some companies?
Steve Stedman 06:58
Yep, definitely. So if you’re in a position of where you are, HIPAA, GDPR, sometimes it may be like DoD relationships or other finance related things, where somebody’s auditing your company to determine Are you worthy of working with them, kind of, I mean, that’s one way of looking at it. And one of the things that they ask, and I did go through a survey on one of these recently as well, with a partner, was, how often do you back up and how often do you test the restoring of those backups? And a lot of people may answer that, but may not actually know how often they test it. So testing those restores is the most important part of it so and the thing is, oh, I was gonna say, and the thing is, data is changing so frequently. And I mean, if you’ve got a system that the data hasn’t changed in the last six months, well, probably don’t need to do weekly testing. But if you have a dynamic system with a lot of stuff going on, customer data, orders, payroll data, whatever it may be. Yeah, you probably want to you test that as often as possible to reduce that risk.
Shannon Lindsay 08:05
What are some of the consequences of skipping the restore testing?
Steve Stedman 08:09
Well, it really comes back to and I shared this on last week’s podcast, a story from a friend that would always ask the question of, what’s the worst thing that could possibly happen, and can you live with that? And in this case, the worst thing that could possibly happen is your SQL server crash, you’re unable to recover it, and you lose 100% of your data. Okay, that’s where we ask the question of, well, what would be the financial impact of that. Some places, I don’t know. Some systems, it might be no big deal. It’s not that important of a system. But other things, it might be really important. What’s the financial impact from lost revenue, if this database is something that’s used for order processing, or what’s the loss of customer trust if you lose that data? Or what are the penalties for non compliance if you have to have so many years of backup history for legal purposes? The other thing is operational impacts. What? What happens if your workforce shows up to do their jobs and nobody’s able to log into the system that they need to use to get their job done? Today, you’ve got a bunch of employees sitting there that are expecting a paycheck, but they’re not actually able to do any work for you because their database isn’t working, and the other is just reputation damage. I mean, how bad will this look to you, your employees, your customers, your partners, when you have loss of data with no way to recover. So one of the key things to remember here is that my belief is a backup really isn’t a backup until you’ve tested out the Restore.
Shannon Lindsay 09:53
Yeah, and that that just helps build confidence in your disaster recovery plan, too. Right?
Steve Stedman 09:59
Absolutely. Think if your disaster recovery plan involves a step that says, figure out how to restore backups for the first time ever. I know you wouldn’t phrase it that way, but if it effectively, it ends up meaning that you’re going to have a very different disaster recovery plan than if it effectively is saying, do that same restore that you’ve tested 15 times over the last 15 months, and that you know worked every time you tried it, or 15 times over the last 15 weeks. So it’s one of those things that they say practice makes perfect. And I know the more and more I practice, even having done this for 30 years, the more and more I practice, the more the better I get at it, and the more I know that I would be able to do a reliable backup and restore in that environment.
Shannon Lindsay 10:47
Now, I’d say kind of a next topic would be like the common challenges in restore testing. You know, sometimes there might be some resource or time constraints?
Steve Stedman 11:02
Oh yeah, absolutely so with that. I mean, if I’m telling you, you need to go test your backups at least once a week, and you’re part of a small business or a team or an organization, most people I know don’t have time just sitting around in their hands where they’re gonna say, I’ve got plenty of time to go do a restore this week and test it. What we need to figure out is, how do we test that in a way that you don’t have to actually spend an hour doing that restore? Maybe you do it the first time, or maybe you do it the first three or four times, but then get it to a point that it’s scripted and automated, so it doesn’t take you an hour or two to do that restore, so it happens quickly. I think that the time constraints, it’s one of those things that you need to invest to make sure you’re good at it. But you don’t need to do it every single week. If you have it scripted and built it in a way that you know that those backups are being restored weekly and tested. There’s this belief that backups are enough.
And I don’t know how many times I’ve tried to work with people who had a system failure, who thought, who thought they had backups, but they’d never, ever tried to restore them, and they’ve never will restore them because they didn’t really have backups. Another technical challenge on that is the lack of a dedicated test environment. I mean, if everybody for their SQL Server they’re working on had a copy of it that was their test environment that they could do restores to all day long. Well, that’s a lot easier than if you don’t have that. But even on small environments where somebody only has a single SQL Server, we’ve been able to do restores where we scripted and maybe once a week, or every two weeks, it does an automated restore of one of those production databases, but changing the name and changing the files at the time it does the restore so that it can be used and tested and confirmed good. Also. The other thing is the complexity of restoring really large databases.
Gosh, one of the, one of the things that drives me crazy is when somebody says, well, our system is too big. We don’t have enough room to restore this database anywhere. Well, the simple fact of that is, if you don’t have room to restore the database as a test, you’re not going to have room to restore a copy of that database when disaster strikes, and you’re going to have a lot less options for what you can actually do. A lot of the times when you’re doing a restore, you’re not restoring it over the existing database. You’re restoring a copy of it so that you can use it. So I think this is even more important, if you’re dealing with large databases, to prove that you’ve got enough space to do that restore if you need it. And then the other thing is, there’s a lot of difficulty in troubleshooting the restores if they fail without really understanding exactly why they fail. I think a big part of this too can come down to human error. And human error, I think, really comes down to making mistakes. And if I’m going to make a mistake, I would rather make that mistake when there’s no crisis, when I’m doing a test run, rather than when everything’s on the line. So one of the things that comes up is practicing the manual restore process so that during that high pressure recovery scenario, scenario, you can be ready to do it, but the flip side of it is also knowing it enough to be able to script it so that you can test it regularly. So let’s jump into how to test the restorers weekly. Kind of a step by step guide.
Shannon Lindsay 14:37
Yeah, I would say probably step one, is planning your testing schedule.
Steve Stedman 14:42
Definitely, because without a good plan, how are you going to know if you’ve achieved what you’re looking for? So pick a time of when you’re going to do this. It could be something scheduled every Sunday night, for instance, if that’s a slow time on your system, or maybe every Monday morning, if it’s something you have to do when you’re in the office. Process, and then figure out what you want to do to get it done regularly, to ensure that consistency.
Shannon Lindsay 15:06
Could you create a documented book to make it so that you could standardize the process and train team members from you know that point on?
Steve Stedman 15:18
Oh, yeah. And the way I like to do that is to have two things in that runbook. One is the steps of what you do, so that if this happens and it’s three o’clock in the morning and you’re a little bit tired and not quite awake, you’ve got a standard list of steps to follow, so you know you’re not missing anything. But the other thing is that run book gives you all the steps to do it that you can use it to train your team members. And then additionally, to track when we do that, how long it takes to do those restores, and what kind of problems we ran into, so we can help address those in the future.
Shannon Lindsay 15:54
And then step two would be set up a test environment.
Steve Stedman 15:58
And the test environment, this is something that’s different for everyone. I mean, we have one client that has a single RDS SQL Server, and their test environment is just to restore a copy onto that same SQL Server. There’s other people we work with that they have a development and a test environment, as well as developer desktops and then their production environment. And the right test environment for them is we first do a restore to their testing server, and then we do a restore to their development server. But there’s a lot of options out there. I mean, you can go and spin up a cloud based virtual machine on Azure or AWS, pretty cost effectively, for a short amount of time. Do the Restore. Do some testing there, and then get rid of that server after you know that the Restore is good.
Shannon Lindsay 16:47
Yeah, there is low cost options for, you know, smaller businesses and stuff?
Steve Stedman 16:53
Oh, yeah, definitely. And I think that one of them is people get caught up a lot on your SQL server licensing. And if you have a production server, you’re usually paid by core licensing. But if you have a non production server that you’re going to go test your restores on, like a development box, you don’t have to pay for standard or Enterprise Edition. You can go with the Developer Edition, which is a free version of SQL Server that could run on as long as it’s big enough to hold your database. It doesn’t have to be well performing as a place to regularly test your backups, too.
Shannon Lindsay 17:24
And then step three would be to perform the Restore.
Steve Stedman 17:29
Yep, and this is one of those things that to perform the Restore, you want to make sure you have as much of this scripted as possible, so you don’t have to be making typos or mistakes every time you do it. You want to decide when you’re doing it, are you going to be restoring a full backup or a full backup plus differentials or a full backup plus transaction differentials and transaction logs for a point in time? Recovery. I think it’s important to do all of these. I know talking with Derrick, one of our team members, when he does a restore like this, he always likes to do a transaction log backup for a point in time, recovery, even if it’s just going to a development or test environment. So if our client said, Can you give us a restore to our test environment from whatever time, usually they say any time in the last 24 hours, what we’ll do is we’ll just pick a time that’s going to force us to do a full backup, a full restore, differential restore and transaction log restores, so they can make sure that that whole process is tested for that client.
Shannon Lindsay 18:27
Step four would be verify that the Restore, you know, worked correctly.
Steve Stedman 18:32
Yeah. So there’s a number of ways to verify the Restore. The first and obvious way is just to check and see, well, the did the database get there? Okay, that’s the first one. If you don’t have any database, you’re in a world of hurt, but if the database got database got there, then there’s things to do to verify Well, is it the right point in time database? And the way I usually check that is, I’ll go find some table that has a lot of transactions or a lot of activity in it, and make sure that there are up to that point in time transactions. There maybe some table that has a date timestamp on it, so you can easily check when the last time something was updated or inserted on it. But the biggest thing is not just to restore it, but to know that it restored and came back clean without corruption. So you’d want to do the restore and then run DBCC checkdb to go and scan that entire database and make sure that it’s not corrupt. And oftentimes that checkdb may take more time than the actual restore itself. And then, in a perfect world, you could take a test application server and point it at that database and make sure things work. But the reality is, most of the time, you don’t have that option, just being able to check to make sure the database is there. There’s recent transactions in it, and the check DB Ran is usually good enough.
Shannon Lindsay 19:45
And step five would be automate and monitor from there on out.
Steve Stedman 19:49
And I mean, one of the things that I truly hate is just repetitive tasks. Even if the client says we want to pay you for this repetitive task, I just don’t like doing those. So I always like to try and figure out, how can we take that and script it and automate it so that I’m not there clicking through dialog after dialog after dialog to be testing all of this, to put it together, get it so it’s fully scripted. And we have a script that we use internally for this that you just give it a database name, you give it a directory and you give it a new name, and it’ll go find the last backup for that database, the freshest backup, and it’ll restore it under a new name and give you a test database or whatever to work off of at that point. That’s one of those that we could put on a SQL Server Agent job and even schedule it so once a week it would run, it would do that restore. Once it’s done, we then run check DB and maybe have a couple of queries that run against it to make sure it looks good. Automation is the way to go there, because I don’t want to be spending my life continually doing this.
Shannon Lindsay 20:50
Yeah, and, I mean, one of the tools that we offer is database health monitor, and there is a free version, but it’s it works so well to track your backup success, it alerts you on failures that have come through, and it monitors those restore test results for you as well.
Steve Stedman 21:12
Yep. And one way to do that in database health monitor. We have our alerting module, and we can go set up alerts for different things, like things in the error log or failed restores or backups or failed checkdb, and if any of those things happen, we get an alert that there’s a problem there. So some best practices to consider here is to test different restore scenarios, full restores, point in time, restores to alternate servers. What are the different scenarios that you might come across that you’re going to run into with the point in time restore that’s using SQL Server transaction logs, that does require you to do a full restore. So it’s really the same the point in time is the starts out as the same as a full restore. It’s just that there’s a little bit more work you have to do to do to get to the right point in time. The other thing to do is to kind of rotate your backup media. That’s kind of an old school deal where you actually have media that it’s being stored to. Usually now it’s being stored to some kind of disk storage somewhere, but if you have multiple locations that it’s going to.
So oftentimes, we’ll see that people will do a backup to the local network, and then from that local network it might get copied to a file server or a backup appliance, and then from there, it may be getting copied to the cloud for some kind of long term storage. Pick different locations when you’re doing your testing, and maybe you only have to do that quarterly, but go pick what’s the most difficult one to get to it, which is usually is like the most worst case scenario. Pull those backups back down and try doing a restore on them and make sure that they work for you. And the key here is document and test the results, including success and failure, how long it took in any issues that are encountered. You don’t want to try and make it all look happy, make it all look good if something didn’t happen well, because this is the time to learn. And if you fail at doing the restore at a test run, it’s usually no big deal. You just got to try it again until you get it right. But if you fail on that restore on a production, live system, that might be the end of your job or the end of the company.
Shannon Lindsay 23:23
Good news is, that’s why we’re here. And with that, I mean, one of our offerings, besides Database Health Monitor, is the Managed Services.
Steve Stedman 23:31
And with the Managed Services, usually, one of the very first things that we do is we try and understand what the client’s backup recovery point and recovery time objectives are, and once we understand that, then we can determine, do the backups they currently have in place meet those expectations, and then if they don’t, what do we have to change in order to get to those expectations? I know a lot of the time, people think they have more robust backups than they really do, and once we really dive in and analyze it, making sure it’s good. And the reason we make sure that’s good is because with those managed service clients, we’re the one they call first when they need to restore. And I don’t ever want to have to tell them that we can’t restore that backup to meet your expectations.
Shannon Lindsay 24:23
Yeah. I mean, some of the ways that we can help with that are the proactive monitoring and the automation of, you know, emails and alerting that go not only to one team member, but multiple team members to make sure somebody’s always watching for you.
Steve Stedman 24:39
A common one on that is where if somebody takes, like, an out of sequence backup, and it’s going to break the restore chain. So it puts us in a position where we can’t restore for our Managed Service clients. When that happens, we get alerts to the whole team that’s involved on that, and we know we are now in an exposed point where we cannot. Restore that backup if they need it right now. And it’s usually our top priority to get a fresh, full backup run so we can put us back in a position, put the system back in a position where we could do a restore, if we have to.
Shannon Lindsay 25:11
What would you say are some of the, you know, the specific ways that we can help support for restore testing?
Steve Stedman 25:21
Well, I think first off is just kind of working through it for the first time with a client like I did that earlier today. It was, well, I’d done it with a client, with that same client before, but it was the first time with this individual where we just worked through the process and trained them so that they didn’t know how to do it. But I think it also involves helping build the right backup strategy so that we know that your backup meets your expectations. If, as a system administrator, you know you’ve got enough disk space for three days worth of backups, but the business manager assumes you’ve got three weeks worth of backups. Well, if something fails and you need to go back in time, that’s going to be a really difficult conversation to have, so understanding what the expectations are, so that we can meet them, and then practice different restores to confirm that those expectations are actually being met regularly, testing of those but then also Disaster Recovery Training, and then knowing that if you need a restore and you’re not super familiar with it, ask for help, call us and we can help with that. And it may make the difference between us doing helping you with a restore on a smaller database that might take 15 minutes, rather than someone else working on it, it might take four or five hours while you go figure out how to do it and make mistakes. So I think at this point, let me just talk a little bit about this case study that I kind of planned here.
So there’s a regular client that we’ve worked with for a number of years. They’ve got a database that’s about 1.5 terabytes in size, and they ran into corruption. Corruption was introduced due to some endpoint protection software that wasn’t properly configured, and it was messing up the SQL database files, but that endpoint protection wasn’t messing up the backup files or the network location where those backups files, backup files were being written to the corruption was introduced multiple times over a two week period, and we didn’t know that it was the endpoint protection software causing it at first. It took us a little bit time to figure that out, but instead of taking the system offline and doing a costly corruption repair on that database that had been partially destroyed by that endpoint protection. Instead, we did a full restore that database and replayed all the transaction logs up through the time that the corruption was introduced, and we had the database standing by ready. This was mid afternoon, and then we kept reapplying those transaction logs throughout the afternoon, so that after 5pm when the business closed, that we could take the system offline, activate the new database and then disable the old database. And we were able to do that with far less than an hour of downtime, and there was absolutely no data loss. It didn’t enter it didn’t interfere with the business activity during the day. And we also had a backup plan that if something had gone back bad during the day, we had a way to recover quickly if it was needed. Had we not had good backups in that scenario, that client would have been down hard, and they would have been down hard for probably a couple days while we had to repair those or those databases.
Shannon Lindsay 28:41
So what tell you know, one of our listeners, how would you get started here?
Steve Stedman 28:49
So getting started, first thing, I mean, you can talk to us, schedule a free 30 minute consult at Stedmansolutions.com or stedman.us/schedule you and you can talk to us. We can help understand what your needs are. Help you understand if you’re close to them or if you’re far off, and then help you come up with a plan of how to address that. Another option is you go and understand we have our backup and recovery course that’s available at Stedman SQL school. We’ll put a link in the video for that as well, and you could go take that backup and recovery course, and it covers most of plus more than what we’ve covered in this in this podcast today. And I think the other is using Database Health Monitor as well in order to be able to track your backups and better understand the overall health of your SQL Server database.
Shannon Lindsay 29:44
Some common questions that we tend to get. Number one is usually, how long should the restore testing take?
Steve Stedman 29:56
That’s a great one. And yeah, it’s like, how long is it gonna take to drive from here to the next town over? Well, it depends what you’re driving. Are you driving in a car or a bus or a tractor or a bicycle? It’s going to be a different speed depending on how you’re doing things. But here it’s the how long your database is going to take to restore testing. It depends on the database size, but usually the restore time is similar to the backup time. Now there are a few exceptions, and there are some times that I’ve seen the restore take five times as long as the backup did things like too many VLFs in your data file or your log files, has caused problems like that. But generally, if things are running well, the restore should take a very similar amount of time, maybe within 20% of what your backup took.
Shannon Lindsay 30:48
Another common question is, what if I don’t have a test server?
Steve Stedman 30:53
What if I don’t have a test server? Well, if I don’t have a test server, we can look at if you don’t have a test server, we can look at other options. One, do you have a lap, a laptop or desktop computer that you work with that you can have SQL Server Developer Edition installed on? You could try backup testing there if you had enough room, you could we could help with this if you need but you could even restore to the same server if you have enough space, just making very certain that you don’t overwrite the existing database and or you can spin up a virtual machine, or there’s a lot of different ways to do things like that, to test it, but really the only way that you’re going to know if your backups are good is to actually restore them somewhere, and that somewhere could be many different any different possibilities there. So I think at this point, what I’d like to do is encourage any of our listeners. If you want to submit questions, I can always contact us through Stedman solutions or our social media or on YouTube and Spotify.
Shannon Lindsay 31:53
You can also comment on the episodes, and if you have any questions too, don’t be afraid to reach out through the website and book a free 30 minute consultation too.
Steve Stedman 32:01
All right, so basically, kind of the wrap up here is to know that it is important to be able to do those weekly restores. Weekly restore doesn’t mean that you have to be doing it yourself weekly, but that you have at least a process down that will do it and verify it weekly. You don’t have to restore all your databases weekly, but just restore a couple of them or one off of each server is a good way to do it. Yeah, I guess with the other thing is, with our managed services, we help take care of all that for you, and then, yeah, at this point, I just say, reach out to us for that free consultation, and don’t forget to subscribe. If you’re watching this on YouTube or Spotify, make sure you hit the like button or hit the bell icon for more information. Thanks for listening. We appreciate this, and our next episode will be on SQL Server Agent, job scheduling and task scheduling and some best practices and some tips to help with your SQL Server, agent, jobs and tasks that wraps it up for today. Thanks for watching and 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.