Incremental/differential backs up a LOT of stuff
I've been working on a VSS problem between Acronis & Windows. Acronis seemed to be ignoring exclude file lists as a result, & I blamed that on the rather large daily backups Acronis produces. The VSS problem seems to resolved, the excluded files seem to be excluded.
The backups are still far too large (imo). It looks like a lot of very old stuff gets backed up in Documents/ & Downloads/, for instance, every day or every differential.
It's hard to tell for sure the size of incrementals due to the way Acronis 2021 stores them now, but I can see these files in each backup. What's puzzling is that the backup couldn't possibly be including every old file in those folders, because the backups would blow out really quickly - or else there's some kind of magic compression going on that no one else in the world has.
Can anyone help me understand this, & what could be done to shrink these incremental / differential backups down to convergence with what actually changes?
Thanks, ==mwh


- Se connecter pour poster des commentaires

These are all disk & partition backups. These backups are purely from a SSD disk. Windows 10 does its own thing for disk fragmentation & the options available for the disk say that it runs once / week (whenever it feels like it). Defrag is sort of a non-issue one way or the other in a modern SSD, but I could turn off the optimization. It's always possible (perhaps likely) that Windows 10 will ignore that & do what it feels like doing, but that's the control I have.
What Windows actually does is complex. This might be part or all of the story:
http://www.hanselman.com/blog/the-real-and-complete-story-does-windows-…
Is turning this optimization off something I could expect could help? It doesn't seem likely, given the behavior I am seeing - the files are backed up again & again, every day, & this optimization supposedly happens weekly - or monthly - or wheneverly.
Normally, when task Exclusions are ignored for backups, this would indicate that the method being used has switched to using sector-by-sector (for disk backups only), so would be unusual if this was happening due to an obscure VSS issue?
Not sure I understand what you are asking here but if you're asking whether VSS caused acronis to ignore the exclude file list ... Acronis 2020 said yes it does in its log file, & Acronis 2021 doesn't say anything about anything in its log file (one way to fix a problem), and the results in backup were the same. Once I went thru the processes needed to correct the VSS error to chkdsk's satisfaction, files were excluded by Acronis 2021. It didn't happen to make a lot of difference in the size of the backups, & on further investigation I can see a lot of very very old files are being backed up again & again in incrementals & differentials.
Perhaps it would be nice if Acronis could be made to log why it is making the choice.
- Se connecter pour poster des commentaires

See webpage: Microsoft fixes Windows 10 bug causing excessive SSD defragging - that has been in play for some months and is now fixed in an 'optional' Windows Update! I have had my own NVMe M.2 SSD drive excluded from any automatic Maintenance since this bug was made known because it was obvious that the drive was being defragged / trimmed unnecessarily during maintenance.
There is a new MVP Assistant log viewer tool that has now been made available by Acronis via the Community Tools page..
If you have Disks & Partitions backups created on ATI 2020 or later using .tibx files, then look in the Backup Worker logs.
If you have Files & Folders backups using .tib files (or Disk backup using same) then look in the Demon logs.
- Se connecter pour poster des commentaires

I wasn't aware of the SSD bug (altho the randomness of Windows 10 misbehavior doesn't surprise me). However that patch has been installed since late September.
I've looked in Backup Worker logs. I mostly don't understand what I see there. I do see a section where it appears to be processing the exclude file list, which is what I wanted it to do. Then there is a long section that I don't understand but I suspect from fields like CTIME it has something to do with a file; many repeats of things like this:
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_UUID; value=0680d76d674f738f5b451d1b1c37e090; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_TYPE; value=1; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_INT_ID; value=2; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_PREV_F_ID; value=1; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_BASE_F_ID; value=0; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_CTIME; value=1600289734670 (16-09-20 20:55:34); id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_FTIME; value=1600296796700 (16-09-20 22:53:16); id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_USER_SIZE; value=928603286939; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_COMP_SIZE; value=808482394112; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_DESCRIPTION; value=; id=1;
11/6/2020 02:08:38:684 AM -08:00 28036 I00000000: Pid: 31284 type=metainfo; name=SLICE_NUM; value=1; id=1;
- Se connecter pour poster des commentaires