AltSql 0.5.0 adds a new module, AltSql Restore. Most backups are never tested until the day someone needs one. altsql-restore takes last night’s PostgreSQL or MySQL dump, SQLite file, archive or folder, restores it into a throwaway sandbox, counts the rows and checksums every table, and compares the result with the last good run. Exit 0 means verified. A failed restore, or a table that shrank more than 10%, raises an alert. NOT VERIFIED, when no engine could run, never counts as a pass. Each run writes a sealed report an auditor can check later, and the history sits in an AltSql DB file the altsql-db shell can query.
An independent review found six bugs, fixed in 0.5.1. The worst: a plain dump could carry client commands like psql’s \! that ran on the host, and the run still said verified. Dumps are now read before they run, and psql runs locked under a key the dump can’t know. The case studies had already found the other big one. A SQLite file copied in the middle of a write passed 0.5.0 while SQLite’s own check reported 100 errors. Restore now checks every index against its table, and 0.5.1 fails that copy. A scripted fuzz run of 30,000 damaged SQLite, tar and gzip files caused no crash.
The other case studies ran on real PostgreSQL and MariaDB with the public Pagila and Chinook sample databases. Over five nights of Pagila backups, Restore caught an upload cut at 60% in a fifth of a second, and a 72% loss of rentals after an archiving job went wrong. Three dumps that psql restored with exit status 0 had silently left tables empty, and Restore failed all three. The use examples run from the cron line to the auditor’s report. Binaries are out for Linux and macOS. The previous note covers AltSql’s open source binaries.