Hi
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
thanks
Hello @dudu7731,
I’m not sure.
Let me ask around.
@dudu7731,
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.
hi
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
r
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 …
Yes.
You likely have a nginx reverse proxy between you and the server.
Try a http direct connection
