ATI 2020: Edited: Estimated backup size of file/folder backup is larger than actual size, if source list includes symbolic links
I use Acronis True Image 2020, incremental backup, full backup after 20 incremental versions, automatic cleanup: keep size of backup to no more than 1740 GB. I backup to an external 2TB USB HDD.
Edit: This system is an Acer ATC-705 desktop PC, i7-4790, 12 GB RAM, 1TB HDD, Windows 10 Home 64-bit 21H1 19043.1348
Before 11/22/2021, the "source" list of files/folders is about 210 GB. The most recent full backup (10/28) is 182.4 GB.
That pre-11/22/2021 source list of files/folders included mostly AppData and media from my user folder in C:\Users\Mike (taking up 85 GB on disk), and several project folders in C: (taking up 118 GB on disk).
On 11/21/2021 (after the 11/21 backup, but before the 11/22 backup), I added more files/folders to my source list. Those additional files take up 64 GB on disk. The total size on disk for all files/folders in the source list is about 274 GB. Therefore, I would expect the size of a full backup to be 274 GB or less.
However, ATI estimated the size of the backup to be 880 GB.
The total amount of space used on my "source" drive (C:) is less than 500 GB. And, as I stated above, I'm only backing up 274 GB of files.
I removed all source items, added them back one at a time and monitored the estimated backup size. Source folders with symlinks seem to cause the problem.
For example, C:\Users\Mike\Documents uses 1.4 GB of disk space. ATI estimates an additional 63.6 GB of space is required to back up the Documents folder. Documents has "standard" Windows junction/symlinks to My Music, My Pictures and My Videos. Altogether, the Documents, Music, Pictures and Videos folders use 63.6 GB on disk, which would explain the increase. However, when I uncheck the My Music, My Pictures and My Videos items from within C:\Users\Mike\Documents in the source list, the estimated backup size is still 62 GB above the 1.4 GB actually used by the Documents folder.
Even worse, C:\Users\Mike\AppData uses 21.3 GB on disk, but adds 606.6 GB to the estimated backup size. There are numerous symlinks in the AppData folder, and they're all in AppData\Local.
When I add C:\Users\Mike\AppData\Roaming to the source list, which has no symlinks, the increase in the backup estimate reflects the actual size of AppData\Roaming on disk: 2.2 GB.
For more info, see "Additional Details", below.
Is there any reason why symlinks would break the ATI estimated backup size now, when it worked perfectly fine for over a year?
If the culprit is not symlinks, do you have any idea what could cause this unexpected increase in estimated backup size?
Is there some way to force ATI to recalculate the estimated backup size?
Additional Details
- estimated backup size before adding C:\Users\Mike\Documents\ : 121.2 GB; estimated backup size after: 184.6 GB; size of C:\Users\Mike\Documents on disk: 1.4 GB
- This seems way off, i.e., 1.4 GB of source files requires 63.6 GB of backup disk space. There are 3 "standard" Windows junction/symlinks to Music, Pictures and Videos in C:\Users\Mike\Documents. Documents, Music, Pictures and Videos take up 63.4 GB of space. Is ATI's backup estimate incorrectly adding the junction symlinks for Music, Pictures and Videos to the document estimate? If so, why is this happening on/after 11/22/2021? Those symlinks have been there forever.
- estimated backup size before adding C:\Users\Mike\Music\ : 121.2 GB; estimated backup size after: 142.9 GB; size of C:\Users\Mike\Music on disk: 21.7 GB
- Those numbers add up.
- estimated backup size before adding C:\Users\Mike\Pictures\ : 121.2 GB; estimated backup size after: 161.5 GB; size of C:\Users\Mike\Pictures on disk: 40.3 GB
- Those numbers add up.
- estimated backup size before adding C:\Users\Mike\Pictures\, C:\Users\Mike\Music, C:\Users\Mike\Videos : 121.2 GB; estimated backup size after: 183.2 GB; combined size of C:\Users\Mike\Pictures, C:\Users\Mike\Music and C:\Users\Mike\Videos on disk: 62 GB
- Those numbers add up.
- estimated backup size before adding C:\Users\Mike\Pictures\, Music, Videos, Documents : 121.2 GB; estimated backup size after: 246.6 GB; combined size of C:\Users\Mike\Pictures, Music, Videos and Documents on disk: 63.4 GB
- The backup estimate is 62 GB above the actual disk usage - the exact amount used by Music, Pictures and Videos. Again, it looks like ATI's estimate is incorrectly including junction/symlinks.
- estimated backup size before adding C:\Users\Mike\AppData\ : 121.2 GB; estimated backup size after: 727.8 GB; size of C:\Users\Mike\AppData on disk: 21.3 GB
- The backup estimate is 585.5 GB above the actual disk space used by AppData. There are numerous symlinks in AppData. I haven't walked these links, so I can't say whether this accounts for the increase.
- estimated backup size before adding C:\Users\Mike\AppData\Roaming\ : 121.2 GB; estimated backup size after: 123.4 GB; size of C:\Users\Mike\AppData\Roaming on disk: 2.2 GB
- Those numbers add up. C:\Users\Mike\AppData\Roaming has no symlinks in its tree.
Executing "dir /al /s C:\Users\Mike\Documents" from a cmd prompt to find all symlinks, I see only the 3 junction symlinks that are standard in Windows 10: My Music, My Pictures and My Videos.
There are numerous symlinks in AppData, most have been there since before the increase in backup size.
In the past 30 days, I have installed the following executables:
- Beyond Compare 4
- Microsoft VSCode 1.62 & dotnet SDK 5.0.402
- CCleaner 5.87.9306
- iMazing 2.14.5 (trial)
In the past 30 days, I've downloaded the following apps/executables, which do not require an installer:
- Awesome Photo Finder
- Acronis MVP Assistant
Hi Steve,
Thanks for the response!
If you have made no changes to any of the source libraries or symbolic links since the time when all was adding up correctly for the backup sizes, then the other questions here are related to any other changes that may have been made?
I have modified, added and deleted files in directories in my source list, e.g., I make frequent changes to my Documents folder, C:\projects, etc. I checked symlinks with "dir /al /s <path>" for every directory tree in my source list. The only dir trees with symlinks or junctions are C:\Users\Mike\Documents and C:\Users\Mike\AppData\Local. I haven't added any symlinks, or modified/deleted any of the Windows symlinks. But, from looking at my ATI logs, the change to the source list on 11/21/2021 was the first time I've modified my backup source list since Dec 2019. I can't recall all the changes I've made in that 2 year span. I have changed permissions on some folders, e.g., changed owner from TrustedInstaller to me, and temporarily added folders to the Picture library.
Windows have been pushing out lots of regular and large updates including the 21H2 one during the past week which may be playing a part in this puzzle.
I'm on 21H1. I checked my update history: the latest feature update is 21H1. There are plenty of quality and "other" updates for 21H1. But nothing for 21H2.
Is there only one disk drive involved in the backup source for this task?
Yes, one source HDD (C:), and one destination USB HDD (E:).
Have any changes been made to the ATI 2020 backup task settings, in particular to the task Exclusions settings?
The Exclusions settings are the default settings: "Exclude system files". I've made changes to the Schedule and Backup scheme. Currently, no schedule, but it was daily. Schedule Advanced settings: backup only when locked/screensaver, wake up sleeping/hybernating computer, prevent computer from sleeping/hybernate, run missed operations at system startup with delay 0 minutes are all on.
Backup scheme is incremental, full version after 20 incremental versions, auto-cleanup with backup no more than 1550 GB (was 1740 GB before 11/21).
I don't remember changing the Advanced Settings, but they are different from the initial settings for a new backup: "stop all current operations when I shut down the computer" is unchecked.
Finally, have you allowed the task to run and checked the actual size of data in the backup versus the estimated value shown initially?
I haven't tried to run the original backup task since it failed on 11/22. However, I created a 2nd backup task with only the Documents folder, and saved it to a 2nd USB HDD. ATI estimated 63.4 GB for the entire backup, even though only 1.4 GB are used on disk. The actual size of the that backup is 900 MB. So, it looks like ATI is saving the correct files in the backup - only those in the Documents directory tree - not the files in the junctions. I'll try the original backup task tomorrow and see if it successfully creates the backup version, given there is less space on the drive than the incorrect estimate.
Hi Mike,
Just check you don't have Sector-by-Sector backup checkbox selected under Options > Advanced. This massively increased my backup size and time.
Hi Chris,
Thanks. My backup is a file-level backup. I checked the Advanced options and Sector-by-Sector doesn't appear under any of the subheadings. By coincidence, I read through your post yesterday, and saw what looked like a discrepancy in space used. I'll leave a comment there.
Hi Steve,
I initiated a backup using the original backup task with the larger 11/22 source list. ATI started to save another incremental version. The remaining time estimate seemed ridiculous, though: After 2-5 minutes, 7+ hours remained; after 45 minutes, 14+ hours remained; after 70 minutes, 22+ hours remained.
I terminated that backup and created a new backup task with a slightly smaller source list. I removed some folders that I don't think I need (I can provide the source lists from demon logs, if needed). The source list still had Documents and AppData, so it still had all the symlinks that the 11/22 source list had.
ATI incorrectly estimated the size of the new backup to be 770 GB. I manually started the backup. That new backup task created a full backup, 184.2 GB of data on disk compressed to 165.6 GB backup size. The backup took 3h:02m to complete.
So, the estimate is off, but the size of the actual backup is fine. And the bad 770 GB estimate didn't prevent ATI from saving the backup, even though the amount of free space in the backup drive (543 GB) was less than the estimate.
It's not clear to me why attempts to backup after 11/22 failed. That is, last night I was able to store a full backup (using a new backup task) even though ATI's estimate exceeded the amount of free space on disk. I thought that was the cause of the problem on 11/22, but maybe not.
To recap:
- On 11/21, ATI saved incremental b28_s20_v1 with the "old" source list. (The options for that task are: incremental, full backup after 20 incremental versions - so the last incremental is always s21.)
- before the 11/22 backup, I changed the source list, adding more files.
- On 11/22, ATI attempted to save full backups: b29_s1_v1, b29_s1_v2, but failed because there wasn't enough space on the backup disk for a ~190 GB backup. (Did ATI attempt a full backup instead of an incremental backup because the source list changed?)
- Between 11/24 and 11/25 ~339 GB of backups were deleted (using ATI Cleanup Versions...), according to the ATI Activity tab/page, to make space for subsequent backups. The "not enough space on the destination drive" notification banner still appeared on the Backup tab/page. Maybe that wasn't actually preventing ATI from making backups?
- No backups have been created/saved for this task since 11/21
- On 11/26, I validated the backup. The "not enough space on the destination drive" notification banner no longer appeared on the Backup tab/page.
- Edit: on 11/29, I initiated a manual backup. ATI started an incremental backup (b28_s21_v1). But the estimates of time remaining after 70 minutes was 22+ hours. So, I terminated the backup.
Bottom line, I would like to be able to turn on automatic cleanup, and limit the size of all backups so that ATI automatically manages disk space, i.e., doesn't fail to save a backup version just because the disk is full.
(I've turned on daily backups for the "new" backup task, as incremental with 20 incremental versions before full backup and auto-cleanup limit the size of all backups to 1550 GB.)
As I was looking through the logs, I see lots of errors. MVP Assistant highlights the Demon, Nonstop Backup, Schedule2 and Sync Agent logs (with bold, blue text) in the tree view.
For example, pcs.0.log:
"failed to open archive: corrupted page is found at 0xXXXXXXXX"
"failed to open archive path=<path> mode=readonly uuid xxxx, err=-5003 (Data is corrupted: CRC mismatch or internal data structures mismatch)"
Also, syncagent.log appears to be corrupted, and causes MVP Assistant to crash. Lines 6-9 appear to be the end of a <event> and <error> elements that have been overwritten. syncagent.log attached.
Let me know if you want to see the other logs.
Thanks,
-Mike
Mike, your syncagent log file is typical for a system not using this feature - I see the same errors in my own log of the same type.,
At this point I am struggling to understand why there is such a big discrepancy for the source estimated and actual sizes, so the next step is to ask if you can create an Acronis System Report zip file and share this with me via a private message using a cloud share service such as OneDrive etc. That will allow me to look at a range of information in context to see if anything else stands out here?
Hi Steve,
I'm generating the system report now. ATI is also currently doing the daily backup. Let me know if I should wait until the backup stops.
As for syncagent.log, I was more concerned that the log was corrupted. For example, if you try to open the syncagent.log in MVP Assistant, it crashes, and if you run an XML validator on it, you can see the invalid XML. Are you saying that a corrupted syncagent.log is typical for systems that don't use Sync Agent?
I was wondering if I need to reinstall ATI.
Hi Steve,
I edited my post from earlier to note the discrepancy in behavior between the 11/22 and 11/29 backup attempts. On 11/22, after adding folders to the source list, ATI attempted full backups (b29_s1_v1 and b29_s1_v2). However, on 11/29, ATI attempted an incremental backup (b28_s21_v1), which it estimated would take 22+ hours.
Mike, please ensure you have the latest version of the MVP Assistant tool when looking at the sync agent logs.
MVP Assistant update for Acronis Cyber Protect Home Office (Version 1.1.5.0)
Doh! That was the problem. I downloaded v1.0.1 from the Community Tools page on 11/25.
Edit: For clarity, MVP Assistant 1.1.5.0 no longer crashes when opening the corrupted syncagent.log file. But the log file is corrupted.
Thanks,
-Mike
Mike, thanks for the PM and system report zip file.
The ti_demon logs are not showing anything untoward that I can see other than the obvious disk full message back on 22/11.
The Event logs (application) are showing Event ID 98 NTFS errors for the Windows / C: volume with the recommendation to run CHKDSK /F which may be linked to issues with incorrect size being suggested for backup data!
Other than the above, I am not seeing anything else of concern in the system report files.
Hi Steve,
I didn't get a chance to run chkdsk yesterday. I'll do it today.
Quick question: I don't need Acronis Universal Restore if I'm trying to restore a file/folder backup to a new system, do I? I'm guessing Universal Restore is necessary only for disk images, correct?
Mike, correct about AUR only being needed for disk restores.
Hi Steve,
I did the following, to get a handle on the condition of my drives:
- Got the SMART drive status with "wmic diskdrive get model,status". Status is OK for internal boot drive C:, and the 2 connected USB drives (E: and F:)
- Checked drive fragmentation with Defragment and Optimize Drives. Windows runs that weekly, and there was no fragmentation on C:
- chkdsk C: (read-only). The command completed in 10 minutes, no problems, no further action required.
- dism /online /cleanup-image /checkhealth - no component store corruption detected.
- dism /online /cleanup-image /scanhealth - no component store corruption detected
- sfc /verifyonly. Sfc found integrity violations. I looked at the CBS.log: all of the logged issues are warnings of the form "Overlap: Directory <dir> is owned twice or has its security set twice." The odd thing is the original owner and new owner are identical for every item, and it's always a Microsoft component.
There is a 2nd odd thing: E:, the backup destination drive is marked active, i.e., it is a boot partition. It doesn't prevent Windows from booting. But I'm guessing that external backup destination drive shouldn't be marked active.
Lastly, I'm able to run scheduled incremental backups with the 2nd "alternate" job. The estimated backup size is still 4x the actual size of the files to be backed up. But it doesn't prevent ATI from running the job. However, after today's incremental backup, the activity log in the ATI client showed an odd estimate. It states that 248.8 GB are backed up. However, the actual .tib file size is 617 MB. That doesn't seem right. That's a 413:1 data compression ratio. It looks like another weird estimate. I've attached screenshots of the ATI client activity log entry (showing that 248.8 GB were backed up today), and the .tib file details from Windows file explorer (showing the actual backup size to be 617 MB).
I'm verifying my backup now, to make sure I have a valid backup before running Automatic Windows Repair and/or sfc /scannow. After that, I'll mark the E: drive inactive.
I have a few questions:
- I backup the AppData directory, but I don't "exclude files matching the following criteria", which includes several directories in AppData. Does Acronis recommend checking the "exclude files matching the following criteria" box in Exclusions, if backing up AppData?
- I attached a screenshot of the incorrect "Estimated backup size" from the Backup Source view. Is your's correct?
Thanks,
-Mike
Mike, the only time that I backup my AppData folders is when they are part of a Disks & Partitions backup task, and I am using the default set Exclusions. I have never used a Files & Folders backup task to save the contents of any system folders where there can be locked files by the OS.
Hi Steve,
I ran sfc /scannow which fixed integrity violations, and marked the destination external USB HDD inactive. But the ATI estimated backup size is still off.
I'll edit the title of this forum post, since the actual backup size hasn't increased - the estimated backup size is incorrect if the source list includes directories that contain symbolic links or junctions.
I would file a bug report, if that helps. I'm licensed only for ATI 2020, and I no longer appear to be able to submit support tickets.
Below is the current state of things (12/8/2021)
- My file/folder backup includes directories that contain standard symbolic links or junctions, e.g., C:\Users\<user>\Documents, C:\Users\<user>\AppData\Local. ATI 2020 incorrectly overestimates the backup size, if the source list includes symlinks.
- My "original" backup task, which I modified on 11/22 to add more files/folders, appears to be broken or corrupted. After 70 minutes, ATI estimated another 22+ hours remained, so I terminated that backup run. I validated that backup job on 11/25, and ATI says it is valid. (ATI demon log lists only the last incremental .tib for this validation task. I'm not sure whether that means the entire backup chain is valid, or just the most recent incremental .tib. I assumed the Validate operation means "validate the entire chain", since the UI lets you choose "Validate" from a backup job/task. But now I'm not so sure.)
- I am able to backup to a new file/folder backup task with the same source list. Those backups are fine. The actual size of the backups is correct, even though ATI overestimates the backup size. I have validated those backups and they are valid.
- "wmic diskdrive get model,status", chkdsk, sfc, and dism all report a healthy C: disk.
- I'm considering repairing ATI program settings, but will put that on the back burner for now.
- Edit: ATI functionality that writes to the syncagent.log appears to have changed on or after 2/27/2021. Prior to that, ATI would append to the syncagent.log. After that, ATI writes the new event record at the top of the file, overwriting whatever is there, but leaving behind partial, invalid <event> and <error> elements.
Thanks,
-Mike