Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
интересно только непонятно зачем, ведь есть btrfs и zfs. поменять файловую систему не сложней чем сделать rsync бекап.
Да, согласен - btrfs и zfs решают эту задачу гораздо лучше на уровне файловой системы.
Но идея была в другом: сделать rollback в условиях, где файловую систему менять нельзя или не хочется (например, уже развернутая система на ext4).
В таких сценариях rsync + hardlink - это попытка приблизиться к поведению снапшотов без изменения инфраструктуры.
Подобных простых и оформленных решений под ext4 найти не удалось, поэтому в итоге и появился этот инструмент.
В статье как раз пытался показать, что это не замена таким решениям, а вариант для более ограниченных условий.
Если файл не изменился, он просто переиспользуется через 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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему rollback на ext4 — боль, и как я решил это через rsync