30 сентября 2026 sqliteбэкапы

Как правильно бэкапить SQLite на живом сервере

Файлы базы app.db и app.db-wal сводятся командой sqlite3 .backup в одну целую копию

SQLite — отличная база для маленьких приложений: один файл, никаких серверов. Из-за этого возникает соблазн бэкапить её простым cp. Пока приложение пишет в базу, так делать нельзя.

В чём проблема

В режиме WAL (а большинство приложений его включают) свежие изменения сначала попадают в файл app.db-wal и только потом переносятся в основной файл. Скопировав один app.db, вы потеряете всё, что ещё лежит в WAL. Скопировав оба файла по очереди, рискуете получить несогласованную пару, если между копированиями произошла запись.

Решение: встроенная команда .backup

sqlite3 /var/lib/app/app.db ".backup '/root/backups/app-$(date +%F).db'"
sqlite3 /root/backups/app-$(date +%F).db "PRAGMA integrity_check;"

.backup использует онлайн-API бэкапа SQLite: получается целая, согласованная копия, а приложение продолжает работать. Вторая строка проверяет копию — должно вернуться ok.

Перед любыми правками руками

Если нужно поправить что-то прямо в базе (иногда в панелях управления это быстрее, чем искать кнопку), порядок у меня такой: снимок через .backup → остановить приложение → правка в одной транзакции → запуск → проверка, что приложение подхватило изменения.

Урок, выученный на собственных граблях: в одной панели данные пользователей хранились не там, где казалось. JSON в одной таблице выглядел как источник правды, а на деле приложение читало отдельные таблицы. Правка «на вид» прошла, а работать перестало. Прежде чем править базу чужого приложения, посмотрите .tables и найдите, откуда оно реально читает данные.