что то смущает?

Господа, на xfs опять пропали данные при потере питания. Что делоть ?

Ахаха, чат стал xfs😂

Действительно чат же про хфс

Ого, а я думал, про NTFS! Посоветуйте тогда чат по FAT32 :D

https://t.me/btrfs_chat

Господа, на xfs опять пропали данные при потере питания. Что делоть ?

Господа, на xfs опять пропали данные при потере питания. Что делоть ?

Перенести данные на ZFS

пусть там пропадают 😁

Шутки шутками, но как не крути, а шансов потерять на ZFS всё равно меньше, если по уму собрать

Шутки шутками, но как не крути, а шансов потерять на ZFS всё равно меньше, если по уму собрать

а потом у них сгорел датацентр вместе с бекапами

а потом у них сгорел датацентр вместе с бекапами

это потому что у них в тимплейтах которые ставятся вместо zfs - mdadm везде сделан )

это потому что у них в тимплейтах которые ставятся вместо zfs - mdadm везде сделан )

Никогда не юзал темплейты

Коллеги, ковырялся в коде ZFS, и выяснил что это пофакту FAT16 на стеройдах. Начал копаться в коде, и походу один из разработчиков ORACLE забыл стереть комментарий. Походу когдато давным давно его форкнули и начали развивать как ZFS

получается zfs можно конвертировать в exfat

теперь только в extzfs

Нифига не сломали, пустой свеже созданный пул без датасетов и вволов , легко конверитует в exFAT обычным хекс редактором

/report

/report

/report

Ну вот опять. Сидел считал хеши (rhash -r) на файлопомойках и их копиях. ZFS на raid1, на быстрых дисках, копия на btrfs на медленном. Размеры помоек больше чем ОЗУ. Если в помойке были только длинные файлы (сотни мб-гигабайты) то ZFS уверенно выигрывает по скорости вычитки. Если куча мелких файлов -- отстаёт. Если и то и то -- примерно наравне с btrfs.

/report

По скорости понятно, а что с хэшами? На btrfs сходятся? :-)

а не должны?

Это был риторический вопрос призванный обратить внимание на надёжность. Сравнивалось несравнимое.

ага. недавно как раз мне zfs файлы зануляло

Давайте подробности. Я такие случаи коллекционирую (чтобы знать как не надо)

Вопрос знатокам btrfs: в zfs мне очень не хватает того, что бы я назвал reverse incremental snapshot receive; представьте, что у вас есть основной zfs и вы делаете сники и пересылаете их на backup-сервер, оставляя на источнике один последний снимок. А теперь вам нужно восстановить один из давно переданных снимков с backup-сервера. Но вы не можете принимать более старый снимок не удаляя более новый. Вопрос: в btrfs это возможно?

а зачем новый снимок, если хочешь восстановить старый?

Вопрос знатокам btrfs: в zfs мне очень не хватает того, что бы я назвал reverse incremental snapshot receive; представьте, что у вас есть основной zfs и вы делаете сники и пересылаете их на backup-сервер, оставляя на источнике один последний снимок. А теперь вам нужно восстановить один из давно переданных снимков с backup-сервера. Но вы не можете принимать более старый снимок не удаляя более новый. Вопрос: в btrfs это возможно?

Поясняю по ситуации с zfs. У вас есть прод, там что-то пишется, вы это снепшотите, затем отправляется инкрементально в бекап. Цепочка снимков должна непрерывно передаваться в бекап, чтобы не отправлять туда датасет целиком. Представьте что вы бакапите виртуалку суммарным объемом 100ТБ и отправляете в бекап по каналу 300 мегабит, например. Вы же не захотите все 100ТБ передавать каждый раз, а инкрементов у вас, например всего 50ГБ в день. Теперь что-то навернулось и вам нужен бекап на проде, как его получить? с zfs у вас один вариант - тянуть все 100ТБ, чтобы восстановить копию. Если бы можно было отправить разницу между бекапным снимком и самым новым (т.е. не новый - старый, а старый - новый) и принять её на в датасет на проде так чтобы там просто снова появился удаленный старый снимок, то вы бы могли клонировать этот восстановленный снимок и что-то с клоном поделать, например виртуалку запустить. Не надо мне предлагать восстановить на бекапном сервере. Часто бывает так что запустить то что забекапилось на бекапный сервер просто не возможно там, надо много ресурсов, которые есть на проде. Не знаю понятно ли объяснил? А может быть такое есть в zfs и я просто не вкурсе? И к моему удивлению такого функционала нет и нигде даже не упоминается что он был бы полезен.

Разверни veeam и прекрати ебать мозг

А veeam умеет zfs?

Разверни veeam и прекрати ебать мозг

Производительность низкая, решение закрытое. Может мне ещё и гиперви поставить?

Зато поддерживает требования которые ты выдвигаешь?

Вопрос был про zfs в контексте сравнение zfs и btrfs. Причем тут веем вообще? Есть ещё требование к удовлетворительной производительности. У веем производительность для моего случая не удовлетворительная, требовпние к ресурсам выше, внедрение жороже и всё в целом хуже. И как веем поможет в инкрементальном восстановлении снимка? Там есть такой функционал? Скорее всего нету, он скорее всего может откатить весь прод к точке бекапа, а этого не нужно.

Вопрос был про zfs в контексте сравнение zfs и btrfs. Причем тут веем вообще? Есть ещё требование к удовлетворительной производительности. У веем производительность для моего случая не удовлетворительная, требовпние к ресурсам выше, внедрение жороже и всё в целом хуже. И как веем поможет в инкрементальном восстановлении снимка? Там есть такой функционал? Скорее всего нету, он скорее всего может откатить весь прод к точке бекапа, а этого не нужно.

Вопрос был про zfs в контексте сравнение zfs и btrfs. Причем тут веем вообще? Есть ещё требование к удовлетворительной производительности. У веем производительность для моего случая не удовлетворительная, требовпние к ресурсам выше, внедрение жороже и всё в целом хуже. И как веем поможет в инкрементальном восстановлении снимка? Там есть такой функционал? Скорее всего нету, он скорее всего может откатить весь прод к точке бекапа, а этого не нужно.

Тут вроде уже поднимали тему бэкапов ZFS sanoid zfs_autobackup

Да само собой так и делается. Речь не о бекапе. Zgs оптимален для бекапа. Речь о небольшой недоработке функционала утилиты zfs-receive, а именно, не возможности принять с бекапа старый снимок в инкрементальном режиме. А это было бы очень полезно. И раз уж решь зашла про соавнение с btrfs я поинтересовался, в контексте соавнения с zfs, нет ли там такого. Ещё раз попробую объяснить. Речь идет о возможности сделать инкрементальную пересвлку не новый минус старый, а наоборот, старый минус новый, т.е. вернуть старый снимок и необходимые доя его существования блоки, когда в целевом датасете есть более новый но уже переданеый в бекап снимок. Нужно это чтобы клонировать сатрый снимок в целях получения доступа к бекапу не на бекапном сервере, а на основном. Речь идет о случае с гиганскими датасетами: 10ТБ, 100ТБ которые бекапятся ингрементально через узкий канал, условноо 300мегабит.

? Он восстановит файлы нужной версионности