Бэкап есть — а восстановить нечем: всё на том же диске

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.