Идеального инструмента не бывает. Всегда есть частные случаи. Если у вас небольшая компания с маленьким парком оборудования, гипервизором и виртуальными машинами, которые работают исключительно по будним дням — такой способ подстраховаться от потери данных вполне применим. Для критичных сервисов, которые не требуют работы 24/7 это можно организовать как внутри виртуальной машины (все верно, механизм тот же, но возможность сбоя меньше), так и с запланированным выключением ВМ по шедулеру. В таком случае будет обеспечиваться полная консистентность.
Да собственно всем устраивает, просто если в компании уже есть работающий бэкап-сервер Veeam, то им проще будет это делать прямо из него и не плодить лишних сущностей.
Возможно это не совсем очевидно, но veeamsnap вначале делает снапшот состояния тех файлов и директорий, которые указаны в задании. Именно поэтому нужен обязательно весь этот подготовительный этап с pve-headers. Вот если вы поставите галочку Backup directly from live filesystem, то вот тогда задание сработает как вы указали и там действительно возможен сбой.
Отличная статья. Сам лично доставал ключик тыкая в MPX01. Раза с пятого только получилось. Вся операция требовала очень большой аккуратности и понимания — что конкретно делаешь.
Тут сложно ответить однозначно. На тестовом стенде было всего 3 машины. Хранилище для стенда было организовано на SSD при помощи FreeNAS. По собственному опыту могу сказать, что тут нельзя как-то обобщать. Все зависит и от операционной системы на гостевых машинах, и от производительности дисковой подсистемы хранилища. Ну и от нагрузки на гостях.
Для достижения максимальной производительности и емкости я бы варьировал тип хранилища от характера нагрузки. Постоянно использую собственную ноду в гибридном варианте. Тем виртуальным машинам, которым нужно постоянное чтение-запись небольших объемов данных — выделяю место на SSD. Там же, где бэкапы / холодные данные / архивы — HDD.
Действительно, этот нюанс я как-то упустил. Если на кластере около десятка машин, то все будет зависеть от количества IOPS, которые способно выдать хранилище. Но обычно проблем не возникает.
Вы правы, настройка «демона-вышибалы» это очень важный момент с множеством нюансов, заслуживающая отдельной статьи. Полагаю, что расскажу об этом в следующей статье цикла про Proxmox VE.
Не так давно вычитал три десятка дисков, записанных 15 лет назад. Хранились просто на даче в закрытом ящике стола. Без ошибок прочитались все, кроме одного (вероятно, изначально информация записалась со сбоем).
Лимиты следующие — 12 Tb ОЗУ и 768 логических CPU на хост.
Proxmox умеет гибко управлять ресурсами как по трафику, так и по IOPS.
Перенастройку ВМ выполнять можно «на лету» с помощью опций HotPlug, однако там есть определенные нюансы, связанные с версиями гостевых ОС. Где-то заработает «из коробки», где-то придется подкинуть пару модулей в ядро ОС.
Абсолютно с вами согласен, что монтирование на «боевой» системе нужно делать только по UUID. Я посчитал, что для объяснения базовых принципов достаточно просто указать /dev/sdX, поскольку так начинающим пользователям будет проще сориентироваться. В остальном — спасибо за пожелания.
Да, да! А еще SSD позволяют держать на домашнем ноутбуке кучу виртуальных машин запущенными, не особо заботясь о том, что дисковая подсистема станет «бутылочным горлышком». Минус SSD только один — чаще всего они умирают внезапно и уносят все содержимое в мир иной без возможности восстановления. HDD же умирают постепенно и зачастую можно успеть спасти данные.
RAW-диски он бекапить может.
Для достижения максимальной производительности и емкости я бы варьировал тип хранилища от характера нагрузки. Постоянно использую собственную ноду в гибридном варианте. Тем виртуальным машинам, которым нужно постоянное чтение-запись небольших объемов данных — выделяю место на SSD. Там же, где бэкапы / холодные данные / архивы — HDD.
Proxmox умеет гибко управлять ресурсами как по трафику, так и по IOPS.
Перенастройку ВМ выполнять можно «на лету» с помощью опций HotPlug, однако там есть определенные нюансы, связанные с версиями гостевых ОС. Где-то заработает «из коробки», где-то придется подкинуть пару модулей в ядро ОС.