Moving Repository to a New Storage Location

I just started evaluating Kopia this month and am hoping someone here can help me with the following issue which I encountered/created when attempting to move my repository to a new location on the same drive (a 2 TB external USB drive). Currently, I am using Kopia UI v.0.8.4 on a Ubuntu 18.04.3 LTS desktop with KDE.

Here are the steps I followed attempting to move my repository:

  1. Created new directory on same drive
  2. Moved all Kopia files to the new directory
  3. Updated the path value in my ~/.config/kopia/repository-?????????????.config file with this new path.

Then, when I started the Kopia UI, it did not automatically find and connect to the repository as it usually does when this USB drive is mounted. So, I tried “Connect to Another Repository…”; picked Filesystem; entered my new path; and entered the repository password.
Kopia responded with:
Connect Error: INTERNAL: internal server error: connect error: unable to create shared content manager: error loading indexes: decrypt error: cipher: message authentication failed

I undid all of this (moved files back to original location; restored ~/.config/kopia/repository-???.config; and even power cycled my machine); but, I am still seeing the same behavior and error message when I start the Kopia UI.

Any advice/insight on what I did wrong and how I might recover would be greatly appreciated. If additional information would be helpful, please let me know what you would like to see.

This is a 31G repository; so, I’d like to avoid recreating it in addition to just understanding Kopia better before choosing it as a backup solution for my family.

Thank you.

You likely have a damaged index file. Look for files that starting with n which are zero length and try deleting them?

Thank you for your quick suggestion.

I searched the repository location as well as my local ~/.config/kopia-ui and ~/.config/kopia directories but found no files starting with n, zero length or otherwise. (The only results from these searches were several directories in the repository.)

Are there other locations I should be searching or other suggestions?

This is how I searched in each directory: find . -name "n*" -print

Thank you again.

sorry, I meant to say “look for zero-byte files in n* directories”.

I don’t have any zero length files in my n* directories; but, I do have 16 files that are very small, all exactly 159 bytes, found using:
find ./n* -size -1000c -type f -exec ls -la {} \;

I also have 33 zero length n* directories in my repository found using:
find ./n* -size 0 -type d -prune -print

Thank you for your quick replies.

The error generally indicates that the encryption key for the repository does not match the encrypted files. zero-byte files would be common culprit, but it does not appear to be the case.

Can you do:

kopia blob ls

Find a blob starting with n (or try several of them)

kopia blob show --decrypt n<hash>
if this works for some blobs but not others, we know which ones are damaged - try removing them.

You can also try kopia index inspect n<hash>

If it does not work for all blobs, you somehow ended up with wrong kopia.repository (possibly from another location) that does not match the blob files - did you try using kopia repository create in the new location?

For future reference - try moving data using kopia repo sync-to filesystem --path <new-path> and connect to the new repository.

The kopia blob and kopia index commands seem to require the repository already be successfully opened; but, Kopia continues to return failed to open repository: unable to create shared content manager: error loading indexes: decrypt error: cipher: message authentication failed when I attempt to open the repository using kopia repository connect filesystem --path

I am sure that I am using the correct password since Kopia returns failed to open repository: invalid repository password when I attempt to open this repository with a random password.

I tried kopia repository repair filesystem --dry-run which returned

looking for format blob…
format blob already exists, not recovering, pass --recover-format=yes

Should I try kopia repository repair filesystem --recover-format=yes or something similar?

Note: I have backed this machine up to another repository on a different drive. That repository seems to still be working fine both from the command line and from the GUI.

Can you make sure that the repository that works and the one that does not has the same kopia.repository file? It’s looking like you’re providing the right password, but the master key that is decrypted using that password is incompatible with files in the repository, which could only be explained if there were two of them and they got mixed up somehow?

BTW. There’s also a cached kopia.repository in a cache directory on the machine that works, please save it somewhere since this is the good copy.