Инкрементальный бэкап в Proxmox VE с помощью VBR

[iwram]

Может сначала стоит сказать что бэкапить запущенные виртуальные машины необходимо средствами гипервизорами (snapshot и потом копирование снимка например), думаю не зря тот же платные Veeam Backup стоит немало денег т.к. просто копировать запущенные виртуальные машины — это все равно что выстрелить себе в ногу. Бэкап работающей не особо нагруженной простым копированием — сразу вызовет сбой при попытке запуска.
Поэтому в данном случае ни в коем случае не используйте это решение для бэкапа, который по сути работает как «cp -r /backup/...».
VM можно бэкапить используя veeam agent, но это из самой виртуалки, но не гипервизора.
Селектел — ведь хорошие инженеры работают, исправьте статью и сообщите о проблемах, которые могут возникнуть используя данные решения.

[Darksa]

Возможно это не совсем очевидно, но veeamsnap вначале делает снапшот состояния тех файлов и директорий, которые указаны в задании. Именно поэтому нужен обязательно весь этот подготовительный этап с pve-headers. Вот если вы поставите галочку Backup directly from live filesystem, то вот тогда задание сработает как вы указали и там действительно возможен сбой.

[iwram]

В начале статьи было написано, что это не для продакшен, поэтому прошу простить мою навязчивость.
forums.veeam.com/veeam-agent-for-linux-f41/proxmox-incremental-backups-with-veeam-t66702.html
Но как он будет копировать данные, которые находятся в оперативной памяти VM, явно для виртуалок с базами данных — это не то решение. Потенциальных глюков может стать больше чем предполагается.

[Darksa]

Идеального инструмента не бывает. Всегда есть частные случаи. Если у вас небольшая компания с маленьким парком оборудования, гипервизором и виртуальными машинами, которые работают исключительно по будним дням — такой способ подстраховаться от потери данных вполне применим. Для критичных сервисов, которые не требуют работы 24/7 это можно организовать как внутри виртуальной машины (все верно, механизм тот же, но возможность сбоя меньше), так и с запланированным выключением ВМ по шедулеру. В таком случае будет обеспечиваться полная консистентность.

[spions]

Чем не устраивает штатная работа backup + github.com/ayufan/pve-patches?

[Darksa]

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

[Iffann]

raw диски виртуалок он сможет бэкапить?
что такое каталог «data»?

[Darksa]

У меня в /data как раз лежали образы виртуальных машин (в формате qcow2).
RAW-диски он бекапить может.

[shashilx]

Не в тему, но о Proxmox — может ктото подскажет решение, чтоб сделать так, как это сделано в Windows Server с Hyper-V — при перезагрузке хоста все виртуалки/контейнеры сохраняли своё состояние и после загрузки его восстанавливали? Т.е. чтобы перезагрузка хоста для гостей всегда была прозрачна.

[fortyseven]

Что это за магия такая расскажите подробнее?

[shashilx]

Что это за магия такая расскажите подробнее?

Всмысле? Какая магия?? Вы о чём?

[fortyseven]

при перезагрузке хоста все виртуалки/контейнеры сохраняли своё состояние и после загрузки его восстанавливали? Т.е. чтобы перезагрузка хоста для гостей всегда была прозрачна.

Я такого ни на одном гипервизоре не видел, кроме VMware с Fault tolerance с кучей ограничений.

[shashilx]

Hyper-V так делает что на Windows Server, что на Windows 8.x/10 — все запущенное даже не будет подозревать что хост перегрузился.

[fortyseven]

Ну это явно какая-то пропиетарщина только для windows on windows.

[shashilx]

Ну это явно какая-то пропиетарщина только для windows on windows.

это то здесь при чём? разговор не о том, проприетарщина или нет, разговор о том как сделать такое же поведение.
qemu может делать suspend виртуалкам/контейнерам. потом перегрузиться и сделать resume. осталось только понять как это всё объяснить делать proxmox'у

[fortyseven]

Так при том. Чтобы такое сделать надо уметь из гипервизора лазить глубоко в ядра гостевых ОС, работать с процессами в гостевых ОС. Очевидно, что сторонним разработчикам это так просто не сделать.

[shashilx]

что за бред я сейчас прочитал? я выше уже сказал — qemu умеет сохранять/восстанавливать состояние виртуалки. осталось это запихнуть в startup/shutdown скрипты.

[HiroX]

Вручную можно. Странно, почему до сих пор нигде нет решения на форуме Proxmox (либо я не нашел).

Если еще актуально, на последней сейчас ProxmoxVE 7.1-10 делается так: в файле /usr/share/perl5/PVE/API2/Nodes.pm ищем функцию $create_stop_worker, в ней строку

$upid = PVE::API2::Qemu->vm_shutdown({node => $nodename, vmid => $vmid, timeout => $timeout, forceStop => 1 });

меняем на

$upid = PVE::API2::Qemu->vm_suspend({node => $nodename, vmid => $vmid, todisk => 1 });

Результат при нажатии перезагрузки ноды:

Контейнеры не умеют в "гибернацию", на VM работает отлично (также как в Hyper-V).

Как будет работать в кластерах не проверял

[Loxmatiymamont]

А почему без ссылки на оригинал?

forums.veeam.com/veeam-agent-for-linux-f41/proxmox-incremental-backups-with-veeam-t66702.html

[KorP]

А-я-я-й, ещё и в корпоративном блоге… как не красиво

[Darksa]

Вы правы, это моя ошибка. Обозначил в начале статьи.