Комментарии 37
Апстрим не достаточно хорошо написал код для решения ваших бизнес-задач. Да, бывает. Метод исправления? Напишите свой!
Но ваша претензия "сделать снапшот любого блочного устройства" — это overstretch. Смотрите, у вас область вашего интереса "мы же крутая бэкап-компания, все блочные устройства должны уметь делать снапшоты".
А вот у меня другая область видения: вот я собрал рейд из блочных рам-дисков. Он должен уметь делать снапшоты? А вот я по rbd подключил ceph. Он тоже должен давать вам host-level снапшоты? А iscsi устройство? А multipath устройство? А nvme-устройство, подключенное через PCI-E-фабрику?
Если вы потребуете, чтобы любое устройство сделало вам снашпоты, вы, фактически, требуете, чтобы мой nvme делал вам снапшоты. Простите, нет. Я ценю мой nvme за 500к IOPS, и жертвовать парой сотен тысяч IOPS во имя удобства для вашего софта я не хочу.
То же касается loop, rbd, iscsi, ataoe и множества других любопытных блочных устройств.
В принципе да. Написать можно всё что угодно. Но мало написать свой out-of-tree модуль. Чтобы решение работало гарантированно везде — нужно чтобы оно было в upstream. А чтобы добавить что-то в upstream недостаточно просто написать своё.
«А вот у меня другая область видения: вот я собрал рейд из блочных рам-дисков. Он должен уметь делать снапшоты? » — я не вижу в этом проблемы. при подключении фильтра не обязательно просаживать performance. Хотя конечно он просядет во время резервного копирования. И потом, никто не заставляет вас подключать фильтр на ваш nvme. Кому надо — тот подключит. Но мне нужна возможность подключения. Для этого я добавляю проверку, что список фильтров пуст, защищённый percpu_rw_semaphore.
Вы не можете подцепить в fastpath что-то, не просадив производительность. Посмотрите на срач в районе аудита io_uring, где добавление одного if'а (без полезной нагрузки) уронило производительность на 5%.
Чтобы обсуждать это предметно я предлагаю сделать эксперимент. Собрать информацию о производительности на ядре без патча. Потом собрать ядро по тому-же config-у, добавив изменения в ядро, повторить эксперимент. Третий эксперимент — уже с загруженным модулем gbdevflt и добавленным правилом.
Уверен, это будет интересный эксперимент полезный всем, если сделать его чисто.
Дело не в каком-то конкретном бекапном софте, а в отсутствии более лучших вариантов в принципе.
Насколько я знаю, в linux все существенные данные находятся в консистентном состоянии. Файловая система журналированная, СУБД журналированные, файловые менеджеры используют safe transaction c fsync.
В целом, весь софт, которому нужно консистентное состояние, сам использует fsync. fsfreeze даёт вам time consistency (нет новых записей в неожиданных местах), fsync даёт вам гарантию записи (и, насколько я понимаю, fsfreeze уважает in-flight fsync'и).
Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.
Если прочитать метаданные в начале тома, а через пять минут дочитать том до конца по живой машине — то получится фарш. И БД превратиться в тыкву. В общем, без снапшота можно делать резервную копию только неизменяемых данных.
«Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.» — нет, нам не интересен кривой софт. Нас обычно интересуют данные на файловой системе и базы данных популярных СУБД.
С другой стороны, перемещая файл фс будет старательно рапортовать об успешном завершении записи очередного чанка с данными. И чисто технически, если мы прямо сейчас начнём читать блоки, они все будут абсолютно консистентны, а вот сам файл нет.
Ну и самое интересное: если мы говорим про бекап здорового человека (а не пофайловое чтение всех данных), то нас интересует приведение в консистентный вид всего что есть на диске разом, а не беготня между всеми файлами и процессами.
Истории про сервера, которые не могут загрузиться после ребута — тру стори. Но они умирают в биосе (не проходят POST) и к ОС никакого отношения не имеют.
Про порчу файловой системы после unclean shutdown я не слышал уже очень долго. Очень. Последнее было в 2009, и с тех пор прошло уже 12 лет.
Вот что реально может быть — это если у вас в зависимостях systemd написано странное. Да, сервер может бесконечно ждать запуска сервиса (если у него так в [install] написано). Но к файловым системам и бэкапам это никак не относится от слова "совсем".
FSFREEZE(8) System Administration FSFREEZE(8)
NAME
fsfreeze - suspend access to a filesystem (Ext3/4, ReiserFS, JFS, XFS)
SYNOPSIS
fsfreeze --freeze|--unfreeze mountpoint
DESCRIPTION
fsfreeze suspends or resumes access to a filesystem.
fsfreeze halts any new access to the filesystem and creates a stable
image on disk. fsfreeze is intended to be used with hardware RAID de‐
vices that support the creation of snapshots.
fsfreeze is unnecessary for device-mapper devices. The device-mapper
(and LVM) automatically freezes a filesystem on the device when a snap‐
shot creation is requested. For more details see the dmsetup(8) man
page.
The mountpoint argument is the pathname of the directory where the
filesystem is mounted. The filesystem must be mounted to be frozen
(see mount(8)).
Note that access-time updates are also suspended if the filesystem is
mounted with the traditional atime behavior (mount option strictatime,
for more details see mount(8)).
fsfreeze is intended to be used with hardware RAID devices that support the creation of snapshots.
fsfreeze is unnecessary for device-mapper devices. The device-mapper and LVM) automatically freezes a filesystem on the device when a snapshot creation is requested.
Полностью согласен! Вот на все 146%.
Я понимаю, что снепшоты lvm вас не устраивают только потому, что не везде системы на нём настроены.
Использую Veeam Agent for Linux уже не первый год для своих домашних машин (Fedora). Какой был облом после обновления ядра в Fedora до 5.9+, когда перестал работать volume backup. Позиция автора по поводу функционала достаточно мотивированная, на мой взгял, чтобы принять изменения в upstream. Не понятна позиция разработчиков ядра. :(
Команде Veeam большое уважение за годный инструмент работающий "из коробки" без "танцев с бубном" и "напильника".
Приходит новый чел и предлагает то, что им не видится как какая-то реальная и весомая проблема для 99.99% пользователей и систем. И при этом предлагается внедрить что-то достаточно замороченное над целым гигантским зоопарком разновидностей блочных устройств, а не над одним-двумя как у проприетарных ОС.
Так что простите, но нет. Им просто не нужно вот такой пласт ответственности за работу в любых ситуациях предложенного механизма тянуть потенциально. Вы для них человек новый и непонятный - а ну как толкнете коммит в своих интересах и уйдете в закат.
Поэтому, чтобы «не уйти в закат» прям сразу, мне видится задача: поднять актуальность проблемы в глазах майнтейнеров и всего сообщества пользователей Linux. Если будут положительные отзывы о патче со стороны разных людей (разных компаний), и они подтвердят необходимость такого фильтра в их работе — то шанс попасть в ядро резко возрастает. Нужно изметить статус проблемы от «патч какого-то выскочки» в «реально нужная фича».
Я готовлю RFC, чтобы обсудить это в upstream перед запуском самого патча. Есть ещё вариант написать статью в lwn. Но для начала решил сделать статью для Хабра.
А тут приходит какой-то новый чел и предлагает какие-то невнятные патчи
ИМХО стоит начать с хорошей презентации себя (скорее компании) и решаемой проблемы, это сильно увеличивает доверие.
P. S. по ссылкам не ходил, может быть всё это уже было.
vSphere и Hyper-V молодцы. Можно снять снапшот с виртуальной машины. Можно получить change-tracking, то есть узнать заранее, какие блоки на дисках машины действительно изменились, а какие можно и не читать.
Нет, Hyper-V не молодцы. Resilient Change Tracking написан через жопу, он чересчур "resilient" и использовать его для систем требовательных к IO категорически нельзя.
Еще попадались скрипты для LVM разной степени заборошенности, вдруг есть что-то похожее?
github.com/tasket/wyng-backup
для LVM-Thin
github.com/mpalmer/lvmsync
для классических LVM snapshot
github.com/datto/dattobd
драйвер ядра Linux
Если система на KVM — уже было объявлено что Veeam поддержит KVM (в составе RHEL). Мне тут подсказывают что CBT там есть, так что должны быть нормальные инкременты.
Зачем бэкапить ос?
Зачем бэкапить конфиги, которые не должны меняться? (Держите их в git)
Не нужно бэкапить СУБД через снапшоты фс, для этого есть средства СУБД.
Зачем бэкапить то, у чего аптайм несколько лет, сменилось пару админов, конфиги уже не те с чем сейчас работает и оно гарантировано не запустится?
Бэкапить нужно с умом, с БД ничего лучше чем сама СУБД не снимет бэкап, конфиги хранить в git и накатывать каким-нибудь ansible...
Чтобы если оно гавкнет, иметь возможность БЫСТРО возвратить систему к рабочему состоянию. А если у вас навернулся тот самый гит с конфигами? И тому подобные проблемы, вплоть до пожара в ДЦ, где оффлайн-бэкапы не выживают. По-ВМный подъем в среднем обгоняет подъем в виде развертываний по скорости, включая миграцию в другой ДЦ, особенно для какого-то легаси, от которого уже и админов не осталось.
Резервная копия всей системы целиком позволяет сделать восстановление в один клик. Когда приходим момент «Х» и «криптодемон» пожирает инфраструктуру нет времени на разворачивание ОС, наката конфигов из git, и восстановление базы.
Нужна кнопка «Сделать хорошо», а точнее откатить нужные машины или даже всю инфраструктуру на нужную дату. Ключевой параметр для бизнеса — время восстановления. Этот параметр мы стараемся минимизировать.
Бэкапить данные - это задача, перпендикулярная бэкапу инфраструктуры.
Поднять всю систему с сервисом и данными на порядок быстрее, чем делать развёртывание новой. И дешевле - виртуалку поднимет дежурный диспетчер, а только из данных развернуть может только овнер сервиса, а он в данный момент может просто спать или лететь 12 часов в Сингапур
Интересные темы поднрмаете, но читать невозможно. Флэшбэки "соло на клавиатуре": Одно предложение по теме, пять какой то ерунды про админа.
Дочитать не смог, простите. Может вам в квн?)
Вся статья ради этого предложения:
Кому интересно взглянуть, мой репозиторий тут. Ветка на базе ядра 5.12 здесь. Для 5.13 тоже есть ветка.
Так что дочитывать необязательно, можно сразу смотреть код. Найдёте баг — заводите issue, ну или сразу pull request.
В статье я старался в простой и доступной большинству форме обозначить проблему, которую я пытаюсь решить. Может кто-то тоже столкнулся с этой проблемой и ищет решение. Могли бы объединить усилия.
Шутки про сисадмина — чтобы читалось легче и создавало позитивный эмоциональный фон. Возможно, вы не поняли шутки про разные шляпы и шапочки? Это нормально.
Может вам в квн?)— извините, даже не смотрю уже лет пятнадцать. Не смешно.
Это будет модуль для фильтрации блоков ввода/вывода (bio). Он позволит сделать какую-то область диска недоступной для перезаписи или ограничить доступ к блочному устройству каким-то конкретным модулем или подсистемой ядра.
а что дальше? просто замораживаем io? чем это тогда лучше fsfreeze?
Это будет модуль для фильтрации блоков ввода/вывода (bio).
Нет, конечно этот модуль фильтрации не решает проблему со снапшотами. Его назначение в другом. Он позволяет заблокировать доступ к каким-то областям диска. Например запретить на запись сектора, содержащие таблицу разделов. Или запретить доступ к разделу, за исключением какого-то процесса или модуля ядра. Это может быть очень полезно для баз данных.
Просто при добавлении такого модуля в upstream появляются и функции для подключения и отключения фильтров, а значит подключаться смогут и out-of-tree модули, так-же как это было до ядра 5.8.
Добавление модуля для создания снапшотов может быть следующим шагом. Но тут проблема в том, что в ядре уже есть dm-snap, а майнтейнеры не любят дубликатов. Я пробовал работать с Майком, майнтейнером DM, который работает в Red Hat. Скажем так, у меня не особо что получилось. Я полагаю что для Майка больше важна стабильность работы существующего кода, а не расширение его функционала, что вполне понятно.
Linux kernel: просто снять снапшот не просто