Backups are the reason a host sleeps at night, and today one can silently leave out most of a world while a restore deletes the only copy of the current one.
Acceptance
[ ] create records what it left out: files over MAX_FILE (8 MB) and everything past MAX_TOTAL (64 MB) are skipped without a word today (src/backups.ts:89). Count them, and carry the count and the bytes they stand for on the backup row.
[ ] A backup that skipped anything is labelled incomplete in the table, in the flash and in the console line, saying how many files and why — it is never presented as a good backup.
[ ] The two caps are named on the page and in the README, with one sentence on what to do when a world outgrows them.
[ ] A restore first takes a pre-restore backup of the current server directory and says so in the flash and the console; if that snapshot cannot be taken, the restore does not happen and the world is untouched.
[ ] A pre-restore backup survives the prune that backup_keep drives, until a newer pre-restore replaces it, so undoing a restore is always available.
[ ] The server page shows what a server costs on disk — its directory and the total of its backups — computed when a backup is taken, not on every render.
[ ] The schema change is additive and idempotent against an existing database, and a row written before the change still renders.
[ ] An archive with a path that escapes the directory is still refused (safeName, src/tar.ts), with a test that says so.
[ ] Tests: a directory holding a file over the cap yields a backup marked incomplete with the right count; a restore leaves a pre-restore snapshot that the prune does not eat; a snapshot that fails aborts the restore with the world unchanged.
[ ] The README's backup section matches the new behaviour.
Pre-restore snapshots double the disk a server needs at the worst moment — keep exactly one per server and count it in the figure the page shows. Walking the tree for sizes on every render would cost the request budget. The migration runs against production's database, so it must be additive and survive a second run.
Who
Hearth — backups and recovery are the middle of its brief, and it wrote this code.
Backups are the reason a host sleeps at night, and today one can silently leave out most of a world while a restore deletes the only copy of the current one.
Acceptance
createrecords what it left out: files overMAX_FILE(8 MB) and everything pastMAX_TOTAL(64 MB) are skipped without a word today (src/backups.ts:89). Count them, and carry the count and the bytes they stand for on the backup row.pre-restorebackup of the current server directory and says so in the flash and the console; if that snapshot cannot be taken, the restore does not happen and the world is untouched.pre-restorebackup survives the prune thatbackup_keepdrives, until a newerpre-restorereplaces it, so undoing a restore is always available.safeName,src/tar.ts), with a test that says so.Files I expect to change
src/backups.ts,src/db.ts,src/pages/server.ts,src/tty.ts,src/server.test.ts,README.md.Risks
Pre-restore snapshots double the disk a server needs at the worst moment — keep exactly one per server and count it in the figure the page shows. Walking the tree for sizes on every render would cost the request budget. The migration runs against production's database, so it must be additive and survive a second run.
Who
Hearth — backups and recovery are the middle of its brief, and it wrote this code.