Large backups fail at around 900gb
Has there been an "official" acknowledgement of this problem from Acronis management and, if so, an estimated date of resolution? Is the problem so complex that it can't be quickly resolved? I haven't seen anything.
David Salter wrote:Has there been an "official" acknowledgement of this problem from Acronis management
I don't think any non-Acronis person on this forum hears anything from Acronis management.
David Salter wrote:if so, an estimated date of resolution?
It would be unwise for such a date to be announced. Bad press if they miss the date.
David Salter wrote:Is the problem so complex that it can't be quickly resolved? I haven't seen anything.
I would guess that either this is a tricky bug to fix or Acronis regression testing takes a long time. It's safe to assume Acronis will release this fix as soon as they have a good, stable one.
Also, you can assume that management is breathing down the neck of the programmers and testers making life miserable for them.
Rob,
I did not try to recover the backup because I think it obvious that a recovery would fail as all data is unreadable. Windows Explorer properties shows the backup file to be 742GB in size. A detailed Explorer view shows 779,063,600KB of 779GB. Windows Disk Management shows the size to be 742GB. Command prompt dir shows file size to be 797,761,126,400 bytes. The backup ran from 22:50 until 00:57 on 09/11/19, 2 hours and 7 minutes. Validation ran from 07:51 until 11:21 3 hours and 30minutes on 09/12/19. Obviously there is data there but again it is unreadable. I suppose I could try a recovery, I suppose it is possible that TI could process the data and restore what's there. Problem is I do not have another PC with 6 unused drives laying around to restore to.
I will do this, I will start a restore to a single disk and see if it will run or not. If it does I will abort it and report back here.
Okay, I gave it a try. If I select to recover Entire PC, Disks, or Partitions I get an error that "Due to an internal error, you can only recover files from this backup. To resolve this issue, restart your computer or recreate the backup:. If I select to recover Files no files are displayed for recovery.
I believe this confirms that the data on disk is unreadable.
Has there been an "official" acknowledgement of this problem from Acronis management and, if so, an estimated date of resolution? Is the problem so complex that it can't be quickly resolved? I haven't seen anything.!
There is an very early post in this thread where Ekaterina, the forum moderator addressed this question.
Ekaterina wrote:Hello Everyone,
our development team is investigating why the issue occurs on some environments and would be grateful for an opportunity to conduct the remote sessions on the affected machines. If you have some time for investigation, please open a support ticket (how to submit a support ticket) and share the case ID with me. Thank you!
This clearly indicates that Acronis is aware that there is a problem.
Ian
IanL-S wrote:Ekaterina wrote:Hello Everyone,
our development team is investigating why the issue occurs on some environments and would be grateful for an opportunity to conduct the remote sessions on the affected machines. If you have some time for investigation, please open a support ticket (how to submit a support ticket) and share the case ID with me. Thank you!
This clearly indicates that Acronis is aware that there is a problem.
Ian
So they say "some environments". Has anyone actually gotten a large reliable backup from ATI2020 yet? I'm going to call BS on that statement and say "all environments". I'm going to test Macrium Reflect today. I'll see if they are worth my money and will ask for my money back for ATI2020 or they'll get a charge back from my credit card company. I've been too long without a reliable backup solution now.
Enchantech wrote:Due to an internal error, you can only recover files from this backup.
Maybe you already said something about this and I missed it, but have you tried expanding the corrupted backup with File Explorer to see if it can find files to copy?
That is obviously no circumvention to this problem with the backup and is no good alternative to a recovery, but if successful it would at least allow stuff to be accessed in the corrupted backup.
(Maybe I should fill up one of my drives with random stuff so I can recreate this problem and contribute more to the conversation.)
Dean Drolet wrotSo they say "some environments". Has anyone actually gotten a large reliable backup from ATI2020 yet?
Actually, yes. But the environment is such that .tibx files were not created.
During the Beta test, and one time following the release of ATI 2020 I successfully created an FTP backup of a drive with about 2TB of data. I did not try recovery, but I did validate it.
However, I do not recommend this as an alternative to the current backup problems. ATI cannot manage large FTP backups. Cleanup will inevitably fail in any environment that cannot handle hundreds of concurrent FTP connections.
Another environment that will succeed is with a backup task created in ATI 2019 or earlier that is still used after an "upgrade in place" - installing ATI 2020 on top of ATI 2019. The task will continue creating .tib backup files and will avoid the .tibx problem. I suspect many existing ATI users will install ATI 2020 directly on top of AT 2019 and will continue using their existing backup tasks. They will not see whatever advantages may exist with the new .tibx format, but they also will not experience this large backup problem.
Patrick,
I didn't discuss Explorer in my posts however, I did try and the result is that when you open the file it doesn't show anything as if no data exists.
David Salter wrote:Has there been an "official" acknowledgement of this problem from Acronis management and, if so, an estimated date of resolution? Is the problem so complex that it can't be quickly resolved? I haven't seen anything.
Hello David,
the issue is known to the development and is expected to be fixed in the upcoming Update 1 (should be available in 1-2 weeks).
Still no update on this? 2019 worked perfectly for me, 2020 has not completed a backup since it was installed. I even built a new computer and it still will not complete.
A week ago Ekaterina said the fix would be available in 1-2 weeks. I'd say give it another week.
Just popping in here to add my name to the list of users running into this issue for the first time. Failure identical on 4PCs (Dell, Windows 10 Pro v 1903, top of the range 64-bit 32GB RAM. I have a 6TB internal drive (1.63 TB used) as I am a professional photographer and a 6 TB external drive for the ATI backup. I see this has been an issue since August. I rolled over to a new backup with the new file extension .tibx instead of .tib and it failed. On all machines I had a massive CPU spike and fan ramp-up at point of failure. I had noticed this new extension on the smaller OS drive backups and the much smaller file size a week before;. I had done some research with pointed to Acronis backup 12.5 (the *,tibx), but not much else. Did not think much of it until the failure tonight. I am glad to see they are addressing it and want to thank all of you for doing the legwork on it. Like you, I am a bit taken aback this slipped through to a "RTM" build, but MS bugled their entire OS last October with V1809 so I guess this happens. I'm not going to roll back to 2019 as from what was said a fix should be out by month's end. Until then I will rely on my second-tier backup; same data on multiple machines with one identical drive at a remote location, but that method is a real pain. Thanks again for your efforts, everyone. A note to the Acronis official, The error link within the program pointed to a fuzzy reference about an unknown error. It is by pure chance I found this thread. A quick update tied into the error code saying "This is a known issue and we are working on it with a fix by October" would be quite helpful and prevent others from taking potentially unneeded drastic action thinking their hardware, disk drives or something else were failing. I've used the program since 2009 and it has come to the rescue many times and made my life easier, but a little communication to the user from ATI would be helpful, seeing what some of you ran into when you reached out a month ago. Again, thank you for investigating. John
Error link points at "https://kb.acronis.com/errorcode/bookmark/0x000B042F_0x000B042F_0x02160015_0x029B138D_0x0000FFF0_0x800703E6/10302/1569114423/BB1BE161-0736-4A5A-8F19-4DCD760579DB"
John Diebolt wrote:A quick update tied into the error code saying "This is a known issue and we are working on it with a fix by October" would be quite helpful and prevent others from taking potentially unneeded drastic action thinking their hardware, disk drives or something else were failing.
Error link points at "https://kb.acronis.com/errorcode/bookmark/0x000B042F_0x000B042F_0x02160015_0x029B138D_0x0000FFF0_0x800703E6/10302/1569114423/BB1BE161-0736-4A5A-8F19-4DCD760579DB"
Was kann ich sonst noch tun? 2020 entfernen und es belassen für die Zukunft-
Hallo Logitech21
Man könnte das alte .tib Format verwenden, bis das Problem gelöst ist.
Möchte man die alten .tib Archive haben, muss man, wenn ein neues Laufwerksbackup erstellt wird den Backuptask mit "Backup später" speichern, dann das Backupscript bearbeiten und aus ".tibx" ".tib" machen.
------------------------------
Backupscript bearbeiten.
Zuerst in den "Explorer-Optionen" (Ordner-Optionen) "Ausgeblendete Dateien, Ordner und Laufwerke anzeigen" anhaken, um später den "Scripts" Ordner finden zu können.
Nachdem ein Backuptask erstellt wurde mit "Backup später" die Backup-Einstellungen speichern.
Am besten jetzt den Acronis Active Protection deaktivieren.
Als nächstes den Dateipfad "C:\ProgramData\Acronis\TrueImageHome\Scripts" öffnen und anhand des Änderungsdatums das richtige Backupscript auswählen. Man kann das Backupscript mit dem Editor öffnen und oben nach dem Backupnamen schauen.
Hat man das Backupscript gefunden, dann dieses Backupscript nach z.B "Downloads" kopieren. Dort dann das Backupscript bearbeiten und bei ".tibx" das "x" löschen und speichern.
Die geänderte Datei jetzt mit rechtsklick und "kopieren", wieder in den "C:\ProgramData\Acronis\TrueImageHome\Scripts" Ordner wechseln, die Original Datei mit linksklick auswählen und mit der "ENTF" in den Papierkorb verschieben.
Jetzt mit rechtsklick und einfügen das geänderte Backupscript einfügen.
Acronis Active Protection kann wieder angeschaltet werden.
Anschließend das Backup starten und später schauen, ob jetzt wieder die normale Dateiendung vorhanden ist (full_b1_s1_v1.tib).
Bilder zum anschauen:
G. Uphoff, Danke für die Alternative, aber ich schlage eher vor die alten Ati 2019-2016 wieder einzusetzen. Die Probleme unter 2020 sind massiv und dauernd müssen die Entwickler von Acronis Daten von meinen Systemen haben um Sie in kommenden Versionen zu beheben.
-2020 langsamer Start mit Einfrieren
-URI ist invalid kommt immer wieder mal
-volsnap Einfügen manuell in der Registry nach Deinstallation von Ati 2020
-Erhöhte cpu beim nutzen eines Backups
-3 mal so langsam beim Backupen wie die Ati 2019
Fakt ist, die Entwickler kommen mit der Problemlösung nicht mehr nach und ich kann jedem abraten zur Zeit von ati neuster Entwicklung.
Let's add a couple new wrinkles to this thread.
I have been backing up slightly over 1TB for about a month with Acronis 2020. A few hiccups, but it appears to be working.
The first wrinkle. I assume all the users in this thread are using Windows. I am using the Mac version of Acronis 2020 to back up an iMac with a 2 TB internal drive to a Netgear ReadyNAS 424. The iMac is running "Bootcamp" so about 900 GB is in a Windows NTFS partition and 100 GB in the Mac world. Acronis CANNOT backup from a Windows Bootcamp partition so I have to backup everything from the Mac Mojave environment. Currently running Acronis on 1 iMac, 2 MacMinis and 2 Windows machines. All 3 Macs run Bootcamp.
The second wrinkle. I am paranoid, so I basically image the RN424 to an older RN204. The tib file grows as incremental backups are done. At about 1.5 TB the NAS to NAS back ups fail. Both simple backup and RSYNC become unstable at about the 1.5 TB point. Not certain if this is an Acronis issue or a Netgear issue. The single huge tib file is certainly harder for the Netgear/RSYNC programs to handle than the older smaller full and inc files.
R D,
I am guessing here a bit but, with that much data being pushed via network you might be overloading the router memory causing the fail.
With RSYNC it is wise to use swap files on large transfers. This can really help with memory requirements.
There is a good discussion of this over on the SNBForum site, link below. I suspect this circumstance would occur with a simple backup as well.
R D,
Also, you need to be using the Mac version at all times. Boot camp can't be recovered from the windows side. You could do a file/folder recovery, but not the entire partition / OS.
I just received an email notifying me that a new Acronis 2020 build (21400) has been posted to my account. I am trying it now and will report back whether or not this one works. It may take a few hours.
I ran a 969mb backup with no problem
Pat
Just downloaded and applied the update. I'll be letting the scheduled backup take place tonight at 11pm. Fingers crossed this fixes it. I've been using Macrium Reflect and a complete backup takes about 5 hours and seems to be quite fast. The older version of ATI that I was using used to take close to 14 hours for the same backup to complete. Now that I'm on the newer TIBX format, hopefully it can match Macrium's speed. If that's the case, then once my trial ends, I'll just uninstall Macrium, or if this continues to fail, then I'll uninstall ATI and pay macrium for the license. I've been with Acronis for so many years, I've been patient. Let's see what happens.
Just downloaded and applied the update. I'll be letting the scheduled backup take place tonight at 11pm. Fingers crossed this fixes it. I've been using Macrium Reflect and a complete backup takes about 5 hours and seems to be quite fast. The older version of ATI that I was using used to take close to 14 hours for the same backup to complete. Now that I'm on the newer TIBX format, hopefully it can match Macrium's speed. If that's the case, then once my trial ends, I'll just uninstall Macrium, or if this continues to fail, then I'll uninstall ATI and pay macrium for the license. I've been with Acronis for so many years, I've been patient. Let's see what happens.
Dean, are you validating with Acronis? That will greatly increase the time. In my experience, True Image generally is faster for backup and recovery (not always, but usually). However, if you validate in Acronis and not in Macrium, then the comparison is really going to be off. The issue in this thread was that True Image is failing to backup large backups (500GB+) at all in the first release of 2020 (which was a bug introduced in the release not found in the 2 betas that came before it).
Either way, use what works best in your environment and for your needs. Neither is perfect though. I have had success using True Image to Clone and restore backups where Macrium failed (was not bootable). Likewise, others in the forum have posted the opposite. Personally (besides some of the new bugs in 2020 that are being worked out), I think that long time users of Acronis can inherit issues overtime but multiple upgrades of Acronis over the top of itself, in addition to OS changes like Windows 10 major versions. When they migrate to a new backup product, it's a completely fresh slate, but the same types of issues seem to pop up overtime in them as well. I have 5 different licensed backup products and I can tell you from experience that that each of them has given me trouble at one time or another in its own unique way. That's why I thoroughly believe in 3-2-1 backup plans and even diversifying farther by having a couple of different products to cover for each other too. Generally speaking though, Acronis has been my go to for many years. Fingers crossed that they get the issues with 2020 ironed out soon too. The move from .tib to .tibx hasn't been as smooth as I hoped for. Then again though, Macrium had quite some trouble moving from Version 6 to version 7 too :).
It appears the new build fixed the problem for me.
One curious thing though: I have 3 drives I'm backing up, selected the same options for all 3 including no compression. My OS drive .tibx is roughly the same size as the amount of data on the drive, so is my 3rd data drive (about 1.5TB). My 2nd data drive, which contains a lot of documents and things which could be compressed had I chosen to do so, resulted in a ~500GB .tibx for roughly 1.7TB of data even though compression is not selected. I am able to mount and browse the .tibx and don't see anything missing in the backup. It just makes me a bit nervous with all the trouble I've had. I'll run another backup tonight and see how that goes before I mark this thread resolved.
I was not validating with Acronis before, and yes, the backups were taking that long. It used to be 7 hours and then it just kept climbing. Last night the backup of 1.7TB finished in about 3.5 hours, so I'm quite happy about that. I have not tested this backup yet though, and I'll spend some time today on that, but so far, this is the first bit of success I'm getting on a full system backup since 2020 was released!
Patrickfixedit,
Your question about your backup file sizes on a per drive basis I believe can be answered by understanding what type of data each drive holds.
Documents are normally small in total file size, (<4KB). If your disk is set at a 4KB block size (Windows default), then these small files probably do not fill the entire space of such such blocks on a physical disk.
True Image, in creating a backup file would write the data in a much more efficient manner thus using a much smaller space. This applies to backups to full disks as file/folder backups are not created at the block level.
The tibx file format makes better use of metadata which should improve the performance of backup and efficiency of all backups as well.
As an example to illustrate this I just put together a new PC. With Win 10 installed plus ATI as the only installed application the total size on disk as reported by ATI is 34.4GB. Explorer shows total size of data on disk as 41.1GB The difference is mostly what is normally excluded from the backup by ATI plus metadata efficiency. A backup uncompressed of this disk shows a total amount of data to be recovered as 21.2GB and the total size of the backup file itself is 7.9GB.
The above is illustrative of the efficiency of the application in backing up of data. The disk used in this illustration is Raid 0 array of 2 disks set to use an 8KB block size so that small file handling and drive space is more efficient than a disk using a larger block size and overall disk performance is at as high a level as possible.
GOOD NEWS!!!
Its working now for me.
The new update that just came out (sept 24th) Build 21400 has fixed these issues...
See changelog here https://www.acronis.com/en-us/support/updates/changes.html?p=42014
and>>>
Acronis True Image 2020 Update 1 for Windows
What's new
- Added support for the Windows 10 September 2019 Update
- Bug fixes and other improvements
Fixed issues
- TI-173951 Login to Acronis True Image fails if the "Go Daddy" certificate's chain on the machine is incomplete.
- TI-168095 Cloud Entire PC backups are empty if browsed from mobile applications.
- TI-174833 Disk backup fails with the error "No Volsnap driver was found."
- TI-173964 The "Unable to copy the product files" error appears during Acronis Survival Kit creation to USB flash drives formatted to GPT.
- TI-174635 Backup to Acronis Cloud fails with the error "Acronis Cloud is full."
- TI-173934 Disk-level backup to an external drive fails with the error "Invalid access to memory location."
Known issues and limitations of this version
- Please note that new technology for disk-level backup is introduced in Acronis True Image and is being improved, so it may currently have the following limitations:
- TI-169821 Backup conversion to VHD format is not present for the new backup format.
- TI-171553 Moving the backup through the Acronis True Image console is not present for the new backup format.
- TI-169548 Renaming local backups is not possible for the new backup format.
- TI-172340 The backup mounting option is not present for the new backup format.
- TI-172086 A differential backup is created instead of full backup, after the second launch of a local disk backup using the "Version chain" scheme.
- TI-168969 Acronis Universal Restore cannot detect external USB drives.
System requirements
Hardware requirements:
- A CPU that supports SSE instructions
Operating systems:
- Windows 10 (all editions, including September 2019 Update, except for Windows IoT editions)
- Windows 8.1 (except for Windows Embedded editions)
- Windows 8 (except for Windows Embedded editions)
- Windows 7 SP1 (all editions)
- Windows Home Server 2011
It is possible for the software to work on other Windows operating systems, but it is not guaranteed.
File systems:
- NTFS
- Ext2/Ext3/Ext4
- ReiserFS(3)
- Linux SWAP
- HFS+**/HFSX
- FAT16/32/exFAT*
Storage media:
- Internal hard disk drives
- External hard disk drives with any of the following interfaces: USB (including USB 3.0), eSATA, FireWire (IEEE-1394), and SCSI
- Solid State Drives (SSD)
- Networked storage devices
Wanting to report my findings on this subject.
The new release version does in fact fix the problem noted in this thread. I ran a backup of an Entire system, same as I used in my post #97 of this thread and it completed successfully.
Well well well. I just read this thread in its entirety and .... guess what, I am experiencing the same problem. The backup fails with "destination is unavailable", after running for 30 minutes and backing up about 75% of a drive containing only 91GB of data. I found this thread while googling for "Error 0xb042f: Destination is unavailable".
For the record, I am running build 22510, well past the supposed fix introduced with 21400 for this problem. This is a brand new install of ATI 2020 (no prior ATI running before). The very first backup failed. The drive being backed up only has 91GB of data. Win10 1909 just updated from Win7, 4GB of RAM. Yes I know 4GB of RAM is not ideal. The backup is going to an external USB drive. I deleted and retried the backup 3 times. Same failure at (about) the same spot (as far as I can tell).
So this bug, which supposedly affected only large datasets also affects small ones. Or if it has to do with memory, which it apparently is, according to this thread, when memory is short. So it would seem the fix has not fixed it in all cases, or Acronis has reintroduced the problem, or .... who knows what. But this tibx format is problematic at best.
So I deleted the backup and accompanying backup file and recreated a brand new backup job, but did not run the backup right away. Then I edited the script file to replace tibx with tib in 3 places (as documented earlier in this thread). Two of the locations were where the format (format="tibx") was specified, and the third one where the name of the backup file (yet to be created) was specified.
I ran the backup again and it completed successfully. Yet my confidence in Acronis is SERIOUSLY shaken, even more so since they claim to have fixed this problem 3 months ago. As an IT consultant, I have been recommending Acronis to all my clients for the past 2-3 years. I may revise my strategy as soon as I gain confidence in another product, such as Macrium Reflect.
Then I proceeded to run a verification, which ran successfully. Then I ran another (incremental) backup, just to see. It completed fine.
I have attached the content of the email received for one of the failures, in case someone can shed more light.
Now what? Why is this tibx format still being allowed to be used? It is scary to think you cannot rely on your backups and sleep soundly. I don't feel good having to edit the script, and I am a tinkerer. I would prefer that Acronis provide a way to switch back to the tib format from the GUI, until they figure out their mess once and for all.
Pierre wrote:So this bug, which supposedly affected only large datasets also affects small ones. Or if it has to do with memory, which it apparently is, according to this thread, when memory is short. So it would seem the fix has not fixed it in all cases, or Acronis has reintroduced the problem, or .... who knows what. But this tibx format is problematic at best.
Pierre, this won't make you feel any better, but I believe the problem discussed in this thread did effect only backups of large datasets, and it was fixed. I think the "destination is unavailable" problem is a separate (and apparently unfixed) one. Reports have been inconsistent, but in some cases (maybe all cases) the error message is incorrect - the destination is available. I don't recall if this is (always) related to .tibx, though.
Pierre, I have to agree with Patrick that this is not the same issue here for the large backup failure which affected backups of 500GB or larger.
Your log shows:
23/12/2019 20:46:52 :990 -05:00 8780 I0064000B: Priority changed to Low.
23/12/2019 21:11:40 :214 -05:00 8780 E000B042F: Error 0xb042f: Destination is unavailable.
| error 0x2160015: A backup error.
| error 0x40015: Network disconnected
| error 0x29b1399: Network operation failed
| error 0xfff0: The semaphore timeout period has expired.
| function: pcs_co_file_writev
| path: \\?\F:\Acronis Backups\MARTIN-420.tibx
| code: 0x80070079
| $module: disk_backup_vs_650
23/12/2019 21:11:40 :754 -05:00 8780 E013C0005: Error 0x13c0005: Operation has completed with errors.
You mention above that your backup is going to an external USB drive for which I would not expect to see mention of network issues if that is connected directly to the host computer?
See webpage: Error 0x80070079: The semaphore timeout period has expired - which again references this issue in the context of transferring large files across a network.
Hi Patrick and Steve,
Thanks for replying so quickly. As I said in my post, I came across this thread when searching for "Error 0xb042f: Destination is unavailable". It was the first result in Google if I recall correctly.
Anyhow, the tibx to tib substitution made the backup work, so is it completely unrelated to this thread? I would think not. But you guys know better than I do most likely.
And yes, I noticed the network error, which makes no sense whatsoever since the target is on a USB drive. But the message "Destination is unavailable" makes no sense either.
And there was a mention about the memory in the thread. And I have a gut feeling that if the backup is first written to memory, then it could be a problem in my case with only 4GB in this particular machine. So again, is it unrelated to this thread? Unclear.
Anyway, should I repost as a new thread? Under what subject then?
Thanks for your support.
Pierre, I would suggest opening a new topic with key error message Error 0xb042f: Destination is unavailable.
If possible, after opening the new topic, create an Acronis System Report zip file and if it is less than 8MB in size, then attach as a file using the option shown below the main edit window.
Get the topic open before adding any attachments as otherwise it may be delayed to wait on moderation!
What is your Source data for this backup? Is this all on the host computer?
Is the USB external drive connected directly to this computer?
I will create a new thread per your suggestion. Thank you Steve.
The source for the backup is the computer where ATI 2020 is installed. The target is a USB drive connected to that computer. So no networking involved.
As I said, for now it works with the backup script modified to use tib instead of tibx.
Just to chime it with my experience. Same problem (Destination is unavailable). This happens without much variation after writing around 450GB to the external USB3.0 drive.
I've tried several different ports and powered hubs and different disk drives (all formatted NTFS). One thing I've noticed is that it seems to happen about 75 minutes into the copy in case there is some time-out involved.
I've switched to backing up each drive separately but I'll try the Files and Folders technique too. I actually liked the older .tib format since it allowed me to copy multiple versions.
Another data point - I have had a similar failure using robocopy on large files. Could this be a Windows 10 issue?
Roger, the original problem for this topic was resolved by Acronis when they released build 22510 and we haven't been seeing any new reports of such problems from other ATI users since that fix was deployed.
If you are seeing this issue or a similar one when using robocopy on large files, then my first thought is to ask if you are overclocking this computer? If yes, then try dialling back on the overclock and see if the computer becomes more stable when performing either the large backups or file transfers?
Other than the above, then we would need to see log files for the failing backup task to try to get a better understanding of what is happening for you.
Thanks, Steve. I'm downloading the new update now and will report on success/failure.
I've reported this problem on trouble tickets with Acronis in the the past. Strange that they didn't suggest a new version.
I'm not overclocked - Thinkpad P71 w 64GB and 3.5TB SSD (fwiw).
The new version 22510 completed the backup successfully.
Needles to say, I'll do some testing since it is critical (to me) that the backup be good.
Still concerned that Acronis didn't bother informing me about the need to upgrade, especially since I've entered tickets on this problem.
Roger, the new build version will be notified to you when you launch ATI if you have this option enabled on the Settings page in the GUI.
It was also published as a sticky topic here in the 2020 forum: Acronis True Image 2020 Update 2 is available! back in November 2019, as was the previous new build #21400 etc.
I have a question, I bought a retail version of ATI 2020 Standard that came with card only, will the new download include this fix?
Noose, if you have ATI 2020 installed, then open the Account page in the GUI and it should show you what build version you have? This should show #25700 which was the final build released by Acronis and which fixed the issue described in this topic title subject.
If you do not have #25700 then you can download this from your Acronis Account download page.
Steve Smith wrote:Noose, if you have ATI 2020 installed, then open the Account page in the GUI and it should show you what build version you have? This should show #25700 which was the final build released by Acronis and which fixed the issue described in this topic title subject.
If you do not have #25700 then you can download this from your Acronis Account download page.
I have not downloaded yet, I plan on backing up the actual .msi setup program in case I ever have to reinstall since no media came in my retail box. I learned long ago to never depend on a program being online forever. I'm asking, If i go to download page to download, will it include this update fix, will it be the latest version or am I forced to install in order to get the updates that fixed this?
Downloading and installing build 25700 will include this fix. All builds are cumulative when it comes to fixes.