Error loading indexes: unable to open pack index "xn37_

Support
1

Hi all,

Running kopia v0.19.0 as a service on Windows 2022. All was good and running great until today. I noticed that kopia was not running. Seems the server rebooted unexpectedly and upon start kopia fails because is unable to:

ERROR failed to open repository: unable to create shared content manager: error loading indexes: unable to open pack index “xn37_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1”: error opening index from xn37_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1: invalid header: invalid header
ERROR open repository: unable to open repository: unable to create shared content manager: error loading indexes: unable to open pack index “xn37_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1”: error opening index from xn37_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1: invalid header: invalid header

The repository is stored in a S3 compatible system and while looking into it I don’t see any object with a name starting with “x”.
I still have the cache. Is there some way to restore the repository?

2

Ok, the xn files seem to be there, I had to use another tool to list the S3 content. Also, that particular file mentioned in the logs is there.
Is ti possible to correct that index somehow? Or skip it and access the remainder of the repository?

image
image731×608 63.1 KB

3

Hey and welcome :waving_hand:

  • If possible, make a copy of your repository to test your changes
  • If object lock is enabled for your bucket, search for an earlier uncorrupted version of the index file
  • If you can’t recover the index file, rename it and try connecting again
  • Run kopia snap verify to check your repository. This should print an error message
  • Run kopia snap fix invalid-files to check which files need to be corrected. Add --commit to this command to rewrite files and correct the errors.
4

Thank you for your quick answer!

  • I am making a copy of the repository (still ongoing, over 5TBs).
  • Unfortunately, this S3 compatible and, as fr as I know, does not even support object lock. So…
  • I don’t think I will be able to recover the index file. So, once the copy is done, I will try to follow with rename and try to connect.
  • I assume that I can run that kopia snap verify from a different computer, right? I am asking because, a few hours before this issue came up, I also experienced an issue with the source data and, before making any repairs to it, I am performing a backup to a new repository (I preserved all the original kopia config and cache in a different directory). This backup will take a huge amount of time and I would really like to be able to move on to perform the so much needed filesystem check (that will also take a lot of time)…

Again, thank you for your very fast help!

5

Update on the current status:

After copying the repository to another bucket, I used a different computer to access the original.
The kopia snap verify displayed no erros and I was able to list my snapshots. So, I moved back to the original computer and renamed the “cache” directory, where I believe the issue is.
I performed a new verify, this time using kopia snap verify --verify-files-percent=1 --file-parallelism=5 --parallel=5 and I got no errors.

I am now going back to use the original repository.

Thank you, @dimejo for your precious help on this!!!

6

Wouldn’t habe thought the cache could cause this issue. Will have to add that to future troubleshooting.

Thank you for reporting back on the solution!