Думаю что у 99% пользователей такого точно нет. А 90% всего 1 ups и в лучем случае в который подключены оба блока питания сервера.

мне нравятся железки типа AP7723 в дополнение к двум бесперебойникам ...

Это решение с проблемой переключения, если сервер не нагружен, то пройдет без сбоев, а если нагружен , тогда конденсаторы в БП разрядятся и сервер перегрущиться при переключение. Лучше еще не придумали, чем 2 online ups подключенные к разным вводам + каждый БП сервера в свой UPS .

Это решение с проблемой переключения, если сервер не нагружен, то пройдет без сбоев, а если нагружен , тогда конденсаторы в БП разрядятся и сервер перегрущиться при переключение. Лучше еще не придумали, чем 2 online ups подключенные к разным вводам + каждый БП сервера в свой UPS .

Генератор с автозапуском ? ))

И регулярным обслуживанием, а то в нужный момент он или не завелся или солярка закончилась.

Нельзя, так как это делается на свой страх и риск. Если свет пропадет, то и пропадут данные в памяти, которая использовалась для расширения пула, а вставить доп диск в сервер не у всех есть возможность.

я предлагал конструктивно общаться.

Я делаю много снимков и также планово старые удаляю. Глобальных проблем не ощущаю

Так было и у меня. Значит не достаточно много. Если уверен - сделай 10 в минуту на протяжении минут 5 и потом их потри. Что будет если закончится место? Уверен на 100%?

Если это 100% воспроизводится. Собирайте с дебагом и демонстрируете для ишью

Все есть. Баг 5 лет висит

Так обнови для свежей версии опензфс.

Зачем. Он открытый висит

Так было и у меня. Значит не достаточно много. Если уверен - сделай 10 в минуту на протяжении минут 5 и потом их потри. Что будет если закончится место? Уверен на 100%?

у меня в среднем 90 снимков на вм. проблем нет, брат пул жив.

у меня в среднем 90 снимков на вм. проблем нет, брат пул жив.

У тебя умвр. У мне нет плюс подтвержденный баг в опене. Может сравним сколько такого в мдадм например или в xfs? В том и смысл, что чем проще тем надёжнее, хоть какой там у нее алгоритм. Один реальный баг перекрывает миллион хороших кейсов. Это фс, а не калькулятор.

Когда на поставленный вопрос по делу мне говорят, что я тупой, а потом объявляют мне ро - это конструктив? Или хи-хи хаха - есть только наше мнение, а другое подкреплённое реальным опытом не может быть верным ибо оно показывает неприятную картину? Это мы и увидели. Достаточно ли конструктивным будет сказать, что история с выделенным местом - ерунда. В файловой системе все функции должны защищать себя от выхода ее из строя. Они и есть в zfs. Только в моем случае, если имело место обход проверок, то оно просто не справилось, потому что код дырявый и это негодящееся для прода поделие(с моей ТЗ). Как убить zfs? Делайте много снапшотов и оно умрет рано или поздно, а может и нет))) идеальная фс для прода. Единственный плюс в моем кейсе - данные не потерялись.

Нельзя, так как это делается на свой страх и риск. Если свет пропадет, то и пропадут данные в памяти, которая использовалась для расширения пула, а вставить доп диск в сервер не у всех есть возможность.

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

Ну так РМ РФ тоже можно неправильно использовать

Согласен, никто не застрахован, все помнят как HPE латала свои схд в которых при наступлении некоторых событиях была полная потеря данных и это в линейках схд для кровавого энтерпрайза

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

Когда это инструкция, тот многие воспринимают это за золотую пулю и применяют, а потом это вливается в неготив, мол делал по инструкции, а данные потерял.

Не везде делают защиту от дурака

Всем привет. Отправили до вас уточнить один момент, а то гугл меня немного запутал. Дано truenas core, который на freebsd. Я - ни разу не админ, просто опытный пользователь. Пул дата и пул бэкап. Между дата и бэкап медленный интернет. Суть вопроса. Сами данные (файлы/каталоги) идентичны на 99%. Если создать снапшот дата и снапшот бэкап, есть ли механизмы для их сравнения, чтоб если запустить репликацию с дата в бэкап не обнулился бэкап и не началась передача данных с нуля ?

ПО тому, что любые изменения записываются в журнал транзакций пула, для этого нужно свободное место, которого не было в пуле, по этому он и не может произвести изменения. ZFS это как БД, которая ведет журнал всех транзакций, и без свободного места для записи данного журнала не может работать. Тут только изучать матчасть, как это делают DBA для управления БД, в нашем случае ZFS и планировать ее работу. А уж если поленился это сделать, то уже не наговаривать, а изучать пост фактум и исправлять свои ошибки, в данном случае просто добавить диск в пул zfs и за счет него произвести удаление ненужных снепшотов, а потом удалить добавленный диск. PS: Я тоже попадал в такую ситуацию, когда разрешил разработчикам создавать снепшоты ВМ, они мне весь пул ими забили. Пришлось на свой страх и риск сделать файл в памяти /dev/shm и добавить его как диск, а потом удалить все снепшоты и после этого удалить добавленный диск(файл) из пула. Предварительно я провел эксперимент на в тестовой среде, и выработал последовательность действий которую мне нужно произвести на 100% забитом пуле. На все у меня ушло 4 часа, с гуглением, чтением документации и изучением истории этого чата.

по сути да, данные в дата и бэкап, но без снапшотов изначальных.

Спасибо. Уже понял ) пришел к выводу что в своем домашнем зоопарке буду миксовать. На локальном уровне снапшотами, а через инет бэкап буду юзать rsync. И тогда такой вопрос, в двух словах на пальцах объясните (ингда не понятен смысл гуглопереводчика, а документация вся на англ) как правильно действовать в такой ситуации: дано: задание снимков по расписанию, задание репликации по расписанию Были снимки 1,2,3,4,5, репликация прошла тоже по всем пяти снимкам. И тут я откатился на снимок 2. Репликация встала с ошибкой. ка правильно сделать, чтоб репликация снова заработала ? потренируюсь в песочнице.

ага

Всем привет. Вопрос: а что будет с первым снимком через две недели ? У меня создано задание каждые 3 часа делать снапшот датасета. Время жизни снимков 2 недели. По этому заданию работает репликация в бэкап. Время жизни рерлицированных снимков также как и у оригинала. Так вот , а смогу ли я, например через полгода, откатиться в нулевое состояние ? Нулевой снимок всегда живет или нулевым становится каждый снимок по очереди и поэтому в любой момент времени откатиться можно только максимум на две недели ?

Значит нулевой тоже сносится и далее всё живет по икрементным ?

Всем привет. Вопрос: а что будет с первым снимком через две недели ? У меня создано задание каждые 3 часа делать снапшот датасета. Время жизни снимков 2 недели. По этому заданию работает репликация в бэкап. Время жизни рерлицированных снимков также как и у оригинала. Так вот , а смогу ли я, например через полгода, откатиться в нулевое состояние ? Нулевой снимок всегда живет или нулевым становится каждый снимок по очереди и поэтому в любой момент времени откатиться можно только максимум на две недели ?

По идее можно выставить нужному снимку запрет на удаление

и тогда он место не отпустит. будет ор что зфс проклятый !

и тогда он место не отпустит. будет ор что зфс проклятый !

Ок. Спасибо. Тогда вопрос: какой целесообразный срок жизни/количество делать, чтоб снимки не съели пол объема хдд например?

Подозреваю, что в первом снимке данных не так много, которые удаляться/изменяться и по итогу он не сильно много места займет

От ваших нужд и занимаемого места смотрите. Кому-то по закону 3 года нужно хранить, а кому-то и года за глаза

Скажем так. Первый снимок вся дата облака {400 ГБ}. А следующие уже то, чем облако пополнялось

Ок. Спасибо. Тогда вопрос: какой целесообразный срок жизни/количество делать, чтоб снимки не съели пол объема хдд например?

у меня так: 15-минутные - 10 часов ежечасные - 2 дня ежедневные - 2 недели еженедельные - месяц ежемесячные - 2 месяца ежегодные - бессрочно, удаление вручную в моей схеме с нулевым размером может быть только последний снимок, поэтому, например, за выходные не вымоются снимки конца недели.

Всем привет. Вопрос: а что будет с первым снимком через две недели ? У меня создано задание каждые 3 часа делать снапшот датасета. Время жизни снимков 2 недели. По этому заданию работает репликация в бэкап. Время жизни рерлицированных снимков также как и у оригинала. Так вот , а смогу ли я, например через полгода, откатиться в нулевое состояние ? Нулевой снимок всегда живет или нулевым становится каждый снимок по очереди и поэтому в любой момент времени откатиться можно только максимум на две недели ?

TL;DR: cannot import [pool]: one or more devices is currently unavailable при этом устройство доступно и ошибок i/o не видно === История: Пару недель назад на сервере с несколькими десятками пулов на одиночных дисках некоторые пулы стали уходить в SUSPENDED из-за i/o ошибок (видны были в dmesg). Причина до конца не изучена, но через несколько дней это безобразие прекратилось. В SMART ни на одном из дисков ничего не появилось, все чистые. Лечил тривиальным zpool clear. Как правило, мгновенно очищалось и диск становился ONLINE, но несколько раз команда зависала, и любая другая команда zpool или zfs тоже - приходилось принудительно перегружать сервер. После одного из ребутов зарузка зависала - оказалось, из-за зависающего импорта одного из пулов. После отключения этого пула и успешной перезагрузки без него начались работы по восстановлению пула. 1. Просто импорт пула - приводит к зависанию zpool import и далее всех последующих команд zpool/zfs Сопровождается это паникой zfs в dmesg вида Thu May 1 01:38:14 2025] VERIFY0(dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, &numbufs, &dbp)) failed (0 == 5) [Thu May 1 01:38:14 2025] PANIC at dmu.c:1176:dmu_write() ... 2. Помог zpool import -fFX -o readonly=on Однако при этом в одном из датасетов пропала одна из директорий с основным объемом данных. zfs list показывал размер несколько TB, а du этого раздела - несколько МБ. Несколько других датасетов выжили, их данные спас и решил воскресить пропавшие. 3. По запросу могу рассказать, что из нагугленного оказалось бесполезно 😉, - остановился на возможности восстановиться до одной из TXG, полученной из zdb -u. 4. И вот сейчас - такое состояние: root@LiveDebian:~/ > zpool import -fFX -o readonly=on -T 6439777 -d /dev/disk/by-id s15 cannot import 's15': one or more devices is currently unavailable Причем до появления сообщений команда выполняется несколько десятков минут. Диск при этом на самом деле доступен (lsblk показывает, zdb на нем выполняется). Сообщений об ошибках в dmesg не появляется, никаких событий zpool также не обнаруживает: root@LiveDebian:~/ > zpool events s15 TIME CLASS 5. Есть нюанс: чтобы избежать частых ребутов основного сервера - лечение провожу через ноутбук, подключив к нему диск через USB (не вынимая диск из основного сервера, так как это довольно сложно). Попробую возобновить на основном сервере, благо в последних попытках зависания с паникой и вынужденным ребутом вроде бы прекратились - но, может, у кого-то есть мысли по возможным причинам unavailable, не связанным с USB? ❓ Приложение. Исходный сервер: Hewlett-Packard HP Z420 Workstation/1589 Debian 12 6.12.9+bpo-amd64 zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1 Ноутбук: zfs-2.3.1-1~bpo12+1 zfs-kmod-2.3.1-1~bpo12+1

TL;DR: cannot import [pool]: one or more devices is currently unavailable при этом устройство доступно и ошибок i/o не видно === История: Пару недель назад на сервере с несколькими десятками пулов на одиночных дисках некоторые пулы стали уходить в SUSPENDED из-за i/o ошибок (видны были в dmesg). Причина до конца не изучена, но через несколько дней это безобразие прекратилось. В SMART ни на одном из дисков ничего не появилось, все чистые. Лечил тривиальным zpool clear. Как правило, мгновенно очищалось и диск становился ONLINE, но несколько раз команда зависала, и любая другая команда zpool или zfs тоже - приходилось принудительно перегружать сервер. После одного из ребутов зарузка зависала - оказалось, из-за зависающего импорта одного из пулов. После отключения этого пула и успешной перезагрузки без него начались работы по восстановлению пула. 1. Просто импорт пула - приводит к зависанию zpool import и далее всех последующих команд zpool/zfs Сопровождается это паникой zfs в dmesg вида Thu May 1 01:38:14 2025] VERIFY0(dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, &numbufs, &dbp)) failed (0 == 5) [Thu May 1 01:38:14 2025] PANIC at dmu.c:1176:dmu_write() ... 2. Помог zpool import -fFX -o readonly=on Однако при этом в одном из датасетов пропала одна из директорий с основным объемом данных. zfs list показывал размер несколько TB, а du этого раздела - несколько МБ. Несколько других датасетов выжили, их данные спас и решил воскресить пропавшие. 3. По запросу могу рассказать, что из нагугленного оказалось бесполезно 😉, - остановился на возможности восстановиться до одной из TXG, полученной из zdb -u. 4. И вот сейчас - такое состояние: root@LiveDebian:~/ > zpool import -fFX -o readonly=on -T 6439777 -d /dev/disk/by-id s15 cannot import 's15': one or more devices is currently unavailable Причем до появления сообщений команда выполняется несколько десятков минут. Диск при этом на самом деле доступен (lsblk показывает, zdb на нем выполняется). Сообщений об ошибках в dmesg не появляется, никаких событий zpool также не обнаруживает: root@LiveDebian:~/ > zpool events s15 TIME CLASS 5. Есть нюанс: чтобы избежать частых ребутов основного сервера - лечение провожу через ноутбук, подключив к нему диск через USB (не вынимая диск из основного сервера, так как это довольно сложно). Попробую возобновить на основном сервере, благо в последних попытках зависания с паникой и вынужденным ребутом вроде бы прекратились - но, может, у кого-то есть мысли по возможным причинам unavailable, не связанным с USB? ❓ Приложение. Исходный сервер: Hewlett-Packard HP Z420 Workstation/1589 Debian 12 6.12.9+bpo-amd64 zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1 Ноутбук: zfs-2.3.1-1~bpo12+1 zfs-kmod-2.3.1-1~bpo12+1

TL;DR: cannot import [pool]: one or more devices is currently unavailable при этом устройство доступно и ошибок i/o не видно === История: Пару недель назад на сервере с несколькими десятками пулов на одиночных дисках некоторые пулы стали уходить в SUSPENDED из-за i/o ошибок (видны были в dmesg). Причина до конца не изучена, но через несколько дней это безобразие прекратилось. В SMART ни на одном из дисков ничего не появилось, все чистые. Лечил тривиальным zpool clear. Как правило, мгновенно очищалось и диск становился ONLINE, но несколько раз команда зависала, и любая другая команда zpool или zfs тоже - приходилось принудительно перегружать сервер. После одного из ребутов зарузка зависала - оказалось, из-за зависающего импорта одного из пулов. После отключения этого пула и успешной перезагрузки без него начались работы по восстановлению пула. 1. Просто импорт пула - приводит к зависанию zpool import и далее всех последующих команд zpool/zfs Сопровождается это паникой zfs в dmesg вида Thu May 1 01:38:14 2025] VERIFY0(dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, &numbufs, &dbp)) failed (0 == 5) [Thu May 1 01:38:14 2025] PANIC at dmu.c:1176:dmu_write() ... 2. Помог zpool import -fFX -o readonly=on Однако при этом в одном из датасетов пропала одна из директорий с основным объемом данных. zfs list показывал размер несколько TB, а du этого раздела - несколько МБ. Несколько других датасетов выжили, их данные спас и решил воскресить пропавшие. 3. По запросу могу рассказать, что из нагугленного оказалось бесполезно 😉, - остановился на возможности восстановиться до одной из TXG, полученной из zdb -u. 4. И вот сейчас - такое состояние: root@LiveDebian:~/ > zpool import -fFX -o readonly=on -T 6439777 -d /dev/disk/by-id s15 cannot import 's15': one or more devices is currently unavailable Причем до появления сообщений команда выполняется несколько десятков минут. Диск при этом на самом деле доступен (lsblk показывает, zdb на нем выполняется). Сообщений об ошибках в dmesg не появляется, никаких событий zpool также не обнаруживает: root@LiveDebian:~/ > zpool events s15 TIME CLASS 5. Есть нюанс: чтобы избежать частых ребутов основного сервера - лечение провожу через ноутбук, подключив к нему диск через USB (не вынимая диск из основного сервера, так как это довольно сложно). Попробую возобновить на основном сервере, благо в последних попытках зависания с паникой и вынужденным ребутом вроде бы прекратились - но, может, у кого-то есть мысли по возможным причинам unavailable, не связанным с USB? ❓ Приложение. Исходный сервер: Hewlett-Packard HP Z420 Workstation/1589 Debian 12 6.12.9+bpo-amd64 zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1 Ноутбук: zfs-2.3.1-1~bpo12+1 zfs-kmod-2.3.1-1~bpo12+1

А тут встроенный САТА контроллер используется?

И вывод zpool import -d /dev/disk/by-id/

Собственно теория которую я хочу проверить - не пытается ли он притянуть за собой ещё какой-то девайс.

На нотубуке ему больше нечего притягивать было

Ибо он пытается притянуть, а устройства нет

vdev ведь у него никаких не было. Исходно как одиночный диск был создан