Nine fixes from a review of the installer against its actual audience: DT leads at sister sites who are not Windows, IIS or Python specialists and who will lean on an AI assistant to get through it. TRUTHFULNESS. The preflight was advisory - an operator read 'IIS is not installed', pressed Next, answered five more pages and the install died partway through with Python already on the box. The results page now blocks while anything is failing, repaints on every run instead of latching after the first, and offers 'Check again' so a fixed problem does not mean starting over. On failure the wizard said 'Nothing was left running', which is false in every path because the stages run with -OnFailure never: it now says the server is part-configured, that re-running is safe, and how to remove it. The final page no longer reads 'ShopDB-Flask is ready' after a failed install. SECRETS. The generated MySQL root password went to Write-Host in a process the wizard runs hidden - so nobody saw it - and stdout is forwarded into the setup log operators are told to send to support, so it was permanently recorded for everyone who did not need it. It now goes to an ACL'd file. Database dumps, which contain every user password hash, landed in a ProgramData directory readable by every user on the box; the directory is now locked at creation. UPGRADES ON REMOTE-DATABASE SITES. mysqldump was looked for only under local MySQL install paths, so a site whose database is on another host silently skipped every pre-upgrade backup - after stage 2 had already stopped the pool and replaced the tree. Find-MysqlTool now prefers a client shipped in the bundle, stage 2 stages it onto the server, preflight reports when it is missing, and mysqlclient\ is an optional locked payload. UNINSTALL. A subpath install is an IIS Application, not a site; removing only the site left the application pointing at a deleted directory, so the parent site - at West Jefferson, the live classic ASP - served 503 on that path forever while Add/Remove Programs reported success. Uninstall now reads MOUNT_PATH and removes the application. The firewall rule was created as "$SiteName $SitePort" and removed as the literal 'ShopDB-Flask 8090', which matches nothing. DAY-2 TOOLING. Every shortcut now passes -AppRoot and -SitePort, and the console forwards them through its own elevation and 32-bit relaunches instead of discarding them - a non-default directory or port made it report a healthy site as broken, from a shortcut the installer wrote. 'Open ShopDB-Flask' resolved to a hardcoded localhost:8090 that was wrong for every subpath install; it now asks the console, which reads the address the installer recorded, and no longer demands administrator to open a browser. SMOKE TEST. The parent-site port lookup filtered for an http binding and defaulted to 80, so an https-only parent site failed a working install with a red dialog. DOCS AND /api/docs. The installer was invisible: nothing in docs/, README.md or CLAUDE.md mentioned it, so a DT lead or their assistant landed on the manual IIS runbook and hand-built the very server the installer then refuses to upgrade. docs/INSTALL-WINDOWS.md and docs/OPERATE-WINDOWS.md are now the canonical route, the two manual runbooks are bannered as reference-only, README and CLAUDE.md route by target, and llms.txt tells an assistant which document to follow and to ask for 'check -Json' before diagnosing. Both ship on the server, along with openapi.json and llms.txt - without those the self-hosted /api/docs was broken on every installed box, which matters most to the sites least able to debug it. Stage 5 now checks it actually serves. shopdb-admin.ps1 gains 'check -Json': one structured, secret-free block covering version, publishing method, IIS state, HTTP reachability, database, Python version, plugins and errors. That is the cheapest useful answer to 'the operator will ask an LLM' - it works with no infrastructure, which a install-time MCP server could not.
182 lines
6.1 KiB
Markdown
182 lines
6.1 KiB
Markdown
# Backup and Restore
|
|
|
|
Each site owns its own data (single-tenant, ADR-004), so backups are the site's
|
|
responsibility. A complete backup is two parts:
|
|
|
|
1. **The MySQL database** - all asset, user, audit, and settings data.
|
|
2. **The `instance/` directory** - uploaded floor plans, branding assets,
|
|
`plugins.json` (the enabled-plugin list), and any tokens or files the app
|
|
writes to disk. These are NOT in the database, so a DB-only backup loses
|
|
them. Back up `instance/` alongside every database dump.
|
|
|
|
Restoring the database without the matching `instance/` directory leaves the
|
|
app pointing at floor plans and logos that no longer exist.
|
|
|
|
## What to back up
|
|
|
|
| Item | Location | Why |
|
|
|------|----------|-----|
|
|
| Database | MySQL `shopdb_flask` | All application data. |
|
|
| `instance/branding/` | repo `instance/` dir | Uploaded logos and favicon. |
|
|
| `instance/modelimages/` | repo `instance/` dir | Uploaded vendor-model photos. |
|
|
| `instance/employeephotos/` | repo `instance/` dir | Uploaded self-hosted employee photos (external mode serves photos from the HR database instead). |
|
|
| `instance/` floor plans | repo `instance/` dir | Uploaded map blueprints. |
|
|
| `instance/plugins.json` | repo `instance/` dir | Which plugins this site enabled. |
|
|
| `.env` | repo root (offline, secured) | Secrets needed to bring the stack back up. Store separately from the data backup, in a secrets manager. |
|
|
|
|
## Backup
|
|
|
|
### Database (Docker)
|
|
|
|
```bash
|
|
docker compose exec -T db mysqldump \
|
|
-u root -p"${MYSQL_ROOT_PASSWORD}" \
|
|
--single-transaction --routines --triggers \
|
|
shopdb_flask | gzip > shopdb-$(date +%F).sql.gz
|
|
```
|
|
|
|
`--single-transaction` gives a consistent dump without locking the tables (InnoDB).
|
|
|
|
### Database (external MySQL, no container)
|
|
|
|
```bash
|
|
mysqldump -h <host> -u <user> -p \
|
|
--single-transaction --routines --triggers \
|
|
shopdb_flask | gzip > shopdb-$(date +%F).sql.gz
|
|
```
|
|
|
|
### instance directory
|
|
|
|
```bash
|
|
tar czf instance-$(date +%F).tar.gz instance/
|
|
```
|
|
|
|
Recommended cadence: nightly database dump to offsite storage, 14-day
|
|
retention; `instance/` captured on the same schedule (and always right before an
|
|
upgrade). Verify a restore quarterly.
|
|
|
|
## Restore
|
|
|
|
Restoring replaces the current database contents. Do it into a known-empty or a
|
|
throwaway target first if you are unsure.
|
|
|
|
### Step 1: Bring up the stack (or a fresh one)
|
|
|
|
```bash
|
|
cp .env.example .env # or restore your saved .env
|
|
# ensure MYSQL_* and DATABASE_URL match the dump's database name (shopdb_flask)
|
|
docker compose up -d db
|
|
```
|
|
|
|
Wait for the `db` container to report healthy (`docker compose ps`).
|
|
|
|
### Step 2: Load the database dump
|
|
|
|
```bash
|
|
gunzip -c shopdb-2026-07-10.sql.gz | \
|
|
docker compose exec -T db mysql -u root -p"${MYSQL_ROOT_PASSWORD}" shopdb_flask
|
|
```
|
|
|
|
For an external MySQL:
|
|
|
|
```bash
|
|
gunzip -c shopdb-2026-07-10.sql.gz | mysql -h <host> -u <user> -p shopdb_flask
|
|
```
|
|
|
|
If the target database does not exist yet, create it as utf8mb4 first (matching
|
|
the schema charset):
|
|
|
|
```sql
|
|
CREATE DATABASE shopdb_flask CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
|
|
```
|
|
|
|
### Step 3: Restore the instance directory
|
|
|
|
```bash
|
|
tar xzf instance-2026-07-10.tar.gz # restores ./instance/
|
|
```
|
|
|
|
The default `docker-compose.yml` does NOT bind-mount `instance/` into the api
|
|
container (its only volume is `- ./plugins:/app/plugins:ro`, and the image never
|
|
copies `instance/`), so the container's Flask instance path is an empty
|
|
`/app/instance` and a restored host `./instance` is invisible to it. To make the
|
|
restored `instance/` visible, add a bind mount to the api service before starting
|
|
it:
|
|
|
|
```yaml
|
|
api:
|
|
volumes:
|
|
- ./plugins:/app/plugins:ro
|
|
- ./instance:/app/instance
|
|
```
|
|
|
|
Make sure `./instance` is present on the host before starting `api`.
|
|
|
|
### Step 4: Bring up the API and reconcile migrations
|
|
|
|
```bash
|
|
docker compose up -d api
|
|
docker compose exec api flask db upgrade
|
|
docker compose exec api flask plugin upgrade-all
|
|
```
|
|
|
|
For a non-docker deploy:
|
|
|
|
```bash
|
|
flask db upgrade
|
|
flask plugin upgrade-all
|
|
```
|
|
|
|
`flask db upgrade` is a safety net: if the dump predates the current code, this
|
|
applies only the core Alembic chain. `flask plugin upgrade-all` then applies any
|
|
newer per-plugin migrations (each bundled plugin owns its own chain, ADR-008);
|
|
without it, plugin-owned tables stay un-migrated. If the dump is at the same
|
|
version both are no-ops.
|
|
|
|
### Step 5: Verify
|
|
|
|
- Log in with a known account.
|
|
- Confirm the floor map renders (branding and map blueprints resolve from
|
|
`instance/`).
|
|
- Spot-check a few asset records and the audit log.
|
|
- `curl -s -X POST -H "Content-Type: application/json" -d '{}' http://localhost:5001/api/auth/login | jq .`
|
|
should return a `VALIDATION_ERROR`, not a 500.
|
|
|
|
## Windows sites (installer-built)
|
|
|
|
On a server installed from the Windows installer, everything above is wrapped by
|
|
the operator console. Do not run mysqldump by hand:
|
|
|
|
```powershell
|
|
cd C:\shopdb-flask
|
|
.\shopdb-admin.ps1 backup # C:\ProgramData\ShopDB-Flask\backups
|
|
.\shopdb-admin.ps1 backup D:\backups
|
|
```
|
|
|
|
The dump is verified complete before it is reported as good; a truncated one is
|
|
deleted rather than left to be discovered when it is needed. An upgrade takes its
|
|
own backup automatically before touching the schema, and restores from it if a
|
|
migration fails.
|
|
|
|
Two Windows-specific notes:
|
|
|
|
- The backup directory is locked to Administrators and SYSTEM, because a dump
|
|
contains every row including user password hashes. Keep it that way.
|
|
- `mysqldump` must be present. It ships with the bundled-database option; a site
|
|
using a remote MySQL needs `mysqlclient\` in its installer bundle, or the
|
|
pre-upgrade backup is skipped. `shopdb-admin.ps1 check` reports this.
|
|
|
|
Restoring is the standard `mysql < dump.sql`, then
|
|
`.\shopdb-admin.ps1 restart`. Also restore `C:\shopdb-flask\instance\` if you are
|
|
rebuilding a server - it holds uploaded branding and map blueprints, which the
|
|
database does not.
|
|
|
|
See [OPERATE-WINDOWS.md](OPERATE-WINDOWS.md).
|
|
|
|
## See also
|
|
|
|
- [DEPLOY.md](DEPLOY.md) - first-time deploy
|
|
- [INSTALL-WINDOWS.md](INSTALL-WINDOWS.md) - Windows Server install
|
|
- [UPGRADE.md](UPGRADE.md) - upgrade procedure (back up first)
|
|
- [CONFIG.md](CONFIG.md) - environment variables and Setting keys
|