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

kvm же

вопрос только в ос

можно в теории через suse studio собрать себе гипервизор  на ее основе.

не уточнил - нужно что то похожее на ынтерпрайзное в стиле oVirt/Proxmox/XEN-NG - то есть что бы потом можно было собрать  и затащить все железки во что то в одно единое целое.
RHEL очень требователен к минимальному инсталлу. в 2 ГБ просто не знаю что можно поставить и чем потом “обвязать"

может тогда проще какой-нить pxe с cloud-init(или аналогом) сделать, будет грузиться через сеть потом донастраиваться. А так я бы генту собрал на минималке.

Терминальный сервер с минимальным 64Гб диском под систему и отдельным диском под файловые 1с. На сервере работает 10-ток или больше пользователей в течении дня или похожая нагрузка.


Интересует:
- возможность бекапа на лету раз в час
- объем резервных копий
- скорость создания и передачи
- возможность ротации и удаления резервной копии из середины цепочки
- скорость удаления резервных копий

Все это интересует особенно по сравнению с бакапом с помощю zfs send / receive

Может быть рассмотреть сетевую загрузку?

Еще можно сюда глянуть, тут объем корня вроде  600 мб https://wiki.centos.org/SpecialInterestGroup/Atomic/Download

ovirt-node может влезть, но там много места под логи нужно, если их шипить или монтировать на NFS например, то можно справиться

в виде чего?  centos/rhel в самом минимальном минимуме не влезает в 2ГБ. С логами можно порешать, да.
С Atomic (CoreOS сейчас это), я боюсь будет много проблем с инсталлом всего, что связано с python, vdsm, и прочего необходимого

ovirt-node это специально собранный мини-дистр

спасибо, посмотрю

Юзер добавлен в группу либвирт

Название пакета все-таки "слегка" намекает: https://packages.ubuntu.com/focal/libvirt-daemon-system

Терминальник с 1С сделать реально, а вот как сымитировать в ней нагрузку, боюсь, не знаю. К тому же бекапы все обычно ночью, когда никто не работает в ней. По другим пунктам:

- есть
- объём диска * коэффициент компрессии, отдельно возможна оффлайн-дедупликация - бэкап при выполнении делится на переменный размер чанка, при следующих бекапах интервалы учитываются. Дедуп (или как они называют "сборка мусора") откидывает блоки-дупликаты.
- Бэкап 250ГиБ инстанса Nextcloud (почти пустой, заполнен на 3.4G из 245G согласно df) занял 17 минут 19 секунд при первом бэкапе. Следующий день занял 37 секунд.
- Из середины удалять можно, незаюзанные по итогу чанки удалятся при следующей "сборке мусора"
- "Удаление" практически мгновенное, время "сборки мусора" - 3:35, за которые было проанализировано 2,29ТиБ данных и очищено 31,62ГиБ неиспользуемых секторов (17205 шт).

В моём случае штраф был на xdelta3 на дифф-патчах, посколько у него ограничен размер чанка, и он фиксированный.

Верификация 447Гб чанков (139 снапов) заняла 2 часа 1 минуту.

Бэкап сервер работает поверх 8x600gb RAID6 на HP P420i, лун был прокинут в виртуальную машину целиком. Внутри неё только ext4 с системой и стором, никакого LVM