Failure when restoring backup - Influx 2


I’m currently having problems when restoring a backup from influx version 2.3.

To generate the backup file I use the following command: influx backup $DIR --skip-verify

The database has crashed, and didn’t restore itself. So, I had to install it again.

After setting up users and tokens, I perform the following command:

influx restore $DIR --full --skip-verify

The restoration process starts, however, after a while it fails showing error 500

The logs are not very helpful in this case, since the file itself exists in the folder

After the restore, I’ve changed the CLI token, however, the error is always the same.

I have made different backups at different times, and none of them could have been restored using the --ful argument.

Any thoughts on what might be the problem?

1 Like

Hello @giuliano.lm,
I’ve asked the team. This is what I’ve heard so far:

This jumped out at me.
To generate the backup file I use the following command: influx backup $DIR --skip-verify
The database has crashed, and didn’t restore itself.
I read that as the process crashed while backing up, which if that’s the case I guess it wouldn’t be terribly surprising that things weren’t working. Maybe that’s not what they meant though

Have you tried since? Is it working now? I’ll keep commenting here if I get any more answers.

Hello, @Anaisdg

To do the backup the process runs fine in my case. We can generate the backup files with manifests and etc.

The failure occurs during the restoration process. The problem remains.

Another way that I tried was not using the --full argument: influx restore $DIR --skip-verify

In that case, the RAM usage gets quite high, and “unexpected EOF” error appears. As a consequence, the DB crashes.

In this second way, if I give enough time between restoring each bucket (I would imagine for the cache to be written), the DB does not crash.

Our DB has 8GB of RAM, so I expected that not to be a problem. Anyway, one solution that I’m testing is simply increasing the available RAM for that server.

If you need more detailed description of the problem, let me know!

Thank you for your attention.


Would you be willing to share your backup? You can leave out the kv and sqlite files to avoid sharing any creds, but having a look at the shards/manifest would hopefully make it much easier to reproduce/debug.


I cannot share with you my entire backup, but I can share an specific bucket. Hope you will be able to replicate the error when using the “–full” argument.

Please, let me know the best way to share the file with you.

Regarding the second error I mentioned (unexpected EOF, following by a DB crash), it disappeared after we increased our available RAM.

Specific bucket will work! Thank you! You can message me directly too if you prefer