DB is getting dropped frequently

Custom Deployment
1

I have deployed custom project on cloud and running using docker-compose but daily db is getting dropped. Seems like Timescaledb is doing some migration. I dont need migration. Could anyone please help with this issue?

2

can you paste your docker-compose.yml I suspect that OR_SETUP_RUN_ON_RESTART: may be true

3

here is my docker compose file. I have set OR_SETUP_RUN_ON_RESTART variable to false.
docker-compose.yml.txt (2.5 KB)

4

Could you please check docker compose and help me with a solution?

5

This is your managers docker file can you also share you docker file in your custom project directory? To my knowledge these are the only variables that can cause a db wipe:

      # Developer mode (see code for usages of OR_DEV_MODE flag)
      OR_DEV_MODE: ${OR_DEV_MODE:-false}

      # !! WARNING: This will wipe your database !!
      # Force a full clean and setup on startup irrespective of whether there is existing data
      # Default behaviour is false unless OR_DEV_MODE = true or openremote database doesn't already exist
      OR_SETUP_RUN_ON_RESTART: ${OR_SETUP_RUN_ON_RESTART:-false}

make sure they are both set to false. in your custom project docker file.

6

docker-compose.yml.txt (5.9 KB)
Uploaded updated docker compose file. I tried the variable you mentioned but still everyday there is db crash.
I get this log after db crash -
2023-10-31 04:45:37.050 CET [231426] FATAL: database “openremote” does not exist

7

please help with the file correction if required or any other suggestion to resolve the issue

8

Added log file
logs.txt (1.2 MB)

9

I don’t know how you managed to delete the database. (maybe you did manually?)
And since the containers automatically restart on shutdown (see restart: always option),
it will fail to start continiously.

Most of the errors in the logs file are just a result of no openremote database being present.

A new database will only be created by us if OR_SETUP_RUN_ON_RESTART is set to true.
Doing this will basically run a script from us that will intialise the database including its tables.
That’s why you see the TimescaleDB migration, it’s part of the script.

So please put the variable back to true, to redo the database initialisation.
As @craigsweb this should be set to false when your database is installed and in production.

If that doesn’t work, you should simply delete the docker volumes for a fresh installation.

.
Back to the original issue;
The only other cause of a DB drop I could think of is some CI/CD script / cronjob.
For example, we ourselves daily drop the database for our demo deployments.

Because, what is the exact issue you are going through?
“everyday there is db crash” or the “daily db is getting dropped” ?
Would be nice for us forum users to get some context :slight_smile:

Hopefully this helps in your search!

10

The issue was the malware attack and it was making db crash. After enhancing security and removing malware db stopped crashing.

1 Like
11

Have you solved your problem? I have also encountered the same problem

13

increase security and recreate the existing cloud instance