Events counts per day lost after database restore


I installed Sentry using the example docker-compose in this repository:

After some hours I docker-compose down, moved the sentry/files and sentry/postgres volumes data to other places in my VPS, updated the docker-compose volume paths, and docker-compose up. At first a config mistake I did made postgres recreate an empty DB. But after another down/up I fixed it, and postgres used the same old DB, but from the new place I pointed the volume to.

After the last docker-compose up everything was right, except the bar charts with events counts per hour/day. They all displayed 0, even if the events were there. New events seem to increase bar count accordingly, but not for the old ones.

I’m not sure if I understood this thread right, but maybe that kind of data is saved on Redis?

Is that right? If so, maybe the example docker-compose should be updated to store Redis data in a volume? If that makes sense for Redis, I don’t know it very well… If not, will that data always be lost on container recreation?

It also would be helpful if the docs made clear what had to be saved in a backup/restore procedure. My guess was to backup the volumes in the docker-compose, but it seems they aren’t enough in this case.

For curiosity´s sake, is there a way to regenerate the bar charts data based on the events in the database?

1 Like

Yes it is correct and the new version over at includes a dedicated volume for redis.

That’s a good point and I’ll see if we can create a backup/restore guide some time in the future. If you are interested though, our docs repo is also open source :wink:

I don’t think so unless you find a way to get that redis data back :frowning:

Thanks for the response!

It’s good to know the docker-compose will be patched.

I said docs, but a few lines in the onpremise repo readme would be enough for me. Something like:

“To backup/restore copy the sentry-data volume content and use the recommend procedures for the postgres and redis images.”

1 Like