Large backups fail at around 900gb

One of the 2TB legacy TIB backups I have is set to do a full backup after 10 incrementals. As a test, I did a number of incremental backups in a row to force the full backup. It completed without an issue. Having said that it took about an hour longer to complete than it did with ATI 2019.

Dar Wunder wrote:

One of the 2TB legacy TIB backups I have ...

Just to clarify, this was a task defined under ATI 2019 (or earlier) that you are now running under ATI 2020?

Dar Wunder wrote:

As a test, I did a number of incremental backups in a row to force the full backup. It completed without an issue. Having said that it took about an hour longer to complete than it did with ATI 2019.

Since this was an existing task, it would have continued creating .tib files so would not be subject to the new .tibx bug.  Your task should continue to work without problem.

The change in run time is strange, though.  I would have assumed that this task used mostly the same code used in ATI 2019.  I don't recall anybody reporting that during the Beta test.  But there were not many large backups taken during the test.

I wonder if there is some sort of text file or something that we can edit in the job itself to tell it to use the old format?  If not, perhaps a request can be put in to allow us to choose the format of the archives we choose to create?

Dean Drolet wrote:

I wonder if there is some sort of text file or something that we can edit in the job itself to tell it to use the old format?  If not, perhaps a request can be put in to allow us to choose the format of the archives we choose to create?

Dean, the choice of file format is shown in the associated .tib.tis script file for the backup task in the C:\ProgramData\Acronis\TrueImageHome\Scripts folder but it is not recommended that these XML files be modified manually or altered especially once a backup task has created any files for the task.

One possible option that I have noticed when looking at my own files, is that a new Disk backup task that goes to the Acronis Secure Zone will still use .tib files, not .tibx.  I expect this is because ASZ is a modified FAT32 partition type and therefore has file size limitations that may require the backup archive be split into segments?

Examples:

New format disk backup .tibx

<archive_options check_network_timeout="false" computer_id="91BD77E2-D4B2-4B78-817B-C92BEFF2DE74" format="tibx" id="13852784271306145624" network_timeout="0" split_archive="false">
                    <volumes_locations>
                        <volume_location partition_id="\local\hd_ev\vol_guid(3B7AFA8001D542F20DB5654000EAA179)" uri="E:\AcronisBackup\Test\Win 10 SSD Diff E.tibx" volume_id="1230126936" />
                        <volume_location partition_id="\local\hd_ev\vol_guid(3B7AFA8001D542F20DB5654000EAA179)" uri="E:\AcronisBackup\Test\Win 10 SSD Diff E.tibx" volume_id="0" />
                    </volumes_locations>
                </archive_options>

Old format disk backup .tib

<archive_options check_network_timeout="false" computer_id="91BD77E2-D4B2-4B78-817B-C92BEFF2DE74" format="tib" id="2353916629801750017" network_timeout="0" split_archive="false">
                    <volumes_locations>
                        <volume_location partition_id="\local\hd_sign(A7FDBF40)\part_sn(2E7DD59001D54BDA)start(67110912)" uri="S:\Steve HP\Win 10 SSD_full_b2_s1_v1.tib" volume_id="459167673" />
                        <volume_location partition_id="\local\hd_sign(A7FDBF40)\part_sn(2E7DD59001D54BDA)start(67110912)" uri="S:\Steve HP\@task@.tib" volume_id="0" />
                    </volumes_locations>
                </archive_options>

New format disk backup .tib going to ASZ

<archive_options check_network_timeout="false" computer_id="91BD77E2-D4B2-4B78-817B-C92BEFF2DE74" format="tib" id="6746030875126347550" network_timeout="0" split_archive="false">
                    <volumes_locations>
                        <volume_location partition_id="" uri="atis:///asz?(7438AF74-4A93-E17B-ADD3-4F7EF58E0652)" volume_id="193701385" />
                        <volume_location partition_id="" uri="atis:///asz?@task@.tib" volume_id="0" />
                    </volumes_locations>
                </archive_options>

Thanks Steve!  That's exactly what I was looking for.  I used to modify these files when backup chains used to go bad on previous versions.  I know it's not best practice to do so, but it may help.  I'm going to create a new job, but before i run it, I will modify the script to TIB format instead.  I'll report in about 7 hours if the job is successful!  I'll send it to the fast synology with can sustain about 150MB/sec vs the older synology I have that only does about 60MB/sec.  This will be a work-around until Acronis can issue a patch.

I just started it, and can see that it's created a TIB file instead!  It's just doing the VSS stuff right now, but should start streaming an image shortly.

Nice! If this works, this could be an easy way to maintain .tib functionality too and shows that an option could be set to allow a user to pick the type of it were added to the GUI... Like in the advanced tab as one of the options that could be changed before a backup script has ever run.

You may want to validate if it does work too.

I just did a first offline backup with recur media and it is failing Evey time on my main rig, despite working fine in 2019 and despite the same media working on my other laptop. I'll open a thread about that a little later.

Sadly, the issue is not really with TIBx format, as this backup also failed using a TIB file, at about 700GB.  Or maybe the format is secretly TIBx in the background, despite the file name being a tib, of course I set that in the script, and also set the format to be tib.

<archive_options check_network_timeout="false" computer_id="779E0A05-7F97-4806-8EAD-5B47CC678131" format="tib" id="0" network_timeout="0" split_archive="false">
                    <volumes_locations>
                        <volume_location partition_id="" password="001F4JJyKD5y4voJJFDkW6g46ysFQ0" uri="\\gzds2\Dean\My Backups\DDROLET-PC2-1.tib" username="001F4!JyDD5m4vwJJEDkB6gC" volume_id="0" />
                    </volumes_locations>
                </archive_options>

Still failed with the following error:   error 0xfff0: Invalid access to memory location.

Bummer. It was worth a shot to see. I guess it's not surprising though as Mustang's offline backup with 2020 rescue media of a 1TB+ backup was successful and in .tibx format.

Looks the bug is in the online backup code and we'll have to wait for a fix, or resort to data only backups in these instances or do offline backups or stay with 2019 for a while.

Dean Drolet wrote:

Sadly, the issue is not really with TIBx format, as this backup also failed using a TIB file, at about 700GB.  Or maybe the format is secretly TIBx in the background, despite the file name being a tib, of course I set that in the script, and also set the format to be tib.

Very strange!  It all seemed consistent until now.  But this was a backup that would have been .tibx if it hadn't been for the changed script.  Yes?  So maybe ATI isn't fooled by the script change an still uses some of the new code.  If so, then the circumvention fails (As Bobbo said: bummer.) but the bug might still be limited to the new .tibx support.

Major bummer if it's a seemingly random bug that occasionally hits both old and new formats.  Have there been any reports of large (2TB or greater) disk/partition backups that have succeeded creating .tibx files?  As far as I know, those consistently fail (except for occasional success with the script change).

Not to side-track this thread, but I am finding a similar issue in rescue media now too.  I say similar because the ATI2020 rescue media is failing to complete a simple 100GB backup due to "lack of resources" and no other information.  I run the same backup offline with 2019 and all is well on this same machine.  I opened a new thread, but in my haste, forgot to save it before adding pictures so it's in the off topic thread for now.

https://forum.acronis.com/forum/topic/ati-2020-20600-rescue-media-fails

Patrick O'Keefe wrote:

Nick Winebarger wrote:

IanL-S wrote:

If I am reading it correctly, this thread indicates that the problem was not present in the beta version of ATI.

Ian

Correct.  The beta had its issues but it at least did backups. 

A minor clarification: The General Availability version of ATI 2020 also does most backups.  It's these just these very large backups that are failing.  If anybody has confirmed doing one of these large backups in the Beta test, I missed it.

But it would actually be good to hear that the large backups worked in the Beta test.  That would imply a bug introduced in the most recent build rather than a fundamental flaw in .tibx design.

I did confirm it in that statement since it that was relating to big backup problem of this thread.  I was a beta tester.  Even have the top 50 award to prove it (shocked, happy, and surprised).  I back up a min of 1.3 TB and other than some software problems that were fixed throughout the beta process and an issue with the recovery partition being create I was able to create backups between 1.3TB-5TB without any problems and almost double the speed compared to 2019.

Like others on the thread, I am backuping up a laptop combining a 256GB system SSD and a 1TB data volume on a 1TB physical disk and the full backup works fine over to a NAS.

So, to avoid confusion, the issue would be linked to the amount of data being backed up, not the size of the disks or partitions involved.

Pat L wrote:

Like others on the thread, I am backuping up a laptop combining a 256GB system SSD and a 1TB data volume on a 1TB physical disk and the full backup works fine over to a NAS.

So, to avoid confusion, the issue would be linked to the amount of data being backed up, not the size of the disks or partitions involved.

 I have a 1tb ssd and a 4tb data drive backing up to a usb3 drive and it backs up 400gb from ssd and 2tb from my data drive so yea its the amount.

I have the same problem.  I routinely run a 1.2TB backup.  Never had a problem under 2019. The backup fails under both 2020 builds at around 800GB. I received an email from tech support today stating that it is a known problem with 2020 and they are working on a fix.

Pat

I am having the same issues that patrickfixedit is having. No problems with ATI 2019 but with ATI 2020 (and their new .tibx filetype)  I experience (with large backups, not small ones) error 0xfff0: Invalid access to memory location. I, too, believe that is how ATI 2020 is written that is causing the problems and NOT all of our computers!! Please do look in to this Acronis, and fix it ASAP!! I moved over from AOMEI back to Acronis to eliminate errors (which AOMEI caused me to have to manually reinstall EVERYTHING, but that's a story for another day!). I'm going back to ATI 2019 until this is resolved, because I cannot spend another week reinstalling all of my programs and settings again--who has that amount of time on their hands, and is this not the reason for backup software in the first place?

@richk, this is a user forum and most of those frequenting it are like you everyday users. There is no doubt that the problem is with the ATI 2020 code and there is a post somewhere saying that a solutionism being worked on. 

May I suggest you submit feedback on this problem via ATI GUI - click on Help, then feedback. Make sure that the attach system report is ticked as this will provide the engineers with information that may assist in finding the cause and an ultimate solution. I suggest you include an link to this forum topic in your feedback. 

Ian

An update: After having created backups using Acronis TI 2019 last night, I am ready to test and submit reports to support with a case I have open with them.

I noticed Acronis TI 2020 build 20770 is in my product list available to download so I upgraded my 2019 install to that and have kicked off some backups.

I will report back with success or failure in a couple of hours. If it fails, I'll send it the requested info to support via the support ticket email I received.

I'm willing to do a remote support session/screen share with engineering if they would like.

Best,

Patrick

IanL-S wrote:

@richk, this is a user forum and most of those frequenting it are like you everyday users. There is no doubt that the problem is with the ATI 2020 code and there is a post somewhere saying that a solutionism being worked on. 

May I suggest you submit feedback on this problem via ATI GUI - click on Help, then feedback. Make sure that the attach system report is ticked as this will provide the engineers with information that may assist in finding the cause and an ultimate solution. I suggest you include an link to this forum topic in your feedback. 

Ian

 

Thanks! I have just done what you suggested.

Unfortunately I have to report back that the new build still fails:

Backup failed

Invalid access to memory location.

The new build still fails around 900GB. 3 hours after I started it, I received the same error.

I have sent all the required details to support re: my open support case.

It's not really a surprise that this "large backup" bug was not fixed yet.  The only (reported) fix in the update was

• [TI-174635] A2 Disk backup to cloud fails with error 'Acronis Cloud is full' after 2019->2020 upgrade

The large backup bug is very serious and undoubtedly has top priority, but Acronis needs time to find and test the fix before releasing it.  We don't want a fix that causes more problems than it fixes. 

Patrick O'Keefe wrote:

It's not really a surprise that this "large backup" bug was not fixed yet.  The only (reported) fix in the update was

• [TI-174635] A2 Disk backup to cloud fails with error 'Acronis Cloud is full' after 2019->2020 upgrade

The large backup bug is very serious and undoubtedly has top priority, but Acronis needs time to find and test the fix before releasing it.  We don't want a fix that causes more problems than it fixes. 

I wish they had a beta program for it.   I would love to test it out. 

Nick, if you have an open Support Case with Acronis for this issue, tell the person you are working with that you would be willing to test any beta fix that they produce - they may decide to take up your offer.

Just adding my name to the list of people experiencing this problem. ATI 2020 fails at about 900Gb with a memory location issue backing up to my NAS.  ATI 2019 works fine.  Appreciate the folks above helping to debug.

james

UPDATE:

I just spent 1.5 hours in chat with a support agent. He collected the system report, logs, etc. and informed me that this is a known issue and I would receive an email once a fixed build was posted. He advised that I go back to Acronis True Image 2019 so that I can complete my backups until the issue has been resolved.

I offered to be a beta tester but I don't think he was interested in my application.

We shall wait I guess.

Patrick

Forum moderator Ekaterina stated the other day that the next release is due out this month and is supposed to fix this.  No idea when this month though.

Kind of pain to roll back to 2019, especially if 2020 is not even usable in this situation. That's a real bummer, especially if you have other working backups in 2020 that are a smaller size since you'll have to start those over too.

Bobbo beat me to this, but I'll keep it posted anyway.

Just be aware that any smaller disk or partition backups that successfully created .tibx files will not able to be processed by ATI 2019.  If you have any such files and cannot afford to lose them, make sure you build a ATI 2020 recovery medium in case you need to recover from those files.

Same issue here, strange thing is that the initial full backup works fine (after creating the job). The subsequent incremental runs fail with the invalid memory location error or destination not available error.

My 1.2 TB backup failed first time, every time with the "destination not available" error.

Pat

My backup is 530GB in size. It also created a second full backup .tibx file with the suffix '-001'.

Unbelievable that a product that has such a major issue is being released and also is still available for download.

Franc.

Frank, the problem was not in either of the public beta, and I cannot say what sort of internal testing would be done on the release version. 

Abundant caution would suggest at minimum users were warned of this now know issue before installing the program.

Ian

I have the same error on backing up large disks 1.1TB and 1.2 TB since loading ATI 2020 to USB 3 Buffalo 4 TB External Hard Drive. Never had this issue with 2019.

Header of error file send to my email:

2019-09-07T05:36:59:222-04:00 21356 I00000000: -----

2019-09-07T05:36:59:222-04:00 21356 I00000000: ATI Demon started. Version: 24.3.1.20770.

2019-09-07T05:36:59:289-04:00 21356 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;

2019-09-07T05:36:59:290-04:00 21356 I00640002: Operation E Disk to Buffalo USB started manually.

2019-09-07T05:36:59:603-04:00 21356 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;

2019-09-07T05:36:59:604-04:00 21356 I013C0000: Operation: Backup

2019-09-07T05:36:59:605-04:00 21356 I0064000B: Priority changed to High.

2019-09-07T07:24:14:419-04:00 21356 E000B042F: Error 0xb042f: Destination is unavailable.

| trace levelc:\bs_hudson\workspace\1105\products\im: error

| line: 0x5d5406763c32a94

| file: c:\bs_hudson\workspace\1105\products\imager\archive\impl\operations\utils.cpp:582

| function: TrueImage::Archive::MakeDestinationUnavailableError

| line: 0x5d5406763c32a94, ager\archive\impl\operations\utils.cpp:582, TrueImage::Archive::MakeDestinationUnavailableError

 I do not find any file as listed:
 c:\bs_hudson\workspace\1105\products\imager\archive\impl\operations\utils.cpp:582

??

ATI backup worked on similar BU on 350GB drive to same USB3 Buffalo Drive.

I can backup same disks to another local drive without apparent problems but the USB drive that I want and had used will not work. I like the safety of removing the USB drive from the system to insure safety from Ransom Ware.

Just in case it helps support debug the problem, my large backup failures were also with a USB attached drive. I detach and use that drive for my remote backup as part of a 3-2-1 backup strategy.

I have not tried to backup to an internal (SATA) volume. 

Mark

 

 

 

Mark Godwin wrote:

Having same problem with large (2+ TB) backups. Will try "files and folders" as a temp workaround until we have a permanent solution. 

 

Mark

This bug may not just be affecting large single backups. I have a backup for my main drive set to keep two chains using the TIBX format. The data on the disk being backed up is about 500GB in size. The initial backup went fine. The second backup chain went fine. But the third failed with the error that the destination drive had been disconnected. I manually deleted the first version of the backup and tried to backup again. It still failed. The only way I was able to backup the drive was to delete the backup entirely and create a new one.

TI 2020 needs to be pulled until this bug is fixed. The software is completely unreliable in its current state.

I don't know whether to laugh or scream at this point: I just received an email from Acronis Support asking if my issue was resolved. I guess the agent I spent 1.5 hours with yesterday failed to update my ticket in the system. 

The release of this broken product, the lack of communication and the failure of Acronis to address this major issue in a timely manner has severely shaken my confidence in this product. I may look for another backup solution and request a full refund. 

Patrick

Same here, opnened a ticket more than a week ago about this issue and it got closed with it was a known issue and they were working on it to resolve it, the agent said. We are now more than a week further and still no solution or response from Acronis.

I'm without a working Acronis backup for more than a week now. Totally unacceptable. Reverting back to 2019 is also not possible since it's not available for download anymore.

I went into my account under downloads. 2020 is the default but there is a pulldown that allows you to pick 2019.

Pat

Thanks, didn't know that #17750 was Acronis 2019. Thought it was the first build of 2020 since when you click on release notes after selecting it, it only mentions 2020.

I'm going to be 100% honest here, and just state that this release should *never* have been released with a bug this major.  the fact that they released an update to only fix the cloud issues they are/were having while we wait on this bug is just plain wrong.  I almost think there should be some sort of compensation for those affected, like either 1/2 our money back, or an extra license, or 2 years of cloud service, etc.  

This product should be pulled from the shelves until a fix is released!  

Dean Drolet wrote:

I'm going to be 100% honest here, and just state that this release should *never* have been released with a bug this major.  the fact that they released an update to only fix the cloud issues they are/were having while we wait on this bug is just plain wrong.  I almost think there should be some sort of compensation for those affected, like either 1/2 our money back, or an extra license, or 2 years of cloud service, etc.  

This product should be pulled from the shelves until a fix is released!  

what is worse is that the beta did not have this backup breaking issue.  There were issues with some backups and restores but majority of it was due to backup schemes.  a single backup (regardless of size) worked using the tibx format. 

Dean Drolet wrote:

I'm going to be 100% honest here, and just state that this release should *never* have been released with a bug this major.  the fact that they released an update to only fix the cloud issues they are/were having while we wait on this bug is just plain wrong.  I almost think there should be some sort of compensation for those affected, like either 1/2 our money back, or an extra license, or 2 years of cloud service, etc.  

This product should be pulled from the shelves until a fix is released!  

 Agreed. They're still advertising it. I got a !@#$% marketing email from Acronis just this morning

Dean Drolet wrote:

 the fact that they released an update to only fix the cloud issues they are/were having while we wait on this bug is just plain wrong. ...

...

This product should be pulled from the shelves until a fix is released! 

I'm certain that Acronis is very much aware of the technical and public relations problems created by this bug.   And I suspect there are technical folk at Acronis that would agree that it should be pulled.

However, I do not agree with your comment about the fix.  Holding back a fix that is ready to go doesn't make much sense.  The speed with which the fix came out says that it must have already been in testing when large backup bug surfaced.  Of course they should have released that fix.

I was planning to upgrade from ATI 2019 to ATI 2020 but, after reading this thread and with a 1.2 TB backup, have been reluctant to do so. 

Tonight, I contacted Acronis about this issue - even directing them to this thread. Their response:

I would like to inform you that there is no such issue with Acronis True Image 2020 version. I assure you that our product is happily used by many Customers. I agree there may be issue in rear case however, it is system specific and can be investigate each case. I would suggest you to please use Acronis True Image 2020 trial version to test the application.

Is this answer correct? Does anyone from Acronis monitor this Forum? 

I was planning to upgrade from ATI 2019 to ATI 2020 but, after reading this thread and with a 1.2 TB backup, have been reluctant to do so. 

Tonight, I contacted Acronis about this issue - even directing them to this thread. Their response:

I would like to inform you that there is no such issue with Acronis True Image 2020 version. I assure you that our product is happily used by many Customers. I agree there may be issue in rear case however, it is system specific and can be investigate each case. I would suggest you to please use Acronis True Image 2020 trial version to test the application.

Is this answer correct? Does anyone from Acronis monitor this Forum? 

 

David, whoever you spoke to in support doesn't have a clue about this issue apparently. I've gone back and forth from 2019 to 2020 and reproduced this bug multiple times. I'm getting pretty fed up with Acronis at this point and I can assure you should you upgrade to 2020 you're going to have the same problem and headaches that the rest of us with big data are experiencing. Currently I am on 2019 and I haven't gotten a response to my last email to support.

If I don't hear something soon then I am going to ditch Acronis and find another solution.

This is unacceptable.

Best,

Patrick

 

 

David Salter wrote:

I was planning to upgrade from ATI 2019 to ATI 2020 but, after reading this thread and with a 1.2 TB backup, have been reluctant to do so. 

Tonight, I contacted Acronis about this issue - even directing them to this thread. Their response:

I would like to inform you that there is no such issue with Acronis True Image 2020 version. I assure you that our product is happily used by many Customers. I agree there may be issue in rear case however, it is system specific and can be investigate each case. I would suggest you to please use Acronis True Image 2020 trial version to test the application.

Is this answer correct? Does anyone from Acronis monitor this Forum? 

Clearly a problem here, the forum Moderator Ekaterina said in an earlier post that the issues is being investigated and that it only happens under some circumstances.

It is unfortunately the case that first level support are not always fully informed about what is going on.

Ian 

I have been following this thread since first posted and finally found the time to give this a test run. 

I created a backup task of my Entire PC, a desktop having 6 storage drives containing 929.2GB total data on all drives.  The target drive for the backup file was a WD Passport USB 3.0 2TB external drive.  The backup failed at some point in the process however, a .tibx file was generated of 742GB in size.  I believe all data was captured and exists in the generated file.

The backup_worker log file showed that the created archive, after creating the file, shows that the "archive close" command was issued and that command experienced an input/output error thus the application "failed to close archive" as evidenced by the log.

Because the file was never closed by the application Explorer is unable to read the contents of the file.  Further, when file property permissions are looked at, all permissions are greyed suggesting that there is no end file metadata so the archive remains open which causes the file to be unreadable/unusable. 

Looking at other backup archives I notice that the Security permissions are different and that inherited permission on the disk level have been applied to this failed backup archive.  Removing these dependencies make no difference as the file remains unreadable.  I believe this is because the file was never closed properly by the application because of the I/O error.

I have submitted my findings along with screenshots, system reports, etc. in hopes to help resolve this issue.

There are at least two very big problems here

1. The backup failure, reported by many users and very well documented by Enchantech.  The technical level of Acronis support is almost certainly well aware of this problem and is hopefully working on a solution.
2. A communication problem within Acronis that will ultimately cause problems for both customers and Acronis.  If Acronis representatives are actively encouraging customers to purchase a (temporarily) seriously flawed product, customers are going to lose backups and Acronis is going to lose customers.

It is, of course, possible that all of Acronis administration is aware of the problem and just doesn't care.  I choose to believe this is not the case. 

An addendum to my previous post:

After the task failed I ran a validation on the backup file.  That validation worked and took a little over 2 hours to complete.  It is obvious that data was being validated and once completed it was possible to open the file in Explorer however, there are no contents in the file that display in Explorer.

So I have a 742GB file with no readable contents.

Enchantech wrote:

An addendum to my previous post:

After the task failed I ran a validation on the backup file.  That validation worked and took a little over 2 hours to complete.  It is obvious that data was being validated and once completed it was possible to open the file in Explorer however, there are no contents in the file that display in Explorer.

So I have a 742GB file with no readable contents.

I am not surprised that the content cannot be seen when the task aborted before completion. The index is probably corrupted and hence cannot be read.

Ian