Backups Stuck Applying Retention Rules
Acronis and the Acronis Community,
I recently updated from v11.5 to v12.0. It's been a bit of a nightmare. v11.5 worked perfectly and v12.0 has given me nothing but trouble. I have tried the chat support and have case numbers but it hasn't yielded any results in this matter.
With that said, let me present the issue:
I have two backup plans for two different sets of data. Sometimes they are executed flawlessly, other times they get stuck on the 'Applying retention rules' portion of the backup. For instance, ive had backups running for the past 4 days flawlessly, and then this morning I had one give me this error. I end up having to cancel the process and it informs me backup completed but with errors. The errors show in the console are:
0x01350032+0x01350032+0x01490002+0x01350032+0x01350032+0x01350032+0x01350032+0x01350032+0x01350046+0x01350032+0x01350032+0x00A100D9+0x0017000B+0x0017000C+0x0004001F+0x00040001+0x0004000F
I have looked at the activity log and I see bunch of the same repeated errors:
2016-11-23 02:37:58:444 7300 C0000001B: Assertion failed: hashesCount, file k:\3622\archive\data_reader.cpp, line 523
2016-11-23 02:37:58:811 7300 C0000001B: 0x000007FEE553DDB6 DiskBundle.dll+0x33DDB6
0x000007FEE6295ED4 DiskBundle.dll+0x1095ED4
0x000007FEE62958C5 DiskBundle.dll+0x10958C5
0x000007FEE6264DAC DiskBundle.dll+0x1064DAC
0x000007FEE626277C DiskBundle.dll+0x106277C
0x000007FEE6260791 DiskBundle.dll+0x1060791
0x000007FEE625F837 DiskBundle.dll+0x105F837
0x000007FEE64020BC LoadAddons+0x9A15C
0x000007FEE63FE3BA LoadAddons+0x9645A
0x000007FEE6400984 LoadAddons+0x98A24
0x000007FEE63F86DB LoadAddons+0x9077B
0x000007FEE6397D78 LoadAddons+0x2FE18
0x000007FEE61A5AAE DiskBundle.dll+0xFA5AAE
0x000007FEE61A4B37 DiskBundle.dll+0xFA4B37
0x000007FEE5481FF0 DiskBundle.dll+0x281FF0
0x000007FEE5485488 DiskBundle.dll+0x285488
0x000007FEE54823EA DiskBundle.dll+0x2823EA
0x000007FEE547F070 DiskBundle.dll+0x27F070
0x000007FEE5489622 DiskBundle.dll+0x289622
0x000007FEE548908C DiskBundle.dll+0x28908C
0x000007FEE547F823 DiskBundle.dll+0x27F823
0x000007FEE5483471 DiskBundle.dll+0x283471
0x000007FEE5497286 DiskBundle.dll+0x297286
0x000007FEE53F6C78 DiskBundle.dll+0x1F6C78
0x000007FEDF28DBF7 staging_command.dll+0xDDBF7
0x000007FEDF27A7F8 staging_command.dll+0xCA7F8
0x000007FEDF39E695 staging_command.dll+0x1EE695
0x000007FEDF39B06E staging_command.dll+0x1EB06E
0x000000013FD791DE service_process.exe+0x1A91DE
0x000000013FDE6C1E service_process.exe+0x216C1E
I am attaching the log file from last nights backup for further review. For the aid of diagnosis, details on my backup plan are as follows:
- Custom Scheme (Full Backup on weekend / Differential on Monday - Friday)
- Clean up is set to 7 days.
- Backup is written to a disk array server on the same network.
- Backups are performed overnight when the business is closed.
Any help into this issue would be greatly appreciated! Thank you!
Hi Sami,
It looks like you've run into a rare bug (internal ID: ABR-109508) - it sometimes appears when performing files/folders backup and retention rules come in play. We're currently investigating this bug with our core development team and plan to fix it in the next update (unless something goes wrong).
The workaround for this issue would be to capture disk/partition backup instead of files/folders one. In other words you should back up entire E:\ volume. Note that you can also apply files/folders inclusion/exclusion rules to this backup plan in order to effectively back up just the required data (single folder).
Thank you.
Vasily,
Thank you for your response. You are the first person to actually acknowlege this is a issue with your software. I am going to be honest this bug is unacceptable. This bug in your software has brought my enterprise down 3 times in the past three weeks (actually 4, once more as of this morning). As a paying customer, and as a busy IT admin, I cannot utilize a product that puts my network and data at risk. I cannot imagine that I am the only one struggling with this.
I appreciate your workaround solution, however, this is a MAJOR feature of your software that is apparently non-functional and this bug should have been disclosed to all customers. If I would have known this bug existed, I would have never upgraded to version 12.
I want to roll back to Version 11.5. or 11.7...so I will be downloading this and re-installing it immediatly.
Is there an ETA on the update with the fix?
Again, I appreciate your direct assistance and honesty in this matter. Look forward to your response.
I also have this issue and have posted about it. I got a simliar answer that this is a "bug" and will b resolved soon. Question is, how soon?
We put our reputation on the line in our professions that the product we recommend will serve the needs of the people we answer too. What we do not need, is to have a "bug" in a critical program defeat backup strategies.
Again, when will this be resolved?
I have this issue as well. Seems a shame that I have to change my backup jobs now to work around this issue. Bit of a pain to be honest. No chance of a hotfix instead of waiting for a full blown update?
Hi,
We're discussing the fix inclusion with our project managers to see if we can fit it into the next major update for Acronis Backup 12 pending for Feb. 2017. There are still (low) chances that we won't be able to do so, and this would move the fix availability to Q2 2017. Once the situation becomes more clear I'll update the thread.
Thank you.
Thanks for replying. It's strange it has only just started doing this. I am assuming that the previous backups will not be removed now as the retention cleanup job is not working as expected?
Hi Mark,
Yes, your assumptions are correct - when retention rules detect that some backups became subject to deletion, it won't happen because of this bug. To note: the problem affects only files/folders backup type and does not affect any other types (entire machine/VM, disk/volume, application).
Thank you.
We're discussing the fix inclusion with our project managers to see if we can fit it into the next major update for Acronis Backup 12 pending for Feb. 2017. There are still (low) chances that we won't be able to do so, and this would move the fix availability to Q2 2017. Once the situation becomes more clear I'll update the thread.
Update: I've got final confirmation from our project managers that the fix will be included into Acronis Backup 12 Update 3 (current version is Update 2 build #3622) which is planned to be published in Feb. 2017.
Thank you for the update - I look forward to it - whilst the workaround is fine for backing up - preliminary tests of data restoration (individual or multiple files/folders) prove that restoring from a volume/partition backup is tediously slow - just moving through the directory structure can take upto five minutes to display the contents of the folder and some of our folder contains tens of thousands of other folders.
Hi Mark,
The files/folders browsing speed inside backup via web console should not differ too much between files/folders archives and disk/partition ones - the overal slowness in your scenario is likely caused by Acronis Backup web console specifics (where it's hard to display thousands of elements at one time - we're aware of this issue and plan to solve it in the next year updates).
The best way to perform the file recovery scenarios is via Acronis extension for Windows explorer which is installed along with Agent for Windows - this way you can simply open Windows explorer -> browse to the backup location where .tib files are -> double-click on any .tib file and either explore it directly OR mount the volume from it. See details here.
Thank you.
Excellent - never tried that before! Worked a treat - MUCH better than the browser based restore. Thanks.
Thank you Vasily for helping to escalate this issue.
Hi Vasily,
I am trying to perform a restore via the Acronis Extension for Windows Explorer as you explained; however, I am experiencing difficutlites. The problem I am having is that when I right click the volume I want to mount and click "Mount as read only", it always mounts the "System Reserved" volume, regardless of which volume I attempt to mount. I have 3 different volumes available in the TIB file (C, D, and E), and I can browse each one fine with no issues. However, when I try to mount it, it always mounts as the "System Reserved" volume. What is happening here? I tried to copy files directly from browsing the volumes, but this does not work. Any ideas?
Regards,
Ryan
Hi Ryan,
The incorrect volume mounting is caused by a recently discovered bug (internal ID: ABR-111976) - the workaround is to simply double-click on the required volume (or right-click->Open or right-click->Explore) instead of "mount in read-only mode". This will drill down to the volume contents. See attached screen shots which should help.
Thank you.
I hve followed your guidance on setting up VOLUME backsup, but not the retention rules are kicking in on this new job I ham having the same issues with the backup job getting stuck after the backup has completed. The data IS backing up, but I have to manually cancel each job every day. This needs to be fixed ASAP, as I dont really want to micromanage all my file backup/volume backup jobs.
(For the record, full server and exchange database & SQL backups work as expected).
Mark,
The issue with backup jobs stuck which have to be cancelled appears to be a new one unrelated to this particular topic. You should contact our support team for assistance with it.
Thank you.