Резервне копіювання живої бази SQLite: API резервного копіювання, а не копіювання файлу

📁 Багато невеликих баз

Наша система тримає свій стан в окремих файлах SQLite, по одному на модуль: трасування, журнал операцій, кеші, черги. 3 листопада 2026, 21:53 UTC у теці з даними лежало 128 файлів баз загальним розміром 12,0 GB. Це звичайний і приємний спосіб будувати невеликі сервіси, і саме через нього резервне копіювання — робота, яку треба зробити правильно багато разів.

⚠️ Чому копія — не резервна копія

База SQLite — це один файл плюс, у режимі попереднього запису, другий файл журналу. Процес, що пише, може саме бути посеред транзакції, коли ви копіюєте. Скопіюйте основний файл і журнал у різні моменти — і ви матимете дві половини різних часів. У результаті копія може відкритися і навіть виглядати нормально, але міститиме відсутні або неузгоджені рядки.

Одне зауваження рецензента в жовтні 2026 зробило це наочним. Файл, який «давно не змінювався», не безпечно копіювати: той, хто пише, може почати транзакцію, поки триває копіювання. Вік файлу — не блокування.

✅ Безпечний шлях

SQLite постачає інтерфейс онлайн-резервного копіювання. Він копіює базу сторінка за сторінкою у файл призначення і зберігає результат узгодженим, навіть якщо в джерело пишуть під час копіювання. Наш скрипт резервного копіювання використовує його з невеликою кількістю сторінок на крок і короткою паузою між кроками, тож велика база не блокує тих, хто пише, надовго. Ми запускаємо копіювання одне за одним, не паралельно, щоб тримати диск і навантаження спокійними.

Два правила обліку постали з інциденту 14 вересня 2026, коли диск сягнув дев'яноста семи відсотків через те, що резервні копії не ротувалися. Перше: рахуйте місце для файлу плюс його журнал у тому самому проході, що робить копію. Друге: коментар самого сторожового обмежувача називає відсутність ротації причиною, тож ротуйте старі копії в тому самому завданні, що створює нові, і тоді завдання не зростатиме без межі.

🛠️ Практика: зберіть завдання резервного копіювання

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

✅ Перевірте себе

• Запустіть процес, що пише, який у циклі вставляє рядки. Зробіть резервну копію, поки він працює. Копія проходить перевірку цілісності.
• Порахуйте місце на диску, яке ваші резервні копії займають сьогодні й наступного місяця. Воно не зростає без межі.
• Відновіть останню копію в окрему теку. Застосунок відкриває її й читає свіжі дані.
• Журнал завдання каже, скільки часу зайняла кожна база і чи пройшла перевірка.

🚧 Коли це не працює

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

📊 Докази

➡️ Далі

Сплануйте відновлення в Відновлення після невдалого, завислого чи невизначеного запуску, і не дайте завданню заморити продуктивне середовище голодом за допомогою скидання навантаження для планових завдань.

Джерела

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