All db data lost after unintended update

[FilippoLec]

HI everyone, I have a docker compose EspoCRM instance running on a remote server; recently I fiddling around in docker when I accidentally pulled the containers down, no big problem, I pulled them up again. While pulling them up I saw some messages of "updating to version x.x.x" and the next thing I know is all the data was gone.

I had a backup in the form of all the /var/www/espocrm zipped and saved; I had to do it this way because the script listed in https://docs.espocrm.com/administrat...p-and-restore/ wasn't working and trying to run the mysqldump or mariadb-dump in espocrm-db wasn't even working. I also have a

So: as of now I have all the .frm and .idb file wich seems to be ok by looking at the size but I have not been able to recover them neither from dbsake or mysql frm

I would gladly appreciate any help to at least recover the data

[lazovic]

Hi FilippoLec,

Could you please provide your docker-compose.yaml file with hidden personal data (passwords, URL) for further analysis, and also clarify which exactly commands were used to upgrade your EspoCRM instance?

You can also provide the CLI output when you try to run the command to backup the database from Docker container.

[FilippoLec]

Here is the docker-compose.yaml
'''yaml
services:

espocrm-db:
image: mariadb:latest
container_name: espocrm-db
command: --max-allowed-packet=64MB
restart: unless-stopped
environment:
MARIADB_ROOT_PASSWORD: [root_password]
MARIADB_DATABASE: [espocrm]
MARIADB_USER: [espocrm]
MARIADB_PASSWORD: [database_password]
volumes:
- ./espocrm-db:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 20s
start_period: 10s
timeout: 10s
retries: 3
espocrm:
image: espocrm/espocrm:latest
container_name: espocrm
environment:
ESPOCRM_DATABASE_HOST: espocrm-db
ESPOCRM_DATABASE_USER: [espocrm]
ESPOCRM_DATABASE_PASSWORD: [database_password]
ESPOCRM_ADMIN_USERNAME: [root]
ESPOCRM_ADMIN_PASSWORD: [root_password]
ESPOCRM_SITE_URL: "https://site.espocrm.com"
restart: unless-stopped
volumes:
- ./espocrm:/var/www/espocrm
depends_on:
espocrm-db:
condition: service_healthy
ports:
- 8080:80
espocrm-daemon:
image: espocrm/espocrm:latest
container_name: espocrm-daemon
volumes:
- ./espocrm:/var/www/espocrm
restart: unless-stopped
entrypoint: docker-daemon.sh
espocrm-websocket:
image: espocrm/espocrm:latest
container_name: espocrm-websocket
environment:
ESPOCRM_CONFIG_USE_WEB_SOCKET: "true"
ESPOCRM_CONFIG_WEB_SOCKET_ZERO_M_Q_SUBSCRIBER_DSN: "tcp://*:7777"
ESPOCRM_CONFIG_WEB_SOCKET_ZERO_M_Q_SUBMISSION_DSN: "tcp://espocrm-websocket:7777"
volumes:
- ./espocrm:/var/www/espocrm
restart: unless-stopped
entrypoint: docker-websocket.sh
ports:
- 8081:8080
volumes:
espocrm-db:
espocrm:
'''
As for the commands used to upgrade the instance, I didn't mean to: I stopped the container with 'docker compose down' and then pulled them up with 'docker compose up -d'. While restarting I saw via lazydocker a log in espocrm container saying "updating to newer version x.x.x"; I don't really remember the version but there were like 4/5 of there messages one after another. If there is a global log somewhere tell me where it is and I'll send it too.

When trying to backup the database from the 'backup.sh' I get
'mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect'

and when trying with manual backup I can get to the first part (compressing files) but I still get stuck on the database dump:when entering in the espocrm-db container with 'docker exec -it bash' it says that the command mariadb-dump (also with mysqldump) is unknown.

Note: As of the time when I tryied the backup there wasn't yet the backup script for docker container specifically.

At the moment I am able to enter the espocrm web interface (I had wrong volumes setted in docker-compose.yaml) but there is still no data.

i hope this is helpful.

[tarasm]

Did you modify the docker-compose.yaml before or after restarting the services?

I see the volumes changes:

./espocrm-db:/var/lib/mysql

but it should be the

espocrm-db:/var/lib/mysql

and for EspoCRM itself

espocrm:/var/www/espocrm

as described in the documentation, https://docs.espocrm.com/administrat...docker-compose.

If you made these changes that could be the reason of your problems.

Do you remember the version of EspoCRM before and after upgrade?

[FilippoLec]

tarasm

I did make some changes to try and recover the data. Could it be that it's accessing the wrong volume and therefor not seeing any data?

The current version is 9.0.8 but I don't remember the exact version before the update; by memory I would assume it was along the lines of 9.0.2/3 but just to give some context I started this docker in April 2025 so it would be the version at that time.

[FilippoLec]

Little update: I changed the volumes as described in the documentation but the result is the same as before.

[lazovic]

FilippoLec,

I tested a scenario identical to yours: I initially used a file with volumes without the dot and slash, then changed them to volumes with the dot and slash (resulting in an empty EspoCRM instance), and then changed the volumes back to the original ones. All data was restored.

In any case, if your volumes were previously set up like this:

espocrm-db:/var/lib/mysql

and

espocrm:/var/www/espocrm

and you changed them, then all your data should still be stored in espocrm-db and espocrm volumes, assuming you didn't use the -v flag when stopping the containers.

Now, you can stop the containers (docker compose down), change the volumes back to their previous values, and restart the containers (docker compose up -d). All data should be restored.

[FilippoLec]

lazovic

Thank you for your time,I went through the .bash_history to see what I was doing: at one point I run the command docker rm -vf $(docker ps -aq) but I am fairly sure it was long before today so this can't be the cause. Keeping in mind the history might not be complete I cannot exclude I didn't do it (I was panicking a bit).


As I noted before, changing the volumes to without './' didn't help so at this point I would assume the data is actually gone and I need to focus on restoring the backup.
Should I follow the instruction at https://docs.espocrm.com/administrat...nual-restore_1 ?
Assuming the data is gone would I be better off just making everything new and trying to restore on the new docker the backup?

[FilippoLec]

tarasm lazovic I have tried to restore the last backup I had available; It seemed to have worked at first but now I realyzed that some records are missing. I have made some changes to the default entities and it looks like these changes didn't get transfered during the restore thus making most of the data useless.

I checked the sql query of the backup and the data is there and correct, including the table creation.

[FilippoLec]

I also want to add the fact that making a backup of the data I just now restored also shows that the entity field and data are actually in the database, I just can't see them on the interface nor I can enable them. There are a lot of fields that are not shown, all of which are named c_fieldname.

My theory is that importing the data the way the says didn't remove the original entityes thus making the new one only populate the existing fields and ignoring the others; could it be it?

[lazovic]

FilippoLec,

Please keep in mind that in a Docker environment, data integrity depends on volumes, and if certain manipulations have been performed on them, some data may have been lost. EspoCRM itself and its upgrade procedure do not affect the deletion or disappearance of fields and data.

In general, information about custom fields and entities, as well as their structure, is stored directly in the following path: {ESPO_DIR}/custom/Espo/Custom.
You can view the files in this folder and check which fields and entities are currently present.