Backup Performance in 2020

Glenn,

Could you provide further details? 

How much data total are you backing up?

Are you making backups of each of your disk independently using the Full Backup method?

Are you using the Entire PC backup method?

How are the external disk you are using connected to your computer, USB 2.0 - 3.0 ?

If using USB connection is a hub involved, case mounted port, or direct I/O port on back panel?

Hello.  I have two internal drives in my desktop, and what I've been doing for years is running independent backups of each.  Each has around 1.5 TB of data, and I'm backing up to external 10 TB USB 3.0 drives that are directly connected (no hub).  I haven't tried doing an "Entire PC" backup.  Each drive has a separate job that runs independently.  I never had problems until True Image 2020.

I've been doing more testing.  For this I created a job that's not scheduled, so I can just run it manually.  No validation, no compression, no splitting, but I do have AES 128 encryption turned on.  I made it high priority, too, though during my testing I wasn't doing anything significant on the desktop.

Here's what I found:

The first time I run it, it takes about 3 hours.  If I run it again, it takes about 8 hours (same if I run it a third time, etc.).  If I delete the backups in the destination folder, the next backup goes back to taking 3 hours.  So, I can run it, delete the backup, run it again, and keep repeating, and every time it takes about 3 hours.  But if I leave one of the backups there, the next run (and subsequent runs) takes about 8 hours.  Here's where it really gets interesting:  If I simply rename the backup file (instead of deleting it), the next backup will take 3 hours.  First I renamed it to x.x, and the next backup took 3 hours.  Then I kept the extension and renamed it to x.tibx, and it still took only 3 hours.  So it's not about the space on the destination drive or the fact that there is already a tibx file in the destination folder that is causing the problem.  It is the fact that there is already a tibx file in the destination folder and that the software recognizes that file as belonging to this backup job that is causing the backup to take several times as long to run.

Hopefully this provides some clues.

Thanks.

Glenn

Glenn, have you opened a support ticket direct with Acronis for this issue?  If not, then I would recommend doing so as we cannot fix these problems in the forums if they are caused by the code or design of the ATI application.

Thanks, Steve.  I'll open another ticket with them.  I initially opened one before I had done all these experiments and the response I got was essentially "tibx is slower than tib".  I didn't feel that was an adequate response, so decided to post here in case someone had any info.

I find this thread interesting. Glenn, are you able to run the Performance Monitor while the backups are running? It would be interesting to see if there are bottlenecks caused by the USB connection, the read/write speeds of the backup device or possibly being low on memory and causing some thrashing.

The required presence of the previous backup says that it is being used in the process, probably continually. If there's constant extra reading (and possibly writing) involving the first .tibx, that would be good to know. I seem to recall that after each backup, the previous backup's timestamp is updated, but we don't really know what is going on.

Are you able to test by running a backup from one internal drive to the other? I'm guessing that may be difficult, but if you can set up a job to eliminate a large chuck of data from the back via exclusions it may be possible. Just thinking about comparing an internal disk destination to external.

Hello, Bruno.  Good questions.  I did some more testing.  There's plenty of free memory and the available CPU, so that's not the bottleneck.  I haven't tried backing up to the other internal drive.  I'm sure it would be faster than going to USB 3.0 drives, but my focus has been on trying to figure out why the first backup is about as fast as it was with True Image 2019, but subsequent backups are much, much slower.

Using Performance Monitor to look at Disk I/O on the USB drive gave me some interesting results, but it's not clear that it's a complete explanation.  I ran it first when there was already a backup file in the target location, and I saw constant disk reads, but in terms of bytes/second it was only about 1-2% of the disk writes to the USB drive.  Still, it seemed odd that it was constantly reading from the disk.  I deleted the second backup file created and renamed the original backup file and ran it again.  Now the disk writes in terms of Bytes/sec are higher, though only about 25% higher (not 3X, as I expected).  I still see disk reads, but they are not constant and the read bytes/second is maybe a tenth of what it was in the previous try.

In my experience the time stamp on previous backup runs isn't updated.  At least with the tibx files (I never really looked with previous versions of the software).

I submitted a ticket to Acronis support earlier, so if they come up with an explanation/solution, I'll post it here.

Glenn, what is the drive you are backing up to? I ask because various drives have such differing performance specifications and maybe you have a drive which does not handle what Acronis is doing very well. That's why I was asking before about running a test backing up to the other internal drive.

I'm seeing a similar situation on my Wife's ATI 2020 b25510 on a Windows 10 Pro machine.

I did open up the TASK MANAGER and looked and ATI2020 had little or no CPU usage? Looked at the PERFORMANCE tab and the backup external USB drive was at 100% usage... about 25MBps speed.

It was around 9 hours to write a 570GB backup file.

I'm going to investigate further today and open another thread on this as there were other issues her PC had (like lost settings it seems). One thing I have to look at is how the USB drive is connected. This is a Dell XPS and has 3 locations for USB ports. The drive in use for the backups is a USB 3.0 WD MyBook (new version). I run the same on my PC and I do NOT see this write speed issue? Suspect it could be where the drive is plugged into on her PC.

None the less, 9 hours seems insane for a backup?

Hi, Bruno -- My external hard drives are WD 10TB Elements external drives.  They're USB 3.0, and about a year old.  I'm sure the drive and USB 3.0 do limit the performance in some way, but I keep coming back to the fact that with True Image 2019 it took a bit less than 3 hours to back up about 1.5 TB, and it's about the same amount of time with True Image 2020 (after I changed some of the settings to match what I was doing before), but only for the first backup.  Subsequent backups take anywhere from 8 to 11-1/2 hours.  I have two internal hard drives, so after the first round each backup is taking almost a full day.

Irv -- If you were using a previous version of ATI before, check your settings.  When I upgraded to 2020, it kept my existing backups, but it changed them from full to incremental, it changed the splitting, it changed the encryption, etc.  I deleted the jobs and created new ones with the settings I wanted.  As far as the performance on your wife's computer is concerned, it could be the same issue as mine and/or some of the changed settings, but I would also check that you have the drive plugged into a USB 3.0 port, not a 2.0 port.

Thanks.

Glenn

The latest on this is that Acronis tech support got back to me the other day with a recommendation to do a complete uninstall and fresh install, but that didn't help so I'm back to waiting for them to respond.  :(

Glenn

I, too, an having the slow backup performance issue since upgrading to Acronis True Image 2020. As an example, my last full backup of 1.5 TB took 15 hours and 45 minutes in a backup speed of 151.0 Mbps. Incremental backups are far slower than the full backups (see attached image).

NumberCruncher,

Your screnshoot definitely shows a problem with your data transfer speed.  Not sure if your issue is the same as the OP but I am thinking not.

I suggest that you open a support case with Acronis and see if you can have them remote in to investigate.  My guess would be faulty hardware, bad connector, cable, etc. but if you can have an tech take a look they should be able to help you.

Enchantech,

Nice to hear from you. Thank you for your feedback.

In the German forum there is a thread containing the information that Acronis support could provide you with a 22840 build (maybe beta quality yet). According to some people having it should have much better performance ratings when the computer is idle (slows done when you work and then becomes fast again when you don't work).

If your problem is not hardware related (previous versions working fast), this could help.

Don't have it myself, can only tell what I have read.

ATIuser,

Thanks for that. 

I don't believe I have a hardware related issue. 

I have multiple computers using Acronis TrueImage 2020 each backing up to a different NAS server. From this information, I could confirm that the super-slow backup times on my primary computer, were not just an isolated incident on a single computer/NAS setup.

Every Acronis TrueImage 2020 backup on each NAS server was much, much slower than previous versions of Acronis TrueImage.

I have requested a copy of build 22840 from Acronis tech support.

NumberCrunch...

I have attached a screenshot of my speed results.  I agree that differentials and probably incremental backups are dreadfully slow but my Full Backup seems to be speedy.  Special Notice to the difference between the 1st full backup and the last full backup.  System is Win 10 Pro,AMD running at 3.4 gh with 32 gig mem.  The backup storage device is a 2TB Seagate Barracuda external SATA connected HDD.

Regards, Steve F.

Steve F,

Thanks for taking the time to respond. I appreciate your input.

Since my last post, I have contacted Tech Support and received a copy of build 22840. Unfortunately, with build 22840, I'm still not seeing an improvement in backup speed.

I'll continue to work with Tech Support and hopefully find a solution soon.

Thanks again for your input.

For what it's worth, I think that the speeds in 2020 have been inconsistent for different people and still see different threads about it.  The majority of those initially identified were due to having validation enabled (which we now know is compounded across all backups in task, and not just the current chain!).  Not the case here since you aren't validating though (double check the logs to be sure!)

After that, Perdido Beach, myself, G. Uphoff and others noted that backup speeds were (and still are) inconsistent with incrementals and differentials when compared to fulls.  To date, I have not seen a fix for this so am hoping that the new build addresses that to some extent. Not relevant here either since these are always fulls.

As for fulls, I see fluctuation, but nothing too crazy.  I can't explain why 2019 wouldn't have an issue, but 2020 would unless it's something "new" under the hood, but then I'd also expect that to be brought up my more people if it was occurring more.  Not that it is out of the realm of possibility since it's happening to you!

However, you may want to test a bit more to see if some setting changes help at all.  For instance, a single 1TB backup file is huge and could be an issue anyway - again not sure why 2019 would be OK with it and not 2020, but that's a big file, regardless.  I've gotten into the habit of creating the .tibs in blu-ray size (25GB - which I still feel are really big - especially when pushing across a network and/or to a NAS that might have limited CPU or memory too).  Maybe try smaller chunks for the .tib / .tibx files just to see if it helps at all.

If the destination disk is fragmented, or if it does not have a large enough "contiguous" blocks of free space, the writes to it will be fragmented on those large files and you're going to see a performance drop as a result.

Also, how full is the destination drive?  Rule of thumb for me is to try and always have at least 10% free. Granted, that's not always possible when you have large 10-12TB drives out there now, but keep that in mind when you're creating 1TB .tib/.tibx files.  It has to fit somewhere and True Image is processing the raw data into the format at the same time, plus who knows what else (network speeds, drive fragmentation, CPU/memory resources on the PC or the destination device/NAS), heat, etc.  

I have been using Acronis True Image 2019 since Jan 2019. I have used it daily to perform local backups of my Windows 10 C: and an internal D:. I have been using a couple of old WD MyBook desktop drives on USB 3.0 as backup targets, one of which has been giving me problems. So last week I purchased a new WD 6TB BLACK drive and put this in a desktop docking station which is attached to the PC via USB3.1. It is now my backup target drive. I can easily dismount and unload the drive when backup is done.

My C: drive is a fast, reliable SSD. SAMSUNG SSD 960 PRO 512GB.

I have recently, Nov 2019, upgraded to Acronis True Image 2020.

It is only now, as I am getting acquainted with the new 6TB drive, and building new backups, that I notice that after an initial backup, which is fast, the subsequent backups are increasing slower, and take longer. What I notice in Task Manager is that I see read and write rates that are no where near what the disks are capable of.  I watched the disks while I performed the initial backup and the SSD has amazing read rates, and the WD 6TB 7200 RPM has quite respectable write rates. The second backup could not repeat these amazing read/write rates. After 7 backups I thought maybe the new disk was filling up, maybe fragmenting. So I created a new backup today, using the same target, and it ran great, just like the initial one I made last week. See attached spreadsheet of numbers.

If this progression continues, soon it will take all day just to backup my C; drive. weird.

Peter

Peter, are you using validation in the backup settings as well, or not?  If so, that can be explained. 

If not, then I would suggest opening a ticket with Acronis, reference this thread and request that a developer or higher tier support be directed to the case.  If this behavior is happening on multiple systems from different users, simply from using a full backup scheme and no validation, I'd say this is definitely an issue. 

The problem with identifying it though, seems to be that it is not consistent (I'm only using 2020 on some test VM's writing the backups to a NAS, but not seeing the deteriorating speed behavior with just full backups).  I can, and do, see deteriorating speeds with incremental and differentials though and have seen that behavior on my test systems since the beta. 

Ultimately, I think Acronis is going to need to see some of these cases "hands on" from support tickets to pinpoint what is causing the behavior on the systems it's occurring on.  I don't experience this issue at all in 2019, but seems like it's happening in 2020 for more than just some.  Hopefully, some other users and/or MVP's can run some additional full-only backups and post their results too.

I was using validation for the first few backups, but I had the same thought - that it might be the reason the backups took longer each time. So I turned the validation off and the next backups continued to run slower. In any event, I don't think the time spent on validation is recorded within the time spent on the successful backup.

Peter

Bobbo_3C0X1,

I appreciate your input.

Re: “However, you may want to test a bit more to see if some setting changes help at all.  For instance, a single 1TB backup file is huge and could be an issue anyway - again not sure why 2019 would be OK with it and not 2020, but that's a big file, regardless.”

What you say certainly seems logical. I have Acronis True Image 2020 running on 3 separate computers, each backing up to a different NAS server. I have attached the activity logs of each of the 3 computers’ Acronis backups. 2 of the backups are much smaller than my main ~1TB backup and the incremental backups are incredibly slow.

I have been working with Acronis Tech Support for the past 4 weeks to get this issue resolved. I recently received the following request for additional information from Acronis Tech Support:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I request you to please collect the following logs and upload it to FTP link to investigate further:

1. capture a photo of the error message (if any)

2. Acronis system report: https://kb.acronis.com/content/56652

3. Process monitor log: https://kb.acronis.com/content/2295

4. Pcap log: https://kb.acronis.com/content/1763

5. NAS and computer IP address.

6. short video illustrating the issue

7. Screen shot of size of source you are backing up.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I performed the tasks and sent in the requested information. Today I was told to: “I suggest you to remove Acronis True Image 2020 using clean up tool reboot the PC and reinstall Acronis True Image 2020 create new backup to NAS share the outcome.”

I will try the last steps suggested by Acronis Tech Support, but I am seriously considering going back to a previous version.

Thanks again for your input.

Numbercrunch, I hope the info helps Acronis find the culprit.  I definitely see slowness in the incrementals and differentials too, going back to the beta. 

It seems to get slower and slower with each additional inc or differential and then the fulls pick up speed again and the slowness starts over.  My guess, is that the .tibx format is still reliant on all of the files in the version chain since it tracks the metadata throughout them all and even seems to have some dependencies of that meta data for recovery, when files from a different chain, but the same backup task, are missing (i.e. in the old .tib format, people could get away with manually copying any full .tib or an entire chain somewhere and still be able to recover from it - even if there was a chain before or after that one - not the case with .tibx for a lot of people now.... each full backup or each backup chain should be completely independent of anything else).

Bobbo_3C0X1,

Thanks for your input. Your take on the difference between the .tib and the .tibx files is interesting.

As instructed by Acronis Tech Support, I have removed Acronis True Image 2020 using the cleanup tool, rebooted my computer, and reinstalled Acronis True Image 2020. Unfortunately, my incremental backups are still abysmally slow.

I would like to thank everyone who took the time to respond in an attempt to help. Your input is greatly appreciated.

Bobbo_3C0X1 wrote:

Numbercrunch, I hope the info helps Acronis find the culprit.  I definitely see slowness in the incrementals and differentials too, going back to the beta. 

It seems to get slower and slower with each additional inc or differential and then the fulls pick up speed again and the slowness starts over.  My guess, is that the .tibx format is still reliant on all of the files in the version chain since it tracks the metadata throughout them all and even seems to have some dependencies of that meta data for recovery, when files from a different chain, but the same backup task, are missing (i.e. in the old .tib format, people could get away with manually copying any full .tib or an entire chain somewhere and still be able to recover from it - even if there was a chain before or after that one - not the case with .tibx for a lot of people now.... each full backup or each backup chain should be completely independent of anything else).

I think it is this reliance on an initial backup that is causing a lot of the consternation and problems with folks moving to 2020.  Due to this reliance TI2020 simply doesn't operate like the 10-13 years of TI before it.  That is a lot of experience and user comfort to throw out the window.  I have taken to using 2020 to delete my previous full backup and building a new one each time I do a Full BU which is everytime I BU.  I used to use Win Exp to do that clean up.  I learned the hard way that does not work with 2020.  I also have learned the hard way that 2020 can't find old backups that have either been renamed or have been moved.  I have 8 drives in each of my main PCs and only operate one as an OS drive and that is the one I am backing up full and regularly.  But I have had to go to this Acronis TI2020 cleaning and deleting method everytime I do a new BU.  I am also keeping only one full BU on each BU drive.  Most of my drives are NVME 2 TB including the OS drive so I am not out of space.  I do have a small handful of SSD 2 TB drives I use occasionally but as they move at SATA3 speeds I prefer the pcie and chipset speeds of the NVME drives.  I suppose I can say that with these changes in methodology at least 2020 works even if not in the way the previous iterations did. 

William,

I concur with your post.  I too run multiple M.2 drives, create Full backups and find the same results as you have. 

Steve Smith has created a very useful post command script file for moving and archiving one time full backup files.  It is linked Here

If you wish to try this script to archive some backups to an external drive or another disk create you task as Non-Scheduled - Custom Scheme - Full Method.

You will need to adjust the script to point to you your destination.

As suggested by Bobbo_3C0X1, I did contact Acronis technical support on Feb 11. They started a ticket and offered some basic suggestions, which didn't change the problem. They then asked me to collect 1) screen shot of Activity tab, 2) process monitor log while backup is running, 3) Acronis system report and upload them to their FTP server. I did this on Feb 17. So far they have not got back to me and when I reached out to them ... "We are are checking with our experts regarding the issue and once we get an update will notify you via email."

I have continued to perform backups using the new format and tracked the performance in a spreadsheet - see attached JPEG screenshot.

In the meantime, I found that I could clone some older backups which were created under ATI2019, and change the destination to point to my new backup disk. These backups run fine and create .tib files. They do not exhibit the performance problem I am having with the .tibx format backups.

Peter

Peter that's great background info.  We don't have much way to help get your ticket more review, better response.  I'd recommend sending a PM to 
 

forum moderator Ekaterina

and/or

product manager Renata

Glad you have a work-a-round in the interim with the earlier product cloned jobs using the old .tib version too. I'm still primarily using 2019 myself.

See forum topic: How to create a Disk backup as .tib (not .tibx) which will create a new backup task using the older .tib format in the Windows ATI 2020 GUI.