Restoring a backup no longer corrupts or locks up the database

Restoring a backup from the Settings page could leave Anthias with a database it couldn't read, or one so locked that the web interface answered with server errors. A player upgraded from an older install could hit the second one too. Anthias 2026.10.0 fixes both, and backups made by earlier versions still restore.

Both problems were in the one SQLite database where Anthias keeps its assets and settings, ~/.anthias/anthias.db, which the web server, the background worker and the viewer all use at once.

Backups and restores

"Get backup", under Backup & restore in Settings, used to put the database in the archive together with its write-ahead log files, anthias.db-wal and anthias.db-shm, each read at a different moment while Anthias kept writing. "Upload & recover" then unpacked the archive over the live files. When the archive carried no log of its own, the old database's log stayed next to the restored database, SQLite replayed it into the wrong file, and the first read after the restore failed with database disk image is malformed.

Now a backup carries a single copy of the database, taken through SQLite at one moment, with everything in the log included and no log files beside it. A restore deletes the log files of each database it replaces before anything opens it.

Backups made before 2026.10.0 still restore. Their log files are skipped, which avoids the corruption but leaves out any changes that were still only in the log when the backup was made.

If the database can't be copied while its log holds changes that aren't in the main file yet, the backup now fails, and the "Get backup" download ends in an error, instead of producing an archive without those changes.

A database that hasn't switched to write-ahead logging

Anthias runs the database with write-ahead logging, so reads and writes don't block each other. It used to ask SQLite to switch to that mode every time it opened a connection. On a database that wasn't switched yet, such as one from an older install or one just restored, the switch needs the file to itself, and with 3 services using it the request failed with database is locked. Each failure left a file open, and the web interface answered with server errors. In the project's crash reports, one device went from database is locked to Too many open files to unable to open database file in a single afternoon.

Now each service checks the mode once when it starts, and switches it if it can. If the database is busy, Anthias carries on in the old mode, which is slower when several services write at once but works, and tries again at the next start.