I backup the boot partitions on my 3 PCs daily. A full backup and 6 differentials every week. I observe how much space in on my boot drives and how big the backups end up being.

I also do a monthly full backup as insurance in addition to the daily backups.

On one of my PCs, my main programming development machine, I have the boot partition on an SSD (C:) and a backup HD (D:) where I install most programs.

The SSD is a 256GB SSD, formats out with Windows to be 232GB. The D: drive is a 2TB HD that formats out to be 1.81TB.

Earlier today I replaced the boot SSD with one that is 1TB, 931GB under Windows.

The backup software I have allowed me to clone my original boot SSD to the new SSD, leaving a lot of unallocated space on the new SSD. After making sure the system booted up with the new SSD I extended the boot partition to use all the unallocated SSD space. So far nothing really unusual.

I had to tweak my backup defs in my backup software to recognize the newer, larger sized SSD. And so I made new full backups, replacing the last full daily and the monthly backups.

This is where things went kinda sideways weird....

Nothing has really changed on the boot SSD, but the full SSD backups were over 1TB smaller in size. Wha'?!?

Aint technology grand? Hehâ„¢.
I also ordered for delivery today a new 4TB HD so I can clone and replace my D: drive. Hopefully this newer plattered HD will be faster than the current one.
Hypothesis: The backup software decided not to assume that unpartitioned space was empty. For example, you might have some encryption software that hides data in unpartitioned space, or the image for some OEM factory restore function might be stored there. If the SSD came random-filled from the factory, that would compress very poorly (although my understanding is that it would be much more likely to come one-filled, so I don't know). However, it does assume that partitioned file system empty space is empty, and it zero-fills those clusters, thus the image compressing much smaller.
Last edited on
There aren't any hidden partitions with OEM hidden stuff, the OSes were custom installed by me back with Win 7. I know what's unallocated and what is allocated. All three of my PCs are computer repair store 2nd hand boxes and HDs. I've been custom building since Win9X/Me was da thang.

I've had PCs that used older Win versions, but these PCs started out as Win 7 machines and have been custom upgraded since.

The new SSD was unformatted/unallocated (for Windows at least) out of the box before the cloning. The cloning mirrored the old SSD's size of 232GB, leaving a large chunk of the new SSD initially unallocated. Using partition management software allocated that space to the C: partition.

As you (probably) know Win machines have a "hidden" system partition reserved at the start of the disc that isn't assigned a drive letter. If that 100MB partition is wiped Windows won't boot. I found that out the hard way.

I just think it's a bit weird, in a "well, that's kinda underwhelming" sorta way. Nothing really earth-shattering. Just rather unusual in my experience.

If'n there is anything hidden partition-wise it is something hidden from Windows drive management, my partition management software and my backup software.

I suspect part of, or in whole, the reason(s) for the size drop is how the data on the SSDs was laid out. The old SSD I've had for some time -- several years -- so the data kept getting moved around as Windows changed things with updates and all, the new SSD the data was "factory fresh".

The advantage for me of an SSD is no matter how fragmented the space on the SSD gets the access time is virtually the same no matter where the bits are located. The difference between a physical HD and an SSD in access speed is very noticeable. Windows boots in a few seconds to a usable state with an SSD instead of over a minute with a plattered HD.
There aren't any hidden partitions with OEM hidden stuff, the OSes were custom installed by me back with Win 7. I know what's unallocated and what is allocated.
Yes, you know that. But the backup software doesn't and can't know that. It must either assume the unpartitioned space is empty, and thus doesn't need to back it up, or nor assume it's empty and therefore needs to backup it up.
I made my backups after I allocated all the free space on the new SSD, so software saw only the two partitions "normal" on the drive.

If there were a third partition (or more), even hidden, the backup software would show it and the backup script wouldn't have it marked as a partition to back up. My script only backs up the two known partitions on my boot drive. The 100MB hidden system partition and the C: boot partition.

In the past when MS released new versions of Win 10 that were close to being a new OS version the C: partition was downsized about 500MB and a new hidden system partition was created at the end of the drive. That partition was never selected as being part of the backup script. Every time that happened I deleted that partition freeing up the space and resized the C: partition to reclaim that lost space. And Windows never had boot problems.

Lately that hasn't happened with the last couple of Win 10 updates. MS is more interested now in keeping Win 11 updated apparently.
Then what do you mean when you say
Nothing has really changed on the boot SSD, but the full SSD backups were over 1TB smaller in size. Wha'?!?
? Smaller compared to what? I assumed what you did was
1. Clone old SSD onto larger SSD, leaving unpartitioned space.
2. Allow a backup image to be made of the entire drive. This created an image much larger than the previous backup with the old SSD.
3. Extend the cloned partition onto the new space, creating ~0.5 TiB of new free space in the partition.
4. Allow a new backup image to be made. This created an image much smaller than the one from step #2, and roughly equivalent to the one previous to that.

If that's not it then what?
Topic archived. No new replies allowed.