Incremental backups are very large with Windows 10
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.


- Log in to post comments

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.
- Log in to post comments

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.
- Log in to post comments

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.
- Log in to post comments

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).
- Log in to post comments

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".
- Log in to post comments

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.
- Log in to post comments

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…
- Log in to post comments

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 |
- Log in to post comments

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 |
- Log in to post comments

I see the summary at the bottom of the example wininit report but this summary is not present in my wininit report
- Log in to post comments

Besides the wininit log entry, were there any other chkdsk log entries dated October 16?
- Log in to post comments

No, the chkdsk files are dated earlier than the wininit file
- Log in to post comments

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.
- Log in to post comments

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 |
- Log in to post comments

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...
- Log in to post comments

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
- Log in to post comments

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.
- Log in to post comments

I am not aware of any method of aborting a backup should it decide that sector by sector mode was required.
- Log in to post comments