Differential backups capture all files changed since the last full backup, offering a faster and less resource-intensive alternative to running full backups repeatedly. Understanding how archive bits track changes and how restore operations work is essential knowledge for any backup and recovery strategy.
Differential Backup
One of the problems with a full backup is that we're backing up all of the files within a folder every time we're doing a backup. This could become problematic. As I mentioned, sometimes I'll start a backup on some of my systems on a Friday night and then it takes until Sunday afternoon to finish up. This could be really problematic if I set off this backup in the middle of the day — it could take forever to do. Not only that, but it can be disruptive: there's a lot of processes that are happening during that time, and so it can bring, and has brought, some of my SQL servers down in the past. So that can be problematic.
We have a solution for that. A differential will back up all files that have changed since the last full backup. So let's say overnight we've done a full backup. What's going to happen is that at 9:00 a.m. it's going to grab the changes, which is going to be file 1. At 10:00 a.m., it's going to grab the changes, which will be files 1, 2 and 3. At 1:00 p.m., it's going to be 1, 2, 3, 4 and 5. At 2:00 p.m., 1, 2, 3, 4, 5 and 6. So as you can see, it's just capturing all the files that have been changed since the last full backup.
How does the differential backup know which files have changed? That's simple: we've got the archive bit, and that archive bit gets checked every time that file gets changed, so it knows exactly what files got changed. What it will do is keep those archive bits intact — it won't change them. So the next time that something gets changed, it will check those as well, and the next time it goes to do a differential backup, it just includes those into the backup. Then let's say more gets changed, and so now that's included into the next differential. It just keeps adding. They don't get cleared out until you do the next full, and when you do the next full, then it clears all of the archive bits out and it resets at that point in time.
It's a pretty slick process, because now if we do that full, then all the archive bits get switched out and get turned off. Then when this file 1 changes, that archive bit gets selected and now it gets included as part of the differential. And then it happens with files 2 and 3, so now those are included every time it does a differential, and so on and so forth.
So what does that look like from a transaction log standpoint when it comes to databases? The differential is just capturing the transaction logs, and they just keep building up. These transaction logs don't get moved into the primary file of the database, so they just keep stacking up until that full backup happens. Once that full backup happens, everything gets committed and moved into the file, and then it starts a new batch of transaction logs.
Let's create a scenario and say there have been some changes that have happened and we want to go back to the 1:00 p.m. version of this. How do we do that? How do we do the restore process with this differential? What we're going to have to do to get all of the files restored initially is restore the full that happened overnight — that gets all of the files back intact there. Then we will do the differential from 1 p.m., so that restores all the changes, all those files that have changed since that last full. So we need to essentially do two restores: one for the full and one for the differential.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →