Как стать автором
Обновить

Комментарии 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%.

Я, конечно, проверил своё решение с помощью perf. Я увидел цифры порядка десятой доли процента.
Чтобы обсуждать это предметно я предлагаю сделать эксперимент. Собрать информацию о производительности на ядре без патча. Потом собрать ядро по тому-же config-у, добавив изменения в ядро, повторить эксперимент. Третий эксперимент — уже с загруженным модулем gbdevflt и добавленным правилом.
Уверен, это будет интересный эксперимент полезный всем, если сделать его чисто.
Иопсы это очень хорошо, но как предлагается приводить хранящиеся данные к консистентному виду перед их копированием?
Дело не в каком-то конкретном бекапном софте, а в отсутствии более лучших вариантов в принципе.

Насколько я знаю, в linux все существенные данные находятся в консистентном состоянии. Файловая система журналированная, СУБД журналированные, файловые менеджеры используют safe transaction c fsync.


В целом, весь софт, которому нужно консистентное состояние, сам использует fsync. fsfreeze даёт вам time consistency (нет новых записей в неожиданных местах), fsync даёт вам гарантию записи (и, насколько я понимаю, fsfreeze уважает in-flight fsync'и).


Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.

Всё так, файловая система действительно журналируемая и fsfreeze даёт консистентное состояние, но только в том случае если после fsfreeze не поступают никакие запросы на запись.
Если прочитать метаданные в начале тома, а через пять минут дочитать том до конца по живой машине — то получится фарш. И БД превратиться в тыкву. В общем, без снапшота можно делать резервную копию только неизменяемых данных.

«Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.» — нет, нам не интересен кривой софт. Нас обычно интересуют данные на файловой системе и базы данных популярных СУБД.

Вся суть fsfreeze, что у вас не поступают запросы за запись. Любой запрос на запись ставит процесс в ожидание и он перестаёт "варить".


Как раз "тыкву" от записей во время чтения данных для бэкапа fsfeeze и предупреждает.

Всё вокруг уже давно журналируемое, с этим не поспоришь. Правда это совершенно не мешает продолжать читать весёлые истории про то, как свет мигнул и супер-журналируемый сервер не может загрузиться. Да, журналы свели к минимуму вероятность потери данных, но не исключили её полностью.

С другой стороны, перемещая файл фс будет старательно рапортовать об успешном завершении записи очередного чанка с данными. И чисто технически, если мы прямо сейчас начнём читать блоки, они все будут абсолютно консистентны, а вот сам файл нет.

Ну и самое интересное: если мы говорим про бекап здорового человека (а не пофайловое чтение всех данных), то нас интересует приведение в консистентный вид всего что есть на диске разом, а не беготня между всеми файлами и процессами.

Истории про сервера, которые не могут загрузиться после ребута — тру стори. Но они умирают в биосе (не проходят 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 вас не устраивают только потому, что не везде системы на нём настроены.

1. они не везде есть.
2. свободного места для diff area нет.
3. нет change-tracking-а.

Использую Veeam Agent for Linux уже не первый год для своих домашних машин (Fedora). Какой был облом после обновления ядра в Fedora до 5.9+, когда перестал работать volume backup. Позиция автора по поводу функционала достаточно мотивированная, на мой взгял, чтобы принять изменения в upstream. Не понятна позиция разработчиков ядра. :(


Команде Veeam большое уважение за годный инструмент работающий "из коробки" без "танцев с бубном" и "напильника".

" Не понятна позиция разработчиков ядра. :(" Дело в том что не так то просто осознать проблему. Всё работает, идёт битва на скорость на NVMe. А тут приходит какой-то новый чел и предлагает какие-то невнятные патчи. А на фоне скандала с Массачусецским Универом, вообще три раза подумаешь прежде чем что-то читать от непроверенного человека. Так что я их уже начинаю понимать. То что они делают это круто, но я продолжу свои попытке сделать ядро ещё лучше.

Приходит новый чел и предлагает то, что им не видится как какая-то реальная и весомая проблема для 99.99% пользователей и систем. И при этом предлагается внедрить что-то достаточно замороченное над целым гигантским зоопарком разновидностей блочных устройств, а не над одним-двумя как у проприетарных ОС.

Так что простите, но нет. Им просто не нужно вот такой пласт ответственности за работу в любых ситуациях предложенного механизма тянуть потенциально. Вы для них человек новый и непонятный - а ну как толкнете коммит в своих интересах и уйдете в закат.

Как это ни прискорбно, да.

Поэтому, чтобы «не уйти в закат» прям сразу, мне видится задача: поднять актуальность проблемы в глазах майнтейнеров и всего сообщества пользователей Linux. Если будут положительные отзывы о патче со стороны разных людей (разных компаний), и они подтвердят необходимость такого фильтра в их работе — то шанс попасть в ядро резко возрастает. Нужно изметить статус проблемы от «патч какого-то выскочки» в «реально нужная фича».

Я готовлю RFC, чтобы обсудить это в upstream перед запуском самого патча. Есть ещё вариант написать статью в lwn. Но для начала решил сделать статью для Хабра.
А тут приходит какой-то новый чел и предлагает какие-то невнятные патчи

ИМХО стоит начать с хорошей презентации себя (скорее компании) и решаемой проблемы, это сильно увеличивает доверие.


P. S. по ссылкам не ходил, может быть всё это уже было.

«one-to-one copy of an existing, read-only source device into a writable destination device» Подходит для рестора, но не для создания резервной копии.

vSphere и Hyper-V молодцы. Можно снять снапшот с виртуальной машины. Можно получить change-tracking, то есть узнать заранее, какие блоки на дисках машины действительно изменились, а какие можно и не читать.

Нет, Hyper-V не молодцы. Resilient Change Tracking написан через жопу, он чересчур "resilient" и использовать его для систем требовательных к IO категорически нельзя.

А какие сейчас есть готовые способы бэкапа с change-tracking? Под KVM/qemu или для блочных устройств Linux — неважно, лишь бы работало. Знаю про Proxmox Backup Server, но он вроде требует, чтобы виртуальные машины были под Proxmox.

Еще попадались скрипты для LVM разной степени заборошенности, вдруг есть что-то похожее?
github.com/tasket/wyng-backup
для LVM-Thin
github.com/mpalmer/lvmsync
для классических LVM snapshot
github.com/datto/dattobd
драйвер ядра Linux
Долго думал как ответить. VBR для машин на ESX и Hyper-V (ещё Nutanix AHV) повезёт Linux со снапшотами и change-tracking. Там снапшоты и CBT реализуются гипервизором. Если физическая тачка (или иной гипервизор) в которой ядро до 5.8 советую Veeam Agent for Linux. Там снапшот и CBT с помощью модуля. dattobd и его форки используют несколько разных вендоров. Там есть инкрементальный бэкап, читайте как это работает тут. У других вендоров тоже, если заявлен инкрементальный или дифференциальный бэкап, то скорее всего перезачитывает он только дифференс (уточните сами).
Если система на KVM — уже было объявлено что Veeam поддержит KVM (в составе RHEL). Мне тут подсказывают что CBT там есть, так что должны быть нормальные инкременты.

Зачем бэкапить ос?
Зачем бэкапить конфиги, которые не должны меняться? (Держите их в git)
Не нужно бэкапить СУБД через снапшоты фс, для этого есть средства СУБД.
Зачем бэкапить то, у чего аптайм несколько лет, сменилось пару админов, конфиги уже не те с чем сейчас работает и оно гарантировано не запустится?

Бэкапить нужно с умом, с БД ничего лучше чем сама СУБД не снимет бэкап, конфиги хранить в git и накатывать каким-нибудь ansible...

Чтобы если оно гавкнет, иметь возможность БЫСТРО возвратить систему к рабочему состоянию. А если у вас навернулся тот самый гит с конфигами? И тому подобные проблемы, вплоть до пожара в ДЦ, где оффлайн-бэкапы не выживают. По-ВМный подъем в среднем обгоняет подъем в виде развертываний по скорости, включая миграцию в другой ДЦ, особенно для какого-то легаси, от которого уже и админов не осталось.

Довольно популярная точка зрения. Я же просил " Комментарии на тему «А я вот логи базы экспортирую и с помощью rsync тащу файлики» тоже не интересны, так как я рассматриваю резервную копию всей системы целиком, а не какую-то её часть."
Резервная копия всей системы целиком позволяет сделать восстановление в один клик. Когда приходим момент «Х» и «криптодемон» пожирает инфраструктуру нет времени на разворачивание ОС, наката конфигов из git, и восстановление базы.
Нужна кнопка «Сделать хорошо», а точнее откатить нужные машины или даже всю инфраструктуру на нужную дату. Ключевой параметр для бизнеса — время восстановления. Этот параметр мы стараемся минимизировать.

Бэкапить данные - это задача, перпендикулярная бэкапу инфраструктуры.

Поднять всю систему с сервисом и данными на порядок быстрее, чем делать развёртывание новой. И дешевле - виртуалку поднимет дежурный диспетчер, а только из данных развернуть может только овнер сервиса, а он в данный момент может просто спать или лететь 12 часов в Сингапур

Интересные темы поднрмаете, но читать невозможно. Флэшбэки "соло на клавиатуре": Одно предложение по теме, пять какой то ерунды про админа.

Дочитать не смог, простите. Может вам в квн?)

Я, как-то, если честно, рассчитывал на какой-нибудь feedback по коду.
Вся статья ради этого предложения:
Кому интересно взглянуть, мой репозиторий тут. Ветка на базе ядра 5.12 здесь. Для 5.13 тоже есть ветка.

Так что дочитывать необязательно, можно сразу смотреть код. Найдёте баг — заводите issue, ну или сразу pull request.

В статье я старался в простой и доступной большинству форме обозначить проблему, которую я пытаюсь решить. Может кто-то тоже столкнулся с этой проблемой и ищет решение. Могли бы объединить усилия.

Шутки про сисадмина — чтобы читалось легче и создавало позитивный эмоциональный фон. Возможно, вы не поняли шутки про разные шляпы и шапочки? Это нормально.
Может вам в квн?)
— извините, даже не смотрю уже лет пятнадцать. Не смешно.
Мне было интересно именно почитать проблемы, с которыми вы столкнулись, как предлагаете решать. Но читать про админов невозможно.

> Шутки про сисадмина — чтобы читалось легче
> Может вам в квн?)
> Не смешно.

Так а я о чем? :)
Это будет модуль для фильтрации блоков ввода/вывода (bio). Он позволит сделать какую-то область диска недоступной для перезаписи или ограничить доступ к блочному устройству каким-то конкретным модулем или подсистемой ядра.

а что дальше? просто замораживаем io? чем это тогда лучше fsfreeze?

Это будет модуль для фильтрации блоков ввода/вывода (bio).

Нет, конечно этот модуль фильтрации не решает проблему со снапшотами. Его назначение в другом. Он позволяет заблокировать доступ к каким-то областям диска. Например запретить на запись сектора, содержащие таблицу разделов. Или запретить доступ к разделу, за исключением какого-то процесса или модуля ядра. Это может быть очень полезно для баз данных.

Просто при добавлении такого модуля в upstream появляются и функции для подключения и отключения фильтров, а значит подключаться смогут и out-of-tree модули, так-же как это было до ядра 5.8.
Добавление модуля для создания снапшотов может быть следующим шагом. Но тут проблема в том, что в ядре уже есть dm-snap, а майнтейнеры не любят дубликатов. Я пробовал работать с Майком, майнтейнером DM, который работает в Red Hat. Скажем так, у меня не особо что получилось. Я полагаю что для Майка больше важна стабильность работы существующего кода, а не расширение его функционала, что вполне понятно.

ну так повторюсь, надо начинать с презентации: кто вы (необязательно лично, можно и компания), какую задачу решаете, почему она важна пользователям, почему она не решается текущими инструментами.
если будет согласие в том, что задачу надо решать, можно уже обсуждать детали реализации

Логично. Так и сделаем.
Готовим RFC с описанием проблемы и вариантами решения.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.