Cant access my backups - invalid character 'H' in literal null (expecting 'u')

I keep getting this error listed here but I haven’t had any help regarding it, would someone be able to help me out?

I can’t interact in any way with my repo as I just get that error.

I’ve tried doing this on 2 separate computers and I’m getting the exact same issue, so I don’t know what is causing it.

This looks like a malformed key file, but I can’t say for sure without looking at it. Would you be willing to send me a private message with the contents of the files under keys? (The key material is encrypted with your repository password. I will destroy them after I’m done helping.)

How can i message you?

If you click my name/icon on this post, in the upper-right of the little panel that pops up there should be a “message” button.

Nope, i don’t see it.
Imgur

Odd, for some reason you may lack permission to send private messages. I’ve sent one to you; see if you can reply to it.

After looking at the key, something is definitely wrong. It’s binary garbage, and it should be JSON (text). @fd0, was there any version of restic that stored keys as binary blobs and not JSON?

My suspicion without more information is that this file was corrupted.

1 Like

What is weird is if i decrypt the binary data through AES256, it seems to give me some base64 code?

New signed up users can’t private message other users right away. They have to first get the automatic discourse rank to do that - I think that happens after a short while of them being on the board and active. That’s why :slight_smile:

1 Like

No, restic always used JSON for the key files. There was no version ever which used a binary format for that.

Uh, what? Can you please elaborate? I find this very surprising. Are you sure? Which key are you using for AES256? How are you decrypting the data exactly?

Are there any other key files (=passwords) for the repo? If not, and the key file is indeed corrupt, there are two issues:

  • You cannot access any data stored in the repo, nor add new data
  • The storage medium for the repository or the local machine (RAM, CPU) has a severe problem

I’ll pm you the details for the key file stuff as I don’t want to make public. I used the password which I used to generate the repo initially as the AES key, and I went online and found an AES decrypted to decrypt the data. Maybe its a fluke but it looked like base64 to me.

The key file I found was the only file under the directory “keys”.

I don’t think its a issue with the storage medium as when i first created the repo it was on my laptop, and i backed up everything, and have since read from it on both computers and its fine. Several months had passed and now i cant read from it at all anymore (on either computer).

Looks like i was incorrect, i swear yesterday when i done it it decrypted into base64, i was even going to send it to @cdhowie but all the websites i try now are erroring, so thats weird.

Anyway i guess the repo is dead and unrecoverable? I really wonder what went wrong, it sucks loosing your backup because there was fairly important data in there. :frowning:

It is unfortunate, yes. It is good backup hygiene to regularly test your backup by restoring it to a spare disk. You should also keep an additional off-site copy of the backup for physical disaster recovery.

Running restic check --read-data on all copies on a regular basis is a good idea; it will make sure that all of the data restic has stored is intact. (Performing test restores ensures that restic has stored the data you wanted it to.)

Presumably this could have detected the failure before you needed the backup.

At this point I would suggest running memtest, a CPU stress tester, and disk tests on your backup disk to figure out which one of them failed.

I ran the intel diagnostic tool which passed and spent a night running the memtest and that passed as well. The hard drive smart status all seems normal so i don’t know how else to test that either.

Ill try running things like Prime95 and memtest again over the next few days.

You can run a test (either long or short) via SMART, so the drive is instructed to check itself. That might also be helpful.

You can also run sha256sum on a few files in the repository to get an idea of the extent of the damage. All files in the repo (except the config file) should have a SHA256 hash which matches the filename. This should also be the case for the corrupt key file, which unfortunately is one of the few very vital files.