Он прекрасно описан у Вима

Не сработает, веем востановит где, ещё 100ТБ места ему подавай?

Видимо я что-то не понятно объясняю.

? Если у Вас навернулось хранилище, то да, ему же надо куда-то восстановить

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

Если навернулось тоинужно новое. У вас часто такое происходит? На проде у меня ни разу не было такого. А доступ к бекапу гиганских виртуалок нужен часто. Иногда их невозможно на бекапе запустить и не удобно, т.к. к бекапу доступа не должно у всех быть. Удобно вернуть снимок на прод в область ответсвенности хозяина вм

Если навернулось тоинужно новое. У вас часто такое происходит? На проде у меня ни разу не было такого. А доступ к бекапу гиганских виртуалок нужен часто. Иногда их невозможно на бекапе запустить и не удобно, т.к. к бекапу доступа не должно у всех быть. Удобно вернуть снимок на прод в область ответсвенности хозяина вм

Во-первых, логично, что Виму понадобится отдельный сторадж на 100ТБ+(retention days*data change rate per day), если система 100ТБ

гигантские виртуалки всегда зло

Снимок всё ещё должен кто-то вернуть, а рестор бэкап кто-то запустить

А теперь ты ещё расскажешь про систему виртуализации

Всё же работает, почему зло?

Потому что если нужны 10ТБ ВМ и это не пустое место, то значит что-то сделано не так, либо для таких объёмов стоит смотреть на enterprise оборудование

Либо делать так, чтобы даже если эта ВМ наебнулась было МНОГО времени на восстановление в силу наличия второй реплики

И зачем это нужно, если есть путь сделать это проще, быстрее, надёжнее и дешевле?

Потому что если нужны 10ТБ ВМ и это не пустое место, то значит что-то сделано не так, либо для таких объёмов стоит смотреть на enterprise оборудование

Ну так зачем тебе тогда Reverse Incremental раз всё надёжнее так?

А если вм только 100ГБ, сто меняется? Или 10Гб - уже ок, чтоли? Почему 100ТБ хуже чем 100ГБ? Я вообще не понимаю. При том "на энтерпрайс оборудовпнии", мало того что будет в 30 раз дороже, так ещё и медоеннее и 100% пересылка никуда не денется. Обычно там всё максимально тупо

Ты серьёзно или рофлишь?

Значит обсуждать отичаи zfs от btrfs - это офтоп идите в личку, а обсуждение типа, весь ваш подход на zfs - это ге энтерпрайс, купите веем и не ебите мозг - это не офтоп? Впечатление что мы из разных чатов и на разном чзыке говорим

Без сравнения

Значит обсуждать отичаи zfs от btrfs - это офтоп идите в личку, а обсуждение типа, весь ваш подход на zfs - это ге энтерпрайс, купите веем и не ебите мозг - это не офтоп? Впечатление что мы из разных чатов и на разном чзыке говорим

А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂

Ну, да. Я выражаю своё мнение про ZFS в ZFS чатике и рекомендую не пытаться натянуть ежа на носорога, а использовать средства предназначенные для описанной задачи

Это мнение, как я вижу, человнка плохо владеющего zfs и ничего ответвенного на нем не делающего. Не надо слушать такое мнение.

А если вм только 100ГБ, сто меняется? Или 10Гб - уже ок, чтоли? Почему 100ТБ хуже чем 100ГБ? Я вообще не понимаю. При том "на энтерпрайс оборудовпнии", мало того что будет в 30 раз дороже, так ещё и медоеннее и 100% пересылка никуда не денется. Обычно там всё максимально тупо

Вм на 10 ТБ - говно для бэкапа. Сохраняйте данные отдельно и к ним, различными методами, можно прикрутить (чаще всего) обратные инкременты.

Все эти методы будут заведомо хуже того как это может работать на zfs в силу логических причин.

Нет, просто ты фиксируешься на zfs, как на чём-то волшебном.

Для указанной ситуации это и есть волшебная пилюля. По тому что, иначе вам придётся из говна и палок сделать... Тадам, аналог zfs! Но это уже надо голосом. Я устал писать со смартфона

Когда СРК надо насаживать на proxmox

Нет, ты пытаешься насадить ежа (СРК) на носорога (ZFS) и удивляешься, почему так плохо насаживается

А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂

я сравниваю в условиях локалхостовой файлопомойки, а не 'ынтерпрайза'

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

Продолжите это обсуждение во флуде, плз.

????????? Ты мало того, что переврал все мои аргументы, так ещё и Т9 включи обратно (и Veeam пишется как Вим на русском) Тебе уже сказали, что не надо делать один большой диск на 10ТБ. Это больно для СРК. Ты просто проигнорировал. Начал говорить про медленно. При том, что изначально ты вообще говорил про административную задачу разграничения прав. Теперь ты продолжаешь гнуть про попытку сделать СРК из ZFS, когда у тебя уже есть виртуализация к которой есть ОТДЕЛЬНАЯ СРК

Что за срк, я не понимаю, и почему ему больно от 10ТБ?

У меня-то всё работает, кроме досадного нюанса с обратной передачей сников, а вы мне тут рассказываете что zfs ненужОн 🤷‍♂

А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂

Кстати, я всё жду sync replication ZFS

В потоке на другой сервер?

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

В потоке на другой сервер?

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

Он умеет бэкапить любую шару и, через агента, любую фс

Агент зфс не умеет

Файлово умеет

Пфф

А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂

Тут только один человек виим постоянно предлагает)

хороший продукт, кстати

Я же не спорю, но Владислав часто его упоминает не к месту)

Скопировал то что удалил бот: Всем привет, есть вопрос по дедупликации, подскажите пожалуйста. ОС - Ubuntu 20.04.6 LTS x86_64, ядро - 6.1.45, zfs - zfs-2.1.12. Создал пул raid-z1 на HDD дисках со special vdev на SAS SSD. На этом пуле создал тонкий том с блоком 32K и отформатировал в ext4. Примонтировал том и нагрузил с помощью fio, при этом rw=write (Sequential writes), а bs=1M. Во время тестирования нагрузка пульсирует c ~ 1300MiB/s до нуля. При этом zpool iostat -yv показывает, что ввод/вывод на special vdev происходит только переодически, небольшими промежутками времени. Заменил SAS SSD на NVME SSD для special vdev, пересоздал пул и повторил описанные выше шаги - результат аналогичный. Нашёл несколько источников источник-1 источник-2 , где говорится что, ввод/вывод с дедупликацией представляет собой смешанный read/write блоками по 4K. При этом только на SSD моделей Intel Optane 900p, 905p, P48xx данная нагрузка (смешанный read/write 4K блоками) будет нормально работать, а на большинстве остальных SSD будет сильная просадка. Так же повторил тест, когда fio bs=128K и для созданного тома -b 128K . Нагрузка так же пульсировала c ~ 1300MiB/s, но уже не падала до нуля, минимальная скорость была 25MiB/s. Может быть есть ещё какие либо способы повысить производительность подобного пула без замены железа? Заранее благодарен.

Спасибо

Скопировал то что удалил бот: Всем привет, есть вопрос по дедупликации, подскажите пожалуйста. ОС - Ubuntu 20.04.6 LTS x86_64, ядро - 6.1.45, zfs - zfs-2.1.12. Создал пул raid-z1 на HDD дисках со special vdev на SAS SSD. На этом пуле создал тонкий том с блоком 32K и отформатировал в ext4. Примонтировал том и нагрузил с помощью fio, при этом rw=write (Sequential writes), а bs=1M. Во время тестирования нагрузка пульсирует c ~ 1300MiB/s до нуля. При этом zpool iostat -yv показывает, что ввод/вывод на special vdev происходит только переодически, небольшими промежутками времени. Заменил SAS SSD на NVME SSD для special vdev, пересоздал пул и повторил описанные выше шаги - результат аналогичный. Нашёл несколько источников источник-1 источник-2 , где говорится что, ввод/вывод с дедупликацией представляет собой смешанный read/write блоками по 4K. При этом только на SSD моделей Intel Optane 900p, 905p, P48xx данная нагрузка (смешанный read/write 4K блоками) будет нормально работать, а на большинстве остальных SSD будет сильная просадка. Так же повторил тест, когда fio bs=128K и для созданного тома -b 128K . Нагрузка так же пульсировала c ~ 1300MiB/s, но уже не падала до нуля, минимальная скорость была 25MiB/s. Может быть есть ещё какие либо способы повысить производительность подобного пула без замены железа? Заранее благодарен.

Для начала зачем Вам нужна дедупликация?

Особенно с таким блоком

система резервного копирования