Расписание и контроль

Бэкап базы данных по расписанию — с алертом, если он не пришёл

Запустить бэкап по расписанию просто — сложно заметить, что он перестал работать. dbsend подходит к любому планировщику: cron, systemd, Планировщик заданий Windows или GitHub Actions запускают dbsend backup, а сервис следит за ожидаемым интервалом и пишет в Telegram или на email, если очередная версия не пришла.

  • Данные в РФ
  • AES-256-GCM
  • Бесплатный тариф без карты
$ crontab -l0 */6 * * * cd /srv/app && /usr/local/bin/dbsend backup ./data.db >> /var/log/dbsend.log 2>&1$ tail -n 4 /var/log/dbsend.log✓ Версия v84 сохранена (id 8c1e…, 3.4 МБ)  https://dbsend.ru/databases/3f2a…/snapshots= Изменений нет — совпадает с v84 (id 8c1e…)  https://dbsend.ru/databases/3f2a…/snapshots

Почему бэкапы по расписанию ломаются молча

cron не сообщает об ошибках, если вы сами не настроили MAILTO и отправку почты, — а на большинстве VPS письма никуда не уходят. Скрипт перестаёт работать из-за мелочи: сменился PATH, истёк ключ, кончилось место на диске, базу перенесли на другой сервер. Лог растёт, но в него никто не смотрит.

Планировщик в CI тоже не гарантия. В GitHub Actions запуски по расписанию могут задерживаться при высокой нагрузке, а в публичных репозиториях расписание автоматически отключается после 60 дней без активности.

Проверять нужно не «запустился ли скрипт», а «пришёл ли бэкап». Именно это делает контроль расписания в dbsend: он смотрит на результат — новую загрузку — и поднимает тревогу, если её нет.

Как dbsend контролирует расписание

Ожидаемый интервал

В настройках базы укажите, как часто должен приходить бэкап. Минимальный интервал зависит от тарифа: «Бесплатный» — раз в сутки, «Старт» — раз в 6 часов, «Про» — раз в час, «Команда» — раз в 5 минут.

Алерт, если бэкап не пришёл

Если очередная загрузка не появилась вовремя, срабатывает событие «Бэкап не пришёл вовремя» и приходит уведомление в Telegram или на email (тарифы от «Старт»). Сигнал — результат, а не факт запуска скрипта.

Коды выхода для планировщика

0 — успех или «Изменений нет», 3 — проблема с ключом, 4 — лимит тарифа, 5 — сеть, 6 — не прошла проверка целостности. systemd, Планировщик Windows и CI сразу видят ошибку.

Без дублей

Если файл не изменился, версия не создаётся: «Изменений нет — совпадает с vN». Запускать бэкап чаще, чем меняются данные, можно без расхода лимита версий.

Как это работает

Примеры для четырёх планировщиков

Во всех примерах CLI установлен глобально (npm install -g @dbsend/sdk, Node.js 22.12+), а ID базы задан флагом -d или файлом .dbsend.json из dbsend init. Ключ берётся из конфига после dbsend login или из переменной DBSEND_API_KEY.

  1. cron (Linux, macOS)

    # crontab -e — каждые 6 часов; полный путь к бинарнику: which dbsend
    0 */6 * * * cd /srv/app && /usr/local/bin/dbsend backup ./data.db >> /var/log/dbsend.log 2>&1
    
    # дамп PostgreSQL каждую ночь в 03:15 (пароль — в ~/.pgpass)
    15 3 * * * pg_dump --format=plain -U app app > /var/backups/app.sql && /usr/local/bin/dbsend backup /var/backups/app.sql -d 9b17… -e postgresql_dump >> /var/log/dbsend.log 2>&1

    cron запускает команды с урезанным PATH и без переменных из .bashrc: указывайте полные пути, а если Node.js установлен через nvm — задайте PATH в начале crontab. Знак % в crontab нужно экранировать (\%), поэтому метки с датой удобнее формировать в отдельном скрипте.

  2. systemd timer

    # /etc/systemd/system/dbsend-backup.service
    [Unit]
    Description=dbsend backup
    
    [Service]
    Type=oneshot
    User=app
    WorkingDirectory=/srv/app
    ExecStart=/usr/local/bin/dbsend backup ./data.db
    
    # /etc/systemd/system/dbsend-backup.timer
    [Unit]
    Description=dbsend backup every 6 hours
    
    [Timer]
    OnCalendar=*-*-* 00/6:00:00
    Persistent=true
    RandomizedDelaySec=5m
    
    [Install]
    WantedBy=timers.target
    
    # включение и проверка
    sudo systemctl daemon-reload
    sudo systemctl enable --now dbsend-backup.timer
    systemctl list-timers dbsend-backup.timer
    journalctl -u dbsend-backup.service -n 20

    Persistent=true запустит пропущенный бэкап после перезагрузки сервера. dbsend login выполните от пользователя из User=, а вывод CLI попадёт в журнал systemd.

  3. Планировщик заданий Windows (PowerShell)

    $action  = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c dbsend backup C:\app\data.db" -WorkingDirectory "C:\app"
    $trigger = New-ScheduledTaskTrigger -Daily -At 3am
    Register-ScheduledTask -TaskName "dbsend-backup" -Action $action -Trigger $trigger

    npm устанавливает dbsend как dbsend.cmd, поэтому задача запускает его через cmd.exe. Чтобы бэкап работал без входа в систему, включите в свойствах задачи «Выполнять вне зависимости от регистрации пользователя».

  4. GitHub Actions

    # .github/workflows/db-backup.yml
    name: db-backup
    on:
      schedule:
        - cron: "15 0 * * *"   # UTC — это 03:15 по Москве
      workflow_dispatch:
    jobs:
      backup:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/setup-node@v4
            with:
              node-version: 22
          - run: npm install -g @dbsend/sdk
          - run: pg_dump --format=plain "$DATABASE_URL" > app.sql
            env:
              DATABASE_URL: ${{ secrets.DATABASE_URL }}
          - run: dbsend backup ./app.sql -d ${{ vars.DBSEND_DATABASE_ID }} -e postgresql_dump -l "gha-${{ github.run_number }}"
            env:
              DBSEND_API_KEY: ${{ secrets.DBSEND_API_KEY }}

    База должна быть доступна из сети GitHub, а версия pg_dump на раннере — не старше версии сервера (при необходимости установите нужный postgresql-client). Расписание GitHub работает по UTC.

Как выбрать частоту бэкапа

Частоту определяет допустимая потеря данных: сколько последних изменений вы готовы потерять при сбое. Блогу или справочнику достаточно раза в сутки, интернет-магазину или CRM — раз в несколько часов, активной SaaS-базе — раз в час и чаще.

Ограничения тарифа: загрузок в день — «Бесплатный» — 5, «Старт» — 50, «Про» — 200, «Команда» — 1 000; минимальный ожидаемый интервал для контроля расписания — «Бесплатный» — раз в сутки, «Старт» — раз в 6 часов, «Про» — раз в час, «Команда» — раз в 5 минут. Неизменившийся файл не создаёт новую версию, поэтому запускать бэкап можно чаще, чем меняются данные.

Ожидаемый интервал задавайте с небольшим запасом относительно расписания: если cron запускается раз в 6 часов, а дамп снимается 20 минут, интервал в 7 часов не будет давать ложных тревог.

Расписание для проверки восстановления

Регулярный бэкап ещё не гарантирует, что из него можно восстановиться. Добавьте в планировщик вторую, более редкую задачу — например, раз в неделю: dbsend restore скачивает последнюю версию во временный путь, сверяет SHA-256 (для SQLite ещё и выполняет PRAGMA integrity_check), а ваш скрипт применяет дамп к тестовой базе и проверяет, что ключевые таблицы не пусты.

Ненулевой код выхода такой задачи — повод разобраться сразу, а не в день аварии. Код 6 означает, что проверка целостности не пройдена и целевой файл не изменён.

Свой скрипт по расписанию или dbsend

  • Узнаете, что бэкап не пришёл

    cron + скрипт + S3
    если настроили MAILTO и почту
    dbsend
    алерт в Telegram или на email, от «Старт»
  • Работает с cron, systemd, Windows и CI

    cron + скрипт + S3
    dbsend
  • Время на настройку

    cron + скрипт + S3
    скрипт, бакет, ключи, ротация — часы
    dbsend
    3 команды — несколько минут
  • История версий с метками

    cron + скрипт + S3
    имена файлов по дате
    dbsend
    v1…vN, метки, закрепление
  • Не плодит одинаковые копии

    cron + скрипт + S3
    dbsend
  • Diff между версиями (таблицы, строки, схема)

    cron + скрипт + S3
    dbsend
    на платных тарифах
  • Проверка SHA-256 при восстановлении

    cron + скрипт + S3
    если написали сами
    dbsend
  • Шифрование и хранение в РФ

    cron + скрипт + S3
    зависит от бакета
    dbsend
    AES-256-GCM, РФ
  • Доступ из Claude Code и Cursor (MCP)

    cron + скрипт + S3
    dbsend
  • Стоимость

    cron + скрипт + S3
    хранилище + ваше время
    dbsend
    от 0 ₽

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

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

Что такое ожидаемый интервал?

Это настройка базы в панели dbsend: как часто должен приходить бэкап. Если очередная версия не появилась вовремя, срабатывает событие «Бэкап не пришёл вовремя», и dbsend отправляет уведомление в подключённые каналы — Telegram или email.

На каком тарифе доступны алерты о пропущенном бэкапе?

Уведомления в Telegram и на email — на тарифах от «Старт». Минимальный ожидаемый интервал: «Бесплатный» — раз в сутки, «Старт» — раз в 6 часов, «Про» — раз в час, «Команда» — раз в 5 минут.

Как часто можно запускать бэкап?

В пределах суточного лимита загрузок: «Бесплатный» — 5, «Старт» — 50, «Про» — 200, «Команда» — 1 000. Если файл не изменился, новая версия не создаётся и лимит версий не расходуется.

Почему cron не запускает dbsend, хотя вручную всё работает?

У cron минимальное окружение: другой PATH, нет переменных из .bashrc, иногда другой пользователь. Укажите полный путь к dbsend и Node.js (или PATH в начале crontab), запускайте задачу от того же пользователя, который выполнял dbsend login, и пишите вывод в лог: >> /var/log/dbsend.log 2>&1.

Можно ли запускать бэкап из GitHub Actions или GitLab CI?

Да. Передайте ключ через секрет в переменной DBSEND_API_KEY — она имеет приоритет над сохранённым ключом. Учтите, что расписание в CI работает по UTC и может задерживаться, поэтому алерт dbsend о пропуске особенно полезен.

Какие базы можно бэкапить по расписанию?

SQLite, DuckDB, plain-дампы PostgreSQL и MySQL/MariaDB, а также любые файлы как generic_file — для них хранятся версии и SHA-256, но без разбора таблиц и diff.

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

Все статьи →

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

Пусть о пропущенном бэкапе вы узнаете первым

Бесплатный тариф: 1 база, 500 МБ и 3 версии, карта не нужна. Алерты в Telegram и на email — с тарифа «Старт».