Private Task Backups and Recovery: What Matters in 2026

A second device is useful when your phone breaks. It is less useful when the same deletion reaches both devices. Before trusting a private task app with work you cannot afford to lose, separate four questions: where is another copy, which earlier state can you recover, who can decrypt it, and what happens when the credential disappears?

Direct answer: sync, backup, export, and recovery are different

Sync keeps devices aligned; a backup preserves a separately recoverable state. Export produces a file, which may be readable plaintext rather than an encrypted backup. Recovery is the demonstrated ability to reconstruct useful data with the copies and credentials you still possess. Choose a task app by that complete path, not just whether it syncs or advertises encryption. A second live replica alone does not prove you can undo a mistake.

Methodology and facts checked: November 4, 2026

This guide reviews current official backup and recovery documentation for Standard Notes and Tasks.org, plus Zero-Friction's public API documentation and current client/server implementation. Standard Notes is a notes/checklist example with an explicit backup workflow, not a claim that it replaces a full task planner. Every failure-mode row above is an evaluation scenario, not a report of a failure we induced.

We checked copy independence, credential dependency, export confidentiality, restore coverage, and remaining device access. We did not run a live recovery, simulate data loss, audit cryptography, or verify an operating-system backup on your behalf. The exercise below is a checklist for you to perform with non-sensitive sample data. No paid-plan price comparison or guaranteed retention period is asserted.

Decide what you actually need to recover

A useful recovery target is more specific than “my tasks.” Write down the fields that would make the list usable again: titles, descriptions, completion state, list membership, dates, recurrence, reminders, and attachments where applicable. An export with correct task titles can still lose the reminder that made the task actionable.

Then choose a tolerable gap. If you would be comfortable re-entering the changes since yesterday, a recoverable earlier snapshot may be adequate. If losing the latest unsynced client edits is unacceptable, investigate how the actual client protects them. Neither a successful cloud login nor a green sync indicator answers that question by itself.

Keep a recovery copy outside the same failure boundary. A file inside the app's removable private directory is vulnerable to an uninstall. A backup on the same failed disk may be inaccessible. A cloud folder that immediately synchronizes deletions is not automatically independent history. Check version retention and access rather than counting locations that all change together.

Encryption protects a boundary, not every copy

Encryption in transit protects a connection between endpoints. The receiving service can still process readable content. Encryption at rest protects stored data under a particular key/access model; a running service with those keys can still read it. Task-content end-to-end encryption keeps the covered content encrypted between participating clients without providing the sync operator the content-decryption capability.

Those definitions do not establish what happens to every field. Task IDs, timestamps, ordering, account information, notification details, and connection records may sit outside an encrypted content payload. Ask separately what the provider stores and what a backup includes. Do not infer encrypted local storage from encrypted cloud sync.

An encrypted backup is useful only if you retain the means to decrypt it. A readable export avoids that particular dependency but creates another exposure. Saving both together in an unrestricted shared folder defeats much of the intended separation. Conversely, keeping the only key on the device whose loss you are preparing for makes recovery fragile.

For the data-flow boundary rather than disaster recovery, see what private task sync sends off your device.

Lost device and lost credential require different decisions

If the device is gone but the credential and a good remote copy survive, reconnecting a replacement may restore the currently synchronized state. That still does not establish historical rollback, recovery of unsynced edits, or preservation of every field. Use the app's actual device-join procedure, and check the result before retiring another working device.

If the credential is gone but a trusted device still opens the data, preserve that access first. Signing out, reinstalling, clearing storage, or changing accounts can remove the remaining readable copy. Consult the product's current instructions before trying a reset. If export is available, protect the resulting file; do not assume it is encrypted.

If every accessible device and the necessary decryption material are gone, the answer depends on the architecture. Some providers document recovery options; others cannot restore the encrypted content. Do not apply one vendor's recovery promise to another app, and do not interpret a provider's ability to resend an access credential as proof of either zero knowledge or guaranteed recovery.

Standard Notes: encrypted backup files still need a password

The official Standard Notes backup guide offers encrypted and decrypted downloads under Preferences, then Backups. The encrypted download requires the account password for decryption during restore. The decrypted download is a ZIP containing a restore file and individual plaintext notes. A ZIP container alone is not evidence of encryption.

Its desktop app creates automatic backups each day while running. Check their location: an automatic file on the same local drive is not by itself protection against losing that drive. The guide documents Import Backup for recovery and an offline decryption tool if the app is unavailable. Retain the relevant password and instructions with an appropriate separation from the protected file.

The official forgotten-password instructions say a password reset cannot recover the encrypted notes. They distinguish losing access everywhere from still being signed in: an accessible session can allow export and movement into a new account. For mobile, the guide describes biometric verification before exporting a decrypted backup. Follow that documented route rather than assuming every signed-in session can bypass every password prompt.

The same instructions handle Files separately: download them and reupload them when moving accounts. Do not count a text backup as proof that file attachments are independently recoverable.

Tasks.org: check backup location and missing attachments

The current Tasks.org backup documentation says automatic backups run at midnight and retain the latest seven automatic files. Manual backups use Export tasks and are not subject to that automatic pruning. These are documented behaviors, not a guarantee that your device has already produced the files you need.

The important warning is location: backups initially live in the app's private directory, which Android deletes when the app is uninstalled. Choose a location outside that directory before relying on an uninstall/reinstall recovery. Inspect the actual resulting file and keep a protected independent copy.

The guide also states that file attachments are not backed up. It describes optional copying to Google Drive and automatic import when reinstalling through Android Backup Service, if that service is enabled. It does not establish, on that page, app-level E2EE for exported backup files. Do not label the backup encrypted solely because you chose an encrypted sync backend elsewhere.

Zero-Friction recovery: protect the code, do not invent a restore feature

Zero-Friction's public API documentation identifies the sync code as the access credential and says it is available in the app's cloud/sync settings. In the reviewed client, the saved code is also the link to the existing synchronized collection. Generating a different code is not a way to reopen that collection.

If you lose one device, first check another trusted device that still has the code and readable tasks. Preserve the code securely before changing that device. Rejoining with the existing code depends on the synchronized data still being available; it is not restoration of an independent historical snapshot.

The reviewed desktop client no longer automatically retrieves a missing sync code from device history. Clearing local storage or resetting without preserving the old code can therefore cut off the normal route to the previous collection. An Email Code feature can send a code you already have; its endpoint requires that code. It is not an email-only forgotten-code recovery flow. We have not established a guaranteed support-assisted lost-code recovery procedure.

Encrypted sync does not establish provider-unrecoverability

The reviewed client encrypts task text before normal sync, but the sync code reaches the backend. The API can derive the key and decrypt content server-side for authenticated responses. Pin state, identifiers, ordering, and timestamps are separate metadata; legacy and encryption-failure paths can retain plaintext. The current data-protection page discloses those limits.

Consequently, we do not claim the provider can never process readable content, or that losing your code proves all server data is cryptographically unrecoverable. A missing user recovery route and a provider-blind architecture are different claims.

We also did not establish a supported built-in backup/restore UI or full-fidelity importer in the reviewed client. An API read is programmatic access, not a complete backup product: it can return readable task content, and list endpoints are paginated. Any custom extraction needs protected output and explicit verification of lists, reminders, deleted-state handling, and all pages. This guide does not present such a script as a tested recovery solution.

A small backup-and-restore verification checklist

Run this exercise only in an isolated test profile, account, or disposable environment that the product supports. Do not restore a trial file over your only production list. If there is no documented safe restore destination, stop and establish one before continuing.

1. Create harmless sample data. Include a title, a description, a completed item, a reminder or recurrence if supported, and an attachment if you rely on one. Note what you expect to recover.
2. Record the prerequisites separately. Identify the required app/version, account, password, sync code, recovery material, and any additional file location. Never paste real credentials into a test log.
3. Create the documented backup or export. Note its creation time, format, encryption choice, and scope. Check that it exists outside any directory you plan to delete.
4. Preserve an independent copy. Use access-controlled storage with suitable encryption and retention. Confirm that deleting the test app will not also delete the only backup.
5. Restore into the safe destination. Follow official instructions. Merely opening a file or seeing an import-success message is not the end of the test.
6. Compare the result field by field. Check task counts, titles, list relationships, completion state, dates, reminders, recurrence, and attachments. Note omissions and duplicates rather than silently accepting them.
7. Write down what worked and clean up carefully. Record the tested versions and missing fields without task secrets. Remove unnecessary trial copies, but do not promise secure erasure from every device, cloud version, or backup.

If the product supports only sync and manual re-entry, say that in your recovery notes. A copied list can be an emergency reference without being a restorable full-fidelity backup. For that distinction, read task-app data portability. If you are also changing tools, the Todoist migration guide separates source exports from destination import support; this recovery checklist should come before closing the old account.

Handle old devices and exposed exports deliberately

An old offline device may hold useful task text, but reconnecting it may alter either copy depending on sync/conflict rules. If it might be the only good state, keep it offline while checking the official recovery options and preserving a readable copy through supported means. Do not assume a conflict algorithm will choose the version you prefer.

A lost device creates an access problem as well as a recovery problem. Use the relevant device/account controls to restrict access where available, and review connected integrations. Do not assume changing a credential retracts already exported plaintext from another computer. Recovery of your copy and removal of someone else's copy are separate jobs.

For readable exports, inspect downloads folders, email attachments, shared links, cloud versions, and temporary test directories. Encrypting the original app does not retroactively protect these copies. Delete unnecessary copies according to the storage system's controls, recognizing that retained backups and synchronized versions may have their own lifecycle. No guaranteed erasure deadline follows from pressing Delete.

Who Zero-Friction is for, and who it is not for

Zero-Friction Tasks fits someone who wants a small personal capture inbox, local-first use, and no email account before first use. Optional sync can support continuity when you deliberately preserve the access code and understand the server-processing boundary. It is not a substitute for a separately verified backup plan.

Choose another tool if a documented full-fidelity backup/restore interface, guaranteed historical rollback, managed account recovery, team administration, or provider-blind task encryption is a requirement. Do not treat a fast capture tool as an archive merely because the tasks appear on two devices.

Want a lighter personal inbox, with those limits understood? Download Zero-Friction Tasks.