For Divvent’s own team. It is generated from the operations document in our repository, which is the one to edit. If you use Divvent, the help centre is for you.
3a. The nightly dump, and the two windows
divvent dump <modelDir> --env <env>Takes tonight's dump into the tenant's own R2 and then sweeps what the policy no longer keeps — in that order, because a sweep that ran first would, on the night the dump fails, leave the application with one fewer restore point and nothing to show for it.
Two windows, and they are not the same promise. Say both, in these words:
| Rollback | Thirty days. D1 Time Travel's own retention — the only mechanism that works on a database with full-text indexes, and not ours to extend. |
| Dump | A year by default, and whatever retention: { dumps: <days> } in app.yaml says otherwise. Slower to restore, and the one that goes back furthest. |
A restore point a customer believes in and does not have is worse than one they know is thirty days long.
The sweep leaves alone every object whose key it cannot read a date from. The bucket holds the customer's media too, and deleting an object because its name was unfamiliar is how a sweep removes something it was never meant to touch.
Now scheduled (docs/proposals/47-backup-scale.md §6). divvent dump was "what the nightly schedule calls" and nothing called it. backups.yml runs, at 02:17 UTC:
divvent backups --env staging --runner <run id> --scheduled— every deployed production whose last scheduled backup is older than twenty hours: a bookmark and a dump into the company's own R2, catalogued in platform_backup (key, size, tables, rows, the revision it was taken on — never a row), the expired dumps swept and their catalogue rows marked, and a failure recorded so the customer's Backups screen says last night's failed. The same pass takes every backup a customer asked for; it runs every half hour.
---