Proxmox backup VM - долго бэкап делается

если больше деталей дашь может телепаты и придут насоветовать че нить.

Стандартными средствами через веб морду настроен бэкап ВМ через снапшот в режиме сжатия ZSTD. Когда зависает на 38%, то даже не могу попасть по VNC в виртуалку, а если остановить бэкап сразу захожу по VNC. Виртуалка жива. Сначала думал может что то с винтом куда копируется, но уже подключил другое хранилище на которое с другого сервера бэкап ВМ делается нормально.

Диски HDD ? А если через gzip делать, проблема есть ?

Могу тебе поведать как делается backup в проксе, вечерком кастани. Расскажу тебе почему у тебя зависает vnc :)

Поведай всем, что жмёшься.

Тайное шаманское знание, передаётся только в привате или за бабло? Всем расскажи, интрига же.

Да с работы уходил. :) Какое нафиг тайное знание, ребят)

Тогда ПРОСИМ, ПРОСИМ111 (интересно же, вдруг новое что узнаю)

Короче, глубокий гуглинг говоритЪ о бекапе прокса очень простую, но грустную штуку:

Бекап средствами прокса начинает вычитку блока с образа VM (в рандомном порядке я так понимаю). Как только VM делает любую попытку записи на диск (а может быть и даже чтения!), kvm(proxmox), перехватывает такую попытку. Останавливает запись. Говорит, подождите, товарисЧь! В бекап записывает блок, который операционка решила изменить, и потом отпускает ввод-вывод виртуалки. И продолжает дальше записывать (в не понятном порядке) блоки образа в бекап.

Из этого следуют ужасные вещи:

1. Во время затормаживания ввода-вывода, операционка это воспринимает так, что у неё вырвали на горячую жесткий диск и у неё режет болты, в том числе VNC сеть, и т.д. отваливаются. Убунта как правило это переживает. Oracle Linux - полностью зависает. Только ребут спасает. Windows - 50/50.

2. Время заморозки ввода вывода зависит от: скорости носителя куда бекапим, скорость и задержку сети (если бекап по сети), скорость чтения с самого прокса, кривожопости kvm драйвера для бекапа, надо ли сжимать бекап, и ограничений скорости которые были выставлены.

3. бекапы прокса из-за этой особенности не возможно задедуплицировать. - Собственно, это меня и натолкнуло на разбирательства со всей этой историей.

В проксе есть возможность сперва бекапить на локальный носитель (условно говоря temp) а потом уносить в сеть. Я так понимаю, что это придумано ровно для того, что бы ускорить backup. Если я правильно всё понял: если скорость хранилища прокс позволяет быстро читать, то подключаем ещё ультра быстрое хранилище для backup, и получаем backup.

Только он нихрена не дедуплицируется. Таким образом: учитывая весь букет проблем, бекапом прокса лучше не пользоваться штатным. Лучше делать backup на уровне zfs, например. Я делаю backup средствами прокса, только в Новогодние праздники, когда можно выключить виртуалку для backup :)

О каких-то тупорылых особенностях (искал ответ на вопрос почему блять дедупликация на бекапах прокса не работает), я выяснил читав стенограмму бородатых чуваков, которые выступали на публичных докладов с конференций прокса. Проблема есть, и всем похер. Кроме пары бородачей.

О как, благодарю. Я бекаплю снапшотами lvm и виртуалки перед этим усыпляю. Видимо поэтому с такими проблемами не сталкивался.

Епт, а снапшотов в proxmox нет?

Есть

Речь о штатном резервном копировании, и о том, насколько оно убого…

Сама ВМ развернута на nvme диске, а бэкапится на hdd, Пробывал в lzo тоже зависает на 38% .

Если машина не большая, попробуй отключить сжатие вообще, и сделать копию на SSD серверного класса (с большим SLC кешем, желательно, в размере всей виртуалки)

А бэкап производится с живой (работающей в момент бэкапа) или предварительно усыплённой\остановленной ВМ? Судя по «даже не могу попасть в виртуалку» - с живой. А уложить её баиньки перед бэкапом, тем или иным способом, заморозить, или shutdown, никак нельзя? Это бы решило проблему, мне кажется.