🗂 Бэкапы VPS: что, как и когда

Версия 1.1 | 12 сентября 2026

Полное описание системы резервного копирования сервера 193.32.179.138: расписание, состав копий, обработка ошибок, статус в Telegram-боте и восстановление. Предыдущая версия скрипта сохранена на сервере как /opt/scripts/backup.sh.v1-20260912.

🕐 Кто, когда и куда

📦 Что попадает в копию

🧠 Ключевые решения скрипта

• Сначала mysqldump, потом tar. Копировать файлы работающей InnoDB-базы tar'ом «на горячую» — лотерея: такая копия может не восстановиться. Скрипт делает дамп через docker exec с паролем из переменных контейнера (пароль нигде не хранится в скрипте), и только при успехе исключает сырые файлы БД из projects-архива;
• Запасной вариант: если mysqldump не удался, «горячие» файлы БД включаются в архив — лучше рискованная копия, чем никакой. Событие помечается в журнале и в статусе;
• Ошибки не глушатся: ушли 2>/dev/null из старой версии (из-за них проблема с 3x-ui месяцами была бы невидимой). Каждая операция логируется и увеличивает счётчик ошибок;
• Retention 3 дня вместо 7: занято ~5 GB вместо ~11 GB. При желании изменить — переменная RETENTION_DAYS в начале скрипта;
• Итог в файле статуса — по нему Telegram-бот показывает свежесть бэкапа (см. ниже).

📬 Статус бэкапа в Telegram

В конце каждого запуска скрипт пишет одну строку в /opt/backups/.last-status:

OK|12.09.2026 20:31|1.3G|1
│        │             │    └─ mysqldump прошёл (1) или нет (0)
│        │             └────── размер копии
│        └──────────────────── время (МСК)
└───────────────────────────── OK или "ПРОБЛЕМЫ (N)"
        

Отчёт /status бота теперь содержит строку бэкапа:

🖥 VPS 193.32.179.138
💾 Диск: 66% занято, свободно 12.7 GB
🧠 RAM: 64% занято
⚡ CPU: 41% · load 1m: 0.96
⏱ Аптайм: 42 дн
🗂 Бэкап: OK, 1.3G, 12.09.2026 20:31 МСК
🛡 Алерты: 1 (disk_space_usage — WARNING)
        

Если копии нет дольше 30 часов (ночной запуск не состоялся), бот сообщит ⚠️ нет свежей копии (N ч назад) — это ранний сигнал, что cron или скрипт сломались.

🔍 Как проверить

# Ручной запуск (создаст копию прямо сейчас; retention почистит старые)
/opt/scripts/backup.sh

# Хвост журнала
tail -20 /var/log/backup.log

# Состав последней копии и статус
ls -lh /opt/backups/$(ls -t /opt/backups | grep ^20 | head -1)/
cat /opt/backups/.last-status

# Убедиться, что дамп не пустой и читается
D=$(ls -t /opt/backups | grep ^20 | head -1)
zcat /opt/backups/$D/mysqldump-all.sql.gz | head -5
tar -tzf /opt/backups/$D/3x-ui-backup.tar.gz
        

♻️ Восстановление (кратко)

# База MySQL (в пустой/запущенный контейнер mylife-common-db)
gunzip < mysqldump-all.sql.gz | docker exec -i mylife-common-db \
  sh -c 'mysql -uroot -p"$MYSQL_ROOT_PASSWORD"'

# Файлы проектов, конфиги, 3x-ui, мониторинг — распаковать на место
tar -xzf projects-backup.tar.gz -C /            # восстановит /opt/projects/...
tar -xzf npm-backup.tar.gz -C /
tar -xzf 3x-ui-backup.tar.gz -C /
tar -xzf monitoring-backup.tar.gz -C /

# После восстановления контейнеров — перезапустить
cd /opt/infrastructure && docker compose -f docker-compose.yml up -d
        

⚠️ Ограничения и что дальше

• Всё хранится на том же сервере. Гибель VPS означает потерю данных вместе с бэкапами. Рекомендуемый следующий шаг — выгрузка одной копии наружу (S3-совместимое хранилище, Яндекс.Диск, второй сервер) раз в сутки; объём ~1.3 GB это позволяет;
• дамп — логический: восстановление идёт медленнее копирования файлов, зато копия гарантированно консистентна и переносима между версиями MySQL;
• базы в Docker-томах, не подключённых к /opt (mysql-логи, npm-кэши), не бэкапятся — они не содержат ценных данных;
• журнал /var/log/backup.log не ротируется — при желании добавить в /etc/logrotate.d.

📜 История изменений

🎉 Готово. Документ обновляйте при изменении состава бэкапов.