An Account Export Is Not a Backup
AI-assisted article. Reviewed by Codebuff automated editorial review on 2026-11-04. Examples are illustrative, not real user data.
Downloading your account data feels like a backup, and the resemblance is close enough to be dangerous. An export is a snapshot of what the service will hand back today, in a format meant for reading. A backup is something you have tested restoring, kept somewhere the original failure cannot reach, and refreshed on a schedule.
What an export is for
An export answers a portability question: what does this account hold, and can I take it elsewhere. It is also the honest way to see what a service stores about you, which is why a good export includes folders, settings and account metadata rather than only the main content table.
Read the file's own notes before assuming it is complete. A large account may be exported in pages, and a response that says it was truncated is telling you the download is a partial view. If the format includes a cursor or a next page, fetch the rest before you archive anything.
What an export cannot contain
Deleted and expired items are gone from the source, so they cannot appear in a later export. That is the point of deletion, but it means an export taken after a cleanup is not a history of the account.
Browser-encrypted text is another gap. The server stores ciphertext and never receives the key, so an export cannot hand back readable plaintext for those pastes. If the link was lost, the export will not recover the content.
Credentials are usually excluded or reduced to metadata for the same reason they are stored hashed: a working key or session token cannot be reconstructed from a backup. Plan to recreate keys rather than restore them.
Store it where the original failure cannot reach it
A copy on the same laptop, in the same cloud account, under the same password is not a backup. Move the archive somewhere else: an external disk, a second provider, or a different account with its own credentials.
Encrypt the archive before it leaves the machine. Exports contain the same material you would not paste publicly, and a compressed tar file is not encryption. Keep the passphrase in a password manager, not in a note beside the archive.
# Create one archive and encrypt it before it leaves the machine
# (age prompts for a passphrase; any equivalent tool is fine)
tar -czf pastesite-export-2026-11-04.tar.gz pastesite-export.json
age -p pastesite-export-2026-11-04.tar.gz > pastesite-export-2026-11-04.tar.gz.age
rm pastesite-export-2026-11-04.tar.gz
Test a restore before you need one
Open the archive, decrypt it, and parse the JSON. Count the records and check one item you remember. A backup nobody has opened is a hope, and the failure mode is discovering the passphrase or the archive is wrong on the day the original is gone.
Check that the restored copy is usable, not merely present. If the export is a single JSON file, a restore may mean importing it into another tool; try that once with a small subset so the shape of the data is familiar before it matters.
Refresh on a schedule and keep one older copy
Monthly is enough for most personal accounts. Keep the previous archive until the new one has been opened and checked, so a bad export does not replace a good one.
Remember that deleting the account deletes the source, not the copies. If the goal is to leave, export first, verify the archive, and only then close the account. If the goal is to keep working, the export is a safety net rather than a substitute for the service's own storage.
Sources and editorial review
Prepared with AI assistance and checked against the export and erasure code at the reviewed revision, which shows paged exports with an explicit truncation flag and the deletion path. The shell example is illustrative and was not run. The article deliberately does not enumerate every field in an export, because that list belongs to the product documentation.