Бэкап есть — а восстановить нечем: всё на том же диске
Cron каждую ночь дампит базу — и в пятницу диск под 97%. Бэкап есть, но он на том же разделе, что MySQL, логи и upload. При сбое теряете и прод, и «спасательный круг» одновременно.
Три ловушки, которые видим часто
- Нет retention — каждый день новый
.sql.gz, старые не удаляются. - Два скрипта в один каталог — ручной дамп + Bitrix + хостинг пишут в
/var/backups. - «Бэкап на VPS» = папка
/home/backupна том же 40 ГБ SSD, что и корень/.
Проверка за 10 минут
# 1. Свободное место по разделам
df -h
# 2. Где лежат тяжёлые архивы
du -sh /var/backups /backup /home/*/backup 2>/dev/null
find / -xdev -type f \( -name '*.sql.gz' -o -name '*.tar.gz' \) -size +100M 2>/dev/null | head -20
# 3. Один mount или разные?
# бэкапы должны быть НЕ на том же разделе, что / или /var
# 4. Retention — есть ли старые файлы?
ls -lt /var/backups | head -10
find /var/backups -name '*.sql.gz' -mtime +14 -ls 2>/dev/null | head -5
Если сотни файлов и самому старому больше года — retention не настроен.
Минимум, который реально работает
- Off-site — другой volume, S3-совместимое хранилище или второй VPS.
- Retention — хотя бы «хранить 14 последних daily» или 7 daily + 4 weekly.
- Тест восстановления — файл на диске ≠ рабочий бэкап, пока не подняли копию на тесте.
- Алерт на 80% диска — до того, как MySQL перестанет писать.
Покупка «+20 ГБ» без поиска причины часто откладывает проблему на месяц — cron продолжит забивать диск.
Честно про Mediops
Mediops не хранит ваши бэкапы — зато пришлёт письмо, когда диск на VDS подходит к порогу. На бесплатном: 1 сервер, 3 сайта, email-алерты.
Узнайте о диске до 100%
Порог 80% — время спокойно перенести дампы и настроить retention.