Proxmox: «vzdump backup failed» — 10 реальних причин і як перевіряти по порядку

Швидкий план діагностики (перевірити 1/2/3)

Коли резервна копія не вдається, є дві цілі: (1) відновити успішну копію сьогодні, і (2) запобігти повторенню, не перетворюючи вікно бекапів на проєкт вихідного дня. Найшвидший шлях зазвичай: логи → стан/місце на диску → можливість знімків → транспорт (NFS/CIFS/PBS) → права/блокування.

Перевірка 1: знайти точну точку збою в логах

Не починайте «ламати» сховище навмання. Отримайте перше жорстке повідомлення про помилку і контекст навколо нього.

cr0x@server:~$ ls -1t /var/log/vzdump/*.log | head
/var/log/vzdump/qemu-101.log
/var/log/vzdump/lxc-203.log

cr0x@server:~$ tail -n 80 /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors
TASK ERROR: job errors

Рішення: Якщо ви бачите конкретну помилку типу No space left on device, Permission denied, Input/output error, stale file handle, snapshot failed, зупиніться й ідіть по цій гілці. Якщо бачите лише ERROR: Backup of VM 101 failed - vma: ... без причини, переходьте до розділу «Практичні завдання» нижче і виконайте поглиблені перевірки.

Перевірка 2: підтвердити, що цільове сховище доступне для запису, змонтоване й не переповнене

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active       102400000        12233456        90016644    11.94%
backup        nfs     active      2048000000      2039000000         9000000    99.56%
local-lvm     lvmthin active        500000000       310000000       190000000    62.00%

Рішення: Якщо backup на 99–100% або показує дивно маленьке доступне місце, вважайте його повним. Звільніть місце або виправте квоти/резерви перед подальшими діями.

Перевірка 3: чи пов’язана помилка зі знімком (snapshot) чи з транспортом?

Помилки в режимі snapshot голосні й миттєві. Транспортні проблеми (NFS, PBS, повільні диски) зазвичай виглядають як таймаути, «broken pipe» або «stalled» завдання.

cr0x@server:~$ grep -E "snapshot|freeze|thaw|qmp|lvm|zfs|ceph|rbd|stale|timeout|broken pipe|i/o error" -i /var/log/vzdump/qemu-101.log | tail -n 30
ERROR: vzdump archive creation failed: write error: No space left on device

Рішення: Ключові слова, пов’язані зі знімками, спрямовують вас до перевірок локального драйвера зберігання (LVM-thin/ZFS/Ceph) і guest agent. Транспортні ключові слова — до перевірки мережі NFS/PBS та стану сервера на стороні прийому.

Цікаві факти та контекст (чому це відбувається)

• vzdump з’явився ще до сучасних «PBS‑перших» налаштувань Proxmox. Він починався як простий інструмент dump і виріс у движок робочого процесу, що координує знімки, заморожування й архівацію.
• Резервні копії через знімки — це передусім функція сховища, а вже потім функція Proxmox. Якщо бекенд не вміє надійно робити знімки (або закінчився простір метаданих), vzdump не зможе «змусити це працювати».
• Інтеграція з QEMU guest agent необов’язкова, але наслідки відчутні. Без агента ви отримаєте crash‑consistent резервну копію, але додатки (бази даних) можуть бути нещасливі.
• VMA — це формат архіву VM у Proxmox. Він простий і швидкий, але не чарівний: залежить від стабільного читання з томів та стабільного запису на цільове сховище.
• NFS популярний для бекапів через простоту, і саме тому часто стає точкою відмови: stale handles, soft mounts, retransmits і синдром «вчора працювало».
• ZFS snapshots дешеві; ZFS send не безкоштовний. Вибух знімків і фрагментація dataset можуть непомітно перетворити нічний бекап на інцидент продуктивності.
• У LVM‑thin метадані — це окрема річ, яку можна заповнити. Коли thin metadata досягає 100%, система не «поступово деградує». Вона зупиняється.
• Стиснення змінює форму I/O. zstd зазвичай корисний, але якщо вузол CPU‑завантажений або ціль повільна, стиснення може погіршити таймаути.
• Proxmox використовує файли блокування й журнали завдань, щоб уникнути подвійних бекапів. Коли вузол перезавантажується під час завдання, ці блокування можуть пережити задачу і викликати другорядні помилки.

10 реальних причин «vzdump backup failed» (в порядку перевірки)

1) Цільове сховище переповнене (або фактично переповнене через квоти/резервацію)

Це нудний, але найпоширеніший винуватець. Це не завжди «100%». NFS‑експорти можуть мати квоти на каталог. ZFS datasets можуть мати reservation. PBS‑датаcтори можуть досягати меж GC для чанків. Симптом у vzdump зазвичай «write error» або «No space left on device».

Перевірка: спершу pvesm status, потім перевірте змонтований шлях через df -h. Якщо NFS — перевірте сервера на стороні NAS. Якщо PBS — перевірте використання datastore і налаштування prune.

2) Ціль не змонтована або змонтована неправильно (шлях NFS/CIFS змінився, гонка автозмонту)

Якщо /mnt/pve/backup тимчасово не є NFS шаром під час запуску, vzdump може писати у локальний каталог, або впаде, якщо його немає. Так ви «таємниче» заповнюєте локальний диск, поки бекапи «падають».

Перевірка: mount, findmnt і впевніться, що опції монтування адекватні (hard mount для бекапів, не soft).

3) Створення знімка (snapshot) не вдається (неправильний режим для типу сховища або сховище зараз не може робити знімки)

Режим snapshot вимагає співпраці: LVM‑thin snapshots, ZFS snapshots або Ceph RBD snapshots. Якщо у вас звичайне dir‑сховище без підтримки знімків, snapshot‑режим не дасть очікуваного результату. Якщо LVM‑thin і метадані майже вичерпані — знімки впадуть у потрібний момент.

Перевірка: лог на наявність помилок «snapshot», перевірте тип сховища через pvesm status/pvesm config, і огляньте стан LVM‑thin/ZFS/Ceph.

4) Засівше блокування або залишковий стан завдання блокує роботу

Видалення живлення, ребут вузла, глюк у сховищі — усе це може залишити блокування. Тоді наступний запуск відразу впаде з помилкою «locked». Proxmox захищає ваші диски від одночасних бекапів; він працює на вашу користь, просто галасливо.

Перевірка: список завдань і файли блокувань; також переконайтесь, що VM насправді не виконує бекап.

5) Нестабільність транспорту NFS/CIFS (stale file handle, відображення прав, таймаути)

Помилки NFS рідко ввічливі. Ви бачите «stale file handle», «permission denied», «input/output error» або «server not responding». CIFS/SMB має свою палітру проблем: обертання облікових даних, версії протоколу й дивні блокування файлів.

Перевірка: kernel logs (dmesg), опції монтування, retransmits і логи NAS. Якщо мережа втрачає пакети — бекап стає розподіленим DDoS для вашого терпіння.

6) Проблеми з PBS datastore (права, переповнення, prune/GC не встигає, помилки верифікації)

Бекап у Proxmox Backup Server загалом надійніший за сирі файлові шару, але і тут бувають збої: переповнений datastore, невідповідність прав, прострочені токени, або контенція при верифікації/GC у вікні бекапів.

Перевірка: логи вузла Proxmox покажуть помилки авторизації/HTTP; PBS покаже помилки datastore і chunk store. Не здогадуйтеся — підтвердіть на боці PBS.

7) Проблеми з QEMU Guest Agent / freeze‑thaw викликають зависання або таймаут знімка

Коли потрібна консистентна копія, Proxmox використовує QEMU guest agent для заморожування файлових систем. Якщо агент відсутній, застарів або завис, ви отримаєте таймаути freeze. Примусовий режим дає «працюючі» бекапи з несправними відновленнями.

Перевірка: статус QMP/агента, шукайте повідомлення «fsfreeze», переконайтесь, що сервіс агента всередині гостя працює.

8) Помилки читання на дисках VM (ZFS checksum, Ceph degraded, SSD що помирає)

Бекап читає всі виділені блоки. Саме тому бекапи часто виявляють погане сховище раніше за користувачів. Якщо читання падають, vzdump переривається. Реальна причина — підступні проблеми під Proxmox: помилки ZFS, mdadm, SMART pending sectors або проблеми Ceph PG.

Перевірка: ZFS zpool status, SMART, стан Ceph і kernel I/O помилки.

9) Вузькі місця продуктивності (CPU, IO wait, занадто тісне вікно) викликають таймаути або перекривання завдань

Бекапи, що падають через «timeout», зазвичай — це проблема планування, замаскована під технічну. Пропускна здатність бекапу нижча за швидкість змін, і ви намагаєтесь затиснути це в невідповідне вікно.

Перевірка: затримки I/O, завантаження вузла, тренд тривалості бекапів і чи перекриваються завдання. Потім виправте розклад, паралелізм або сховище — не лог‑повідомлення.

10) Збій в пайплайні VMA/стиснення (broken pipe, tmp заповнений, тиск потоків zstd)

vzdump пропускає дані через інструменти (vma, стиснення, можливо шифрування залежно від цілі). Якщо пайплайн ламається — цільний запис зависає, процес вбито OOM, тимчасове місце заповнене — ви побачите «broken pipe», «killed» або загальні коди помилок.

Перевірка: systemd journal на OOM‑killer, вільна RAM, активність swap і лог бекапу навколо початку стиснення.

Жарт №1: Резервні копії — як парашути: якщо він вам знадобився і не розкрився, ваше післясмертне розслідування буде дуже коротким.

Практичні завдання: команди, значення виводу та рішення

Це навмисно практично. Виконуйте їх у порядку, доки не знайдете «першу реальну помилку». Приклади виводу репрезентативні; ваші рядки можуть відрізнятися. Суть — ваше наступне рішення.

Завдання 1: Швидко ідентифікуйте невдалу задачу і VM/CT

cr0x@server:~$ grep -R "TASK ERROR" -n /var/log/vzdump/ | tail -n 5
/var/log/vzdump/qemu-101.log:68:TASK ERROR: job errors
/var/log/vzdump/lxc-203.log:55:TASK ERROR: job errors

Що це означає: Є логи для кожного гостя. Не дивіться на зведення в GUI; відкрийте конкретний лог для гостя, який впав.

Рішення: Візьміть найновіший невдалий лог і працюйте з ним, перш ніж гнатися за вторинними помилками.

Завдання 2: Витягніть перший рядок ERROR і 30 рядків перед ним

cr0x@server:~$ awk 'BEGIN{e=0} /ERROR:/{e=NR} {a[NR]=$0} END{for(i=e-30;i<=e+5;i++) if(i>0) print a[i]}' /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors

Що це означає: Перший значимий рядок помилок часто є єдиним, що важить.

Рішення: Якщо це пов’язано з записом на ціль, зупиніться і виправте ємність/монтування/права перед тим, як чіпати налаштування знімків.

Завдання 3: Підтвердьте, що Proxmox вважає сховище активним

cr0x@server:~$ pvesm status --storage backup
Name    Type  Status  Total        Used        Available   %
backup  nfs   active  2048000000   2039000000  9000000     99.56%

Що це означає: «active» лише значить «змонтовано» і «відповідає зараз». Це не означає «є місце» або «достатньо швидко».

Рішення: Якщо доступного дуже мало — видаліть старі бекапи або розширте простір. Якщо total виглядає неправильно (наприклад 0) — підозрюйте проблеми з монтуванням.

Завдання 4: Підтвердьте, що монтований шлях реальний (а не локальний каталог)

cr0x@server:~$ findmnt -T /mnt/pve/backup
TARGET         SOURCE               FSTYPE OPTIONS
/mnt/pve/backup 10.10.0.20:/exports/pve-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Що це означає: Якщо SOURCE порожній або виглядає як локальний пристрій, значить ви не змонтовані там, де думаєте.

Рішення: Якщо не змонтовано — не запускайте більше бекапів. Виправте монтування і приберіть «випадкові локальні бекапи», що заповнили вузол.

Завдання 5: Заміряйте реальний вільний простір там, куди пише vzdump

cr0x@server:~$ df -h /mnt/pve/backup
Filesystem                      Size  Used Avail Use% Mounted on
10.10.0.20:/exports/pve-backup  2.0T  2.0T  9.0G 100% /mnt/pve/backup

Що це означає: Діагностика завершена. Місця немає.

Рішення: Обріжте старі бекапи, перемістіть частину даних або розширте хранилище. Потім запустіть один бекап вручну, щоб підтвердити.

Завдання 6: Перевірте неприємні сюрпризи квот/резервацій (поширено на ZFS‑бекап серверах)

cr0x@server:~$ zfs get -o name,property,value,source quota,reservation,refquota,refreservation tank/pve-backup
NAME            PROPERTY         VALUE  SOURCE
tank/pve-backup quota            2T     local
tank/pve-backup reservation      none   default
tank/pve-backup refquota         none   default
tank/pve-backup refreservation   none   default

Що це означає: Квота dataset може зробити файлову систему «повною», хоча пул має місце.

Рішення: Якщо квота вузька — збільшіть її або реалізуйте pruning відповідно до політики ретенції.

Завдання 7: Виявлення помилок транспорту NFS у kernel логах

cr0x@server:~$ dmesg -T | egrep -i "nfs|stale|server not responding|timed out|rpc" | tail -n 20
[Thu Dec 26 02:05:11 2025] NFS: server 10.10.0.20 not responding, still trying
[Thu Dec 26 02:05:44 2025] NFS: server 10.10.0.20 OK

Що це означає: Ваша «проблема зі сховищем» може насправді бути втратою пакетів, перевантаженням або завантаженістю NAS.

Рішення: Якщо ви бачите це під час вікон бекапів, трактуйте мережу і продуктивність NFS‑сервера як перший клас залежностей бекапу.

Завдання 8: Виявити застряглі або накладені завдання vzdump

cr0x@server:~$ pgrep -a vzdump
21984 /usr/bin/perl /usr/bin/vzdump 101 --storage backup --mode snapshot --compress zstd

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 5
┌──────────────┬───────────────────────────────┬───────────┬──────────┬─────────┬──────────────┐
│ upid         │ starttime                     │ type      │ status   │ user    │ id           │
╞══════════════╪═══════════════════════════════╪═══════════╪══════════╪═════════╪══════════════╡
│ UPID:node... │ 2025-12-26T02:00:01Z          │ vzdump    │ running  │ root@pam│ 101          │
└──────────────┴───────────────────────────────┴───────────┴──────────┴─────────┴──────────────┘

Що це означає: Задача ще працює; лист‑повідомлення про «збиток» міг прийти від іншого гостя або попередньої спроби.

Рішення: Якщо вона справді застрягла (немає прогресу, сховище замерзло), можливо, треба зупинити задачу і обережно прибрати блокування.

Завдання 9: Перевірте блокування бекапу на гості

cr0x@server:~$ qm config 101 | egrep -i "lock|backup"
lock: backup

Що це означає: Proxmox вважає, що бекап виконується (або був перерваний).

Рішення: Підтвердіть, що немає реально працюючого процесу vzdump. Якщо його нема — зніміть блокування.

cr0x@server:~$ qm unlock 101
OK

Завдання 10: Підтвердьте можливість знімків і тип сховища для дисків VM

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|ide|sata"
scsi0: local-lvm:vm-101-disk-0,size=80G

cr0x@server:~$ pvesm status --storage local-lvm
Name      Type    Status  Total       Used       Available  %
local-lvm lvmthin active  500000000   310000000  190000000  62.00%

Що це означає: LVM‑thin підтримує знімки, але лише якщо thin metadata здорова.

Рішення: Якщо у вас dir сховище (не LVM‑thin/ZFS/Ceph) і ви вимагаєте snapshot‑режим — готуйтеся до розчарувань.

Завдання 11: Перевірте використання метаданих LVM‑thin (тихий вбивця знімків)

cr0x@server:~$ lvs -a -o+seg_monitor,metadata_percent,lv_size,data_percent vg0
  LV                VG   Attr       LSize   Pool     Data%  Meta%  Monitor
  data              vg0  twi-aotz--  465.76g          68.12  98.77  monitored

Що це означає: Meta% близько 99% — червоний сигнал. Знімки й алокації можуть раптово впасти.

Рішення: Розширте thin metadata LV (якщо так задумано) або зменшіть churn. Не «чекайте, поки само розсмокчеться» — не розсмокчеться.

Завдання 12: Перевірте стан ZFS пулу, якщо диски VM на ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 00:12:44 with 2 errors on Thu Dec 26 01:10:02 2025
config:
        NAME        STATE     READ WRITE CKSUM
        rpool       DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     2

Що це означає: Помилки контрольних сум під час scrub — не просто попередження. Бекапи, що читають усе, швидше за все натраплять на ту ж корупцію.

Рішення: Замініть/виправте проблемний пристрій, відновіть уражені дані з відомо хороших копій і тільки потім довіряйте бекапам знову.

Завдання 13: Перевірте стан Ceph, якщо використовуєте RBD

cr0x@server:~$ ceph -s
  cluster:
    id:     2c1b2d24-aaaa-bbbb-cccc-6f4f3b2d1b2a
    health: HEALTH_WARN
            Degraded data redundancy: 12/3456 objects degraded
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   3 pools, 256 pgs
    objects: 1.15M objects, 4.2 TiB
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     10 degraded, 5 undersized

Що це означає: Degraded/undersized PGs можуть уповільнювати або ламати знімки, а читання можуть застопоритися.

Рішення: Виправте стан Ceph в першу чергу. «Бекапувати більше» — це не стратегія ремонту сховища.

Завдання 14: Підтвердьте статус guest agent (для freeze/thaw і кращої консистентності)

cr0x@server:~$ qm agent 101 ping
QEMU guest agent is running

cr0x@server:~$ qm agent 101 fsfreeze-status
thawed

Що це означає: Агент доступний і може повідомити стан заморожування файлових систем.

Рішення: Якщо агент не відповідає — виправте його всередині VM або змініть очікування (crash‑consistent бекап). Не прикидайтесь, що маєте application‑consistent знімки, якщо агента нема.

Завдання 15: Виявлення OOM‑kill або загибелі процесів стиснення

cr0x@server:~$ journalctl -k --since "2025-12-26 01:50" | egrep -i "oom|killed process" | tail -n 20
Dec 26 02:03:22 node kernel: Out of memory: Killed process 22311 (zstd) total-vm:8123456kB, anon-rss:2147488kB, file-rss:0kB, shmem-rss:0kB

Що це означає: Пайплайн бекапу вмер, бо ядру потрібна була пам’ять більше, ніж вашому бекапу.

Рішення: Знизьте рівень/потоки стиснення, рознесіть завдання у часі, додайте RAM або перенесіть стиснення поза вузол (PBS допоможе). Інакше ви будете «успішно падати» щоночі.

Завдання 16: Протестуйте швидкість запису до цільового сховища (не бенчмаркуйте вічно)

cr0x@server:~$ dd if=/dev/zero of=/mnt/pve/backup/.pve-write-test bs=16M count=128 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18 s, 119 MB/s
128+0 records in
128+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18.0832 s, 119 MB/s

cr0x@server:~$ rm -f /mnt/pve/backup/.pve-write-test

Що це означає: Якщо ви бачите однозначні MB/s на системі, що раніше робила 200 MB/s — у вас регрес продуктивності.

Рішення: Виправте мережу, NAS або конкуренцію за ресурси. Або підлаштуйте паралелізм бекапів, щоб вікно було реалістичним.

Завдання 17: Запустіть ручний бекап одного гостя з максимальною деталізацією і мінімальною конкуренцією

cr0x@server:~$ vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}' --stdout 0
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template {{guestname}} {{vmid}} --stdout 0
INFO: issuing guest-agent 'fsfreeze-freeze'
INFO: creating snapshot 'vzdump'
INFO: starting kvm to execute backup task
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-03_10_01.vma.zst'
INFO: issuing guest-agent 'fsfreeze-thaw'
INFO: archive file size: 14.32GB
INFO: Finished Backup of VM 101 (00:05:54)
INFO: Backup job finished successfully

Що це означає: Контрольований одноразовий запуск показує, чи проблема системна або викликана конкуренцією/розкладом.

Рішення: Якщо вручну працює, а нічний job падає — виправляйте розклад, конкуренцію за ресурси або параметри завдання, а не VM.

Жарт №2: Єдина річ більш надійна, ніж невдалий job бекапу — це тема листа, яка каже, що він «успішно впав».

Три міні-історії з корпоративного життя (анонімні, правдоподібні і болючі)

Міні-історія 1: Хибне припущення (NFS — «просто диск»)

У них був акуратний кластер Proxmox для внутрішніх додатків: CI‑ранери, кілька баз даних і купа «тимчасових» VM, які були тимчасовими вже три роки. Бекапи йшли на NFS‑share на NAS‑пристрої. Нічого екзотичного. Працювало, поки перестало.

Припущення було простим: «Якщо сховище активне — воно змонтоване, отже бекапи потрапляють на NAS». Це майже правда. Проблема була в тому, що NFS share іноді не монтувався при завантаженні через порядок залежностей systemd, залишаючи /mnt/pve/backup як пустий локальний каталог. Job бекапу записував локально, потім падав, коли локальний диск заповнювався. Деякі ночі «працювало» (писало локально й не заповнювало диск). NAS виглядав невинним.

Інженер на виклику тиждень ганявся за NAS: прошивка, диски, навантаження, мережа. Тим часом локальний диск одного вузла потихеньку заповнювався частковими файлами .vma.zst. Справжня підказка була в логах: «filesystem type on dumpdir is ‘ext4’» у погані ночі і «nfs» у хороші. Лог говорив правду — ніхто не слухав.

Виправлення було просте: забезпечити порядок монтування (systemd dependencies), додати моніторинг, який сповіщає, якщо тип файлової системи для бекапу неочікуваний, і робити job провалюваним, якщо монтування відсутнє. Також вони почистили локальні «фантомні бекапи» і додали ретеншн, щоб NAS не доходив до 99% завантаження.

Урок: ставтеся до мережевого сховища як до мережевої залежності, а не до каталогу, який сьогодні випадково працює.

Міні-історія 2: Оптимізація, що призвела до удару (стиснення стало DDoS)

Інша організація захотіла зменшити витрати на зберігання бекапів. Хтось увімкнув zstd з вищим рівнем і дозволив кілька паралельних vzdump job. У тесті виглядало добре: один VM став меншим за розміром і не зайняв значно більше часу. Усі поїхали додому задоволені.

У продакшні вузол мав мішані навантаження. Під вікном бекапів CPU підскочив, IO wait виріс, а latency‑чутливі сервіси почали таймаути. Бекапи почали падати з «broken pipe» і іноді «killed process». Найгірші ночі — OOM‑killer вбивав процес стиснення. У другу найгіршу ніч — брали щось цікавіше.

Оптимізація базувалася на хибній моделі: «стиснення знижує I/O, отже полегшує систему». Стиснення зменшує байти по мережі й на диску, але вимагає CPU і пам’яті. Якщо вузол вже завантажений — стиснення додає навантаження.

Виправили, зменшивши конкуренцію, знизивши рівень стиснення до розумного, рознесли великі гості в окреме вікно. Також перенесли частину бекапів на PBS, де chunking і дедуп змінюють економіку. Вузол перестав робити стільки важкої роботи під час піків.

Урок: «оптимальна» настройка — та, що завершиться надійно, не шкодячи продакшну. Менші архіви — мило; надійне відновлення — важливіше.

Міні-історія 3: Скучна практика, що врятувала день (scrub, SMART та тестові відновлення)

Ця команда експлуатувала Proxmox на ZFS. Нічого особливого: дзеркальні SSD для ОС, більший пул для VM. Вони були «нудні» у найкращому сенсі: щотижневі scrub, перевірка SMART і щомісячний drill з відновлення у відокремленій мережі. Drill всім не подобався. Він займав час. Створював тикети. Та саме завдяки йому вони не мали інцидентів із «жаль» у звітах.

Одної п’ятниці бекапи почали падати для конкретного VM з загальною помилкою читання. Додаток працював. Користувачі були задоволені. На черзі був понеділок, але вони перевірили zpool status і побачили помилки контрольних сум. Scrub підтвердив кілька поганих блоків на одному SSD. Ніяких червоних ламп, жодних драм — просто ранні ознаки.

Вони замінили пристрій у планове вікно. Потім провели drill: відновили вчорашній бекап у sandbox, підняли і перевірили базові функції. Воно працювало. Це підтвердило ланцюжок бекапу і процедуру відновлення, а не лише наявність файлів архівів.

Скупі практики окупилися двічі: по‑перше — виявили деградацію до того, як вона стала втратою даних, по‑друге — довели, що бекапи реально відновлюються.

Цитата (парафраз): Werner Vogels (CTO Amazon) підкреслював ідею «проектувати систему під відмови», а не припускати, що компоненти не зламаються. (парафраз)

Типові помилки: симптом → корінь → виправлення

1) «Сховище бекапів активне», але бекапи заповнюють локальний диск

Симптоми: використання локального диска зростає; сховище бекапів виглядає нормально; у логах vzdump згадується ext4 замість nfs; архіви з’являються під /mnt/pve/backup, але цей шлях локальний.

Корінь: ціль не змонтована або монтування тимчасово впало; каталог існує локально.

Виправлення: забезпечити залежності монтування, сповіщення при невідповідності типу файлової системи за допомогою findmnt, робити job провальним, якщо монтування відсутнє. Прибрати локальні випадкові файли.

2) Snapshot‑режим падає лише для деяких гостей

Симптоми: «snapshot failed» або «unable to create snapshot» для одного VM; інші проходять.

Корінь: цей гість має диск на сховищі без підтримки знімків (наприклад, dir), або має неочікувану конфігурацію (raw mapping), або thin metadata вичерпані на момент створення знімка.

Виправлення: перемістіть диски на snapshot‑сумісне сховище; виправте тиск на metadata LVM‑thin; перевірте конфіг через qm config і тип сховища.

3) «stale file handle» на NFS під час бекапу

Симптоми: vzdump падає під час запису; kernel логи показують stale handle; іноді вирішується ремонтом.

Корінь: експорт змінився, сервер перезавантажився, підлегла ФС перереекспортувалася або агресивне обслуговування NAS. Іноді викликано знімком файлової системи на NAS.

Виправлення: стабілізуйте експорти; уникайте зміни кореня експорту; використовуйте hard mounts; координуйте maintenance NAS поза вікном бекапів; ремонтуйте й перезапускайте спробу.

4) «Permission denied», хоча шар writable з shell

Симптоми: вручну ви можете touch, але vzdump падає при створенні архіву.

Корінь: root‑squash на NFS, неправильна власність у цільовій директорії або job пише в підкаталог з іншими правами.

Виправлення: перевірити опції експорту на сервері; встановити правильні права власності на директорію дампу; використовувати консистентне відображення UID/GID.

5) Код виходу 1 з «broken pipe»

Симптоми: в логу згадується «broken pipe» під час стиснення або створення архіву.

Корінь: downstream writer помер: ціль застіла/відключена, закінчилось місце або процес вбитий (OOM).

Виправлення: перевірте OOM‑kill; логи цільового сховища і вільне місце; зменшіть стиснення або конкуренцію; виправте нестабільний транспорт.

6) Бекапи успішні, але відновлення повільне або падає при верифікації

Симптоми: бекапи завершуються, але відновлення повільне або верифікація падає (поширено з PBS, якщо datastore хворий).

Корінь: деградація підлеглої інфраструктури, проблеми з chunk store або прихована корупція, виявлена пізніше.

Виправлення: регулярно перевіряйте стан datastore; робіть scrubs/SMART; періодично виконуйте тестові відновлення.

7) Бекапи таймаутять тільки в робочі години

Симптоми: job зависає/застигає; NFS «server not responding»; Ceph latency стрибає; IO wait зростає.

Корінь: конкуренція. Бекапи змагаються з продукційним навантаженням на одному сховищі/мережі.

Виправлення: перенесіть бекапи на позапіковий час, обмежте паралельність, ізолюйте трафік бекапів або покращіть вузьке місце (часто мережа або CPU NAS).

Чеклісти / покроковий план

Крок за кроком: добийтеся успіху в сьогоднішньому бекапі

1. Відкрийте конкретний лог: /var/log/vzdump/qemu-<vmid>.log або lxc-<ctid>.log. Знайдіть перший значимий ERROR:.
2. Підтвердьте цільове сховище: pvesm status та df -h /mnt/pve/<storage>.
3. Перевірте реальність монтування: findmnt -T /mnt/pve/<storage>. Якщо тип/джерело неочікувані — зупиніться і виправте.
4. Швидко звільніть простір, якщо потрібно: видаліть або перемістіть старі бекапи за політикою ретенції. Не робіть «rm -rf everything», якщо цінуєте кар’єру.
5. Перевірте блокування: qm config <vmid> на lock: backup; знімайте qm unlock тільки після перевірки, що жодної задачі немає.
6. Якщо помилки зі знімками: перевірте LVM‑thin metadata (lvs ... metadata_percent) або стан ZFS/Ceph.
7. Запустіть один ручний бекап: vzdump <vmid> --storage ... --mode snapshot щоб довести виправлення. Не чекайте на запланований job «можливо спрацює».
8. Задокументуйте причину: один рядок: «Backup failed because X; verified by Y; fixed by Z; validated by manual backup.» Ваше майбутнє «я» вам віддякує за каву.

Крок за кроком: запобігання повторенню (зменшення ймовірності)

1. Резерв місця: тримайте ціль бекапів під ~80–85% використання. Вище — все стає крихким: фрагментація, GC‑тиск, сюрпризи з квотами.
2. Робіть помітними відмови монтування: моніторте findmnt і сповіщайте, якщо джерело/тип файлової системи змінився.
3. Контролюйте конкуренцію: менше паралельних бекапів часто означає більше успіхів. Налаштовуйте під завершення, а не під теоретичну пропускну здатність.
4. Виділіть важкі гості: плануйте великі БД чи файлові сервери в окреме вікно. Вони домінують над I/O і роблять інших підозрілими.
5. Рутинні перевірки стану сховища: ZFS scrub, моніторинг SMART, gating Ceph health. Бекапи не повинні бути вашим першим сигналом про відмову диска.
6. Періодичні тестові відновлення: доводьте, що ви можете відновити і завантажити, а не лише записати архіви.

Чит‑шит порядок операцій (для друку)

1. Лог показує space/permission/IO? Виправте саме це першим.
2. Підтвердіть, що монтування реальне та стабільне (NFS/CIFS/PBS).
3. Перевірте шар знімків (LVM‑thin meta%, ZFS pool, Ceph health).
4. Перевірте блокування і застряглі завдання.
5. Перевірте регрес продуктивності (dd тест + dmesg + iostat, якщо використовуєте).
6. Перезапустіть один бекап вручну для підтвердження.

FAQ

1) Де знаходяться реальні логи vzdump у Proxmox?

Дивіться в /var/log/vzdump/. Зазвичай є по одному логу на гостя за запуск (наприклад, qemu-101.log, lxc-203.log). Подання задач у GUI — це зведення, не повна історія.

2) Чому vzdump каже «backup failed», хоча файл архіву існує?

Тому що створення файлу — не визначення успіху. Job може впасти після запису (крок верифікації, фіналізація, flush, права на тимчасові файли або post‑hooks). Перевірте кінець логу на фінальну помилку і чи виглядає розмір архіву правдоподібним.

3) Який режим краще: snapshot чи stop?

Snapshot‑режим — за замовчуванням і з причин: він уникає простоїв. Використовуйте stop‑режим для гостів, які не можуть коректно робити знімки (рідко) або коли сховище не підтримує знімки і вам важливіше коректне резервування, ніж аптайм.

4) Що означає «lock: backup» і чи безпечно розблокувати?

Це означає, що Proxmox вважає, ніби бекап виконувся або був перерваний. Розблоковувати безпечно лише після підтвердження, що ніякий процес vzdump для цього гостя не працює і немає активної операції зі знімком на сховищі. Інакше ризикуєте отримати неконсистентний стан.

5) Як зрозуміти, NFS проблема чи локальний диск?

Два швидкі підказки: findmnt -T /mnt/pve/backup (чи змонтовано з правильного сервера?), і dmesg -T на предмет помилок NFS під час вікна бекапу. Якщо тип файлової системи у логах vzdump неправильний — це не NFS, ви пишете локально.

6) Чому бекапи виявляють корупцію сховища раніше за користувачів?

Бо бекапи читають багато і послідовно по всіх дисках VM. Регулярні робочі навантаження можуть торкатися лише «гарячих» областей і ніколи не натрапити на поганий блок. Бекап — ненавмисний тест цілісності — не ігноруйте цей сигнал.

7) Чи завжди краще сильніше стиснення для бекапів?

Ні. Сильніше стиснення зменшує місце й мережевий трафік, але збільшує навантаження на CPU і пам’ять і може робити завдання довшими або перекритими. Обирайте налаштування, що завершуються надійно у вашому вікні.

8) Що робити, якщо PBS‑бекапи падають, а NFS‑бекапи працюють (або навпаки)?

Зазвичай це вказує на проблему на стороні цілі: авторизація/токен, переповнення datastore, контенція верифікації/GC у PBS або проблеми експорту/прав на NFS. Розділіть систему: підтвердіть мережу вузол→ціль і перевірте логи та стан самої цілі.

9) Як довести виправлення без очікування до завтра?

Запустіть ручний бекап одного показового гостя одразу після зміни. Якщо нічний job падатиме через конкуренцію, запустіть два паралельно і подивіться, чи повертається помилка. Доказ краще за надію.

10) Яка найефективніша звичка для надійності бекапів?

Періодичні тестові відновлення за графіком. Не раз і не після інциденту. Регулярно. Бекапи дійсні настільки, наскільки останнє успішне відновлення.

Висновок: наступні кроки, що реально зменшують тривоги

Коли Proxmox каже «vzdump backup failed», він не такий уже загадковий; він повідомляє, що зламався ланцюжок залежностей. Найшвидше виправлення — знайти першу конкретну помилку в логах по гостю, підтвердити, що цільове сховище реальне й доступне для запису, а потім перевірити можливість знімків і стан сховища перед тим, як чіпати налаштування.

Зробіть ці кроки, у такому порядку:

1. Додайте перевірку монтування: тип файлової системи й джерело перед запуском бекапів, і сповіщення при зміні.
2. Забезпечте резервний простір: політика ретенції/prune, зрозумілі квоти і суворе правило «стоп на 85%».
3. Аудитуйте готовність до знімків: (LVM‑thin metadata percent, стан ZFS пулу, Ceph health) і блокуйте бекапи, якщо платформа деградована.
4. Підігнайте конкуренцію та стиснення: щоб завдання завершувалися надійно. Ваша віконна пропускна здатність — бюджет; не перевитрачайте його.
5. Плануйте drill відновлення: ставте їх як пожежні тривоги: дратують, але необхідні, і різниця між контрольованою подією і катастрофою.