Backup & Restore¶

A complete HEMMS backup has two parts: the Postgres database (records, configuration, audit trail) and the Odoo filestore (attachments — scanned ปจป. PDFs, signed service contracts, equipment photos). If you only back up one of the two, you cannot fully restore.

This page covers what make backup-private actually does, how to add the filestore to that backup, how to restore, and the cadence Trinity Roots recommends for production deployments.

What gets backed up¶

Database backup — make backup-private¶

The headline command:

make backup-private    # or make backup-gov

This invokes scripts/backup_db.sh which runs pg_dump inside the Postgres container and pipes the output through gzip:

docker exec hemms_db_private pg_dump -U odoo_private hemms_private \
    | gzip > ./backups/private_<timestamp>.sql.gz

Output landing point:

./backups/private_YYYYMMDD_HHMMSS.sql.gz
./backups/gov_YYYYMMDD_HHMMSS.sql.gz

The script creates ./backups/ if it doesn't exist. Files are timestamped to the second, so two backups taken in the same minute won't collide.

Adding the filestore to the backup¶

For production, wrap make backup-private with a filestore copy:

#!/usr/bin/env bash
set -euo pipefail
TS=$(date +%Y%m%d_%H%M%S)
SANDBOX=private
DB=hemms_private
CONTAINER_ODOO=hemms_odoo_private

# 1. DB dump (via the Makefile target)
make backup-${SANDBOX}

# 2. Filestore tarball — read from inside the Odoo container
docker exec ${CONTAINER_ODOO} tar -czf - \
    -C /var/lib/odoo/.local/share/Odoo/filestore ${DB} \
    > ./backups/${SANDBOX}_filestore_${TS}.tar.gz

echo "==> Filestore backup complete: ./backups/${SANDBOX}_filestore_${TS}.tar.gz"

Now each backup is two files with matching timestamps:

./backups/private_20260523_020005.sql.gz
./backups/private_filestore_20260523_020005.tar.gz

Keep them together — they must be restored as a pair.

Restore procedure¶

A clean restore drops the existing database, recreates it, replays the dump, and unpacks the filestore.

Step 1 — Stop Odoo, keep Postgres up¶

docker stop hemms_odoo_private
# leave hemms_db_private running

Step 2 — Drop and recreate the database¶

docker exec -it hemms_db_private psql -U odoo_private -d postgres \
    -c "DROP DATABASE IF EXISTS hemms_private;"
docker exec -it hemms_db_private psql -U odoo_private -d postgres \
    -c "CREATE DATABASE hemms_private OWNER odoo_private;"

Step 3 — Replay the SQL dump¶

gunzip -c ./backups/private_20260523_020005.sql.gz \
    | docker exec -i hemms_db_private psql -U odoo_private -d hemms_private

This restores every row but not the filestore.

Step 4 — Restore the filestore¶

# Wipe the existing filestore for this DB first
docker exec hemms_odoo_private rm -rf \
    /var/lib/odoo/.local/share/Odoo/filestore/hemms_private

# Unpack the tarball into the same parent directory
docker exec -i hemms_odoo_private tar -xzf - \
    -C /var/lib/odoo/.local/share/Odoo/filestore \
    < ./backups/private_filestore_20260523_020005.tar.gz

Step 5 — Start Odoo, verify¶

docker start hemms_odoo_private
make logs-private    # watch for "Modules loaded."

Open the UI, log in, and spot-check:

1. Maintenance → Equipment — record counts match the source DB.
2. Open a signed service contract and click the attachment — it should download (proves the filestore is intact).
3. HA Report → Annual Reports — open last year's report and verify the PDF renders.

If attachments 404, the filestore restore missed a step — repeat step 4.

Recommended cadence¶

Backups should be copied off the Docker host to object storage (S3, GCS, or an NFS share on a different machine). A backup on the same disk as the live DB does not survive disk failure.

Disaster recovery drill¶

Schedule annually. The drill answers two questions: Does the restore procedure actually work? and How long does it take?

1. Pick a non-prod host (a laptop or a cheap VM).
2. Clone the repo, make up-private, but do not make install-private. You want an empty DB to restore into.
3. Copy the most recent off-site backup pair to ./backups/.
4. Run the restore procedure above end-to-end. Time it.
5. Verify the spot-checks in Step 5.
6. Record:
   • RTO (recovery time objective) — how long the restore took
   • RPO (recovery point objective) — gap between last backup and the drill time
   • Any steps that failed or surprised you — feed back into this doc

Keep the drill report with your HA Thailand documentation. HA reviewers look for evidence that disaster recovery is rehearsed, not just documented.

Common pitfalls¶

Related pages¶

• Installation — initial deployment
• Upgrade Guide — always backup before upgrading
• Multi-company / Multi-hospital Setup — per-hospital backup boundaries