SQLite

Бэкап SQLite в облако — одной командой

dbsend делает согласованную копию работающей SQLite-базы, сохраняет её как версию в российском облаке и позволяет восстановить любую версию с проверкой целостности. Без своего S3-бакета, скриптов ротации и ночных проверок «а бэкап вообще работает?».

Почему cp data.db backup.db — это не бэкап

SQLite хранит всю базу в одном файле, и кажется, что достаточно его скопировать. Но если в момент копирования приложение пишет в базу, вы получите файл с половиной транзакции. В режиме WAL всё ещё коварнее: свежие изменения лежат в data.db-wal, и копия одного основного файла молча теряет последние записи.

Вторая проблема — копии никто не проверяет. Скрипт в cron годами складывает файлы в бакет, пока однажды не выясняется, что последние три месяца он падал из-за истёкшего ключа, а единственная живая копия весит ноль байт.

Третья — непонятно, что внутри. Когда пользователь пишет «у меня пропали заказы», нужно быстро найти версию, в которой они ещё были. По файлам вида backup-2026-10-06.db это превращается в ручной перебор с sqlite3 в терминале.

Как dbsend решает это для SQLite

Согласованная копия через VACUUM INTO

Перед загрузкой CLI создаёт целостный снимок базы средствами самой SQLite. Приложение можно не останавливать, WAL-режим поддерживается.

Версии вместо файлов с датами

Каждая загрузка — версия vN с размером, SHA-256 и меткой. Если файл не изменился, новая версия не создаётся: «Изменений нет — совпадает с v11».

Diff по таблицам

Откройте две версии и увидите, в каких таблицах добавились или исчезли строки и изменилась ли схема. Удобно, чтобы найти версию «до инцидента». Доступно на тарифах от «Старт».

Восстановление с проверкой

dbsend restore скачивает версию во временный файл, сверяет SHA-256, выполняет PRAGMA integrity_check и только потом атомарно заменяет базу, убирая устаревшие -wal, -shm и -journal.

Настройка за пару минут

Нужен Node.js 22.12 или новее; согласованная копия через VACUUM INTO работает без дополнительных флагов на Node.js 22.13+. API-ключ создаётся в разделе «API-ключи» — его можно ограничить одной базой. Ключ сохраняется в пользовательский конфиг, в проект попадает только .dbsend.json с ID базы.

1. Установка и первый бэкап

npm install -g @dbsend/sdk
dbsend login --key sqv_pk_…
cd /srv/app
dbsend init --database <id базы> --engine sqlite
dbsend backup ./data.db
# ✓ Версия v1 сохранена (id 8c1e…, 3.4 МБ)

2. Автоматический бэкап по cron

# crontab -e — каждый час
0 * * * * cd /srv/app && /usr/local/bin/dbsend backup ./data.db >> /var/log/dbsend.log 2>&1

Укажите полный путь к бинарнику (узнать: which dbsend). Если версия не изменилась, дубль не появится — запускать бэкап можно чаще. Код выхода 0 — успех, 3 — проблема с ключом, 4 — лимит тарифа, 5 — сеть.

3. Бэкап перед миграцией и восстановление

dbsend backup ./data.db -l "до миграции 0042" && npx prisma migrate deploy

dbsend log                       # история версий
dbsend pin <id версии>           # закрепить, чтобы ротация её не тронула
dbsend restore <id версии> ./data.db --yes

В PowerShell команды те же; путь пишется как .\data.db.

Для каких проектов это подходит

SQLite отлично работает в продакшене небольших и средних проектов: Telegram-боты, внутренние сервисы, PocketBase, Django и Rails-приложения на одном сервере, локальные приложения и прототипы, собранные с AI-ассистентом. Во всех этих случаях база — один файл на диске VPS или в Docker-volume, и потеря этого диска означает потерю всего.

dbsend не заменяет репликацию в реальном времени, а даёт простой и проверяемый слой защиты: регулярные версии вне сервера, понятную историю и восстановление, которое можно отрепетировать за минуту. Для большинства проектов на SQLite этого достаточно, чтобы спокойно делать миграции и не бояться сбоя диска или ошибочного DELETE.

dbsend или свой скрипт cron + S3

cron + sqlite3 .backup + S3dbsend
Безопасная копия работающей базыесли не забыли .backupVACUUM INTO автоматически
PRAGMA integrity_check при восстановлении
Время на настройкускрипт, бакет, ключи, ротация — часы3 команды — несколько минут
История версий с меткамиимена файлов по датеv1…vN, метки, закрепление
Не плодит одинаковые копии
Diff между версиями (таблицы, строки, схема)на платных тарифах
Проверка SHA-256 при восстановленииесли написали сами
Алерт, если бэкап не пришёлTelegram и email
Шифрование и хранение в РФзависит от бакетаAES-256-GCM, РФ
Доступ из Claude Code и Cursor (MCP)
Стоимостьхранилище + ваше времяот 0 ₽

Тарифы и лимиты — на странице «Тарифы». Документация: CLI, форматы файлов, базы.

Частые вопросы

Нужно ли останавливать приложение на время бэкапа SQLite?

Нет. CLI создаёт копию через VACUUM INTO — это штатный механизм SQLite, который читает базу в рамках одной транзакции. Приложение продолжает работать, а в облако уходит целостный файл.

Что с файлами -wal и -shm?

Их не нужно копировать отдельно: VACUUM INTO включает в копию все зафиксированные транзакции из WAL. При восстановлении с флагом --yes CLI убирает устаревшие -wal и -shm рядом с целевым файлом, чтобы SQLite не применила к восстановленной базе чужой журнал.

Как часто можно делать бэкап?

Загружать можно в пределах суточного лимита тарифа: 5 раз в день на бесплатном, 50 на «Старт», 200 на «Про». Неизменившийся файл не создаёт новую версию, поэтому частый cron не тратит лимит версий впустую.

Чем это отличается от Litestream?

Litestream непрерывно реплицирует WAL в ваш бакет и требует постоянно запущенного процесса. dbsend работает по расписанию или по команде, не требует своего S3, показывает версии и diff в панели и присылает алерты, если бэкап не пришёл. Если нужна потеря не более нескольких секунд данных — выбирайте Litestream; если нужны понятные версии и проверенное восстановление — dbsend.

Какой максимальный размер базы?

До 100 МБ на файл на бесплатном тарифе, 500 МБ на «Старт» и до 2 ГБ на «Про» и «Команде». Файлы больше 32 МБ CLI загружает частями автоматически.

Статьи по теме

Все статьи →

Бэкап SQLite без повреждения: .backup, VACUUM INTO и WAL

Как сделать бэкап SQLite на живой базе: почему cp опасен в WAL-режиме, .backup, VACUUM INTO, Python и Node, cron, systemd, Windows, S3 и восстановление.

Litestream, cron-скрипт или dbsend: как бэкапить SQLite

Litestream, cron-скрипт или dbsend для бэкапа SQLite: как работает каждый подход, какой RPO даёт, как восстанавливать и когда их стоит совмещать.

Бэкап базы Telegram-бота на SQLite: aiogram, PTB, Telegraf

Бэкап базы телеграм-бота на SQLite: копия через backup API без блокировки бота, расписание, отправка админу, загрузка в S3, Docker и восстановление.

Бэкап PocketBase: pb_data, встроенные бэкапы, S3 и восстановление

Бэкап PocketBase на практике: что лежит в pb_data, встроенные бэкапы и API, копия data.db через sqlite3, файлы в S3, восстановление и чек-лист обновления.

Как проверить бэкап: тест восстановления, checksum, integrity_check

Как проверить, что бэкап базы рабочий: sha256sum, gzip -t, integrity_check, тестовое восстановление в Docker, еженедельный тест в cron и контроль пропусков.

Другие сценарии

Первый бэкап SQLite — через пару минут

Бесплатный тариф: 1 база, 500 МБ и 3 версии навсегда. Карта не нужна.

Начать бесплатно →