Error 413 while restoring


I’m trying to restore a backup on another bucket with command on debian 11 (influxdb V2.6) :
influx restore --bucket hass -o production --token <MY TOKEN> /tmp/hass_influx.bak --new-bucket hass_dev

it leads me to this error :

2023/03/02 17:21:09 INFO: Restoring bucket "fc6b2f98dc61b5c9" as "hass_dev"
2023/03/02 17:21:14 INFO: Restoring TSM snapshot for shard 454
Error: failed to restore TSM snapshot for shard 454: 413 Request Entity Too Large: unable to decode response content type "text/html"

FYI my backup command
influx backup --bucket hass -o production --token <MY TOKEN> /tmp/hass_influx.bak

how can i handle this ?

i’ve been looking for some internet ressources for 2 days but i can’t troubleshoot this


Hello @dudu7731,
I’m not sure.
Let me ask around.

From a coworker:

so, ask if they are backing up with the compression option, and (regardless of the answer) how big their shard file is. They may need to do some ugly generation of line protocol from the backup and ingest it that way if they have created a huge file that is compressed. I would have to research the options for them going forward, but I will wait on a response before I spend that time.

thanks for the reply

My backup is around 26 Mo and my bucket is around 109 Mo.

Here is the file list of my backup :

-rw-------  1 root root  16K  2 mars  10:04 20230302T090423Z.bolt.gz
-rw-------  1 root root 3,4K  2 mars  10:04 20230302T090423Z.sqlite.gz
-rw-------  1 root root 3,3M  2 mars  10:04 20230302T090423Z.1.tar.gz
-rw-------  1 root root 3,6M  2 mars  10:04 20230302T090423Z.166.tar.gz
-rw-------  1 root root 3,8M  2 mars  10:04 20230302T090423Z.177.tar.gz
-rw-------  1 root root 3,6M  2 mars  10:04 20230302T090423Z.187.tar.gz
-rw-------  1 root root 3,7M  2 mars  10:04 20230302T090423Z.197.tar.gz
-rw-------  1 root root 3,4M  2 mars  10:04 20230302T090423Z.207.tar.gz
-rw-------  1 root root 3,7M  2 mars  10:04 20230302T090423Z.217.tar.gz
-rw-------  1 root root 4,1K  2 mars  10:04 20230302T090423Z.manifest
-rw-------  1 root root 1,5M  2 mars  10:04 20230302T090423Z.391.tar.gz

nothing too big i think.

and i use the default compression (gzip)
my backup file list look like this wihtout compression :

-rw-------  1 root root 128K  8 mars  08:55 20230308T075507Z.bolt
-rw-------  1 root root 120K  8 mars  08:55 20230308T075507Z.sqlite
-rw-------  1 root root 8,3M  8 mars  08:55 20230308T075507Z.1.tar
-rw-------  1 root root 9,3M  8 mars  08:55 20230308T075507Z.166.tar
-rw-------  1 root root 9,3M  8 mars  08:55 20230308T075507Z.177.tar
-rw-------  1 root root 9,1M  8 mars  08:55 20230308T075507Z.187.tar
-rw-------  1 root root 9,2M  8 mars  08:55 20230308T075507Z.197.tar
-rw-------  1 root root 9,1M  8 mars  08:55 20230308T075507Z.207.tar
-rw-------  1 root root 9,4M  8 mars  08:55 20230308T075507Z.217.tar
-rw-------  1 root root 9,6M  8 mars  08:55 20230308T075507Z.391.tar
-rw-------  1 root root 4,5K  8 mars  08:55 20230308T075507Z.manifest
-rw-------  1 root root 3,5M  8 mars  08:55 20230308T075507Z.468.ta


I tried also without compression, still same error

before o the v1, we were able to set max body size but with the v2 i don’t find how to set a such parameter, I think we could not do this that way anymore

Any idea ?

i can’t restore my DB in case of failure …