
Комментарии 36
Не совсем согласен с тезисом, что PBS и ProxmoxVE на одном хосте - это плохо.
Когда у вас один PBS, да ещё и на том же хосте что VE - да, это глупо. Сломался хост - накрылись бэкапы.
Впрочем, один PBS - это всегда глупо, ибо и PBS смертен. :)
Когда же у вас PBSов несколько (из которых один живёт на том же хосте, что и ProxmoxVE), то локальный PBS очень даже удобен с точки зрения скорости работы (при условии, что бэкапы не лежат на тех физических же дисках, что и виртуалки). Плюс, не тратится трафик при бэкапе/восстановлении с локального PBS.
В результате, локальный PBS - для скорости, нелокальные PBS - для надёжности.
Поддерживаю, локальный pbs плюс push во второй удаленный pbs — вполне рабочая связка
И крутить 24/7 PBS тоже глупо.
У меня отдельный хост PVE кластера в котором
TrueNAS со своими дисками для резервных копий
PBS LXC, использующий хранилище в PBS
QBT, чтобы тарахтел в фоне
Jellyfin, тоже запихнул туда
Остальные 200 виртуалок и контейнеров крутятся на других хостах.
PBS в процессе синхронизации с удаленным хранилищем (вот тут ждал шифрования на-лету)
А в чём проблема с 24/7/365 PBS? Ресурсы кушает мизерные, зато система бэкапов доступна всегда.
Там, где отдельные ProxmoxVE хосты, у меня везде в качестве компаньона PBS стоит. Но есть и извраты, когда PBS в бздёвой виртуалке живёт (ну, так получилось).
В контексте разнесения PVE и PBS на разное железо.
На отдельном железе чисто под PBS, я крупных контор с выделенным железом есть смысл, так проще.
Для мелких и домашних PBS внутри PVE имеет место быть, поэтому я и расписал свой вариант, где работающий 24/7 PBS доступен всегда, но на общем потреблении ресурсов это влияние минимально.
У меня pbs живет в lxc, а pbs-сторадж живет на truenas (zfs raid-z2) и монтируется по nfs.
Допом на трунас-е по крону делаются снимки этого стораджа на случай, если кто-то доберется до рута на pbs.
Схема работает более 4-х лет и прекрасно себя зарекомендовала в плане надежности.
У меня был PBS на хосте ProxmoxVE. Много лишнего трафика, особенно если больше одного хоста. Еще важный момент - PBS во время бзкапа пустое место на диске VM-ки скипается, а во время верификации - нет, поэтому трафика намного больше будет по сети гулять лишнего именно во время верификации. С выделенным хостом под нужды PBS - лично мне поприятнее работать. Зависит конечно от размера кластера и от бюджета.
Единственный минус решений от proxmox - отсутствие официальной поддержки soft raid (mdadm\lvm). В принципе можно настроить, но придётся делать вручную через консоль, а не через удобный интерфейс.
Есть ZFS, можно собрать в установщике или webui.
Потом что авторы считают, что штатно не стоит такое, а вот через zfs софтовый рейд дают.
Но руками собрать несложно.
Про soft raid (mdadm\lvm):
Проблема флага O_DIRECT в MDRAID, DRBD или LVM RAID
https://www.linux.org.ru/news/linux-general/18114137
https://bugzilla.kernel.org/show_bug.cgi?id=99171
С zfs такого не случится - это фс проверяет данные на корректность.
По этому авторы pve и не используют soft raid (mdadm\lvm)
Сама новость хорошая, но написано - просто жесть. Одно и тоже разными словами по 2-3 раза. Видно что текст писал GPT, с его фирмеными оборотами. Читать просто невозможно, какое-то ИИ графоманство. На опеннете это событие идет как мини-новость, тут же написано ИИ для ИИ.
Ох. После бага с гонкой в GC и потерей чанков есть какое-то недоверие к PBS и желание перейти на что-то другое. И то преимущество системы хранения, позволяющее экономить место, является и слабым звеном. До verify или использования бэкапа (распаковки/записи на ленту) ты не можешь быть уверен ни в том, что бэкап живой, ни в том, что зацепило только один, а не много или вообще всё. И поменять поведение этой "дедупликации" ты вроде бы и не можешь (не смотрел, что там в последних версиях)
Это вы еще не сталкивались с весельем в связки pve+pbs, когда указываешь какому-нибудь диску LXC не бэкапиться, а потом решаешь восстановить ВМку/контейнер. Случится эпик момент, о котором тебя не особо и спрашивает, я когда-то столкнулся.
Плюс если Вим легко и непринужденно поправит HealthCheckом чуть побитые данные, то Pbs скажет "ой, у меня лапки, тут все твои цепочки сдохли"
Я промолчу про практически нулевую документацию. Чтобы понять чего-куда-зачем, нужно идти на форум фактически или разбирать самому сорсы..
И что будет, если диск не бэкапить? Как это влияет на восстановление?
Вы еще вместо просмотра интерфейса предложите не сорсы смотреть, а самому написать.
Перед восстановлением вся вмка/контейнер сносится со всеми дисками, даже которые не бэкапятся. Об этом не сильно интересуется процесс восстановления: а нужно ли? Очень "удобно" в целом. Проверьте на досуге :)
Так сносятся только конфигурация, а не диск, который не бэкапится. И что? Там еще можно не включать диск в репликацию. И что?
Это же действия продуманные админом? Цепляй руками.
Вы хоть погуглите перед написанием или проверьте в тестлабе :)
Еще раз: восстанавливая бэкап с 2мя дисками или MP, один из которых не бэкапится (снят чекбокс в настройках диска), сносит ОБА диск физически со стораджа. Что и куда пристёгивать? Диска нету, его снёс restore за компанию.
https://www.google.com/search?q=site%3Aproxmox.com+restore+vm+removed+disk+not+backed &udm=14
Чего мне проверять, у меня pbs исп. несколько лет.
Да, после восстановления в железе не будет диска, который исключен из бэкапа. Но зайдите в хранилище где он был, там его и найдете. Зачем ресторе его удалять оно тупо исключено из бэкапа и его описания там нет.
Я столкнулся с данным кейсов в сентябре прошлого года, когда ресторил LXC контейнеры.
И диск удаляется физически. Нечего там доставать. И неоткуда. Еще и проблемы с бутом возникают потом, т.к. диска то нет.
Сомневаюсь, что за полгода что-то кардинально поменялось. Тестить 2 часа кейс заново, чтобы доказать что-то кому-то, когда за меня это сделал офф. форум и багтрекер - как бы глупая трата времени (:
Proxmox в целом помойка уровня Hyper-V. Не завидую тем, кто использует это решение в энтерпрайзе, а не на уровне дома.
Логически его удалить можно когда делается бэкап, но он пишет exclude. Когда идет ресторе он удалится не может, потому-что в бэкапе его нет. Возможно вы наткнулись на баг, но скорее всего сами чего-то не заметили (не учли), очень непохоже что вы продуктом всерьез пользовались, так мышкой помахали и вернулись к своему продукту где скорее всего такого инструмента вообще нет, тем более бесплатного.
Мне доказывать не надо, просто не говорите чушь.
Мне доказывать не надо, просто не говорите чушь.
Когда идет ресторе он удалится не может
Специально для экспертов. MP0 маунтпоинт /HUJ123 не бэкапится. Рестор контейнера. Где файл /HUJ123/HUJ500 после рестора и где я его должен пристегнуть на отформаченном MP0? :)
https://i.imgur.com/bCz28Nb.png
https://i.imgur.com/hCkcxR4.png
https://i.imgur.com/m6pT2Ej.png
https://i.imgur.com/mut89UD.png
https://i.imgur.com/W2yrxUm.png
Как же так вышло, опять стерло MP. Не должно же. Ну никак.
В случае с ВМкой - да, диск остается отстегнутым и не удаляется. И его можно пристегнуть обратно. С теми же самыми страшными сообщениями, что весь контент ВМки сотрется
https://i.imgur.com/XrHU17u.png
https://i.imgur.com/tCVl1TV.png
https://i.imgur.com/95Z3E8D.png
https://i.imgur.com/4QMOdGj.png
так мышкой помахали и вернулись к своему продукту
Может самому попользоваться стоит больше чем next-next-next? ;)
Честно говоря лень разбираться с этим контейнером, тем более я не вижу разницы в логике работы pbs.
Только что прогнал ВМ, при бэкапе он пишет exclude, при ресторе конечно он предупреждает, что вы восстанавливаете в существующую VM (восстановите в новую, не будут предупреждать) и данные будут очищены, по-моему это вполне логично, но восстанавливает он тот который бэкапил и его и трет соответственно.
После ресторе диск висит в unused, виден он естественно и в хранилище, в вашем случае загляните local-lvm. Цепляете и работайте спокойно.
У меня в продакше 4 года висит, и за такие косяки отвечаю как минимум своим местом работы, а ВМ-ок с диском, которые не попадает под pbs пару десятков.
Просто не надо восстанавливать ВМ/lxc с тем же id - восстанавливайте бэкап в сущность c другим id.
Использую pve еще с 2013-го.
Сотни узлов с тех пор развернул.
Десятки фирм и фирмочек перевел на pve с hyper-v и esxi.
Особых проблем за все это время не было, кроме случаев копнуть глубже и собственных кривых лапок )
По hyper-v:
Как дела с пробросом usb?
Снепшоты ВМ у hyper-v инкрементные?
Есть ли встроенный механизм бэкапов у hyper-v?
Есть ли аналог lxc у hyper-v ?
И это я только по верхам пробежался.
Зы. Из интересно-нового для pve на сегодня:
https://github.com/rcourtman/Pulse
По hyper-v
Проще сказать, что появилось нового за последние 10 лет в HV, WSUS-е и любом MS продукте. :)
Появилось конечно, но для этого в крайне низкий уровень лезть нужно, вроде Get-Cluster <clusterObject> | fl *
В любом случае: за все бесплатные продукты платится из рабочего времени админа :) И да, HV - помойка на уровне Proxmox-а. Где то был мой коммент 2х летней давности про все косяки HV. Нашел: https://habr.com/ru/articles/947118/comments/#comment_28840236
А мониторинг то в конторе или ПРТГ, или Заббикс, или вариации, вроде Veeam One. Опять 50 прокладок между пихать (еще и на другой хост-кластер, чтобы мониторинг не упал вместе с хостами)?
Так и не ответили ,что же не помойка по вашему мнению?
>> В любом случае: за все бесплатные продукты платится из рабочего времени админа
А платное ПО прям само развернулось, настроилось и поддерживать его не надо?
Любое ПО требует времени на его поддержку вне зависимости от платности-бесплатности.
что же не помойка по вашему мнению
При выборе гипервизора из всего что есть на рынке? Всё еще ESXi на ближайшие 3-5 лет. Если отбрасываем вопрос цены и угасание продукта по причине Broadcom-а. Минимум детстких болячек, учитывая, сколько ему лет.
Proxmox всё еще сырой:
То софт-локи CPU в опред релизах
то с оф.инсталлера встаёт с третьего раза
то удаляешь бэкап репу, а у нее висит хэндл, она удаляется с ошибкой, но линк не удаляется и ты не можешь создать такой же, пока не удалишь ручками.
То интересности с восстановлением из бэкапа
Когда допилят - можно будет и поговорить. Как минимум Вим только-только научился с ним работать. А это значит, что еще точно рано и шанс "не восстановить" стремится в высь. Многое всегда привязано к бэкапам. А админить 5 решений параллельно - время на их обновления, поддержку и решение косяков.
За 5 лет использования ESXi (с 5.0 по 7. Это 3 шкафа серверов+стораджей) в проде с учетом миграций, новых хостов, редеплоев старых, тонны vmotion-ов и storage vmotion-ов и т.п. - таких детских глупостей не встречал. Да, был нюанс с iSCSI таргетом пару раз, который после определенных подергиваний (не помню каких) не хотел маунтиться до рестарта ESXi хоста. Всё.
Ну ладно, еще у клиентов видел балаган из билдов, там на определенных билдах со временем вставал раком SNMP. Фиксилось принудительным рестартом по cron-у. Обычно в официально KB была вся информация.
И речь идет про именно идёт "работал с ним", а не "завел и поставил в угол пылиться" :)
А платное ПО прям само развернулось
У платного ПО есть суппорт. Берешь, пишешь в тот же Veeam и за тебя решают проблему :) Например в 13 Veeam B&R я зарепортил 3 проблемы. 2 из которых пофиксили. 1 - в новом релизе пофиксят.
За 5 лет использования Вимом 1.5 тикета. Всё остальное: или работает из коробки, или есть информация, как пофиксить.
MS премиум суппорт тот же - за суппорт особо не считаю. Привет пятилетнему кейсу между Вимом и MS, где проблема была со стороны MS и у юзеров просто закрывали премиум кейсы: https://forums.veeam.com/microsoft-hyper-v-f25/windows-server-2019-hyper-v-vm-i-o-performance-problem-t62112.html
Если это опенсорс какой-нибудь, то удачи. Не факт, что тебе ответят, даже если в кейс ты выдал наидетальнейшую инфу со всеми логами, шагами, скринами. И не факт, что пофиксят.
Далько за примером ходить не нужно: VLC, который успешно посылал всех, кому что-то не нравится.
вне зависимости от платности-бесплатности.
В зависимости :) Рандомный контейнер с гитхаба в большинстве своём даже не имеет нормальной документации и ее приходится вычленять анализируя код. Половину перемененных в докуменации может не быть. Они будут в обрывках кода валяться. Половина - "допили сам".
Я тут 3 года фиксил падающий Hyper-V кластер. Замечательное чувство, когда у тебя кластер на 300+ машин падает раз в 3 месяца и когда некуда обратиться :) По итоге было найдено около 5 критичных проблем в конфигурации железа-софта-самого_кластера, которые могут доводить до отвала.
Pve скоро 20 лет исполнится - я бы не назвал продукт с 20-летней историей сырым.
Примеры описанного можно? В каком релизе, какое железо, конфа ВМ при этом?
Не стартует либо на оч старом (при этом всегда можн о качнуть более старую версию самого pve и 99.9%, что pve встанет тогда нормально), либо на оч новом железе - тут вопросы к поддержке такого железа в самом ядре линукса.
Pve заводится практически на любом совместимом железе - хоть на самосборе, хоть на брендовом серверном. Тогда как вмваре подавай только брендовое серверное и посвежее - они крайне активно поддержку даже 5-летней давности железа выпиливают без раздумий. Особенно это касается поддержки raid-контролеров. Сталкивался много раз с подобным на вмваре (
Снова живой пример в студию хотелось бы.
Тут 99% проблем - это кривость рук восстанавливающего, имхо. Особенно если бездумно это делать.
Касаемо платного ПО и т.н. "поддержки".
Все иностранное ПО сейчас пошлет просящего в пешее эротическое.
Поддержка же нашего посконного ПО мягко говоря не блещет за редким исключением.
Особенно умиляет отечественный подход с предоставлением чуть ли не паспорта и родословной до 5-го колена лишь для того, чтобы скачать их .iso на попробовать.
Pve не идеален как и все в этом мире. Но он открыт, у него адекватное и оч немаленькое комьюнити (только реддит 100к+) и офиц форум отзывчивый. Кстати и платная поддержка у него тоже имеется за вполне вменяемые деньги.
Вмваря же для простого смертного мертва ( Спасибо эффЭктивным манагерам.
Я сам с вмвари начинал в 2008-м и на тот момент это было единственное удобное ПО для вирт-ции.
Кстати, в случае проблем данные вытащить из вмвари с их сугубо проприетарной ФС крайне проблематично в отличие от pve.
Лично сталкивался, когда прямо во время работы сервер превратил данные в кашу на hw raid (что-то произошло с самим контроллером). Сервер стоил 40к+ $, если что. Данные так и не вытащили и офиц. ТП ничем не смогла помочь (
P.s. Можете xcp-ng попробовать - вполне себе вариант на замену esxi, если не требуется чего-то крайне специфического.
Vmware esxi как не помойка? Ну-ну.
Нынешний уровень esxi:
https://www.huntress.com/blog/esxi-vm-escape-exploit
Это даже не назвать уязвимостью, это какой-то чемодан всего на свете, для эксплуатации уязвимостей в ESXi. И, судя по всему, это всё было сделано давно, потому что уровень заморочи такой замороченный, что проще было стрипушню с баром целиком снять, дабы напоить админа и стащить все его ключи, чем вот это вот всё
Множественные критические уязвимости ESXi, Workstation и Fusion https://internet-lab.ru/esxi_workstation_fusion_cve Проблема настолько серьёзная, что вышли патчи для неподдерживаемых версий 6.5 и 6.7.
Уязвимости в vCenter Server — 9.8 баллов https://internet-lab.ru/vcenter_CVE-2024-37079_CVE-2024-37080_CVE-2024-37081
vCenter — критическая уязвимость 9.8 баллов (CVE-2024-38812) https://internet-lab.ru/vcenter_CVE-2024-38812_CVE-2024-38813
Множественные уязвимости ESXi (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) https://internet-lab.ru/VMSA-2025-0004
Broadcom вынуждает обладателей продуктов VMware с вечными лицензиями купить подписку https://internet-lab.ru/broadcom_vmware_trouble
CVE-2025-22249 (критический риск) — уязвимость в наборе инструментов Aria.
CVE-2025-22247 (средний риск) — проблема в VMware Tools. CVE-2025-22247 (VMware Tools) — позволяет злоумышленнику с правами гостевой ВМ манипулировать локальными файлами. Рекомендация: переход на Open-VM-Tools.
CVE-2025-22249 (VMware Aria) — уязвимость типа XSS (межсайтовый скриптинг), затрагивающая инструменты автоматизации. Многие компании могут не использовать этот функционал.
Часть владельцев бессрочных лицензий VMware не могут получить своевременные обновления безопасности https://habr.com/ru/news/931320/
Киберпреступники начали использовать критическую уязвимость в VMware ESXi. Ее исправление недоступно в России https://habr.com/ru/companies/orion_soft/news/1000888
Все и сразу:
https://www.vmware.com/security/advisories.html
https://www.cvedetails.com/vulnerability-list/vendor_id-252/Vmware.html
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vmware
Вроде можно же восстановить из бэкапа в уникальную VMку, не стирая оригинал
Есть задача на проверку бэкапа. А уверенным можно быть только после распаковки и запуска бэкапа какая бы система не была.
Не туда
Proxmox Backup Server 4.2: бэкапы для Proxmox стали взрослее и умнее