# Docker Compose issue risking data loss of complex\_obs **URL:** \ **Category:** Development\ **Tags:** ozone, docker, o3\ **Created:** [July 4, 2025, 5:46pm UTC](https://talk.openmrs.org/t/docker-compose-issue-risking-data-loss-of-complex-obs/46470 "2025-07-04T17:46:40Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\ **Post date:** [July 4, 2025, 5:46pm UTC](https://talk.openmrs.org/t/docker-compose-issue-risking-data-loss-of-complex-obs/46470/1 "2025-07-04T17:46:40Z")
@michaelbontyes raised a really interesting issue with me today: - In the RefApp currently we have 2 docker volumes: the OpenMRS Database, and OpenMRS Data. - Your OpenMRS Data Volume (looks like openmrs-data volume) contains complex\_obs, like patient photos/attachments for example (as you can see in the screenshot below). ![image](https://talk.openmrs.org/uploads/default/original/3X/f/b/fb68d4df9589fa7255484cb0c9a86a4ea8d1e4df.png) - Sometimes when you have changes in your Docker cache, or updates / new versions in your binaries, or for backup reasons, you will want to start fresh with your volumes. - - ⚠ But: you have to be _really_ careful about resetting this because you have patient data, like patient attachments, in the same volume where you have OpenMRS binaries and configurations. So you could **update your binaries and _lose_ those complex obs**. I have questions for @dkayiwa @ibacher: - Are we already aware of this concern? - Ozone 13+ solves this by separating patient data; should we incorporate this approach into how we package the RefApp/EMR as well? [ozone-docker-compose/docker-compose-openmrs.yml at main · ozone-his/ozone-docker-compose · GitHub](https://github.com/ozone-his/ozone-docker-compose/blob/main/docker-compose-openmrs.yml) ![image](https://talk.openmrs.org/uploads/default/original/3X/c/1/c1eea13cc80e94986ce3a12f4f6a27dbf61b46dd.png) This contrasts with the RefApp where they are in openmrs-data volume [openmrs-distro-referenceapplication/docker-compose.yml at main · openmrs/openmrs-distro-referenceapplication · GitHub](https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/docker-compose.yml) ![image](https://talk.openmrs.org/uploads/default/original/3X/0/4/0465de7c0f89a2d3441f9077458437e669bd44b7.png) ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [July 5, 2025, 9:01pm UTC](https://talk.openmrs.org/t/docker-compose-issue-risking-data-loss-of-complex-obs/46470/2 "2025-07-05T21:01:55Z")
I totally understand the difference between patient data that cannot be automatically recreated, and the other categories. I had never thought of this. And for these cases, i would vote yes to using the same approach as Ozone. ---
**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\ **Post date:** [July 8, 2025, 10:35am UTC](https://talk.openmrs.org/t/docker-compose-issue-risking-data-loss-of-complex-obs/46470/3 "2025-07-08T10:35:06Z")
We can definitely put complex-obs in a separate volume, but that’s not enough in most cases. Unfortunately before openmrs-core 2.8 module devs were only advised to put files in the application data directory and by design we didn’t maintain any separation between config, metadata, binaries, patient data regardless if it’s in a docker volume or an OS directory. In openmrs-core 2.8 we introduced [StorageService](https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/api/StorageService.java), which should be the main way to store files that do not fit in DB. It is configurable and it can store data using different means. Out of the box we will provide a local file system and S3 support for clustered environments. Modules can provide other integrations. We back-ported StorageService with local file system support as far as openmrs-core 2.5.x for ease of use in modules supporting older versions of OpenMRS. ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [July 8, 2025, 5:40pm UTC](https://talk.openmrs.org/t/docker-compose-issue-risking-data-loss-of-complex-obs/46470/4 "2025-07-08T17:40:46Z")
> [@grace](#): > > Are we already aware of this concern? Yes. My concern about Ozone’s approach is that it’s extremely sensitive to where modules actually store data. As @raff points out, the `StorageService` is probably a better long-term solution for this kind of thing, but it’s my view that everything in the OpenMRS data directory should be backed-up anyways, even if it’s duplicative of what’s otherwise in the distribution. By design, when using the OpenMRS Dockerfile, the places that OpenMRS artifacts are stored are [overridden](https://github.com/openmrs/openmrs-core/blob/a085b50b63f81249fb3b1a9722327062e53b863e/startup-init.sh#L102) by whats in the distribution configuration, modules, etc. The error here is wanting to support resetting the volumes. I think this is an issue introduced by the way Ozone is structured and not something the RefApp should worry about. In essence, the design around this is precisely that restarting the Docker container should be enough to reset the binary files and you should have no good reason to reset _volumes_ other than wanting to _destructively reset_ your implementation.