Backups on AltSql.com

AltSql Restore Catches a Cut Upload and a 72 Percent Rental Loss in Five Nights of Pagila Backups

Sat, 31 Oct 2026 00:00:00 +0000

Pagila is the public sample database of a made-up DVD rental chain, a PostgreSQL port of MySQL’s Sakila. It has customers, films, stores, 51,805 rentals and 51,061 payments, and the payments sit in one partition per month. That makes 69 tables in all, which is close enough to a small shop’s real database to be worth a test.

We loaded it into a local PostgreSQL 16.15 server and backed it up five times with pg_dump | gzip, the way many teams do it every night. After each backup, the released altsql-restore 0.5.0 checked the file with the same job name and the same history. The five runs were made one after another on 31 October 2026, and each one stands for a night.

AltSql Restore Fails Three PostgreSQL Dumps That psql Restored With Exit Status 0

Sat, 31 Oct 2026 00:00:00 +0000

Plenty of teams already test their backups with a one-line script. It loads last night’s dump into a spare database with psql, and if the exit status is 0, the backup counts as good. The trouble is that psql reading a file keeps going after an error. It prints the error, moves on to the next statement, and exits with 0 at the end, however many statements failed.

We took three PostgreSQL dumps with real faults and gave each one to that script and to altsql-restore 0.5.0. Then we did the same with a MariaDB dump. Everything ran on 31 October 2026 against local PostgreSQL 16.15 and MariaDB 10.11.14 servers.

AltSql Restore Proves Your Nightly Backup Restores Before You Need It

Sat, 31 Oct 2026 00:00:00 +0000

Most backups are never restored until the day someone needs them. That’s a bad day to find out the dump stopped halfway through.

AltSql Restore is a new AltSql module that tests the backup every night instead. It’s one program, altsql-restore, open source under the Apache License 2.0, and it ships in the 0.5.0 release on GitHub beside the two shells.

What It Does

You point it at last night’s backup. It restores the backup into a throwaway sandbox, counts the rows in every table, takes a checksum of each, and compares the numbers with the last good run. Then it removes the sandbox.

AltSql Restore Use Examples From the Cron Line to the Auditor Report

Sat, 31 Oct 2026 00:00:00 +0000

These are the recipes we’d hand to someone setting up AltSql Restore on a backup host for the first time. Each one was run as written on 31 October 2026 with the released altsql-restore 0.5.0, on a gzipped PostgreSQL dump and a SQLite file of Chinook, the public sample database of a digital music store. Paths were changed to a test folder for the runs, and the outputs below are copied from them.

SQLite File Copied During a Write Passes AltSql Restore and Fails the SQLite Integrity Check

Sat, 31 Oct 2026 00:00:00 +0000

Most case studies show a tool doing its job. This one shows AltSql Restore 0.5.0 passing a backup it should have failed, because that’s what the recorded run says, and because the way the backup was made is common enough to matter.

The database is Chinook, the public sample database of a digital music store, as its project ships it for SQLite: one file of 1,007,616 bytes with 11 tables and 12 indexes. In this test an application keeps it as app/chinook.db in SQLite’s default journal mode, and the nightly backup is a plain cp of that file. Every night ended with altsql-restore checking the copy, and with SQLite’s own PRAGMA integrity_check run on the same copy for comparison. The three nights ran one after another on 31 October 2026.