Influxdb backup not working as expected

,
1

Hi all,

I am using Influxdb v1.7.8 running in a docker-compose environment. Everything works fine, I have successfully inserted several million points using the HTTP api and visualized them in Grafana.

But while trying to implement a backup routine I need some help. I execute the backup as follows:
docker-compose exec -T influxdb influxd backup -portable /var/lib/influxdb/backup

The command is executed successfully, 18 files get created. But all of them are nearly empty (1KB), the data is definately not contained in these files.

What is happening here?

Thanks and best regards
Keith

2

Additional information:
The tar.gz files are all broken as it seems:

root@a89c12d810a1:/var/lib/influxdb/backup# tar xzf 20191008T152834Z.s11.tar.gz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

3

Regression of Restoring backup causes: Error updating shards: unexpected EOF · Issue #9613 · influxdata/influxdb · GitHub?

4

Another finding: All gunzipped tar files are either 512 bytes or 1024 bytes in size. The rest seems to be lost.

5

Still happening in 1.7.9… Nobody seems to care :frowning: Is that reproducable for anybody?

6

I meanwhile traced that down to an issue related to bind mount vs. volume mount.

A simple reproduce case:

mkdir influx_data
docker run --name=influxdb -d -p 8086:8086 --mount type=bind,source="$(pwd)"/influx_data,target=/var/lib/influxdb influxdb
docker exec -it influxdb /bin/bash
cd
influxd backup -portable .

-> backup files get created but are broken:

tar xzf *.s1.tar.gz

-> shows for me:

tar: Unexpected EOF in archive

Everything works as expected when I use a docker volume instead by replacing the “docker run…” command above with:

docker run --name=influxdb -d -p 8086:8086 -v influx_data:/var/lib/influxdb influxdb

Can you reproduce this issue? Do you have an idea what is happening here? May be Windows related, I am running Docker Desktop 2.1.0.5 on Windows 10 Professional.

7

Hi @sauvant,

I’m not able to reproduce this issue on macOS, so it does seem likely that it’s an issue with Windows, Docker, and bind mounts.

We’ll see if we can look into this a bit more, but in the meantime, is using Docker volumes a suitable workaround for you?

8

Sure, will do so. Thank you!

1 Like