Skip to main content

Incrementals and Full backups are hugely larger than source backup size

Thread solved

Hi,

After continuous problems with slow and failing backups to a NAS, I decided to install a 4TB WD drive into my PC and back up my 1TB SSD from there.  The SSD is typically half full (around 579GB at the moment), but ATI 2020 has managed to fill up a 4TB drive after 1 full and 5 incrementals.  Usually, an incremental would only require 5-20GB so what's going on?  Even the original Full backup was 3.3TB for a 0.5TB backup!  I've got "Back up sector-by-sector" enabled but not "Back up unallocated space"

I've included a screenshot of the back disk which is now full.  I'm only backing up C:\ (not D:\ and not B:\ itself - I have exclusions of B:\* and D:\* just to make sure). 

Any ideas?

Thanks. Chris

Attachment Size
Image 1.png 30.78 KB
Image 2.png 21.99 KB
0 Users found this helpful

Chris, first response is to ask why you are using sector-by-sector?  Doing so will always result in far larger backup images than is necessary!

I only ever use sector-by-sector when dealing with a failing disk that would give constant errors for bad sectors otherwise.  It should not be used for regular backup tasks as it invalidates all exclusions for a start.

What exactly is your selected source for the backup task?  Is it definitely Disks & Partitions with only the main C: OS drive selected (along with the required hidden / system partitions on the same drive)?  Please check that you are not using 'Entire PC' which would include any other fixed drives present.

If you still see very large files after the above, then time to run CHKDSK on all drives / partitions to ensure that there isn't something causing a free space error in the file system.

That's resolve the issue Steve - thanks so much.

I thought all modern backup systems performed backups using Shadow Volume Copy and thus backed up "by sector".  I also assumed that this was how it tracks "changes" along the backup change (backing up only those "sectors" that have changed.  I would have thought this would have been faster (as it just has to scan modified dates on sectors and back up those that have newer dates on them) and pretty space efficient (although it backs up a sector, it only actually backs up the proportion of the sector that holds data - and only those sectors holding changes in large files etc.) but you've demonstrated that my intuition is wrong here!
 

I'm now backing up to a local WD disk at 900Mbps+ and a full backup only taking 45 mins instead of many hours. Thanks.

Steve Smith wrote:

What exactly is your selected source for the backup task?  Is it definitely Disks & Partitions with only the main C: OS drive selected (along with the required hidden / system partitions on the same drive)?  Please check that you are not using 'Entire PC' which would include any other fixed drives present.

I used "Disks & Partitions" and selected the relevant partitions only.  I think if I'd chosen Entire PC then I wouldn't have been able to select a local disk (B:) as a backup destination.  Thanks for your help.

 

Hi Chris,

I'm experiencing some odd sizing estimates in ATI.  I noticed from Image 1.png that the ATI "Clean up backup versions" panel shows 20TB of backups.  Is ATI estimating the size of all backups to be 20TB on your 4TB backup drive?

Mike Araya wrote:

Hi Chris,

I'm experiencing some odd sizing estimates in ATI.  I noticed from Image 1.png that the ATI "Clean up backup versions" panel shows 20TB of backups.  Is ATI estimating the size of all backups to be 20TB on your 4TB backup drive?

Hi Mike,

It doesn't make a whole lot of sense because the backup drive is 4TB (3.6TiB formatted). 

It totally has to do with the "sector-by-sector" option being enabled though as the partition being backed up is only 930GB!  Having cleared the backup drive down, switched off "sector-by-sector" and rerunning the initial full backup, that same Image 1.png now shows 249.5GB (which for a 930GB drive containing 578GB of data sounds right after compression).  I hope you get your issue solved on the other thread.