Backups

lk-wiz can export its entire dataset — the main DynamoDB table plus every workspace asset in S3 — into a single downloadable ZIP file, and can restore from one later. It lives as a Backups tab inside the existing /admin page, reuses that page's admin-only access gate, and supports restoring a backup either into the same environment it came from or across environments (e.g. importing a dev snapshot into prod).

⚠️

This is a completely different mechanism from AWS Backup, which lk-wiz also runs (automated, twice-daily, infrastructure-level DynamoDB + S3 snapshots with 30-day retention — see the Architecture overview). This page is about the application-level, admin-triggered ZIP export/import feature only. The two don't know about each other.

This page describes product-facing behavior. For exact request/response shapes and error codes, see the Backups API reference. Backups shares its HTTP handler with the rest of the admin domain — see the Admin feature guide for the surrounding page and its RBAC rules, which apply unchanged here.

Who can use it

Same gate as the rest of /admin: the caller's role must be admin, checked fresh on every backend call. There are no partial permissions — an admin can create, list, download, and restore; nobody else can do any of the four.

What's inside a backup

Every backup ZIP contains:

manifest.json — metadata: when it was made, which environment made it, how many items/assets it contains, and what triggered it (manual vs. scheduled).
A full export of the main DynamoDB table — every workspace, post, idea, comment, user profile, everything, as one JSON array.
Every asset in S3 (photos, uploaded documents, etc.) — except previous backups themselves, so backups never nest inside each other.

Not included: the WebSocket connections table (ephemeral, meaningless to restore) and Cognito itself — user login accounts (passwords, enabled/ disabled state) live entirely outside this system. Restoring a backup never touches Cognito directly; instead, on a cross-environment restore, it matches DynamoDB user profile rows to the target environment's existing Cognito-backed accounts by email. See Restoring a backup below.

Creating a backup

Two ways to get a fresh backup, both producing an identical ZIP format:

Manually — the Create Backup button in the Backups tab, on demand.
Automatically — once a day at 04:00 (Europe/Zurich time, so it stays at 04:00 local time year-round through the DST switch), via a scheduled job that runs independently of the admin page.

Backups accumulate in storage over time with no automatic cleanup or expiry — every manual, scheduled, or imported backup stays around forever unless someone deletes it out-of-band. This is unlike AWS Backup's own 30-day retention policy mentioned above.

Restoring a backup

Pick a backup from the list, confirm the "Overwrite all data?" prompt, and the restore kicks off. This is a full, destructive replace — every row in the database is deleted and replaced with what's in the backup. There is no merge mode.

⚠️

Restoring is fire-and-forget. Confirming the prompt only starts a background process — the UI has no way to tell you afterward whether the restore actually succeeded or failed. If something goes wrong partway through (a corrupt file, a transient AWS error), the only trace of it is in backend logs, not anywhere in the product.

Same environment vs. cross-environment

lk-wiz can tell whether a backup came from the same environment it's being restored into, or a different one (e.g. restoring a dev backup into prod):

Same environment: every row in the backup is written back exactly as it was, including user accounts.
Cross-environment: the target environment's own user accounts are protected. Before wiping the table, every current user's profile is snapshotted; after the backup's content is restored, those profiles are written back — and any reference to a user from the backup's environment (workspace ownership, post authorship, comments, etc.) is automatically remapped to the matching target-environment user, matched by email address. Users with no email match in the target environment simply aren't remapped — their old references are left as-is.

This is what makes it safe to pull a dev backup into prod for testing, or vice versa, without prod admins losing their accounts or dev content ending up owned by the wrong person.

Importing a backup from a file

The Import from File section handles backups that didn't come from lk-wiz's own list — e.g. one downloaded earlier, or from another environment. Pick a local ZIP file, tick the mandatory "I understand this will overwrite all current data" checkbox, and click Upload & Restore. Under the hood this is three steps (request an upload location, upload the file straight to storage, then trigger the same restore as above) but the UI collapses it into one action.

S3 layout

All backup files live in the same storage bucket as regular workspace assets, distinguished by a _backups/ prefix — there's no separate backups bucket. Manually/scheduled-created backups and imported ones use slightly different key patterns; see the API reference for the exact naming and a sorting quirk it causes in the backup list.