Бэкап базы бота в Telegram: когда это опасно

Бэкап в чат Telegram удобен, пока в базе нет чужих данных

У владельца бота или небольшого сайта база часто лежит на одном VPS, а копий нет. Платить за облачное хранилище лень, и появляется идея: пусть сервер каждую ночь присылает дамп мне в Telegram. Бесплатно, и файл всегда под рукой.

Проект azerothcore/telegram-automated-db-backup делает ровно это. Данные GitHub на 29.10.2026: лицензия AGPL-3.0, 83 звезды, репозиторий создан в мае 2020 года, последний коммит от 25.10.2026, у проекта два автора, релизов нет, открытых issues нет. Я прочитал README и скрипты. Скрипт я не запускал и в Telegram ничего не отправлял.

Важная деталь про происхождение: проект сделан командой AzerothCore, это открытый эмулятор игрового сервера. В примерах базы называются acore_world и acore_characters. Автор писал под игровые базы, про клиентские данные магазина или клиники он не думал.

Что я нашёл в коде

Основной скрипт bak.py снимает дамп через mysqldump с флагом single-transaction и сразу пропускает его через 7z. Получается архив с шифрованием AES и зашифрованными заголовками, на диск несжатый SQL не попадает. Архив режется на тома по 1400 МБ, потому что Telegram принимает файлы до 2 ГБ (до 4 ГБ с Premium, это написано в FAQ Telegram). Отправка повторяется до 20 раз, скрипт сверяет размер документа и только после этого удаляет файл с диска.

Что бы я проверил перед внедрением.

• Скрипт заходит в Telegram от имени вашего пользовательского аккаунта через pyrogram, бот не используется. Нужны api_id и api_hash, а рядом со скриптом появляется файл сессии. Кто его скопирует с сервера, получит аккаунт со всеми чатами. Бот через облачный Bot API отправляет файлы до 50 МБ, видимо поэтому автор выбрал аккаунт.
• Пароль от базы и пароль архива записаны переменными в самом файле. Пароль архива по умолчанию «db_zipped». Команды уходят в оболочку с паролем в аргументах, то есть пароль может быть виден в списке процессов на время запуска. На сервере я это не проверял.
• СУБД одна: в коде только mysqldump. Для PostgreSQL, SQLite и MongoDB в репозитории ничего нет. Работу с MariaDB я не проверял.
• Запасной скрипт bak-per-table.py устроен хуже: архив делается через zip с паролем в аргументе, таблицы лежат на диске до упаковки без шифрования, отправка идёт без повторов и без проверки. Я бы его не брал.
• Расписание это одна строка cron раз в сутки. Старые копии скрипт не удаляет, они копятся в чате. Сообщения об ошибке он не шлёт, при сбое просто завершается с ошибкой, а архив остаётся на диске.
• Восстановление описано двумя командами в README. Проверки, что копия разворачивается, в проекте нет.

Где так делать нельзя или опасно

Первое ограничение юридическое. Если в базе имена, телефоны, заказы или переписка клиентов, это персональные данные. Часть 5 статьи 18 закона 152-ФЗ не допускает запись, хранение и извлечение персональных данных граждан России с использованием баз за пределами страны, кроме случаев, названных в самой норме. Статья 12 требует, чтобы оператор до начала трансграничной передачи уведомил Роскомнадзор. Я сверил тексты на consultant.ru 29.10.2026, портал показывает редакцию от 26.07.2026 и предупреждает о подготовленных изменениях.

Хранение ли это в смысле части 5 и считается ли отправка в Telegram трансграничной передачей, я не берусь решать. В FAQ Telegram я не нашёл заявления, что файлы лежат в России, и исхожу из того, что нет. Освобождает ли шифрование от этих норм, в тексте статей я не увидел. Это вопрос к юристу. Что бот вообще попадает под закон, я разбирал в статье про 152-ФЗ для чат-ботов.

Второе ограничение про доступ. Если чат общий, файл видит каждый участник. Если это «Избранное», всё держится на одном аккаунте: потеряли телефон, получили блокировку или забыли зайти, и копии пропали. По FAQ Telegram неактивный аккаунт удаляется вместе с медиа после 18 месяцев, срок по умолчанию.

Третье ограничение про правила. В условиях Telegram API запрета хранить там файлы я не нашёл. Там есть требование беречь приватность пользователей, а в пункте 4.2 сказано, что при невыполнении требований в течение 10 дней доступ к API могут отключить. Telegram не обещает работать как сервис резервных копий, и гарантий сохранности файлов я в его FAQ не видел.

Чем заменить

Идею «ночной дамп с уведомлением в Telegram» можно оставить. Сам файл должен уходить в другое место.

Шифрование делайте до отправки, ключ держите отдельно от сервера с базой и от самого скрипта. Копию складывайте в свой S3-совместимый бакет или на второй сервер в России, а в Telegram отправляйте короткое сообщение: копия готова, размер такой-то, контрольная сумма такая-то. Пароли выносите в переменные окружения или в файл с правами только для владельца. Для дампа заведите отдельного пользователя базы с минимальными правами. Храните, например, семь дневных и четыре недельных копии и удаляйте остальные.

Раз в месяц разворачивайте свежую копию на чистой машине и смотрите, открывается ли сайт и видны ли свежие заказы. Как это делать, я описывал в статье про проверку восстановления. Такую связку, с шифрованием, хранением у вас и репетицией восстановления, я настраиваю в рамках DevOps-сопровождения, ориентиры по стоимости есть на странице цен.

Что можно сделать уже сейчас

1. Откройте свою базу и выпишите, какие данные в ней лежат. Если там имена, телефоны или заказы клиентов, в Telegram эти копии не отправляйте, пока не поговорите с юристом.
2. Если данных клиентов нет (тестовый стенд, игровой сервер, справочники), берите скрипт. Сначала замените пароль архива «db_zipped», выведите пароли из файла, ограничьте права на файл сессии и заведите отдельный аккаунт Telegram под копии.
3. Возьмите вчерашний архив и разверните его на пустой машине. Если не получилось, у вас сейчас нет бэкапа, есть файл.
4. Добавьте сообщение о сбое и правило удаления старых копий. Без них скрипт молча остановится, а вы узнаете об этом в день аварии.

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

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

Технически можно, но облачный Bot API принимает от бота файлы до 50 МБ, это указано в FAQ для ботов. Для небольшой базы хватит, вопросы про персональные данные остаются теми же.

Какие СУБД поддерживает проект?

В коде используется mysqldump, то есть MySQL. Для других СУБД я поддержки не нашёл. Для PostgreSQL нужен pg_dump, и скрипт пришлось бы переписывать.

Мешает ли лицензия AGPL-3.0 использовать скрипт в бизнесе?

Я не юрист. Для запуска на своём сервере без изменений проблем я не вижу. Если вы правите код и даёте к нему доступ другим людям по сети, прочитайте условия лицензии до этого.

Коротко о главном

Скрипт делает дамп, шифрует его и проверяет отправку. Слабые места вокруг кода: пароли в файле, доступ к целому аккаунту Telegram, одна СУБД, молчание при сбое и отсутствие проверки восстановления. Если в базе есть данные клиентов, добавляются 152-ФЗ и вопрос, куда именно уходит файл.

Хотите, чтобы копии базы бота или сайта шифровались, ложились к вам в Россию и раз в месяц проверялись на чистой машине? Напишите мне в Telegram слово «РЕЗЕРВ». Посмотрю, как у вас устроена база, соберу схему копий и прогоню восстановление.