Резервная копия живой базы SQLite: через backup API, а не копированием файла

📁 Много небольших баз

Состояние нашей системы лежит в отдельных файлах SQLite, по одному на модуль: трассы, леджер, кэши, очереди. На 3 ноября 2026, 21:53 UTC в папке данных было 128 файлов баз общим объёмом 12,0 ГБ. Это нормальный и приятный способ строить небольшие сервисы, и он означает, что резервное копирование надо делать правильно много раз подряд.

⚠️ Почему копия — это не резервная копия

База SQLite — это один файл плюс, в режиме журнала предзаписи, второй файл журнала. Писатель может быть посреди транзакции, пока вы копируете. Скопируйте основной файл, а затем журнал в разные моменты, и у вас на руках две половины разных времён. Результат может открыться и даже выглядеть нормально, но содержать пропавшие или несогласованные строки.

Возражение одного ревьюера в октябре 2026 сделало это конкретным. Файл, который «давно не менялся», копировать небезопасно: писатель может начать транзакцию прямо во время копирования. Возраст файла — не блокировка.

✅ Безопасный способ

В SQLite есть интерфейс онлайн-копирования. Он копирует базу страница за страницей в файл назначения и сохраняет результат согласованным, даже если в источник пишут во время копирования. Наш скрипт использует его с небольшим числом страниц за шаг и короткой паузой между шагами, чтобы большая база не блокировала писателей надолго. Копии мы делаем одну за другой, а не параллельно, чтобы диск и нагрузка оставались спокойными.

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

🛠️ Практика: постройте задание резервного копирования

1. Перечислите файлы баз и отметьте, какие живые. Включите в размер файлы журнала предзаписи.
2. Напишите скрипт: открывает каждый источник, открывает файл назначения и запускает интерфейс копирования шагами по несколько сотен страниц с короткой паузой.
3. Обрабатывайте базы по одной. Логируйте размер каждой копии и время.
4. После каждой копии откройте результат и запустите проверку целостности. Запишите итог.
5. Храните фиксированное число свежих копий и удаляйте более старые в том же запуске.
6. Оберните задание обёрткой сброса нагрузки, чтобы оно не стартовало на занятом хосте.
7. Раз в месяц восстановите одну копию в пробную папку и прочитайте несколько строк.

✅ Проверьте себя

• Запустите писатель, который в цикле вставляет строки. Сделайте копию, пока он работает. Копия проходит проверку целостности.
• Посчитайте место, занятое копиями сегодня и через месяц. Оно не растёт без предела.
• Восстановите последнюю копию в пробную папку. Приложение открывает её и читает свежие данные.
• Лог задания говорит, сколько заняла каждая база и прошла ли проверка.

🚧 Когда это не работает

• Очень большие базы. Пошаговая копия сотен гигабайт занимает часы. Планируйте окно и диск.
• Высокая нагрузка записи. Занятой писатель заставляет копирование перезапускать страницы много раз. Копируйте в тихий час.
• Тот же диск. Копия на диске, который вы защищаете, не переживёт его потерю. Копируйте за пределы машины.
• Нет проверки восстановления. Непроверенная копия — надежда. Проверяйте восстановление по расписанию.
• Другие хранилища. Файлы вне SQLite, например загрузки, требуют своей копии.

📊 Доказательства

➡️ Дальше

Спланируйте восстановление по материалу Восстановление после сбойного, зависшего или неопределённого запуска и не давайте заданию душить прод с помощью сброса нагрузки для плановых заданий.

Источники

• Восстановление после сбойного, зависшего или неопределённого запуска: восстановление.
• Права и потоки данных: что где хранится.
• План реагирования для небольшой команды: шаги при инциденте.
• Квитанции задач агента: что они доказывают: записи о запусках.