Another slower backup process in TrueImage 2021

Walt, welcome to these public User Forums.

I can only advise that you should be prepared to exercise a great deal of patience if you are expecting Acronis Support to be able to explain why your backup timing has increased from 197 seconds to 333 seconds..!

What you can expect is a shopping list of diagnostic data to be collected and uploaded to the Acronis FTP servers, some suggestions coming back following by a repeat shopping list of the same data, repeated when someone new from support takes over the case...!

If I sound somewhat jaded, then it is because this is exactly what I have been dealing with for 2 open support cases I am dealing with!  The most obvious comment is that no-one at Acronis Support actually reads support cases or understands what is being communicated!  They also seem to work from set scripts so are totally incapable of thinking outside of these guides plus refuse to escalate cases to their expert or development team!

Good luck with your case!

Walt,

I agree that TI 2021 is slower than previous versions.  I have seen this myself but certainly not an almost doubling of the time involved to do so.  Other than your comment of backing up SSD to SSD internal trimmed disks, you provide no other details about your system.  I will say that hardware and system configuration have sometimes big impacts on performance.

Given the above I can only compare my results against yours.  I use TI 2021 on a test bench machine.  The platform is:

• ASRock Z490 Taichi mobo
• Intel i7 10700K CPU @ 3.80GHz
• 32 GB GSkil PC3600 DDR4 ram
• Windows 10 Pro X 64 20H2
• Installed disks:

1. - 240GB Mushkin SSD for OS
2. - 500GB Samsung 860 EVO SSD for user data
3. - 2 x 1TB Samsung 860 QVO scratch disks
4. - 2 x 1TB Samsung 970 EVO Plus M.2 scratch disks
5. - 2 x 1TB Seagate SATA 3 HDD mass storage

The only installed apps on the OS disk are Acronis True Image and Firefox browser.  Other applications are installed to one of the 860 scratch disks.

This machine is on a LAN that hosts 4 networked storage device locations.  These consist of 2 x NAS's, 1 - WD MyBook 4TB disk attached via USB to a router. and another Windows 10 Workstation machine that hosts an MS Storage Space array device.

I run 4 scheduled OS disk backups scheduled daily.  They run to the 2 NAS devices, the networked HDD, and finally to 1 or the 970 scratch disks.  Two of the tasks are incremental method backup and the other two are differential.  The OS disk total data currently is 37.2GB.  All tasks have automatic cleanup enabled and store no more than 3 version chains before cleanup.  Number of inc or diff is either 5 or 6 (1 each for each method) completes the scheme.

Performance:

• HDD today ran a Full prior to cleanup - elapsed time 464 sec. followed by clean up which freed 18.3GB and then ran the next inc of 1.5GB in 82 sec.
• NAS 1 ran a Full 2 days ago no cleanup and took 222 sec. - today's diff took 150 sec.
• NAS 2 ran a Full 4 days ago no cleanup and took 392 sec. - today's inc took 97 sec.
• M.2 disk ran a Full today no cleanup and took 132 sec. - last diff took 211 sec.

The point here is to illustrate that performance varies and is dependent on may factors.  In the above data you can see that the M.2 diff backup took 79 sec. longer that the Full backup did today.  Now contrast that to the Full backup processing and writing to disk 37.2GB of data whereas the diff processed and wrote 3.6GB of data.  This is indicative of backup software products.  I have tested TI against several other products and I can tell you that overall TI is the leader in performance.  It may not win every time but overall it does outpace the competition.

Having said that I recognize that others here have had much worse results.  Personally, I believe that is due to backup task configuration not using auto cleanup to maintain a reasonable backup chain size mostly with hardware used secondarily to that.

Another factor with Ti 2020 and 2021 is that of disk scan and data processing.  These functions have increased or been implemented in a more robust fashion at the expense of some performance loss.  If you were to strip off the time for preparing data and shows as time calculation in the GUI and simply time the actual amount of time writing the backup file, these numbers would half what is reported in the Activity tab of the application.

In the end, I find TI performance to be acceptable.

Steve,

Thank you for the words of welcome.  Sadly, I have to agree with you that support these days for almost all products seems to consist of following a cookbook approach to every problem without really listening, followed by requests for a deluge of doc...then silence.  Plus, the chat agents seem to be tasked with handling multiple customers in parallel...little wonder the attention is not always there. Even in the follow-up email requests for this problem there are references to topics which were never discussed in the chat...I think the agent had my case confused with another.  Ugh.

Well, I hope that Acronis is different on this one.  And hope your cases turn out to have a resolution as well.

Thanks again for your comments. 

Walt

Enchantech, 

Thanks for taking the time to respond and provide detail.  I did not include detail in my first post because I was simply attempting to confirm others' experiences.   So here I go, config follows.

 i9-10900K, processor itself not overclocked
Asus Z490-A Prime mobo
32G Corsair 3600 memory, clocked at 3600
Samsung M.2 970 EVO, 500G (OS volume, backup source drive)
Samsung 1TB 960 EVO (backup destination drive)
Samsung 1TB 950 EVO
(All SATA storage simple AHCI, no RAID configured)
Windows 10 Pro 20H2
VMWare Workstation (installed, no VM's active)
MS Visual Studio, Anaconda Python
Odds and ends, e.g. Chrome, Office, etc. 

All backup tests were run with nothing active other than the normal background noise, with the exception of one test with sysinternals procman running for a minute to gather doc for Acronis). The destination drive was trimmed before each test, even though only 50% full. For each run ATI listed only 108.7 GB "Data to recover", so you have an idea of how much was backed up. These scenarios were intended to be as simple, straightforward, and controlled as possible. All elapsed times taken from ATI "Activity", with the exception of the "calculating" times which were timed manually. 

Test 1 (3:43 PM).  

• ATI 2019 17750 current version
• Backup job wg6-2021-04-01 created.  Full backup each time, all OS partitions on 970 EVO
• Backup runs 197 seconds.  Of that, first 61 seconds spent "calculating".  This is typical of times on this machine for recent months. 

Test 2 (7:24 PM)

• ATI 2021 39216 installed
• Backup job wg6-2021-04-01 run again (full backup)
• Since a legacy carryover job I guess, created a tib, not tibx file
• Backup runs 272 seconds, of which first 135 seconds were spent "calculating"

Test 3 (7:34 PM)

• Backup job wg6-newtest created. Full backup each time, all OS partitions
• Job wg6-newtest run, created a tibx file
• Backup runs 322 seconds, of which 131 seconds spent "calculating/examining"

Test 4 (7:42 PM)

• Job wg6-newtest run again
• Backup runs 333 seconds, of which 129 seconds spent "calculating"
• At 120 seconds in, procman was started, and run for about 60 seconds

I also ran a test with the ATI performance parm changed to "high" ...no difference in timings. 

Probably more detail than you wanted, but there it is.  While I agree that all performance is dependent on the machine resource, I doubt if there were any hardware bottlenecks in this config.  And yes, a significant part of the increase is spent in "calculating" and initial data processing.  If that is by design, I would love to understand what value has been added for the increase in time.  322 vs 197 is a 63% increase for full backup.  If this maps proportionally similar for much larger backups to slower devices, I can see why others are very upset.

Although I currently have no intent to abandon ATI any time in the near future (it is essential to me), I would like to better understand what value the increased time gives, and if it can be reduced back.  I use ATI on multiple machines...the time adds up. 

I will likely be running more benchmarks in the future, depending on response from Acronis.

Again, thanks for taking the time to respond.  Hope anything here is of interest.

Walt

Walt,

Okay, thanks for the detail.  Questions, with these tests 2,3, + 4, were they all the same task?  I understand these to be a new test but did you use the same task and just say change the destination?

Your best comparison here is between test 1 and test 2.  The reason for this is that test 1 numbers are for TI 2019 vs. test 2 numbers for TI 2021.

NOTE: .tib file format has been replaced with a new .tibx format for Disk and Partition backups only (folder + file backup still uses the .tib format).  The new format offers the advantage of superior data handling via use of metadata tracking, and disk health checks.  These functions are not available in the .tib format.  The trade off in using the new (since TI 2020) .tibx functions is that backup performance does suffer in exchange for a higher integrity factor for backups of full Disk and presumable partitions, I say presumably because I do not and have not used partition level backup.

So looking at your Test 1 we see that 197 seconds less a 61 second time calculation so 136 seconds or 2 min. 16 seconds for backup of 108.7GB.  Now test 2 shows that the total elapsed time was 272 seconds less 135 seconds of preparing data and time calculations or 407 seconds (6 min. 47 seconds).  If we strip out the 135 seconds for preparation and calculation from the total 272 we end up with 137 seconds vs. 136 for the TI 2019 product.  So we find that actual backup time has not increased significantly at all.  What has increased is preparing data and calculation times.  So again, the trade off is with data processing rather than backup write performance.

For your tests 3 + 4, if you did what I think you did here and that is you simply ran test 3 + 4 back to back using the same task, what you are actually doing is creating a Full disk backup chain of a single task.  This presents a problem that all users of the product have faced.  That problem is that the use of metadata tracking brings along with it a dependency of backup files that did not exist prior to the change to .tibx format.  This dependency means that all files within a backup chain are fully dependent upon each other with respect to file location on disk.  This means that if any file of the chain is found to be missing the entire chain is found to be corrupt.  So with each Full disk backup you make using the same task, the app must scan and calculate.prepare the other dependent files of the chain before backup file write begins.  Thus the increase in that time that you see in your tests.

The remedy for this is simple really, the user needs to adjust how the product is used when creating Full disk backs as well as those that use and inc. of diff. method.  For Full disk methods, you need to create one-off backup files.  So task configuration needs to be set to Non-scheduled, Custom Scheme, Full method.  this will produce a single backup fully independent backup file.  You can run the task as many times as you like but you cannot schedule the task to run automatically.  Scheduling is the trigger that starts a backup chain, remove it and performance consistency will be within 10 to 15 seconds between backups.

So in exchange for improved data integrity we sacrifice scheduling or rethinking our backup strategy to conform with the new operation.  I have done both.  As a result I enjoy fast backup times and as a result of my changes I actually reduced the amount of space required to maintain my backups.  So for me the change is a win-win situation.

Enchantech,

Thanks again. 

I understand your point about the chaining.  Therefore, from an example standpoint, it was not proper to run two full backups from the same task.  In actuality, however, each of the backups I run normally are separate tasks, custom, full backups with no scheduling, manually initiated, just as you specify above.  So, for my previous entry, the truly valid comparisons are really between test 1 and test 3, 197 for 2019 vs. 522 for 2021, the first runs for each task and version.  Only reinforces my concern.

So let me try the arithmetic again. 

I looked at my last three full backup jobs under 2019.  Their times were 201, 187, and 208, for an average of 199.  Assuming the prep/calc time was about 61 seconds again, that results in a copy time of 138 give or take.

Tonight I configured and ran three separately configured full backup tasks under 2021 on the same machine I had been using.  They ran  320, 318, and 321, for an average of 320.  Assuming the prep time is again about 130 (I retimed that again tonight), that means the copy time is about 190. 

So the comparison again is:

2019 – 61 prep time, 138 copy time

2021 – 130 prep time, 190 copy time

This is still much longer in both categories.  I am, of course, not qualified to say whether the longer prep time makes for a more robust product (more on that below).  But it seems puzzling that the copy time should take longer, particularly when the file size is smaller (which I DO appreciate), unless the compression algorithms are slower or the write process has changed.  

One additional thought.  I have Acronis protection turned off for 2021 as I did for 2019, since I use the product solely for backup.  In spite of that, is some malware scan now part of the prep phase?  I still don’t quite understand what improvements account for the dramatic difference in that phase.  Perhaps you could clarify further.

Regards,

Walt 

Walt,

You said:

I understand your point about the chaining.  Therefore, from an example standpoint, it was not proper to run two full backups from the same task.  In actuality, however, each of the backups I run normally are separate tasks, custom, full backups with no scheduling, manually initiated, just as you specify above.  So, for my previous entry, the truly valid comparisons are really between test 1 and test 3, 197 for 2019 vs. 522 for 2021, the first runs for each task and version.  Only reinforces my concern.

In test 3 you originally stated that the backup took 322 seconds, you now say it took 522, which is it?  

I think the above was just a typo as your 3 latest tests are more typical of actual times.

You mention drive trimming.  I am going to theorize here a bit.  I only trim my SSD's occasionally, maybe once every 3 months I'd say.  Now after I do that I notice the next backup on that disk will take somewhat longer to backup.  I believe this is due to running trim.  Why do I believe this?  So I have not definitive proof of what I am about to say and it comes from reading between the lines of the documentation if you will however, I have the idea or opinion if you will that the .tibx format makes use of the NTFS MFT and associated metadata to generate its own metadata database which is I believe performed during the preparing data stage of the task run.  I also believe that this additional metadata is created during the write phase and written to disk.  When you trim an SSD the disk controller logic marks all deleted memory cells as free.  This in turn changes the metadata for any such operations.  This is more so true for HDD's and defragmenting.  Since Windows 10 runs disk optimization automatically, I find that process good enough to not have to do this manually any longer.  There are occasions when I have been hammering a disk for awhile that I do run optimization.  Maybe you should back off the trim runs on your disks and see if backup performance improves.

I have to say that your last test runs here are comparable to my results relative to the differing total data sizes.  Like I said before, these times are perfectly acceptable to me and, I have yet to find a product that consistently runs faster.