Skip to main content

Not able to recover/export backups

Thread needs solution
Forum Member
Posts: 24
Comments: 45



we've run into quite a big problem on one of our Acronis storage nodes - user contacted me complaining that he is unable to select backup for recovery (with Acronis USB recovery media).

He has shown me that it's loading the backup contents for a long time and then ends with "Failed to obtain the backup contents" - thus preventing him from proceeding with the recovery task.
I asked him to try different backup, even different archive (made for another PC), always the same result.

This storage node was recently updated to build 16386 (from 14330) so I thought that maybe he is still using USB media made with previous version (even though he was convinced that he is using the most recent one) and this is some incompatibility problem - but that was not the case. We made a new recovery media with the same result.

So we though that maybe we can at least export this backup (it's in deduplicated location, so from it to non-deduplicated one), do offline recovery and find out what's going on later.

But that also didn't work - after we enter target location and then credentials for source and destination we immediately get following error/warning:

Export problem


This made me think that there must be something wrong with the location itself. I tried to export another backup(s) for different clients, always the same result with location being unavailable.

I'm able to browse contents of any archive and any backup in this location, but unable to export any of them. And since the location is deduplicated, we can't even just simply take out the .TIB files and use them.


What I tried to do - restart all Acronis services, repair the installation (problem started to occur only after the last update), reboot the server. Didn't help.

Then I deleted the location and tried to add it again - Succeeded with warnings. Warnings being:

Failed to read metadata attribute for archive '52838D95-0D7C-4631-9A50-A7BDEC5B1920' from location 'arl:/343FF4AC-B52D-46A3-BFC9-315409071444/28F96BD5-AFB9-4E92-9910-495F2A26B357'.

Error while processing metadata in the database.

violation of PRIMARY or UNIQUE KEY constraint "OWNER_COMPUTER_UNIQUE" on table "ARCHIVE"; Problematic key value is ("OWNER_SID" = 'S-1-5-21-160562036-3150058255-2134394716-580158', "HOST_ID" = '2F94E65F-E7B4-4E85-8DBF-6148B9BF2A7A', "INSTANCE_ID" = '6D14BD41-7570-4FF6-B880-CA609019C1E8', "NAME" = ''); (1, 335544665); (2, 'OWNER_COMPUTER_UNIQUE'); (2, 'ARCHIVE'); (1, 335544382); (2, 'Problematic key value is ("OWNER_SID" = 'S-1-5 ... ....

Failed to reindex archive '52838D95-0D7C-4631-9A50-A7BDEC5B1920' in location '28F96BD5-AFB9-4E92-9910-495F2A26B357'.
Unknown archive: '52838D95-0D7C-4631-9A50-A7BDEC5B1920'.

Cannot open archive 'arl:/343FF4AC-B52D-46A3-BFC9-315409071444/28F96BD5-AFB9-4E92-9910-495F2A26B357/F1E22AFD-2CB1-4298-A1D5-1DB360073C2B' because it is corrupted.
The archive is invalid or its type is unsupported.


Before I did anything else, I first tried to export the backup again - again the error about location being unavailable.

So I went back to this error log, found the archive it was pointing to - which was some old archive from 2019 which wasn't even shown in the Acronis console. So I deleted it manually (both the archive and also corresponding .meta file).

Deleted the Location again, also deleted the .FDB file, so it gets recreated from scratch and then attached it again ... and again the same "successful with warnings". Same warnings, different archive for different PC.

Again I found the archive, deleted it and also the .meta file. And did it all again.

Another successful attaching of the location, again with warnings - another archive. And so on and so on. So far I deleted 6 old archives containing backups from 2019 which weren't even shown in the console.


At this point I have no idea how many more there might be, as the log is completely stupid and useless since it obviously shows ONLY THE FIRST corrupted archive and I can't say if there are 5 or 50 more. It's quite time consuming and I don't even know if that will help with the "The source location selected for replication does not exist or is not available" error (and the recovery problem as well, of course, but I think it's related)


Is there something else I could do to fix it?

Or can someone say for sure, that if I go through this painful process of attaching location -> finding corrupted archive -> deleting the archive -> "deleting" the location -> deleting the FDB file -> attaching the location and do this all over and over again , then it will in the end work and the location is currently unavailable just because this system is completely stupid and prevents exporting backups from location that contains *any* corrupted archives (even though I'm not trying to recover/export backup from any such corrupted archive)?


Thank you for any tips ..



0 Users found this helpful
Forum Member
Posts: 24
Comments: 45

Also - I ran validation task over the whole Location and it was successful. No issues found. 

Forum Member
Posts: 24
Comments: 45

Forgot to update: it seems that after manually deleting ~40 "corrupted" archives and their metadata files (many of them weren't even shown in the console and either contained only some old backups or no backups at all) the export finally works. 

I'm still getting error messages when attaching the Location, but now only 3 instead of 4 - "Failed to read metadata attribute for archive 'XXXXX' from location 'YYYYY'" is gone now, so this error was probably preventing backup export, as it's working now.

I will leave it as it is. Created a new Location which will replace this corrupted one.

Forum Support specialist
Posts: 0
Comments: 1735

Hello Brose,

thank you for posting this on Acronis forums!

Sorry for the delayed response. 

We recommend that you open a case with Acronis Support Team for investigation of this peculiarity. Please collect Acronis System Information from both machines with Acronis Management Server and from Acronis Storage Node components.