Backup and restore

What a complete backup contains

Nightly script

#!/bin/sh
set -eu
STAMP=$(date +%F)
DEST=/backup

# database, live, no downtime needed
docker compose exec -T db \
  mongodump --archive --gzip --db=employeedesk \
  > "$DEST/edc-db-$STAMP.archive.gz"

# uploads, incremental
rsync -a --delete ./uploads/ "$DEST/uploads/"

# keep 14 daily database dumps
find "$DEST" -name 'edc-db-*.archive.gz' -mtime +14 -delete

Off-host or it does not count. A backup sitting on the same disk as the database survives an application bug and nothing else. Sync /backup to object storage or another machine, and check that the sync is still running once a quarter.

Restore

1. Bring up a clean stackSame version tag as the backup was taken from. Restoring an older dump into a newer schema is a migration, not a restore.
2. Restore the databaseDecompress the dump into the database container before the application container starts writing to it.
3. Restore the uploads volumeCopy the uploads tree back into the mounted path, preserving ownership.
4. Start the application and check healthGET /api/health should return 200 with the expected version.
5. Verify against known dataOpen an employee record, an attendance month and a screenshot from before the backup date. If a screenshot is missing, the uploads restore is incomplete.

# restore the database (--drop replaces existing collections)
docker compose exec -T db \
  mongorestore --archive --gzip --drop < /backup/edc-db-2026-08-31.archive.gz

# restore uploads
rsync -a /backup/uploads/ ./uploads/

docker compose up -d
curl -fsS https://hr.yourcompany.com/api/health

Test it on a schedule

Restore into a scratch database once a quarter and open three records. It takes twenty minutes and it is the only way to know the backup works. Put it in the calendar of whoever owns the server, because it will not happen otherwise.

Related