# Account copies and restore HealthLog keeps copies of each account so that one account can be rolled back on this server. These copies are per account. They cannot rebuild a lost server: a restore writes into an account on this server, the one the copy belongs to, or, when that account has been erased, one you choose (see "Restoring an erased account"). To recover a server, you need a database dump and the encryption keys. That procedure is in [disaster-recovery.md](disaster-recovery.md). ## What exists | Copy | Where | When | Kept | | ----------------------- | ------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Weekly account rollback | this database | Sundays 03:00, or **Backup now** in Admin → Backups | one per account, replaced in place each week | | Copy before a data wipe | this database | right before "Delete all data" deletes anything | until `ACCOUNT_DELETION_GRACE_DAYS` has passed, then the purge job deletes it | | Uploaded copy | this database | when an admin uploads a file in Admin → Backups | until deleted | | Off-host copy | your S3-compatible bucket | nightly at 02:30 Europe/Berlin, one object per account per day | as long as the bucket's lifecycle rule keeps it | | Personal export | the person's device | Settings → Export, "Full backup" | wherever they keep it | The weekly, pre-wipe and off-host copies carry the whole record, document files and ECG traces included, with the database's ciphertext inside them as stored. An uploaded copy holds whatever its file held. The personal export is portable: readable values, and documents as metadata only. It is meant for the person to keep and read. A restore refuses it when the file lists any document, because it carries no document content to put back. Two kinds of data are not in any account copy: workout GPS routes and sample series. Credentials, devices, share links and account grants are left out on purpose (see "What a restore does not touch"). The JSON import in Settings → Export & import is not a restore. It adds measurements and mood entries, up to 16 MB and 10,000 entries per list. ## The deletion grace window `ACCOUNT_DELETION_GRACE_DAYS` (14 by default, at most 30) sets how long an erasure waits: - **Deleting an account**, or a guardian deleting a **managed profile**, locks the account at once. Every session, refresh token, API token, connector and share link is revoked, sign-in is refused with the date the account is erased, and nothing runs for the account any more: no reminders, syncs, copies, scores or AI work. The record, its stored copies and its off-host objects stay as they are. **Admin → Users** shows the account with its erasure date and an **Undo deletion** button. When the window ends, the hourly `account-deletion-purge` job erases the account and asks the bucket to delete its off-host objects. - **Delete all data** first stores the whole record as a copy of its own (shown as "Before all data was deleted" in Admin → Backups), then empties the record. An admin can restore that copy until the window ends. The off-host objects from before the wipe are kept until then too. Database dumps are not purged per account: a deleted account stays in them until they age out (`DB_BACKUP_KEEP` nights on the server, and the bucket's lifecycle rule for `database/`). The deletion dialogs say so. `0` erases immediately, as releases before 1.46 did. The Data & Privacy page and the deletion dialogs state the configured number. ## Restoring an account In **Admin → Backups**, every stored copy has **Restore**. The dialog first shows what the copy holds, then asks you to type `RESTORE`. The restore runs in the background and replaces the account's data tables: every row the copy holds comes back under its original id, and every row the account gained after the copy was taken is deleted. If the current state is worth keeping, press **Backup now** first. _Also restore instance settings_ writes the registration, MFA, locale, module, notification and AI settings from the copy back for the whole server. Leave it clear unless those settings themselves need to go back. To restore from an **off-host object**, fetch and decrypt it from a source checkout with the backup variables of the server that wrote it: ```bash BACKUP_S3_ENDPOINT=... BACKUP_S3_BUCKET=... \ BACKUP_S3_ACCESS_KEY=... BACKUP_S3_SECRET_KEY=... \ BACKUP_ENCRYPTION_KEY= \ pnpm dlx tsx scripts/restore-backup.ts 2026-05-08/user-.json.enc /tmp/restored.json ``` Then upload `/tmp/restored.json` in Admin → Backups (up to 512 MB after compression) and restore it from its row. When the account `` no longer exists on this server, the upload offers to put the copy into another account (next section). Every restore, preview and upload checks first that this server holds every application key the copy's content was written under, and refuses with the key id named if not. Nothing is changed by a refused restore. ### Restoring an erased account Once an account has been erased (its deletion window ended and the hourly purge ran), its copies on this server and in the bucket are gone, but a file you kept still holds the record: a disaster-recovery download, an off-host object you fetched before it expired, or the person's own full backup. Uploading it in Admin → Backups is refused at first, because the account it names no longer exists, and the console then asks where the records should go: - **A new account.** Type a username. The account is created without a password or email, as an ordinary account with the user role, and nobody can sign into it yet. Before handing it over, set its first password with **Reset password** in Admin → Users; the person can change it, add an email and enrol a passkey from their settings. The account is made before the file is read, with an `admin.user.create` audit row (`outcome: "created"`), and removed again when the file is refused, with an `admin.user.delete` row (`reason: "backup_upload_refused"`). When that row says `outcome: "failed"`, the removal did not happen and the account is left over, holding nothing: delete it in Admin → Users. - **An existing account**, for someone who has signed up again. Pick the account and type its username to confirm. The account must hold no records yet: a restore replaces an account's records and does not merge them, so an account with even one record of any kind a copy carries is refused, with the kinds named. What signing up and the setup questions leave behind does not count (the setup answers and the cycle settings): the restore replaces both with the copy's. A reading or medication entered on setup's last screen is a record, and the account is refused until it is deleted, because the restore would delete it too. Managed profiles, accounts pending deletion and admin accounts are not offered: an admin account is the operator's, its settings are read under the operator's wider AI endpoint policy, and its role reaches every account, so another person's record does not go into it. The file is then uploaded a second time, and its owner is changed to the chosen account as it is read. Nothing else in the file changes. The stored copy is then that account's copy in every respect but one: its preview, its download and its restore are the ordinary ones, and **Restore** on its row brings everything back under the chosen account. The one difference is that it is stored as `RETARGETED_UPLOAD_