Proxmox VE надає вбудований інструмент vzdump для резервного копіювання VM і LXC-контейнерів. Розклад налаштовується через веб-інтерфейс або CLI і підтримує гнучкі політики зберігання (retention).

Режими бекапу

Режим	Опис	Вплив на VM	Коли використовувати
snapshot	Знімок + бекап на льоту	Без зупинки	Продакшн VM (KVM)
suspend	Заморожування, бекап, відновлення роботи	Короткочасна пауза	Консистентний бекап
stop	Зупинка, бекап, запуск	Повна зупинка	Найнадійніший варіант

Налаштування розкладу через веб-інтерфейс

Перейдіть у Datacenter → Backup → Add:

Node: обрати ноду або All
Storage: вказати PBS або локальне сховище
Schedule: обрати час (наприклад, 00:00 для нічного бекапу)
Selection: All, Pool або конкретні VM
Mode: snapshot / suspend / stop
Retention: кількість бекапів для зберігання

Налаштування через CLI (vzdump)

# Ручний бекап VM 100 у PBS
vzdump 100   --storage my-pbs   --mode snapshot   --compress zstd   --notes-template "{{guestname}} - {{node}}"

# Бекап усіх VM на ноді
vzdump --all 1 --storage my-pbs --mode snapshot

# Бекап у локальний файл
vzdump 100 --dumpdir /mnt/backup --mode stop

Retention Policy (політика зберігання)

PBS підтримує гнучке керування кількістю збережених бекапів:

# Приклади retention у /etc/vzdump.conf або налаштуваннях завдання
# 7 щоденних + 4 щотижневих + 3 щомісячних
keep-daily 7
keep-weekly 4
keep-monthly 3

# Через API
pvesh set /cluster/backup/1   --keep-daily 7   --keep-weekly 4   --keep-monthly 3   --keep-yearly 1

Глобальна конфігурація vzdump

# /etc/vzdump.conf
storage: my-pbs
mode: snapshot
compress: zstd
bwlimit: 0
ionice: 7
lockwait: 3
stopwait: 10
tmpdir: /var/tmp

Бекап зі сповіщеннями: Proxmox VE 9 підтримує надсилання сповіщень про результати бекапу через email, Gotify, ntfy. Налаштуйте в Datacenter → Notifications.

Тестуйте відновлення! Регулярно перевіряйте, що бекапи можна відновити. Непомічена проблема з бекапом — це відсутність бекапу.

Типові помилки vzdump і їхні причини

Під час регулярних бекапів час від часу трапляються одні й ті самі помилки — розберемо три найчастіші і як відрізнити їх одна від одної. Усі три видно у виведенні завдання бекапу в веб-інтерфейсі (Datacenter → Tasks) або в журналі /var/log/vzdump/, тож перший крок діагностики — читати точний текст помилки, а не лише код повернення завдання.

VM 100 qmp command 'guest-fsfreeze-freeze' failed - got timeout
ERROR: Backup of VM 100 failed - unable to open file '/var/tmp/vzdumptmp1024_100.tmp' - No space left on device
INFO: skipping vzdump.lock: unable to acquire lock - got timeout after 3 seconds

guest-fsfreeze-freeze failed: qemu-guest-agent не відповідає або не встановлений усередині VM — режим suspend не може заморозити файлову систему. Встановіть агент і увімкніть його в налаштуваннях VM: qm set 100 --agent 1.
No space left on device: тимчасовий каталог (за замовчуванням /var/tmp) заповнений. Вкажіть окремий tmpdir у /etc/vzdump.conf з достатнім місцем.
unable to acquire lock: попереднє завдання бекапу цієї самої VM ще виконується. Перевірте активні завдання через pvesh get /nodes/pve/tasks і дочекайтеся завершення або зніміть завислий lock вручну.

На практиці ці три помилки повторюються хвилями: після оновлення Proxmox, після перенесення каталогу тимчасових файлів на інший розділ або після додавання нової великої VM до спільного розкладу — варто перевіряти саме ці місця в першу чергу.

Коли vzdump не підходить

Вбудований інструмент закриває більшість сценаріїв, але є випадки, де потрібен інший підхід — розуміння меж застосовності економить час на розборі проблем, які vzdump у принципі не вирішує.

Бази даних з високим транзакційним навантаженням: режим snapshot не гарантує консистентність на рівні застосунку — перед бекапом запускайте штатний дамп СУБД (pg_dump, mysqldump).
Вимога RPO в одиниці хвилин: vzdump — це повнообсягове копіювання за розкладом, а не безперервна реплікація; для хвилинного RPO потрібна ZFS-реплікація між нодами.
Дуже великі VM на повільному каналі до PBS: перший повний бекап може тривати години — плануйте вікно обслуговування заздалегідь.

Перевірка результату бекапу

Успішний лог ще не означає, що бекап придатний для відновлення — перевіряйте окремо.

# Статус останніх завдань бекапу
pvesh get /nodes/pve/tasks --typefilter vzdump --limit 5

# Список точок відновлення в PBS
proxmox-backup-client snapshot list --repository pbs:backup-store

# Пробне відновлення у тимчасовий VM ID
qmrestore pbs:backup/vm/100/2025-03-15T01:00:00Z 999 --storage local-lvm
qm destroy 999 --purge

Якщо тестове відновлення проходить без помилок і VM 999 стартує — бекап робочий; таку перевірку варто робити раз на місяць на реальних бекапах, а не покладатися лише на зелений статус завдання в інтерфейсі. Детальніше про відновлення — у статті відновлення VM з бекапу.