😭 Как один rsync положил прод

Иногда прод падает не из-за zero-day, не из-за DDoS и не из-за кривого кода. Иногда его кладет… обычный rsync.

🔖 Сценарий. Есть:

прод-сервер
staging
cron-задача синхронизации
и уверенность «я же сто раз так делал»

Команда выглядела примерно так:

rsync -av --delete /data/ backup@storage:/prod-data/

Или еще лучше:

rsync -av --delete /data/ /mnt/nfs/prod/

Все работало годами. Пока однажды:

/data не примонтировался
NFS отвалился
переменная с путем оказалась пустой
кто-то перепутал source и destination

И rsync честно сделал то, что должен был сделать.

С --delete.

▪️ Почему это происходит. rsync - не "умная синхронизация". Он синхронизирует состояние директорий. Если source пустой - значит, и на destination должно быть пусто. Логика железная.

Особенно опасные кейсы:

▪️ Не примонтированный диск
/data - пустая локальная папка

rsync --delete удаляет все на целевом хранилище.

▪️ Пустая переменная

SRC=""
rsync -av --delete $SRC /backup/

Подставится / или текущая директория. И дальше - лотерея.

▪️ Перепутаны местами аргументы

rsync -av --delete backup:/data/ /data/

Удаляем прод, потому что backup оказался пустым.

▪️ Что происходит в этот момент

inode удаляются
файловая система занята
приложения падают
БД начинают ругаться
контейнеры теряют volume

А вы смотрите на логи и видите, как rsync методично чистит прод.

▪️ Как не повторить

1️⃣ Всегда делайте dry-run

rsync -av --delete --dry-run ...

Если видите тысячи deleting - остановитесь.

2️⃣ Проверяйте, что диск примонтирован (добавляйте это в скрипты)

mountpoint -q /data || exit 1

3️⃣ Используйте защитные опции

--max-delete=100

Если удалений больше - rsync аварийно завершится.

4️⃣ Делайте snapshot перед синхронизацией.
LVM, ZFS, btrfs - спасают карьеры.

5️⃣ Разделяйте роли.
Бэкап не должен иметь права удалять прод-данные.

#linux #rsync