Backup & restore

Backup and restore are server-side only, deliberately. Backing up exports every engagement’s data, and restoring can completely overwrite it, so this is a terminal-only operation for whoever already has that level of server access, not a button reachable over the web. Everything on this page runs on the server, not from any screen in the app itself.

Creating backups

This is one-time setup. Backups get written into a directory on the server, which needs a real host directory behind it to survive a container recreation:

mkdir -p backups

Note

The web container runs as a non-root user, so the directory Docker just bind-mounted needs to be writable by that user. If a backup run fails with a permission error, check which user ID the container actually runs as (docker compose exec web id -u) and make sure the host directory is owned by that same ID.

Set a backup encryption passphrase in your environment file. It’s required for unattended runs, since there’s no one at a terminal to prompt for it. Then run this daily via the host’s own cron:

0 2 * * * cd /path/to/redscribe && docker compose exec -T web python manage.py create_backup

Each run writes one timestamped, encrypted file into the backup directory and prunes anything older than the configured retention window (30 days by default, a month of daily backups). A one-off passphrase override is available for a single run if you ever need that, but the environment variable is the safer default.

Keeping backups on the same disk isn't enough on its own

Living on the same disk as the database it’s backing up is better than nothing, but it doesn’t protect against a whole-host failure. Sync it off-box yourself, with whatever tool you already use for that. RedScribe doesn’t build or assume any specific remote target.

Permanently deleted data can still exist in a backup

Permanently deleting an engagement removes it from the live database only. A routine backup taken before the deletion, or the safety snapshot a restore takes automatically (below), is a whole-database dump. It still contains that engagement’s data exactly as it was at backup time, and there’s no way to scrub a single engagement back out of an already-written backup file.

Caution

Routine backups age out on their own after the retention window (30 days by default). Pre-restore safety snapshots (below) aren’t auto-pruned at all. If a retention or disposal obligation means deleted data needs to be gone from every copy, not just the live database, that means finding and removing any backup taken before the deletion too, rather than assuming the permanent-delete action alone covers it.

Restoring a backup

docker compose exec web python manage.py restore_backup /app/backups/redscribe-backup-<timestamp>.rsbk

This prompts for the passphrase interactively by default; a one-off override is available for scripted disaster-recovery drills.

The account-state safety report

Before touching the live database, restoring loads the backup into a throwaway scratch database and compares its accounts against the ones live right now, then prints exactly what would change. This answers a specific problem: a whole-database restore silently undoes any account change made after the backup was taken, including someone deactivated since (say they left the team) quietly regaining access, in a way that’s easy to miss if you’re not specifically looking for it.

You’ll see one of four things per affected account:

Outcome	Meaning
Reactivated	Inactive right now, active in the backup. This is the one that matters most: if this account was deliberately deactivated since the backup, restoring undoes that.
Newly deactivated	The reverse: reactivated since the backup.
Disappearing	Created after the backup, so restoring removes it.
Reappearing	Deleted since the backup, so restoring brings it back.

Restoring can undo an erased account

The report doesn’t flag erased accounts. A backup taken before an account was erased still holds that person’s name, email, and other personal data, and restoring it brings them back. After any restore, check which accounts were erased since the backup was taken and erase them again.

Nothing here is automatic. You still have to look at the list and decide, but it can no longer slip past unnoticed. Type restore at the prompt to proceed, anything else to abort with zero changes made. A flag is available to skip that prompt for scripted disaster recovery (the report is still computed and printed either way), so make sure you know what you’re restoring before you automate past this step.

The pre-restore safety snapshot

Immediately before the restore itself actually touches the live database (which drops every table first, then restores, so it isn’t something a partial failure can undo on its own), restoring also takes its own encrypted snapshot of whatever’s live right now and writes it into the backup directory, using the same passphrase.

Caution

If the restore then fails partway through, the database may be left inconsistent. Restore that safety file (same command, same passphrase) to get back to exactly how things were the moment before you ran this. Unlike the routine daily backups above, these aren’t auto-pruned, so clean them up yourself once you’ve confirmed the restore actually worked.

Because this loads the backup up to three times over, once for the scratch-database comparison, once for the pre-restore safety snapshot, and once for the real restore, expect the whole process to take noticeably longer than a single raw database restore would.

Upgrading, and rolling back a bad deploy or migration

RedScribe applies any pending database schema changes automatically on every container start, with no dry-run step and no automatic snapshot before it touches the schema. Taking a manual snapshot before every upgrade is the way back if something goes wrong; see Upgrading & rolling back for the exact step-by-step sequence (snapshot, pull or build, verify, then roll back code and/or restore the snapshot if needed).