Согласен, и мне это более критично, как и возможность поднять софт-рейд на любом попавшемся тазике)

Тут главное помнить - обычно все равно что будет под LVM, а вот ZFS и аппаратные решения несовместимые вещи.

Здравствуйте, помогите пожалуйста разобратся как можно указать proxmox6,  восстанавливать машину из бекапа в другую локальную директорию ?

Хотя у кого как =) видел народ ZFS на аппаратном рейде крутил ... хз чем закончилось, но я бы не делал такого

уточните задачу

Все дело в block align? Как я понимаю, это что два-антивиря на винду поставить) подерутся...

Щас, секунду

надо восстановить машину на другое хранилище или в виртуалку но с другим ИД?

Машину на другое хранилище, так как он восстанавливает в свою директорию по умолчанию, где места 200мб а в другой больше 3 тб, я просто не знаю какую ему команду сказать, что бы он так сделал

Вот ошибка:

qmrestore /mnt/pve/ISO/dump/vzdump-qemu-104-2020_01_27-02_47_33.vma.gz 106 -storage local
restore vma archive: zcat /mnt/pve/ISO/dump/vzdump-qemu-104-2020_01_27-02_47_33.vma.gz | vma extract -v -r /var/tmp/vzdumptmp7281.fifo - /var/tmp/vzdumptmp7281
CFG: size: 441 name: qemu-server.conf
DEV: dev_id=1 size: 1395864371200 devname: drive-ide0
CTIME: Mon Jan 27 02:47:34 2020
Formatting '/var/lib/vz/images/106/vm-106-disk-0.qcow2', fmt=qcow2 size=1395864371200 cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16
new volume ID is 'local:106/vm-106-disk-0.qcow2'
map 'drive-ide0' to '/var/lib/vz/images/106/vm-106-disk-0.qcow2' (write zeros = 0)

(process:7284): ERROR : 22:05:42.177: restore failed - blk_pwrite to  failed (-28)
/bin/bash: line 1:  7283 Broken pipe             zcat /mnt/pve/ISO/dump/vzdump-qemu-104-2020_01_27-02_47_33.vma.gz
     7284 Trace/breakpoint trap   | vma extract -v -r /var/tmp/vzdumptmp7281.fifo - /var/tmp/vzdumptmp7281
temporary volume 'local:106/vm-106-disk-0.qcow2' sucessfuly removed
no lock found trying to remove 'create'  lock
command 'set -o pipefail && zcat /mnt/pve/ISO/dump/vzdump-qemu-104-2020_01_27-02_47_33.vma.gz | vma extract -v -r /var/tmp/vzdumptmp7281.fifo - /var/tmp/vzdumptmp7281' failed: exit code 133

Нет, ZFS создавалсь для прямой работы с дисками, у нее свои средства обеспечения надежности, аппаратный рейд будет подсовывать ей "левые" данные с точки зрения ZFS, и соотвественно при сбое возможен шанс потери данных не потому что сбой серьезный а потому что ZFS сделает что то не так, грубо говоря не поняв в чем собственно дело, т.к. прямая работа с дисками будет скрыта от нее. Но я тут не настолько глубокий эксперт =) Ну банальный пример - в аппаратном рейде умер диск, но ZFS про это не знает, и вот из-за этого скорость самого аппаратного рейда упала и ZFS приняла решение дропнуть диск из пула, потому что он ну не так с ее точки зрения работает, сбойный там или еще что, а она то не знает что там все ОК, просто в 5-м рейде на аппаратке диск сдох из-за этого все плохо.

Я разве не так сказал «подерутся»? Рейд с файлухой.

Ну я не так понял =) Ну тут даже не подеруться, просто ZFS будет не в курсе =) Но в принципе так и есть

Не в кусе будет и начнёт ерунду творить) вообщем, ваш опыт зачту, благодарю.

Эт не мой опыт, я ZFS всегда поверх HBA крутил, ну как в доке и написано =)

Я просто попытался образно объяснить.

Да, я тоже не без аллегорий)

Zfs пофиг на серверное железо и ecc , есс вообще всем как бы нужен для надёжности.

Да пофиг zfsу что под ним. Если аппартный рейд настолько просел что zfs решил его кикнуть - то дело и без zfs очень плохо

Набор мифов прям:)

Zfs и на файлах работать может😁