Backups and updates
Backups, every night
A scheduled task dumps the whole database into the backups/ folder inside the system's folder, keeps thirty days of dumps, and copies the newest to the backup copy location: a USB drive that stays plugged in, or a folder on another machine.
docker compose run --rm otcms-backup
It is scheduled at install: on Linux with cron at 22:15, on Windows with Task Scheduler. The line the scheduler runs, so it can be checked:
15 22 * * * cd /home/shop/otcms && docker compose run --rm otcms-backup >> backups/backup.log 2>&1
backups/backup.log says when the last one ran; glance at it on the first of the month.Restoring
On a fresh install with an empty database, from the system's folder:
docker compose up -d otcms-postgres
docker compose run --rm --entrypoint sh otcms-backup -c 'pg_restore --clean --if-exists --dbname="$PGDATABASE" /backups/otcms-<date>.dump'
docker compose up -d
Everything comes back as it was at the time of the dump: users, catalogue, batches, sales, the audit trail. Sales made after the dump are gone, which is why the dump runs nightly and why a sale outside the system was never a good idea.
Updates
The version the shop runs is pinned in .env by its digest, so nothing changes until someone changes it. An update is:
Back up first
A migration that has applied to the database cannot be rolled back by starting the old version under it. Run the backup before every update.
Change the version
Set API_IMAGE in .env to the new digest and replace the web bundle in www/ with the one that matches it. Affram sends both with the release note.
Pull and restart
docker compose pull otcms-api
docker compose up -d
The database migrates itself forward on start. The till is back in about a minute.
What is in a release
Every release is built and scanned in our pipeline and has run on our test box before it is offered to a shop. The release note says what changed in the words of the shop, and whether the update needs anything from the owner (a new setting, say) before it is applied.