docs/wiki/4.23-Managing-Your-Data.md
Your data in Super Productivity is everything the app stores to represent your work: tasks (active and archived), projects, tags, time tracking, metrics, notes, reminders, configuration, and more. The app is local-first: data lives on your device (or in your browser), and you control how it is backed up, exported, imported, and synced. Understanding what “your data” includes, how import and export work, how backups are created, and how sync and conflicts are handled helps you keep your data safe and move it between devices or recover from problems.
For where data is stored, where backups go by platform, and technical details of backup/import/export/sync, see [[3.06-User-Data]]. For how to restore from a backup file, see [[2.02-Restore-Data-From-Backup]].
A full backup or export is a restorable snapshot of the application model. It includes:
This is the state needed to restore the workspace, not a byte-for-byte copy of every local database. Device-local support data is deliberately outside it, including the sync conflict journal, operation-log transport metadata, the internal import-recovery slot, and sync-provider private configuration stored separately (credentials and encryption key material). Issue-provider settings inside the snapshot can still contain API credentials or tokens.
Normal backup and export files are plaintext JSON, even when sync encryption is enabled. Protect them like the private work data and credentials they may contain. The anonymized/privacy export masks known field names, but it is not a credential-safety boundary: inspect it before sharing and remove any remaining provider or plugin credentials, tokens, and private content.
Import replaces your current app data with the data from a backup or export file. The app supports full backup format: a single JSON structure that contains (or wraps) the complete application-model state. Pre-v14 backups from the v10–v13 data shape are detected and migrated before validation. The much older V1 config + tasks format is detected but no longer supported, so it shows a migration-not-supported message.
Validation and repair: Before applying an import, the app validates the data (structure and relationships, e.g. tasks referencing existing projects and tags). If validation fails, it may still repair the data automatically when possible—for example fixing orphaned tasks, missing project or tag references, or inconsistent lists—so you end up with a consistent state instead of a failed import. If repair is not possible, the import is aborted and you get an error.
Encryption: If the snapshot records a different sync-encryption state from the current app, the app may warn you before importing because the imported state can change how subsequent sync is configured. This does not mean the backup file is encrypted; normal backup and export JSON remains plaintext.
Effect of import: Import replaces current state. The app persists the imported data (including writing archive data to storage) and treats it as the new source of truth. Your previous state is no longer active; restore it only by importing an older backup if you have one.
Export produces a snapshot of your data at the time you export. It is not a “live” view: the application model at that moment (including archives if you choose to include them) is serialized into one plaintext JSON file. You can use that file as a backup, move it to another device, or archive it, but you should store and transfer it securely. Relationships (e.g. task → project, task → tags, subtask → parent) are preserved by ID references in the JSON; the validation and repair logic used on import ensures those references stay consistent when the file is later imported.
So export = “save the restorable application model as it is right now”; import = “load that model from this file and replace current data.”
Automatic backups — When enabled in settings, the app creates a backup on a schedule (e.g. every 5 minutes). Where it is stored depends on the platform: on desktop (Electron), backups are timestamped JSON files in the User Data Folder (e.g. a backups/ directory) with automatic cleanup of older files; the desktop Maximum backup files setting controls how many automatic backup files are kept. On Android and iOS, backups are stored in platform-private storage. On the web, there is no automatic file-based backup; you use “Export data” to download a file. See [[3.06-User-Data]] for exact locations and behavior per platform.
Manual backups — You can trigger a backup by: (1) using “Create manual backup” in settings, (2) relying on safety backups the app creates before certain sync operations (the app keeps a limited number of recent and daily slots), or (3) using “Export data” to download a backup file. Exported files can be imported later via Settings → Import/Export (see [[2.02-Restore-Data-From-Backup]]).
What is included: Backups and exports include the restorable application model; when archives are requested, both recent and old archive tiers are included. Device-local operation metadata, conflict-review history, internal recovery state, and separately stored sync credentials/key material are not copied. The files can nevertheless contain private work content and issue-provider credentials, and they are plaintext JSON. The anonymized/privacy export is best-effort, so inspect it and remove any remaining credentials, tokens, or private content before diagnostic sharing.
The app is local-first and records changes as operations, then adapts that log to different transports. SuperSync sends operations through an ordered server API. File providers use the default v2 monolithic format, which rebuilds and uploads the current snapshot, both archive tiers, and retained operations on an operation-bearing upload. The opt-in v3 split format stores those parts separately, so ordinary operation uploads do not rewrite snapshots between compactions. See the maintainer field guide's transport comparison.
Conflicts — When the same data is changed in two places (e.g. on two devices) before they sync, the app compares vector clocks to detect concurrency. Resolution first applies explicit archive/delete precedence and safe disjoint-field merging. Remaining overlaps use last-write-wins: the newer operation timestamp wins; an exact tie uses stable client-ID ordering. When the local or merged result must dominate both histories, the app emits the appropriate update, archive-win, or delete-win operation so the result propagates. In some cases (e.g. first sync when both local and remote already have data), the app may ask you to choose use local or use remote. After resolution, the app validates and can repair state so references stay consistent.
Disjoint-field auto-merge — For entity types whose sync contract explicitly supports reconstruction, edits to different real fields can be combined instead of discarding one side. This only happens when it is unambiguously safe and neither operation is a deletion or structural change; unsupported or overlapping changes fall back to last-write-wins.
Reviewing what was auto-resolved — A device-local conflict journal store and Sync Conflicts page (/sync-conflicts, also linked from Settings → Sync) exist, but normal production remote-conflict processing currently has journal emission disabled. The page is therefore dormant/incomplete: not every automatic resolution is recorded or available for review. For entries that do exist, you can see which side won, which fields differed and both values, and then either Keep (confirm the automatic resolution) or Flip (re-apply the discarded change as a new edit that syncs to all devices — nothing is rewound). Flip is disabled where re-applying isn't safely possible (e.g. overridden deletions or structural moves). Existing journal data is informational only: it lives on the device, is never uploaded by sync, is not part of backups/exports, is cleared whenever you import a backup or switch user profiles, and old entries are pruned automatically (after 14 days or beyond the newest 200).
So in practice: explicit archive/delete rules first, both changes when safe fields do not overlap, then deterministic newer-wins for the remaining overlap. You only choose when the app prompts you (e.g. first sync). The Sync Conflicts page may contain earlier review entries, but current production journal emission is disabled, so it is not a complete resolution history.