rsync --delete стёр единственный бэкап. Минута молчания

[asyncmonk]

Сегодня сделал rsync -a --delete с пустого каталога (mount не примонтировался) на сторону с бэкапом. За 4 секунды снёс 60 гигов архивов клиента. Бэкап бэкапа, конечно, не было. Пойду поплачу.

[infern]

Святое правило: --delete всегда с --dry-run сначала, и обязательно проверка mountpoint в скрипте перед запуском. mountpoint -q /mnt/src || exit 1 в начало и такого не случится.

[grumpylurker]

Поэтому бэкапы делаются не rsync --delete, а инструментом со снапшотами. restic/borg/zfs send. Удалённый файл там не исчезает, остаётся в предыдущем снапшоте. rsync --delete это не бэкап, это зеркало, оно по определению повторяет и твои ошибки.

[lorenzinoarq]

Понял, прочувствовал, иду переписывать на restic. Дисковую утилиту с фоторекавери уже запустил, что-то даже находит. Урок на всю жизнь за 60 гигабайт.

[asynclover]

Клиническая картина знакома. Стандартное решение после такого — pre-sync проверка: перед любым rsync --delete монтировать источник и проверять что он не пустой. Скрипт-обёртка в три строки: mount, проверить `[ $(ls -A /source | wc -l) -gt 0 ]`, и только тогда запускать rsync. Если mount не прошёл или директория пустая — exit 1 и алерт. Это ловит ровно тот случай что произошёл у тебя.

[allyssa]

На будущее: restic или borg вместо голого rsync именно потому что у них нет флага --delete как концепции — они хранят снапшоты и старые версии по умолчанию. restic forget --keep-last 7 оставит 7 последних снапшотов и не тронет их даже если источник пустой. Цена — дедупликация и чуть больше места, но зато случайный rm -rf на источнике не убивает историю на реципиенте. rsync это инструмент зеркалирования, а не бэкапа — это важное концептуальное различие которое дорого стоит когда забываешь.

[miagi]

Если данные ещё не перезаписаны физически — есть шанс через photorec или testdisk, особенно если это ext4 и --delete физически не перезаписывал блоки, а только обнулил inode. Команда extundelete --restore-all /dev/sdX иногда вытаскивает файлы если диск не нагружали после удаления. Но это уже в режиме надежды, а не гарантии. Главное сейчас — размонтировать раздел и не писать на него.

[pandas4]

@grumpylurker, плюсую, и добавлю ещё слой: даже restic/borg не спасут, если клиент с правами на запись способен выполнить forget/prune. Репозиторий лучше держать в append-only — rest-server --append-only или объектное хранилище с object-lock. Тогда даже кривой скрипт или скомпрометированный хост физически не сотрёт историю, только допишет. Вот это уже бэкап, а rsync --delete — зеркало, которое честно повторяет и твои ошибки.

[asynclover]

@infern, mountpoint -q обязателен, но он ловит не всё: примонтировалось не то устройство (старый или левый диск) — проверка пройдёт, а источник по сути чужой/пустой. Я кладу в источник sentinel-файл .src_ok и проверяю [ -f /mnt/src/.src_ok ] && mountpoint -q /mnt/src. Два условия отсекают и «не примонтировалось вообще», и «примонтировалось не то».

[roylrs]

По recovery конкретика: раз ты лил с пустого каталога, новых данных rsync не писал — он только удалял, то есть блоки с большой вероятностью ещё не перезаписаны, шанс реальный. Главное прямо сейчас — umount раздела или mount -o remount,ro, не давать туда писать вообще ничего. extundelete/photorec гоняй с другого диска и результат сохраняй на ВНЕШНИЙ носитель: каждая запись на пострадавший раздел снижает шансы вытащить inode.