Disaster Recovery

Purpose

Defines the procedure for recovering the IQV Flex ERP services (MongoDB, backend, frontend) after data loss, container loss, or a server failure.

Components That Must Be Protected

Based on the actual project structure (docker-compose.yml, docker-compose.prod.yml):

Component	Why it's critical
MongoDB (mongo_data, mongo_config volumes)	The single persistent store for ERP data
.env	Secrets (ERP_AUTH_SECRET, GO_API_CLIENT_SECRET, MONGO_INITDB_ROOT_PASSWORD, etc.) and environment configuration
docker-compose.yml / docker-compose.prod.yml	Service definitions, network, healthchecks, resource limits
Application images (backend, frontend)	Built from iqvflex/backend/Dockerfile and dashboard/Dockerfile; tagged with the VERSION file
VERSION	Canonical version used for image tagging
Source code (repository)	The git repository itself — images are rebuilt from it

The only reverse proxy/config in this repository is nginx (inside the frontend image, dashboard/nginx.conf); a separate reverse proxy service is not defined in the repository.

Backup

The following should be backed up regularly:

• MongoDB data: the mongo_data and mongo_config named volumes (see docker-compose.yml → volumes:). docker compose down does not delete these volumes; only down -v does, and the update script never runs it.
• The .env file: secrets and environment configuration exist only here; if lost it cannot be reconstructed (randomly generated secrets are created once, at install time).
• docker-compose.yml / docker-compose.prod.yml: already protected by git history as part of the repository.
• VERSION: part of the repository, protected by git.

Standard Docker/OS-level backup tooling can be used to back up volume contents on disk (the project does not ship its own custom backup tool).

Restore

1. Prepare a new host (OS, disk space, network access).
2. Verify Docker / Docker Compose is installed and running.
3. Check out the repository (or the relevant release) via git clone / git checkout.
4. Restore .env from backup (if unavailable, regenerate it from the .env.example template and re-set the secrets).
5. Restore MongoDB data (mongo_data / mongo_config volumes) from backup.
6. Start the containers: ./install.sh / .\install.ps1 (recommended), or directly docker compose up -d.
7. Run a health check: docker compose ps (STATUS/HEALTH columns) and curl http://localhost:8080/health.
8. Verify the application from a browser at http://localhost:8080; test ERP login and core functionality.

Beyond these steps, there is no special recovery command or automated backup system defined in the project's code — the procedure above relies on the existing install.sh / install.ps1 / docker compose infrastructure.

Disaster Scenarios

Scenario	Impact	Recovery Approach
Container loss	Service stops	Recreate from the image (docker compose up -d)
Host loss	All services affected	New host + config + volume restore (procedure above)
MongoDB data loss	ERP data affected	Restore mongo_data/mongo_config from the last valid backup
Bad release	Application error	Roll back to the previous stable image/release (see Update / Rollback)
Env/config loss	Service won't start	Restore .env from a secure config backup

RTO / RPO values are not defined in the project's code, so no fixed number is given here:

• RTO: should be determined by the organization's operations policy.
• RPO: should be determined by the backup interval.