Huge differential backup compared to other backups - HBS v5.0.2_241228

[al3x]

I'm backing up my Windows 11 on a daily basis with grandfather/father/son method. A full backup currently is about 164 GB. Each day there are a few changes on the drive, mostly browsing with MS Edge (temp folder) and other small changes. So in total, the difference for each day is about 2 - 6 GB usually.

Yesterday I did nothing special in comparison. But today (sunday) this first differential backup was made:



Please have a look at the file size. It is huge compared to the other ones, more than a 1/3 of changes compared to the last full backup.

I'm not sure what changed exactly, there was no Windows updates, no Edge update, no other big changes. Still the difference is huge. Could it be that there's a bug somewhere with the detection of file changes?

I don't know if logs will help here, all I can say is that I'm pretty sure I didn't change more than 60 GB of my C: drive in the last 3 days.

Any ideas what could've caused this? I noticed something similar a few days ago when I had mounted my C: drive outside of Windows in Linux Mint, but this was not the case recently.

Maybe there's still a bug somewhere with the detection of changed files?

[al3x]

Ok, maybe I was too quick with the judging.

According to HBS restore page the difference since the last full backup was really that big:

- Full backup: 637.47 GB free space
- Last inc. backup: 627.90 GB free space
- Diff. backup: 605.13 GB free space

Will try to figure out what changed exactly. 

[al3x]

Ok, I mounted the 3 different C: partitions and compared sizes with WizTree:

- Full backup: 242.6 GB in use, 688.1 GB free space
- Last inc. backup: 249.9 GB in use, 680.9 free space
- Diff. backup: 250.0 GB in use, 680.7 GB free space

So there were some changes. But free space dropping from 637.47 to 605.13 (like HBS shows) is not correct.

Does HBS maybe still count in page, hibernation, swap and VSS snapshots although they're filtered out?
Are they maybe still included in the backup but not shown or something like that?

*Edit:

Also, I mounted the differential backup and opened it again in WizTree.
This time I went to "File View" and sorted all files from the mounted partition by column "Modified".

When I mark all the files between 2024-12-29 14:14 and 2024-12-26 05:31:
- Selected files: 13.755, total size: 9.8 GB.

So in my opinion the differential backup shouldn't have been bigger than 10 GB, given that every file change was properly reflected in the last modified date in $MFT.

[admin]

We understand your concern about taking up too much storage space. For incremental and differential backups, all data blocks are compared with the corresponding blocks in the full backup before they are written to the image file to make sure that no duplicates are stored in the image file, so we can be sure that the data blocks written to the image file are the ones that have changed. As to why such a large image file was created, we believe there may be the following reasons:
1. Windows updates changed some of the files;
2. Windows may have defragmented the drive. Usually Windows optimizes and defragments the C: drive on a regular basis, and we think this is the main reason why your computer generates a huge backup image file.

For the disk backup feature, the backup program will divide the entire drive into blocks of specified size, then check whether the data in these blocks have been changed, and if a block has been changed then the data in that block will be written to the backup image file, so if the drive to be backed up performs a defragmentation operation, a very large backup image may be generated.

Regarding the problem you mentioned that WizTree only found about 10 Gigabytes of changed data, we are not familiar with WizTree, but usually these software will only list files whose content has changed, and will not tell you about the files whose location has changed.

In fact, the best way to find out if Hasleo Backup Suite is taking up too much storage space is to compare it to other competitors (e.g. Macrium Reflect), and we'll do some testing.

[al3x]

Well,

Windows updates were not the case, it's a new setup that was installed a few days ago.

Defragmentation shouldn't be the culprit ether. First off it's an SSD so Windows would normally not trigger full defragmentation but only some optimizations once a week/month. But even then I don't think this new setup would instantly require defragmentation.

You're of course right with WizTree. This tool only compares timestamps in $MFT as far as I know. I just used that to actually see the difference in what was changed between the backups.

The only thing that does heavy disk usage is VMware Workstation that I use a lot. But I use snapshots with the VMs and actual changes in VMs on the disk were not made between HBS backups. But as you said already, maybe the layout of the disk still changed with that and HBS detects this as changed blocks, don't know for sure.

I was under the impression that HBS only checks $MFT timestamps though, didn't know it was still able to track changes on block level without a driver. That's kinda cool!

[Froggie]

HBS does not track block (sector) level changes, dev will explain, I'm sure. Their mention of "blocks" most likely refers to allocation blocks (some # of clusters).

[al3x]

HBS does not track block (sector) level changes

Not sure about that. I ran a test in a VM to test the behavior:

• I created a text file with some content and saved it on the desktop.
  
• Then I made a HBS full backup from the full drive and turned off the VM.
  
• Next I edited the VM drive (vhdx file) with a hex editor and changed that content slightly by replacing some bytes.
  
• Then I turned the VM back on and ran a HBS incremental backup.
  

Turns out, that backup contains the updated content! And that even though I directly modified it by a hex editor, so there couldn't have been any $MFT updates.