Comments 17
интересно только непонятно зачем, ведь есть btrfs и zfs. поменять файловую систему не сложней чем сделать rsync бекап.
Да, согласен - btrfs и zfs решают эту задачу гораздо лучше на уровне файловой системы.
Но идея была в другом: сделать rollback в условиях, где файловую систему менять нельзя или не хочется (например, уже развернутая система на ext4).
В таких сценариях rsync + hardlink - это попытка приблизиться к поведению снапшотов без изменения инфраструктуры.
Подобных простых и оформленных решений под ext4 найти не удалось, поэтому в итоге и появился этот инструмент.
В статье как раз пытался показать, что это не замена таким решениям, а вариант для более ограниченных условий.
ясно
где файловую систему менять нельзя или не хочется (например, уже развернутая система на ext4).
Самое сложное в замене rootfs на btrfs -- это пересобрать initramfs и переустановить модули для grub с поддержкой оной. Делается через chroot, после физического копирования файлов с ext4 на btrfs -- 1 раз.
Того же не могу сказать про OpenZFS, она со своими заморочками (груб поддерживает только старую версию дискового формата, маунт её в рутфс надо делать в явном виде в initramfs etc.) и тормознутостью (сильно медленнее при начальной загрузке, когда кеши не прогреты) явно не очень подходит для rootfs.
Согласен, при наличии опыта это вполне рабочий путь, особенно если не пугают моменты с initramfs, grub и chroot.
Но у меня изначально был чуть другой фокус.
Я рассматривал сценарий, где миграция файловой системы сама по себе не входит в задачу - либо из-за ограничений, либо просто потому, что хочется минимальных изменений в уже работающей системе.
Плюс в реальной эксплуатации всплывают дополнительные нюансы:
Тот же Docker может начать работать через другой storage driver;
Активные сервисы (БД, очереди) требуют аккуратной остановки;
Изменения в загрузке - это отдельная зона риска.
Поэтому я пошёл от обратного: не менять базовую ФС, а собрать поведение rollback поверх ext4.
То есть здесь скорее вопрос не “можно или нельзя перейти на btrfs”, а “нужно ли это в конкретном случае”.
При этом сам подход с переходом на btrfs - абсолютно нормальный и логичный, если он изначально вписывается в задачу.
Если файл не изменился, он просто переиспользуется через hardlink. Если изменился — создаётся новая физическая копия.
В какой момент создаётся новая физическая копия?
Новая физическая копия создаётся в момент выполнения rsync.
rsync сравнивает текущее состояние файлов с предыдущим snapshot через --link-dest. Если файл считается неизменённым, он переиспользуется через hardlink.
Если файл отличается, rsync записывает новую физическую копию в директорию текущего снапшота.
То есть решение принимается на этапе синхронизации: нет изменений - hardlink, есть изменения - новая запись на диск.
Не понял. С чем сравнивает rsync, какое предыдущее состояние? По порядку:
Создали файл, сделали на него хардлинк, изменили файл. Где предыдущее состояние? Как понять, что файл изменился?
Сравнение идёт не “по порядку изменений”, а между двумя состояниями:
Текущей файловой системой (SRC)
Предыдущим snapshot (через --link-dest)
Каждый snapshot - это отдельная директория и фиксирует состояние файлов на момент её создания.
Дальше происходит следующее:
Если файл в текущей системе не изменился относительно предыдущего snapshot, rsync создаёт hardlink на файл из snapshot (оба указывают на один и тот же inode)
Если файл изменился, rsync записывает новую физическую копию уже в новый snapshot (с новым inode)
Snapshot’ы после создания не меняются. Изменения происходят только в текущей системе (SRC), а не в уже созданных snapshot’ах.
Поэтому “предыдущее состояние” - это просто файл в предыдущем snapshot, который остаётся неизменным.
Чем отличается от rsnapshot?
Наличием restore?
По механике - да, идея та же: rsync + hardlink, как и в rsnapshot.
И частично пересечение есть - у меня тоже хранится история и можно запускать по расписанию. Но отличается основной сценарий использования.
rsnapshot - это прежде всего backup-инструмент: хранение данных и их историй.
Здесь же акцент на rollback - быстрый и предсказуемый возврат системы в предыдущее состояние.
Поэтому: restore - центральная операция (с dry-run перед применением), работа идёт именно с состоянием системы (system/docker), нет цели строить полноценную backup-систему с ретеншеном и архивом
То есть механика похожая, но фокус разный: backup vs rollback.
А разве timeshift не основан на том же принципе Hardlink ?
Да, в rsync-режиме timeshift использует тот же механизм: rsync + hardlink. Так что основной принцип тот же.
Пересечение тоже есть - хранение истории, запуск по расписанию.
Но отличается основной сценарий:
Timeshift - это в первую очередь system snapshot “целиком”, с минимальной настройкой.
У меня же упор на rollback и контроль:
Можно выбирать, что именно снапшотить (весь /, только /home и т.д.).
Есть разделение зон (system / docker).
Есть исключения (пока задаются в коде, без вынесения в конфиг).
То есть механика похожая, но фокус другой:
Не просто snapshot системы, а управляемый и точечный rollback.
Да, спасибо за ссылку - ccollect из той же категории, что и rsnapshot. Он использует ту же идею: rsync + hardlink для инкрементальных snapshot’ов.
У меня подход похож по механике, но отличается по сценарию использования.
Ccollect - это прежде всего backup-инструмент: хранение истории, ротация snapshot’ов, часто работа с несколькими хостами.
В моём случае акцент на rollback: быстро и предсказуемо вернуть локальную систему в предыдущее состояние.
Поэтому в моём решении:
Restore оформлен как отдельная операция (с обязательным dry-run)
Есть явное разделение system и docker
Можно гибко управлять тем, что именно snapshot’ить и восстанавливать
То есть идеи похожие, но модель применения разная: backup vs rollback.
В целом это уже не первый похожий инструмент, который всплывает в обсуждении - различие в основном именно в фокусе использования.
Почему rollback на ext4 — боль, и как я решил это через rsync