Skip to main content

Backup fails - "Database file appears corrupt"

Thread solved
Forum Member
Posts: 16
Comments: 30

Hello,

I'm not sure what exactly happened, but some backup plans started to fail on one of our Storage Nodes. Most of backup plans there works well, but there are (currently) 3 PCs whose backup plans are failing constantly and judging from the error message, it's only a matter of time before it gets worse.

We are getting following error message for those 3 clients:
database file appears corrupt (C:\PROGRAMDATA\ACRONIS\BACKUPANDRECOVERY\ASN\VAULTMETADATADATABASES\28F96BD5-AFB9-4E92-9910-495F2A26B357_L.FDB); wrong page type; page 0 is of wrong type (expected 7, found 1); (1, 335544335); (2, 'C:\PROGRAMDATA\ACRONIS\BACKUPANDRECOVERY\ASN\VAULTMETADATADATABASES\28F96BD5-AFB9-4E92-9910-495F2A26B357_L.FDB'); (1, 335544650); (1, 335544403); (4, 0); (4, 7); (4, 1)

So it seems that vault metadata DB got corrupted somehow and now I wonder what to do with it. I guess there's no way to fix the broken .FDB file, so is the only way to fix this deleting (or moving somewhere else) the FDB file and letting the server create a new one by refreshing the Vault/Location?

Will we lose anything by doing that? There are plenty of archives and backups present on this Storage Node in its deduplicated Vault.

Thank you for any hints/tips

Lukas

0 Users found this helpful
Support specialist
Posts: 0
Comments: 1269

#1

Hello Lukas,

thank you for posting on Acronis forums!

So it seems that vault metadata DB got corrupted somehow and now I wonder what to do with it. I guess there's no way to fix the broken .FDB file, so is the only way to fix this deleting (or moving somewhere else) the FDB file and letting the server create a new one by refreshing the Vault/Location?

Yes, you are correct. At first, please refresh this vault (where these three machines are backed up).

If it does not help, please detach the vault from ASN, then open the vault's folder and delete 28F96BD5-AFB9-4E92-9910-495F2A26B357_L.FDB file from there. After this, you can attach this vault back to ASN. The new .fdb file will be automatically created after rescanning this vault. 

 

Forum Member
Posts: 16
Comments: 30

#2

Hello Maria,

 

thank you for your recommendation, I was successful in the end, but it wasn't as simple as I expected (well, it was, but not really :) )

Just in case anyone would go through the same issue as I did, I will list the steps I did until I found out the right way to do this. It will be maybe unnecessarily detailed, so if you just want to know the solution, then skip to the last step:

1. Detached the vault with corrupted DB

2. This automatically deleted .FDB file from VAULTMETADATADATABASES, so there was nothing for me to delete manualy

3. Attached the vault again - Succeeded with warnings
In the log there was a warning stating "The value of field 'catalog_method' in the database does not correspond to its value in the metadata file. Copying the value from the metadata file to the database..."
and also Error that one archive can't be open and that it's invalid or its type is unsupported.

4. For some reason I wasn't able to refresh the Vault ("database file appears corrupt.."), so I detached it again, restarted Storage Node Service and attached it again

5. Again it succeded with warnings, with the same warning description, but this time also with additional error, that it failed to reindex archive (the same archive that it's saying that Acronis can't open)

6. Nevertheless, this time it was possible to refresh the archive and browse its contents, so I ran the backup plan, that was failing.

7. Same error again (database file appears corrupt..). Same for 2 other clients and their backup plans..rest was working. So I temporarily created another Vault and tried to make the backups there and it was working, so I was sure, that problem really is with this specific Vault database.

8. I went back to log for attaching the Vault, checked archive ID, found it on the server and noticed that it's empty (containing only empty "1" and "1_data" folders, no data), so I just deleted it, detached the vault, attached it again (at this moment I was thinking that maybe if I fix warnings/errors appearing when attaching the vault, the problem will be solved)

9. Again, succeeded with warning. Different archive ID this time. Archive again with no data, just empty folders. Deleted the archive, Vault detach, Vaul re-attach.

10. Same warnings/errors again..different archive...

11. I did step 9 at least like 6-times, every time it was reporting different empty archive (each time for different client) which I deleted afterwards, so my patience wear thin and I lost hope, that this might eventually fix the issue.

12. I checked the VAULTMETADATADATABASES folder again and noticed, that every time when I detach the Vault, .FDB file goes missing and re-appears after I attach the Vault again, it's always the same size (even after I did some changes in the Vault). In the file properties I noticed that it was created months ago (and not just only a moment ago, when I re-attached the Vault), so I started to think that Acronis probably doesn't delete this file, only moves/hides it and then use the same file again when I attach the Vault again

13. so I first deleted the .FDB file, then detached the Vault (which was still appearing in the console), then restarted Storage Node service (just in case, probably unnecessary) and only after that I attached the Vault again. 
This finally created brand new .FDB file and I'm not getting database error any longer.

 

 

Lukas

Support specialist
Posts: 0
Comments: 1269

#3

Hello Lukas.

I'm sorry that I did not emphasize that the .fdb file should have been deleted in the vault's folder. 

You have correctly noted that the corrupted .fbd is automatically deleted from VAULTMETADATADATABASES right after you detach the vault and copied to the vault's folder location for backup purposes. That is why we should delete the .fbd file there in order to avoid all these peculiarities.