Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This surprises me. I was under the impression that SQLite backups run inside a dedicated transaction in order to avoid this.


See the SQLite online backup API documentation [1].

You can finish the backup in one step, but a read-lock would be held during the entire duration, preventing writes. If you do the backup several pages at a time, then

> If another thread or process writes to the source database while this function is sleeping, then SQLite detects this and usually restarts the backup process when sqlite3_backup_step() is next called. ...

> Whether or not the backup process is restarted as a result of writes to the source database mid-backup, the user can be sure that when the backup operation is completed the backup database contains a consistent and up-to-date snapshot of the original. However: ...

> If the backup process is restarted frequently enough it may never run to completion and the backupDb() function may never return.

The CLI .backup command does non-blocking backup IIRC so is subject to restarts.

[1] https://www.sqlite.org/backup.html


This comment cleared that up for me: VACUUM INTO backups are transactional, but the .backup mechanism is not: https://news.ycombinator.com/item?id=31387556

Ben I suggest updating that cron backups documentation page to recommend VACUUM INTO instead!



Good catch. I went ahead and added an issue on the docs. https://github.com/benbjohnson/litestream.io/issues/56




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: