Backup and Recovery
What LeraLink backs up, how restore is tested, what we have measured, and the limits.
Last updated: 13 November 2026
Summary
| Measure | What it covers | How often | Kept | Where |
|---|---|---|---|---|
| Nightly logical backup | The whole database: every table holding application data | Every night | 30 days | Cloudflare EU jurisdiction |
| Point-in-time restore (Cloudflare D1 Time Travel) | The whole database, to an earlier moment | Continuous | 30 days | Cloudflare EU jurisdiction |
| File storage | Images, audio, documents and other files | Stored redundantly by Cloudflare R2; no separate backup | As long as the file exists | Cloudflare EU jurisdiction |
| Customer exports | An installation's content, and each person's own data | When the customer or person asks | As the customer decides | With the customer |
The nightly backup
Every night, the platform writes a logical copy of the whole database to file storage in Cloudflare's EU jurisdiction.
- It covers every table that holds application data. Which tables exist is read from the database itself, so a new table is included without anyone having to add it.
- It is written in parts. Each part has a checksum and a row count, and a manifest written last lists them all. A backup without its manifest is incomplete and is never restored.
- Backups are kept for 30 days and then deleted automatically.
- A backup run that stops making progress is marked as interrupted after 30 minutes, and if no backup has succeeded in 26 hours a new one is started. The platform administrator's readiness screen shows the latest backup and flags it when none has completed in the last 36 hours.
The backup is in an open text format. A verification tool restores it into a standard SQLite database outside Cloudflare.
Point-in-time restore
For a destructive change, such as a faulty release or a mistaken bulk edit, the database can be returned to the moment before it, using Cloudflare's point-in-time restore. Every production release records a restore point before it applies changes to the database structure.
Point-in-time restore returns the whole database, and so every installation, to that moment. Returning one installation to an earlier point without affecting the others is done by restoring a separate copy and transferring the affected records, which takes longer.
The platform administrator can also put the affected installation, or the whole platform, into read-only mode first, so that nothing more is changed while the restore is prepared.
Files
Files are stored in Cloudflare R2, which stores each object redundantly within its jurisdiction. There is no separate nightly copy of files today, so a file that is deleted is removed at once and cannot be restored by us. A verified copy tool exists: it was used to move every file to the EU on 3 November 2026 and checked each one.
How restore is tested
- A restore always goes to a new, separate database first. Production is never overwritten to test a backup.
- A restore is accepted only when every checksum matches, every table's row count matches the manifest, every table of the current software version is present, and no reference between records is broken.
- Restore is rehearsed on staging and on a copy of production.
What we have measured
| Event | Result |
|---|---|
| Full database restore, on a copy of production (263,287 rows, 31 October 2026) | 24 minutes, plus about 11 minutes of checks before the restore |
| Move of the platform to the EU, 3 November 2026 | A real-world restore of production: 271,032 rows in 24 minutes, every count matching and no broken reference. Rehearsed three times beforehand; every row and file was checked |
| Read-only time during that move | About two hours, of which about half an hour was a first attempt that stopped before writing anything and was corrected. About 90 minutes without it, as rehearsed |
Recovery objectives
| Scenario | Recovery point (data that could be lost) | Recovery time |
|---|---|---|
| Destructive change (faulty release, mistaken bulk change) | Point-in-time restore to the moment before the change | Target as in the Service Level Agreement |
| Total loss of the database | Up to 24 hours: the last nightly backup | Target as in the Service Level Agreement |
| Faulty release without data damage | None: the previous version is redeployed | Target as in the Service Level Agreement |
We do not promise a recovery time for a specific incident until the restore path has been verified for it. The 24-minute measurement is for the database restore alone; checks before the service is reopened come on top.
What you can do yourself
- Installations can export their content at any time. Keeping your own copy protects you against any failure on our side, and against our own exit. See the Data Export and Exit Policy.
- Every person can download their own data from their account. See Your Data Rights.
Limits, stated honestly
- The nightly backup is taken while the service is running, table by table. It is not a single-instant snapshot. A record changed during the backup may be in its old or new state, and a record deleted during the run can leave a related record without it; the restore check reports this. For a precise moment, point-in-time restore is used.
- A total loss can lose up to 24 hours of changes.
- Backups are kept for 30 days, and point-in-time restore reaches back 30 days. Data deleted more than 30 days ago cannot be recovered.
- Files have no separate copy. They depend on Cloudflare R2's durability, and a deleted file cannot be restored.
- Point-in-time restore applies to the whole database; restoring one installation alone takes longer.
- Backups are stored with the same provider, Cloudflare, though separately from the live database. A failure of Cloudflare as a whole is addressed in Business Continuity.
- Backups are not edited. Data deleted at someone's request stays in backups until they expire.
- Customer support is provided during office hours. A restore requested outside them that is not part of an incident response may start later.