Skip to main content

Incremental backups are very large with Windows 10

Thread needs solution

When I first started using Acronis 2017 my incremental backups were relatively small (~1 GB) but now they are huge (~150 GB), almost the same magnitude of full backups.  How do I find out what is going wrong.  I have not been changing anything on the computer, but Acronis is seeing something I'm not.

0 Users found this helpful

Defragmenting the source disk can cause such behavior.

My computer is set to optimize once per week, but I'm doing incremental backups daily.

Enchantech wrote:

Defragmenting the source disk can cause such behavior.

Bad sectors on the disk can cause TI to revert to doing a sector-by-sector backup. Run CHKDSK /R on all partitions on your disk.

1) Defragging can cause the behavior (noted by Enchantec): 2712: Acronis Backup Software Creates Large Incremental or Differential Backup Archives

2) A bad disk / dirty sectors may revert to a sector-by-sector backup (noted by Mark Whalton) - run chkdks /f /r on the source drive

3) Do you have an "entire pc" backup or did you select "disks and paritions"?  If you have "entire pc" and change disks around, Acronis may be backing up more than you're bargaining for.  I never use "entire pc" and always use "disks and paritions" so that I can ensure that the backup is only for the intended drive(s).

4) Did you upgrade Windows to a newer version (Windows 10 upgrade?) or restore a disk or partition?  These will trigger the entire sytem to be backed up again.

My guess is defrag if you're doing this often.  In most cases, defrag only needs to run once a month on a standard disk.  If you have an SSD, disable defrag.  Windows 7 and neweer automatically uses TRIM which keeps the SSD defragged in a more SSD friendly manner which should not impact the entire drive like standard defrag.  If you are defagging, then schedule your full to occur next after that and incrementals should remain relatively small until the next defrag. Not sure of your backup scheme (frequency / days / retention)... but a monthly defrag, followed by a full and daily incrementals should be ok.  Personally, I'm not comfortable going an entire month with only one full and numerous incrementals, but that's just me.  I tend to do a weekly full with 6 daily incrementals for the OS and keey 4 version chains (1 month).  For things where data is hardly changing (pictures, movies, software repository), I don't mind having a monthly full and monthly incrementals because of the low frequency of change.  To each their own though. 

Well that's pretty strange, actually pretty scary.  I ran chkdks c: /f /r and then created a backup scheme in Acronis and ran a full backup of Entire PC and the backup size was only 46 GB, whereas before chkdsk was run the backup size was ~150 GB.  I have a 1TB SSD on a Dell XPS 15 (9550).

SATWAR.

This is normal.  It sounds like your disk had some corruption on it and the chkdsk /f /r found it, fixed it and/or marked the bad sectors so it is no longer needing to do a sector-by-sector backup to try and circument the dirty/bad sectors that were there before.  When the disk is healthy, Acronis should only need to backup the actual written content of the drive and with compression, it should be about 20-30% smaller than the original expanded data (minus things that are also filtered out like pagefile.sys, hiberfile.sys, swapfile.sys and whatever else is being filtered in your exclusions area of your backup.  A backup after a defrag can still be nearly as large as the original backup - really depends on how fragmented the disk is/was and where the data was re-written to as those changes are read as "new data".  

 

Well I've never seen something that bad before, I wouldn't think that would happen with SSD.  I did a little research and many agree with disabling defragmentation on SSD.

Thank you, again, for all your help.  I'm afraid Tech support wasn't helping me.  Thank goodness for the strong MVPs in this forum.

satwar:

It might not be as bad as you think. The problem may have been file corruption, which could have been caused by the operating system or a program error; not a defect on the SSD. If you look at the chkdsk log, it might tell you what the problem was. http://www.tenforums.com/tutorials/40822-chkdsk-log-event-viewer-read-w…

I can't read this, but it looks like trouble.

Mark Wharton wrote:

satwar:

It might not be as bad as you think. The problem may have been file corruption, which could have been caused by the operating system or a program error; not a defect on the SSD. If you look at the chkdsk log, it might tell you what the problem was. http://www.tenforums.com/tutorials/40822-chkdsk-log-event-viewer-read-w…

Attachment Size
395876-134437.txt 32.98 KB

satwar:

Was there additional text following what you posted? If you look at the article on the Windows 10 forum and scroll down until you see the last picture you'll see a report on whether any bad sectors were found. I've highlighted the pertinent part of the chkdsk report on the attached file. If there were no bad sectors found then the disk is OK and this was probably caused by a Windows software error.

Attachment Size
395880-134440.png 199.67 KB

I see the summary at the bottom of the example wininit report but this summary is not present in my wininit report

Besides the wininit log entry, were there any other chkdsk log entries dated October 16?

No, the chkdsk files are dated earlier than the wininit file

I wonder if there is a limitation on the size of a log file entry, and since your chkdsk report was so long, it just got truncated.

What happens if you run chkdsk /f again and view the log report? Use only the /f switch this time to shorten the amount of time it will take to check the disk.

That looks better

Mark Wharton wrote:

I wonder if there is a limitation on the size of a log file entry, and since your chkdsk report was so long, it just got truncated.

What happens if you run chkdsk /f again and view the log report? Use only the /f switch this time to shorten the amount of time it will take to check the disk.

Attachment Size
395908-134473.txt 4.96 KB

You're probably OK but there is some uncertainty that the first run of chkdsk was able to fix all of the problems that it found with the file system. Unfortunately, without the complete log file you won't know. I suppose you could look at the first wininit log entry in reply #9. It lists filenames of some of the file entries that had errors. Go find a few of these files on your disk to verify that they are still there. If so, you're probably OK.

Then again, you have TI backups to fall back on if any further problems crop up...

If you are worried obout possible problems with the SSD you should run the manufacturer's diagnosic program on the drive - it may also offer update firmware for the drive.

Ian

Another question regarding the topic of sector-by-sector backup.

Is there a way of flagging when sector-by-sector mode occurs and not make the backup but simply send a message to user.  This way you don't run out of storage space unexpectedly in destination.

I am not aware of any method of aborting a backup should it decide that sector by sector mode was required.