Step 1
Know what local browser persistence protects—and what it does not
A workspace stored in browser storage can survive a tab close or browser restart on the same profile. It may disappear when site data is cleared, a private window closes, a managed-device policy runs, a profile is reset, storage is evicted, or the user moves to another device. Synchronization should never be assumed unless the product explicitly provides and documents it.
Anyone who can use the same unlocked browser profile may be able to open the workspace. Local storage avoids routine server upload, but it is not a permission system, an archive, or encrypted file storage. Shared classroom and production computers need an explicit retention and cleanup rule.
Step 2
Export before the moments that are expensive to reconstruct
Create a workspace JSON backup after a complex setup is reviewed, before importing someone else's file, before a browser or device migration, and before a live event where last-minute edits are likely. Also export after a meaningful approved change so the recoverable copy matches the next operational run.
Use a filename with the project, purpose, date, and a non-sensitive version marker, such as workshop-rotation-2026-08-22-v3.json. Do not put student names, prize identities, confidential clients, or secret event details into a filename that may be indexed by desktop search or displayed in a recent-files menu.
Check before continuing
- The workspace has been reviewed before export.
- The filename identifies purpose and version without private details.
- The destination is approved for the data in the labels and history.
- At least one restore test has been completed for critical setups.
Step 3
Treat a full workspace file as more sensitive than a share link
A full export may include multiple wheel names, entries, weights, modes, colors, settings, history, scores, and other recoverable workspace state. That breadth is the reason it works as a backup and the reason it should not be posted as a generic download or attached to a public support ticket.
Open JSON is useful for inspection and migration, but it is not encrypted merely because the application produced it. Protect the file with operating-system access controls or an approved encrypted storage and transfer system when the contents require it. Avoid editing production backups by hand unless the schema and validation rules are understood.
Step 4
Validate an import before it replaces current browser state
An importer should parse JSON, recognize a supported schema version, validate required fields, enforce wheel and entry limits, reject invalid numbers or modes, and build a complete candidate workspace before committing it. A failure should leave the current workspace unchanged and explain what the user can correct.
Do not trust a file because its extension is .json or because it came from a colleague. Review its origin and, where practical, inspect the summarized wheel count and names before replacement. Export the current workspace first so a successful but unwanted import can be reversed without reconstructing local changes.
Run it in this order
- Export and label the current workspace.
- Select the intended backup and confirm its source.
- Review validation results and the proposed workspace summary.
- Import, then verify every wheel before deleting the rollback copy.
Step 5
Verify a restore and handle schema migration explicitly
After import, compare wheel count, names, active entries, duplicate rows, weights, modes, history, scores, and the active-wheel selection with the expected setup. Run a rehearsal with non-official consequences; do not discover a missing exclusion or reset elimination state during the live draw.
A versioned importer may migrate older fields into the current schema. Migration should be deterministic, tested with fixtures, and surfaced to the user when it changes meaning or drops unsupported state. Keep the original old-format file until the migrated workspace has been verified and re-exported in the current version.
Step 6
Set a retention, handoff, and deletion routine
Keep the smallest number of backups that satisfies the operational need. Separate reusable templates from event records: a generic classroom activity may remain useful, while a roster and its selection history may need deletion after the term or event. Record which version is authoritative so operators do not restore a stale list by mistake.
When handing off, transfer through an approved channel and verify the recipient can restore the file before removing your copy. Empty the relevant recycle or cloud retention area only under the organization's policy; deletion from one folder may not remove synchronized versions or managed backups. Finally, clear the local browser workspace on shared hardware when it should not remain available there.
Use the right surface
Tools mentioned in this guide
Common questions
Questions about workspace backup and restore
Is browser local storage already a backup?
No. It is convenient persistence tied to a browser profile and can be cleared, evicted, reset, or left behind on another device. Export a workspace file for recoverable state.
What can a workspace JSON backup contain?
It can contain multiple wheels and recoverable state such as entries, weights, modes, settings, history, and scores. Treat the file according to the most sensitive label or result inside it.
Will a failed import erase my current workspace?
It should not. A safe importer validates a complete candidate before replacement. Export the current workspace first in case a valid but unintended import succeeds.
Can an old workspace file be restored after an update?
A versioned importer may migrate supported older schemas. Keep the original, review any migration notice, verify every wheel, and re-export only after the restored meaning is confirmed.
How long should I keep wheel backups?
Keep them only as long as the operational, educational, or recordkeeping purpose requires. Separate generic templates from personal rosters and delete superseded sensitive copies under the applicable policy.