Current status of 2020 performance issues
I've about had it with Acronis True Image. I've been a user for around 10 years now and up until version 2020, have been happy with no issues. I'm had it with this version and am seriously looking to find an alternative. Before I do, can anyone provide a simple update as to what, if anything, Acronis is doing to address the numerous complaints/issues in regards to the performance issues?
Without getting into a full discussion about it, I have always made single full backups without a schedule. What use to take 20-30 minutes to backup now runs 1.5 hours or so. Validation use to take 10-15 minutes, now take around an hour. The exact same set-up and hardware, the only difference is "upgrading" to 2020.
I've read many of the threads, but there are so many dealing with performance problems and it seems that Acronis is remaining almost silent on the issue. I don't want to deal with work-around fixes, I just want a product that works as expected and the way it has for years. It would also be nice if Acronis openly addressed the issues, rather than saying nothing about it and letting users find out the hard way.
Someone at Acronis needs to do a massive PR campaign to keep people like myself from leaving this product behind and looking for a replacement.
I'm seeing performance issues with cloud backup as well. In particular, it seems like something happened on April 15, 2020. Prior to that backups of my C: drive took about 20-30 minutes. Since then they take 3-5 hours. And most of that time, by far, is with the progress bar stuck at "less than 1 minute" remaining. I've got an open incident with support, but they don't seem to get that something has changed, and that other people are seeing issues as well.
Does anyone know what it's doing when it's stuck at the 1 minute to go mark?
Also, once a backup completes, if I immediately start another backup, it takes another 3 hours and backs up the same amount of data. Why would that be? These are incremental backups. In my experience with other vendors, the second backup would barely take a minute.
Is there a way to get a list of the files selected for backup?
Jim, welcome to these public User Forums.
What version of ATI are you using here for your backups to the Acronis Cloud?
If you have an Activity page showing in the ATI GUI, then check that page for your Cloud backup task and see if it mentions 'cleaning up' as this is known to happen with 'less than 1 minute' showing but can take hours to complete!
What type of backup is involved here? Is it a Disk backup or one of Files & Folders?
What schedule is set for the backup?
I'm seeing similar behavior, incremental cloud backups used to take 15-30 minutes, now they take around 1.5 hours, with a lot of time spent on "less than one minute" with the backup speed at a very low rate, around 50-75Kbps. Once the backup is done, the activity screen says the backup ended at a particular time, and the cleanup ended at the same time. My typical incremental backup size is 400-700 MB. A few weeks ago, cloud backups stopped completely for a couple of weeks, with the "Can't obtain the box.." error message, then started working again. I'm running ATI 2020, Build 25700.
One possibility is that you hit you cleanup rule activation point. You should be able to work that out from the activity TAB. Several other possibilities suggest themselves to me; your ISP has put a choke on some types of uploads/downloads or there is significantly increased demand resulting in time blowouts (an indication of the later would be high ping time), increased demand on the server to which you are backing up (related to much larger number of people working from home), or a misconfiguration/reconfiguration of the Acronis server you are backing up to. I have seen what turned out to be configuration issues cause weird cloud backup behaviours during early beta testing of both ATI 2020 and ATI 2021.
I a guilty of not monitoring backup times. I have a lot more backups going on at the moment, particularly to the Cloud, as I have 4 PCs running the first beta of ATI 2021, so there is frequently one or more backup task running.
Ian
Thanks, Steve! I'm running ATI 2020, Build 25700. It is an incremental disk backup to the cloud for the C: drive, which is a Samsung 1TB SSD with 32% in use. The backup runs daily at 10pm. It does appear that the bulk of the time is in the cleanup. I've attached screenshots of the activity pages from March and from June. You can easily see there's a significant drop in speed. Further, from looking at the activity log, that drop seems to have occurred right at 4/15/2020. Before that date, fine...after...not so good. I've also attached a screenshot of the activity log right at the 4/15 point. Even though it's a small sample, it really looks like something happened on 4/15...no backup occurred on that date, after that it's slower.Speedtests run while it's stuck at the one minute point show the network is fine.
I probably wouldn't have even noticed this slowdown, except a week or so ago, it started outright failing with the same "Can't obtain the box..." message MrVivona reported or "Destination is unavailable." As I was looking into that, the backups started working again, but then I noticed how slow they were.
fwiw, I would have thought cleanup would run as a server-side function without a lot of chatter with the client. And I certainly don't expect cleanup to take 10 times as long as the actual backup!
Jim, thanks for the further information and screen images. The latter does not show a difference between when the backup finished and when cleanup completed (which it used to do when I reported similar issues last year), so it looks like Acronis have effectively hidden the cleanup time within the backup time rather than move the cleanup function purely into the cloud side as you and I would both expect!
I can only recommend that you raise this direct with Acronis by opening a support case. Please check that you are storing your Cloud backups on the nearest Cloud servers to your geographic location.
See KB 4350: Acronis Backup to Cloud access ports and hostnames - for details of where all the servers are and what ports they use.
Use the above in conjunction with the Acronis Cloud Connection Verification Tool.
Steve, I confirmed it's using cloud-wr-us2 for backup, which appears to be in Phoenix, AZ...don't think there's a better choice. Ran the cloud connection verification tool, which seems to show everything's ok...but it does end kind of funny...fills the window and then just sits there. I've attached a screenshot. Please let me know if that doesn't look right. Re-sizing the window doesn't show anything else.
I've got a ticket open, but it's been frustrating. They keep asking for data, which I keep providing, but it's not clear that anyone has actually looked at it. By contrast, you immediately noticed the identical timestamps on the cleanups.
I'd be perfectly happy if the answer was that we're aware of a problem and we're working on it. But something has changed, and it's not clear that anybody realizes or is acknowledging that.
Jim, your screen image of the connection tool is normal and has been doing the same for as long as I can remember!
The only other suggestion (while waiting on your support case) is to take a look at the backup_worker logs to see if they contain any further information at the time when the task looks to be sitting on 'less than 1 minute...'.
The backup_worker logs are not shown by the MVP Log Viewer tool because the tool was created before their use, so it is a manual process to review them until a new log tool becomes available.
The logs are at: C:\ProgramData\Acronis\TrueImageHome\Logs\backup_worker\ and the time stamps should help you identify the correct one. Note: they can be very large files!
Steve, I ran another backup to get a clean log file. It seemed to take about 40 min to backup and another 2.5 hours to do whatever it's doing. Thanks for the worker log tip! It generated 2 logs: backup_worker_2020-06-19-19-16-54.0.log (716KB) and backup_worker_2020-06-23-13-49-58-0-log (5.3MB) I've attached the shorter log intact and excerpts from the longer associated backup worker log. In that log, from 13:49:58 to 13:50:00 it seems to be doing setup and then I'm guessing a bunch of file backups (where message=#io1 and astor_client=1) Pity it doesn't show file names, but it seems to be showing offsets into the archive.
At 14:29:55 we see what looks like finishing up of the backup. Immediately following that, there's a bunch of activity that looks similar to the above: message=io#1 readfile different offsets in the archive slice, but now astor_client=2. This seems to be where we're spending all this time...it runs until 16:58:13. The remaining log entries only take until 16:58:21.
Any ideas? Any chance it's re-reading all the files from the archive to verify them unnecessarily? That is what we have checksums for, after all. :)
Jim, thanks for the logs, I am seeing errors here that really need to be analysed by Acronis as (to me) are indicating issues at the server end of things!
I have pruned a section of the log that show the errors and attached in PDF format.
The key sections are as snipped below:
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#1.conn_co#3: rq#0: gw closed the connection prematurely;
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#1.conn_co#3: failed to do communicate_handshake: -13 (Peer did not respond or did not hold deadline);
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#2.conn_co#2: rq#0: gw closed the connection prematurely;
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#2.conn_co#2: failed to do communicate_handshake: -13 (Peer did not respond or did not hold deadline);
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#2.conn_co#1: rq#0: gw closed the connection prematurely;
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#2.conn_co#1: failed to do communicate_handshake: -13 (Peer did not respond or did not hold deadline);
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#1.conn_co#4: rq#0: gw closed the connection prematurely;
23/06/2020 09:07:34:784 AM type=log; level=err; message=cl#1.conn_co#4: failed to do communicate_handshake: -13 (Peer did not respond or did not hold deadline);
23/06/2020 09:07:34:784 AM type=log; level=inf; message=cl#1.conn_co#5: connecting to 162.244.6.115:44445;
23/06/2020 09:07:34:784 AM type=log; level=inf; message=cl#1.conn_co#6: connecting to 162.244.6.111:44445;
23/06/2020 09:07:34:784 AM type=log; level=inf; message=cl#2.conn_co#7: connecting to 162.244.6.115:44445;
23/06/2020 09:07:34:784 AM type=log; level=inf; message=cl#2.conn_co#8: connecting to 162.244.6.111:44445;
23/06/2020 09:07:37:574 AM type=log; level=inf; message=cl#1.c#7: id is 2d1f260e1c5830919f3646576161b410;
23/06/2020 09:07:37:574 AM type=log; level=inf; message=cl#1.c#7: srv is 162.244.6.111:44445, Acronis Storage 2.6.113;
Then at the end of the section:
23/06/2020 09:07:38:361 AM type=retcode; value=0; id=15726;
23/06/2020 04:58:21:596 PM >>> exit
Don't think Acronis has a Tardis (time machine) to do a final exit over 4 hours before the previous entries!!
My attached activity log looks very similar to Jim Mac's. Very slow upload speed by comparison to months ago and much longer backups for the same size incremental backups. I suspect the problem is at the Acronis server end. I haven't had the time t dig into the logs or pursue this with Acronis. I will sure be interested in what Acronis finds for Jim Mac.
I suspect there could be an issue here. In May case it may have something to do with running beta of ATI 2021 and some associated Replica problems. Will investigate and report back.
Ian
Unfortunately, I am thoroughly unimpressed with Acronis technical (and I use the term loosely) support. After spending hours and providing much data, they just keep saying there must be a network problem. This despite their own tools showing the network is fine. Further, that would not explain why every single backup takes longer now by a factor of 5-10 times. Nor would it explain why other users are experiencing this same slowdown.
I'm curious to see if Ian can pin anything down. The Help desk is pretty much useless.
Ok, we seem to have a work-around! Tech support eventually suggested un-installing ATI, re-installing and doing an entirely new clean backup of the C: drive. I did that...the backup took 2 days and 11 hours, which seems excessive. Average upload was 4 Mbps, but Speedtest run during the backup shows additional upload capability of 17 Mps, so bandwidth is being left unused.
But now incremental backups to the new backup run at their old, faster speeds. Woo hoo! No hours long delay at 99%.
Incidentally, incremental backups to the old backup continue to take 3-5 hours. I've attached screenshots of the activity logs so you can see the difference.
It seems to me the un-install/re-install may not be necessary...the key seems to be creating a clean new backup, but if you're going to wait a few days for the backup, it would certainly suck to find out that the re-install was necessary after all.
Now, in the realm of speculation: the slowdown started for me around 4/15. As near as I can tell, that is about the time of the deployment of Build 25700. Which makes me suspicious that that there was something about the format of the data on the servers that the new build took longer to clean up. A clean backup would have any new format changes, and seems to have no problem cleaning up now. Or it might be something else entirely.
Jim, interesting suggestion about the possible relationship to the latest build. Cannot find any firm evidence of a link. Quick look at one backup task shows high variation in average speed (not sure if it is related to cleanup process - would take some time to work that out) but nothing exceeding 20 Mbps, some less than 10 Mbps.
Ian
At the suggestion of tech support, I did a new, clean backup to a different data center. Normally, ATI goes to Phoenix (I'm in Connecticut in the US) I picked Germany. The backup took 17h 24 min for an average speed of 11.5 Mbps. By contrast, a clean backup to Phoenix took 2 days 11 hours for an average speed of 4.0 Mbps. So roughly 3 times longer to go to Phoenix. Subsequent incremental backups differed by a similar ratio.
Speedtests to both data centers showed comparable upload bandwidth. But the backups to Germany used much more of the bandwidth.
So for now, I'm doing all my cloud backups to Germany and I'm finding the performance satisfactory.
If anyone else cares to try this and finds comparable improvement, please report this to Acronis so they can see that there really is something going on with Phoenix.
Very strange if you are getting better performance using a data centre in Europe versus one close to you!
Steve, not as surprising as one might think: the number of hops is more significant in this case. I was kind of shocked to see that it took 12 hops to get to Frankfurt, but 21 hops to get to Phoenix! I've attached the two tracerts to illustrate.
Given that many more hops, it is perhaps not surprising that there were multiple instances of dropped and out-of-order packets going to Phoenix, while there were none going to Frankfurt. Although recovered, these would have an impact on TCP/IP thruput.
I noticed the Frankfurt data center appears to be using Level 3 for their networking. Level 3 is well known to me and obviously performs well. Phoenix appears to be using "zayo" which I've never heard of and don't know anything about. But looking at the additional hops and the packet statistics, I'm not too impressed.
Germany is definitely going to be my data center of choice now. lol
I just did a tracert to my local data centre in London which is less than 40 miles away and see 12 hops.
C:\Windows\System32>tracert 62.138.203.222 Tracing route to ma2003899.psmanaged.com [62.138.203.222] over a maximum of 30 hops: 1 9 ms 10 ms 9 ms 192.168.0.1 2 51 ms 56 ms 56 ms 10.158.28.1 3 39 ms 39 ms 30 ms winn-core-2a-xe-133-0.network.virginmedia.net [62.253.121.237] 4 * * * Request timed out. 5 42 ms 39 ms 38 ms m686-mp2.cvx1-b.lis.dial.ntli.net [62.254.42.174] 6 43 ms 44 ms 46 ms 213.46.174.118 7 41 ms 81 ms 62 ms ldn-bb3-link.telia.net [62.115.122.188] 8 60 ms 60 ms 65 ms prs-bb3-link.telia.net [62.115.134.92] 9 67 ms * * ffm-bb1-link.telia.net [62.115.123.12] 10 97 ms 75 ms 71 ms ffm-b1-link.telia.net [62.115.141.237] 11 114 ms 71 ms 63 ms plusserver-ic-324767.c.telia.net [62.115.156.42] 12 73 ms 73 ms 55 ms ma2003899.psmanaged.com [62.138.203.222] Trace complete.
Steve, I'm not surprised...a few hops to get thru your ISP, a few in the backbone and a few through the data center's ISP...you can hit 12 in no time. By comparison, I did a tracert to speedtest.net's server in Phoenix (as opposed to the Acronis speedtest server presumably in their data center). It only took 13 hops with time around 77ms, compared to the 21 hops and 100ms time to get through whatever network Acronis is using in Phoenix. So it is possible to reach Phoenix faster and more reliably. And apparently by using Level 3 just as the German data center does.
At least there's a workaround. Doing a clean backup seems to have eliminated the long delays at cleanup. And using the German data center has resulted in much faster backups overall.
I'd be curious to see what routes other users in the US are getting to Phoenix and with what kind of latencies.
Jim,
See KB 4350: Acronis Backup to Cloud access ports and hostnames - for details of where all the servers are and try doing a tracert to some of the other US data centres to see if they all give similar numbers of hops?
Steve, thanks for the link. Turns out I get high hop counts and ping times over 100 ms to all those US destinations. I was almost ready to leave it at that, but then I tried putting a packet sniffer on during an actual backup to Phoenix and checking the IP address for the backup server actually in use. The IP address in one case turned out to be 162.244.6.109 (it varies from backup to backup presumably because load balancing) Tracert to that address was only 12 hops with ping times of 78 ms. Comparable number of hops and latency I get going to Germany. But the backup to Phoenix takes 3-4 times longer than to Germany. So much for the network theory. Seems like it has be something going on in the Phoenix data center.
Now I'm doing all my cloud backups to Germany. And, possibly because these all started as clean backups on the latest version, I'm not seeing any long delays on cleanups either. Good performance all around.
I haven't heard anything from Acronis support in awhile...they have all the data showing the variation between Germany and Phoenix. I have no idea if they're actually looking into Phoenix for a problem, but I'm not holding my breath.
cheers, jim
I am still having the same problem as I mentioned above, 1.5 hours to back up 400-700MB incremental backups. I am on the US2 server which I understand is in Phoenix. From what I am reading in this thread, the problem appears to be with the Phoenix server. It would be very helpful to have an Acronis representative comment here on whether this is a known problem that is being worked on. I know I could change servers, perhaps to Germany, but I have a 475GB backup size and don't want to go through the long initial backup phase if the Phoenix problem is going to be resolved by Acronis.
What puzzles me is that there are only a few of us reporting a problem in the forum. Does that mean it is a problem isolated to a few users or just that many users only know of a problem if a backup fails, so a slow backup doesn't get any attention?
MrVivona, there are two problems here you may be hitting. One is what seems to be slower processing in Phoenix. The second problem, which the timings you give for incremental backups make me suspicious you're getting, is the long delay during the cleanup phase after an incremental. What seemed to help here is making sure you're on the latest versions of the ATI software and then doing a new, clean backup. That helped tremendously with the incremental timings. And if you have to do a new clean backup anyway, it might be worth trying the Germany data center, especially if you're on the east coast of the US.
I finally gave up on the excessively slow backups to the Phoenix data center. I created a new cloud backup and chose the Germany data center. Incremental cloud backups of 500GB now take only 20 minutes, including cleanup, instead of the 1.5 to 2.5 hours it was taking for Phoenix. Actual upload speeds are also substantially faster now. So, there is definitely something about the Phoenix data center that doesn't work for some of us. The lack of mention on this forum seems to indicate that it is not a widespread problem and probably will not get fixed.
It would sure be great if an Acronis employee would comment on this issue.
This is one of my Windows 7 problems, along with very intermittent successful .tibx backups after upgrading (with Steve Smith's help) from 2019 perpetual to 2020 subscription.
Now Customer Support are saying I must update further to 2021 (which seems to have a slew of problems) before they will continue to help me although I've seen issues about this on this Forum, so I need help here and surely any Beta NDA restrictions cannot apply any more as Acronis are washing their hands of 2020 support? My main issue is .tibx OS or data (~1.3TB) Disks & Partitions backups taking a long time then failing ~25-75% progress.
The error message is usually 'The network share is inaccessible' but once I saw a 'volsnap is missing' message. Customer Support did point to KB63024 where they did a remote registry edit to add volsnap, but it prevented restart and had to be repair / restored.
On a new Win 10 laptop, I did a fresh 2020 install that seems to work fine and has both volsnap and fltsrv in the registry. The latter is present on all Win 7 devices, but KB 48668 Cleanup tool recommends removing fltsrv from the registry.
After 3 months of unsuccessful trying, please advise what to do. Thanks
Windows 7 is problematic as it is now out of long term support.
During beta testing some of the testers did informal comparison of speeds and 2021 was generally faster. Validation, through the ability to validate only the last backup is much faster.
On the substantive issue someone else will need of offer guidance.
Because of issues related to the new virus protection features I would not recommend upgrading to 2021 until those issues are resolved.
Ian
Greetings,
Sorry for being late to this thread…but I am new to the forum as a participant and went the route of Tech Supt (since Aug 21st/22nd) to no avail to date. Playing 20 questions with them and seem to be getting circular scripted responses.
I am already at a disadvantage speed wise compared to some, as my ISP only provides 5Mbps upload. But my jobs are relatively small, so backups were not taking forever.
Now they are working at about half their previous speed and it is a noticeable slowdown from about 4Mbps to 1-2Mbps, even for small jobs.
Here is a little detail about my situation:
- Started with ATI 2019 Build 17750 in 2019, currently ATI 2020 Build 25700.
- My computer wakes in the middle of night to run backups
- Nothing else is open or running during the backups
- Backups consist of both Disk and My folders (incremental - tibx)
- The CPU usage is about 2-3%
- The Acronis provided tools show perfect connectivity to Phoenix DC
- Speed test with Acronis tools and Ookla separately, show a solid 5Mbps upload.
- Like another responder in this thread, My backup_worker logs show many errors with the backups losing connectivity and/or exhibiting timeouts waiting on responses during the backups.
- Upgraded to ATI 2020 B25700 in April, it was announced April 7, 2020.
- In April, started to see a backup speed difference and thought it related to B25700. So I waited for an acknowledgement/fix. When ATI 2021 was announced and no mention of backup slowdowns I opened a ticket.
- I was lucky to find this thread which validated my experiences.
- Last night an incremental backed up of 11Mb and took over 3mins when I am pretty sure in the past it would have taken seconds.
- Not only are my backups slower, but bigger jobs run faster than smaller jobs…consistently.
- My jobs take about 6-7 mins at start to calculate a Disk incremental backup (this may be normal) but can spend hours with less than 1 minute left. They clearly calculate the backup speed using the overall time even though data is not moving for the first 6-7 mins in my case. Don’t know if this changed recently.
- When my backups hit the less than 1 minute mark, watching the network backup_worker in Resource Monitor shows throughput reduce to a trickle.
Tech Supt:
- I am in the Phoenix DC. Asked about other DC’s and can it potentially change with a new job creation…apparently not within the same country???
- The provided me KB4350. purported to have been updated 9-10-2020. But for the US, it mentions Boston as US2, and St Louis as US1 & US3. No mention of Dallas, Phoenix, Ashburn? Can’t get a straight answer from Tech Supt.
- I was told that ATI 2020 began throttling jobs, by design, and that bigger/faster smaller/slower is normal. Maybe jobs are not throttled outside the US based upon job speeds to Germany?
Here are some questions that someone may be able to answer: Steve, Ian?
- Does anyone know if Acronis owns its DC’s or they lease space?
- Is it acceptable/normal for backup_worker logs to routinely show errors?
- Does anyone else have knowledge around job throttling starting in ATI 2020, maybe with B25700 since that is about the time some of us noticed slowdowns.
- Does anyone know if Tech Supt is outsourced? Is there any Tech Supt at Corp Headquarters? I can’t seem to get beyond the front door with my reported issues.
- Has anyone seen speed improvements with ATI2021 Build 30480 over ATI 2020 Build 25700.
- The last entry in this thread suggested holding off on ATI2021 due to anti-virus issues. Ian was that before they released a 2nd build, 30480?
- Anyone able to confirm or test job throttling? Not sure if it could be by Country due to DC overload?
Thinking maybe some of us are seeing 2 separate issues…one being the potential introduction of job throttling and the other the Phoenix DC. If I had a ATI 2019 build I would be tempted to go back and validate some of our issues…unfortunately I don’t…
Sorry for the length.
Thoughts?
Kep, welcome to these public User Forums.
I am pretty sure that other users have had significant performance issues when using the Phoenix DC, with one user deciding to use one of the Germany DC's because got vastly improved performance by going out of country! I don't know if that user tried other US DC's or not.
I am using the London DC and don't see any problems in this area with either 2019, 2020 or 2021 backups. My own upload rate is max 10Mbps for a 100Mbps download service.
Regarding the other questions, do a Who Is on the IP address for your Phoenix DC and this will show who are actually hosting that address. My backup_worker log for a cloud backup shows an IP address of 62.138.203.225 for my London DC, and doing a lookup on this using the GeekTools WhoIs webpage, shows the address is hosted by PlusServer GmbH in Germany!
Final results obtained from whois.ripe.net.
Results:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.% Information related to '62.138.203.192 - 62.138.203.255'
% Abuse contact for '62.138.203.192 - 62.138.203.255' is 'abuse@plusserver.com'
inetnum: 62.138.203.192 - 62.138.203.255
netname: ACRONIS-SXB
descr: Acronis Germany GmbH
country: DE
admin-c: AR36290-RIPE
tech-c: PNO7-RIPE
status: ASSIGNED PA
mnt-by: MNT-PLUSSERVER
created: 2016-10-24T16:15:54Z
last-modified: 2019-03-13T17:05:07Z
source: RIPE
remarks: 1838654role: PlusServer Network Operations
address: PlusServer GmbH
address: Hohenzollernring 72
address: 50672 Koeln
phone: +49 2203 1045 3600
abuse-mailbox: abuse@plusserver.com
remarks:
remarks: **************************************************
remarks: * Auskunftsersuchen gemaess TKG werden nur unter
remarks: * Fax: +49 2203 1045 1045
remarks: * Mail: backoffice@plusserver.com
remarks: * bearbeitet!
remarks: **************************************************
remarks:
admin-c: ADPS-RIPE
admin-c: RHPS-RIPE
admin-c: SG13291-RIPE
admin-c: CA4524-RIPE
tech-c: ADPS-RIPE
tech-c: RHPS-RIPE
tech-c: SG13291-RIPE
tech-c: CA4524-RIPE
nic-hdl: PNO7-RIPE
mnt-by: MNT-PlusServer
created: 2016-06-02T09:51:40Z
last-modified: 2018-11-19T08:41:26Z
source: RIPE # Filteredperson: Network DCO team
address: Euro Haus, Rheinweg 9
address: 8200
address: Schaffhausen
address: SWITZERLAND
phone: +41 52 630 280-0
nic-hdl: AR36290-RIPE
mnt-by: ch-acronis-1-mnt
created: 2016-05-03T11:33:36Z
last-modified: 2017-09-22T06:27:46Z
source: RIPE% Information related to '62.138.203.0/24AS61157'
route: 62.138.203.0/24
descr: PS-Net
origin: AS61157
mnt-by: MNT-PlusServer
created: 2017-10-10T13:54:11Z
last-modified: 2017-10-10T13:54:11Z
source: RIPE% This query was served by the RIPE Database Query Service version 1.97.2 (BLAARKOP)
The backup_worker logs can often show some errors for network connectivity but most of my successful backups look to be clean! Errors shouldn't be a major issue provided that retries done are successful, but are an issue if they keep repeating the same error!
I would say that the first level support team at Acronis are very much reading from prepared scripts and do not have a good knowledge of the actual products they are giving support for! All I can recommend here is that you keep asking for the issue to be escalated to either a more experienced support team or else to Acronis Management.
If needed, submit regular Feedback using the tool in the ATI GUI and quoting your Support Case number, expressing your dissatisfaction with progress, answers etc. The Feedback goes to a different team as far as I understand, therefore if they start seeing increased levels of complaints via this method, it should be escalated!
I have no reason to see any throttling of uploads but there has always been a statement about allowing for 'fair usage' between all the subscribed users of this type of service, i.e. if you are the only user, then you might expect to get full upload bandwidth, but if you are just one out of 10,000 users going to the same DC, then the server performance has to be shared so that no users are being starved of capacity or are unable to connect etc.
I would suggest creating one or more new backup tasks, each selecting a different DC and using the same source data set, then do a little comparison between the performance of these backups. DC's can only be selected on new backup tasks - this cannot be changed after the task has run, the same as some other options are no longer available, i.e. compression, encryption etc.
Steve,
Thanks for the reply and info!
I have been using your co-authored tool MVP Assistant. Unfortunately my limited experience with it is showing and I don't know if some errors are to be ignored or they need to be pursued. For example, I have 9 MMS logs and each one is loaded with errors (I uploaded 1 for you to view). I have a relative that has followed my path with Acronis and while they appear to have fewer errors in backup_worker logs (still Phoenix DC), their MMS logs mirror my own with errors.
Hoping for a little more help...
- Does it make sense from a technical POV, that smaller jobs (at least in my case), now run slower (Time spent) than bigger jobs? This is what I see in my job Activity and Tech Supt says this is new and by design???
- Can MVP Assistant provide the same detail that is contained in job Activity i.e. Backed up, Speed, Time spent, etc.? in a log, or is it derived from logs overall?
- Acronis Dashboard is reporting jobs not done, but the desktop says they completed successfully. Known Dashboard issue?
- I still have not gotten a definitive answer from Tech Supt on whether my Phoenix DC was assigned when I first created my Acronis account and therefore never changes unless I pick a different country? In the US, there are reportedly multiple DC's, but you cannot individually select one at job creation, only the country. I am trying to find out so as not to waste time with new US job testing if I will always end up in Phoenix. Anyone know for sure?
- I, and others, see a behavior with ATI2020 where their cloud jobs get to 'less than 1 minute remaining', but maintain that status for long periods of time (10's of minutes to hours for me) before actually completing. Since job size and time spent is used to calculate the backup speed, this prolonged time affects the calculation negatively and may make the job appear to be slower. I don't think the backup is actually still pumping data to the cloud during this time...or it is at a trickle.
Can anyone confirm that this behavior is not happening in ATI2021?
I am thinking I may go the route of uninstall and clean install of ATI2021 and see where I stand, but before tackling it I would like to know any answers to the above.
Thanks Much!!!
Kep, the MMS logs relate only to the communications between your PC and the Dashboard but I have not come across the particular error being shown in your log previously! Nothing like it in my own logs!
I would suspect that the discrepency between the ATI GUI Activity and Dashboard is related to the MMS log errors, as these point to the script ID's for your backup tasks!
Personally, I do not use the Dashboard and never look at any activity shown there. We had a serious issue with the Dashboard in late 2019 where it caused turmoil by resetting the backup task configuration to default values for far too many users, which was the nail in that coffin for me! You can set the Acronis Managed Machine Service Mini service to be disabled in the main Windows services control panel if needed. My own MMS log just has lots of errors because I have the Sync Agent service disabled! I also have the NonStop service disabled too, as I don't use either of those features!
All the Activity page statistics are derived from the logs etc but are not in a format that makes for easy identification or understanding!
Each Acronis Account is assigned to a Country and you can set an address within that country but there are no options shown to allow selection of a particular data centre, so have no idea how Acronis decide which one should be used by default!
For my own Account, I have this set for United Kingdom which should default to London as the only DC but I have to always check on new backups as it defaults to France for some unknown reason!
The status of 'less than 1 minute' taking a long time has been the source of complaints for more than a year and has hit my own backups previously! This was being caused by cleanup actions running on the server side but holding the local task and preventing any new tasks from running! For me, this was resolved by creating new backup tasks in ATI 2020 and playing with the retention settings for how many versions over what time are kept.
Cross reference to topic: Network disconnected by timeout. where other users have reported issues with the Phoenix DC.
Steve,
Thanks for the additional information!
Think with the issues I am seeing I will head into uninstall/reinstall.
Jim
Hi Steve,
I wanted to provide an update and ask a couple more questions.
After reading through the ATI 2021 Forum, I decided to hold off on upgrading and uninstalled/reinstalled ATI2020 Build 25700. Taking a hint from your earlier mention of cleanup actions, I now have them set modestly and they show much improved overall performance at the end of the jobs i.e. 1m remaining.
I built some fairly small (40GB and less) File/Folder backup jobs with identical size/selections/settings and ran them towards Phoenix (USA) and Germany. Once again, the jobs wake the computer at 1am CST and run back to back. Not surprisingly, the Germany jobs run faster in regardless of size, and scale towards faster as the job is larger.
The biggest backup was only 41GB and took 22hr 11m to Phoenix and 20hrs 41m to Germany at my measly upload speed of 5Mbps. Incremental jobs thereafter were very small but always favored Germany in terms of faster speeds. As others in this thread have mentioned, backing up disks would show a huge difference in backup times. Since we are unable to select different DC's in any country, I cannot tell if all DC's in the US perform this poorly or just Phoenix. Maybe you have more insight?
I am including a couple of screenshots showing Resource Monitor during the backups to Phoenix and Germany. It's pretty easy to see why Phoenix lags in performance IMHO. I am wondering if you ran a similar test to your own DC if the network performance for backup_worker would show the dropouts the Phoenix DC shows?
As I may have mentioned previously, I have had a ticket open with tech support since August and have received the typical 'cut and paste' responses, from more than 1 person, in terms of backup speeds are affected by a lot of uncontrollable factors etc. etc. I don't feel like they even look at the data provided. Once again, after the above testing, I provided their requested data dumps and got a response to upgrade to ATI 2021...again. I find it hard to believe that the ATI app would have some bias against Phoenix over Germany.
I, like you and others, believe that the Phoenix DC may have issues (equipment? configuration? or maybe an agreed to SLA?). But I am unable to get visibility to an Acronis Network or DC team, just desktop/app support, even after escalation requests.
So... here are my questions.
Are you aware of any published Acronis documents stating they will not support the most recent previous version once a new version is released? For well documented problems and fixes I can understand, but no evidence exists that I can find in their documents and ATI2021 release notes about DC issues, speeds etc..
Do you have any knowledge or even perceptions, as to the various Acronis Support Teams above the app level and how to engage?
Thanks
PS...I have been unable to upload the 2 jpg files the last couple of days (about 1.5MB total)...get an error "The file could not be uploaded.' So decided to post anyway. Anyone else having problems with uploads?
Are you aware of any published Acronis documents stating they will not support the most recent previous version once a new version is released? For well documented problems and fixes I can understand, but no evidence exists that I can find in their documents and ATI2021 release notes about DC issues, speeds etc..
Do you have any knowledge or even perceptions, as to the various Acronis Support Teams above the app level and how to engage?
Acronis will only support the current version of ATI after 30 days from it being released to the public, hence they end support for the prior version at that 30 day cut-off time. This should not impact on issues related to their Cloud servers / Data Centres as these should be version interdependent for the server side but it is normal for Acronis to 'insist' on testing on the latest version, i.e. ATI 2021 !!
In terms of getting past the first level Acronis Support teams, then I can only recommend that you request your support ticket be escalated either to the next support levels or to Acronis Management. One way of doing this is to use the Feedback tool in the ATI GUI quoting your support ticket and complaining about lack of progress, and repeating this feedback until you see some movement!
PS...I have been unable to upload the 2 jpg files the last couple of days (about 1.5MB total)...get an error "The file could not be uploaded.' So decided to post anyway. Anyone else having problems with uploads?
I have been reporting the issue with file uploads for around about a week now but so far it hasn't been fixed. See forum topic: Feedback on Acronis Forum
Thanks Steve,
I too had reached out to Ekaterina about the uploads but have not received a reply. Could this also be affecting external url links in a post or has that always been the case? I know I have myself, and seen other url links, created to Acronis documents.
To my knowledge the file upload issue is unrelated to any issues with linking to external URL's within text. I regularly use web links in my posts where I highlight text then press Ctrl+L to insert the link, which has been working fine.