Швидкість відновлення в Proxmox: налаштування PBS, вибір стиснення та чому відновлення повільні

November 20, 2025 • February 3, 2026 • Читання: 5 хв • Views: 13

Було корисно?

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

Proxmox Backup Server (PBS) спроєктований для ефективного прийому даних, дедуплікації та безпечного зберігання.
Відновлення — це інше навантаження. Воно карає вашу найслабшу ланку: випадкові читання, пошук метаданих, декомпресію,
перевірку контрольних сум і мережевий шлях, який раптом починає значити. Ось звідки береться «бекупи швидкі, відновлення повільні».

Як насправді працює відновлення PBS (і чому це не просто «скопіювати файл назад»)

PBS — це не тупий репозиторій tar-файлів. Це контент-адресований сховищний шар з дедуплікацією та інкрементними бекапами.
Під час бекапу клієнт розбиває дані на чанки, обчислює контрольні суми, стискає чанки й відправляє «нові» чанки на сервер.
Це в основному послідовні записні операції плюс хешування. Сучасні системи люблять послідовні записи.

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

Конвеєр відновлення (ментальна модель)

PVE host запитує у PBS вміст снапшоту (через proxmox-backup-client / інтегровані інструменти).
PBS читає метадані чанків, знаходить файли чанків, читає їх із datastore, перевіряє контрольні суми.
PBS декомпресує чанки (залежно від того, як дані зберігалися).
PVE host приймає потік і записує його у цільове сховище (ZFS, LVM-thin, Ceph, каталог тощо).
Цільове сховище виконує свою роботу: алокацію, copy-on-write, перевірку сум, поведінку parity/TRIM тощо.

Швидкість відновлення — це по суті мінімум із чотирьох обмежувачів:
читання datastore IOPS/пропускна здатність, CPU для декомпресії/перевірок,
мережевий канал/затримка і поведінка запису цільового сховища.
Достатньо однієї слабкої ланки, щоб усе погіршилося.

Одна з неприємних істин: «швидкість бекапу» часто обмежується швидкістю змін, вигодами стиснення та ефективністю дедуплікації.
«Швидкість відновлення» обмежується тим, як швидко можна відтворити весь образ, а не лише дельту.

Цікаві факти та історичний контекст (бо системи не стали дивними випадково)

Дедуплікація стала мейнстримом в корпоративних бекапах у середині–кінці 2000-х, бо диски подешевшали за стрічки, а WAN був болючим.
Контент-адресоване зберігання (збереження блоків за хешем) має коріння в дослідницьких системах, але піднялося з інструментами типу Git через надійність і підтримку дедуплікації.
Сучасні дефолтні компресори зрушили з gzip на zstd наприкінці 2010-х, бо zstd дає хороше стиснення та значно швидший декод, ніж старі кодеки.
«Інкремент назавжди» бекапи часто оптимізують вікно бекапу, а не вікно відновлення; шлях відновлення може стати купою індексацій.
ZFS популяризував end-to-end перевірки суми в масовому зберіганні; це добре для коректності, але кожна сума — це CPU-робота під час відновлення.
Пенальті RAID5/6 при записі всім відомі; менш відомо, що parity RAID також може бути не вражаючим при випадкових читаннях під навантаженням.
NVMe змінив очікування щодо «швидкості диска», тож багато команд тепер звинувачують мережу першими — іноді помилково, іноді правильно.
Джоби верифікації бекапів з’явилися як реакція на мовчазну корупцію даних у 1990-х–2000-х; вони корисні, але можуть конфліктувати з відновленнями.

Цитата, яку люди в операціях повторюють не просто так: Надія — не стратегія. — генерал Гордон Р. Салліван.
План відновлення, що спирається на «воно буде достатньо швидким», — це просто надія з рядком у бюджеті.

Швидкий план діагностики (знайти вузьке місце за кілька хвилин)

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

Перше: чи це сторона читання PBS, мережа чи сторона запису цілі?

Перевірте реальну пропускну здатність на обох кінцях. Якщо диски PBS завантажені, а хост-ціль проста, ви обмежені читанням. Якщо мережа насичена — це мережа. Якщо цільове сховище зайняте (високий iowait), а PBS в нормі — це запис.
Перевірте CPU. Якщо один ядро гаряче, а інші спокійні під час відновлення, можливо, обмеження в однопоточності (декомпресія, контрольні суми чи драйвер сховища).
Перевірте конкуренцію. Якщо на PBS виконуються GC/verify/prune, ви можете конкурувати самі з собою. Зупиніть фонові роботи під час аварійного відновлення.

Друге: чи datastore поводиться як «багато дрібних читань» чи як «великі послідовні читання»?

Якщо ваш PBS datastore на HDD RAID і ви бачите низькі MB/s зі значним IOPS тиском, випадкові читання чанків б’ють по вас.
Якщо на SSD/NVMe і все одно повільно — дивіться CPU, шифрування/компресію або проблеми з offload мережі.

Третє: чи цільове сховище — мовчазний злодій?

ZFS з маленьким recordsize, активним sync або неправильним ashift може зробити записи сумними.
LVM-thin під тиском метаданих може провалити продуктивність.
Відновлення в Ceph/RBD має свої реалії реплікації та backfill.

Жарт №1: Відновлення — як пожежна тривога, тільки будинок насправді горить і всі раптом пригадують, що мають «питання».

Вибір стиснення: zstd проти lzo проти без стиснення і за що насправді платять відновлення

Стиснення — це найменш зрозумілий регулятор у системах бекапу. Команди вибирають алгоритм за вікном бекапу,
потім дивуються в день відновлення, коли приходить «відсотки й відсотки заборгованості».

Що ви обмінюєте

CPU: стиснення і декомпресія коштують циклів. Декомпресія зазвичай дешевша за стиснення, але не безкоштовна.
Мережа: стиснуті дані зменшують байти на дроті; це може значно покращити відновлення, якщо ви обмежені мережевою пропускною здатністю.
Дискова підсистема datastore: менше байтів для читання допомагає, якщо ви обмежені пропускною здатністю, але якщо ви обмежені випадковими читаннями, CPU може стати наступним вузьким місцем.
Ефективність дедуплікації: деякі стратегії стиснення взаємодіють із чанкуванням/дедупом. Здебільшого чанкування роблять на сирих даних, а потім стискають чанки — це зберігає дедуплікацію.

Правило великого пальця, що зазвичай працює в продакшені

zstd (помірні рівні) — розумний дефолт. Хороше стиснення, швидкий декод і дружнє відновлення.
lzo може приваблювати низьким навантаженням на CPU, але ви платите більшими обсягами даних (більше читань, більше мережі). На 10GbE+ це ще може бути прийнятно; на 1GbE часто боляче.
без стиснення рідко є відповіддю, хіба ви критично обмежені CPU і маєте надлишкові диски та мережу.

Реальність відновлення: пастка «швидкий бекап, повільне відновлення» при стисненні

Часто підвищують рівень стиснення, щоб зменшити обсяг збереження. Це може обернутися проти вас.
Відновлення вимагає декомпресії всього датасету, який ви хочете повернути, а не лише змінених блоків. Якщо CPU PBS скромний
і ви обрали агресивне стиснення, під час відновлення ви можете опинитися обмежені CPU на сервері.

Краща практика нудна: обирайте налаштування стиснення, що тримають і бекап, і відновлення в межах вашого RTO.
Потім перевіряйте це реальними тестами відновлення, а не відчуттями.

Шлях зберігання має значення: диски datastore PBS, ZFS, RAID, SSD і міфи про кеш

Продуктивність PBS в основному залежить від datastore. Не від UI. Не від каталогу. Від datastore — де лежать файли чанків.
Якщо ви зберігаєте datastore на повільних дисках, відновлення вам це нагадає.

I/O-патерни datastore PBS простими словами

Прийом бекапу: багато послідовних-ish записів нових чанків плюс оновлення метаданих.
Відновлення: багато читань файлів чанків, що може бути частково послідовним, але часто стає «з великою кількістю seeks» залежно від розподілу чанків і історії дедуплікації.
Верифікація: читає багато чанків для підтвердження цілісності; вона безпосередньо конкурує з відновленням за пропускну здатність читання.
GC (сміттєзбирання): може виконувати значну роботу з метаданими і дискові читання; це не безкоштовно.

Особливості ZFS (бо більшість PBS коробок в кінці кінців на ZFS)

ZFS може бути відмінним для PBS: перевірки сум, снапшоти й передбачувана поведінка. Але важливо розуміти, як ZFS алокує й кешує.
Datastore PBS — це файлове навантаження з великою кількістю читань і звернень до метаданих. Це тиск на ARC і потенційно поведінку з маленькими блоками читання.

Розмір ARC: достатній обсяг RAM допомагає метаданим і гарячим чанкам. Недостатньо RAM — більше дискових читань і повільніші відновлення.
Recordsize: для файлової системи, що зберігає файли чанків, дефолтний recordsize часто підходить. Не міняйте recordsize навмання, якщо ви не знаєте розподіл розмірів чанків і не виміряли наслідки.
SLOG: зазвичай не має значення для відновлення PBS; SLOG впливає на синхронні записи, не на читання. Якщо хтось каже «полагодити швидкість відновлення SLOG», ви знайшли впевненого вгадувача.
L2ARC: може допомогти, якщо робочий набір чанків піддається кешуванню і повторюється. Для одноразових аварійних відновлень він часто прогрівається повільно й мало що дає.

Жарт №2: L2ARC — як стажер: корисний після адаптації, але не врятує вас у перший день інциденту.

Мережа та транспорт: коли 10GbE усе ще відновлює, ніби це 2009 рік

Мережеві проблеми нудні, поки ними не стануть. Відновлення — це тривалий потік, який робить видимими кожну погану налаштування NIC і кожен переповнений комутатор.

На що звертати увагу

Несумісні MTU: jumbo-фрейми на одній стороні і не на іншій призводять до фрагментації або «чорних дір». Продуктивність стає «таємниче поганою».
CPU на пакет: малі пакети на високій швидкості можуть завантажити ядро. Це трапляється частіше, ніж визнають.
Помилки при агрегації/ LACP: ви можете не отримати агреговану пропускну здатність для одного потоку; багато відновлень — це один TCP-потік.
Фаєрвол/IPS: глибока інспекція пакетів на VLAN бекапу — чудовий спосіб перетворити відновлення на перформанс-арт.

Затримка важить більше, ніж здається

Патерни вибірки дедуплікованих чанків можуть вимагати багато дрібних читань і запитів метаданих. Якщо клієнт-серверна взаємодія потребує багатьох циклів запит/відповідь, затримка і втрата пакетів мають значення. Ось чому «10GbE» — не гарантія. Це лише верхня межа.

Налаштування PBS, що дійсно дають результат

PBS не має 400 прихованих «кнопок продуктивності», і це добре. Основні перемоги — архітектурні:
швидке сховище, достатній CPU, достатньо RAM і планування фонових робіт так, щоб вони не конкурували з відновленнями.

Планування та конкуренція: найпростіший виграш

Verify jobs важливі, але не повинні виконуватися в робочий час, якщо відновлення повинні бути швидкими.
GC має бути запланований з урахуванням вікон відновлення. GC плюс відновлення = сумні диски.
Prune зазвичай легший, але також може викликати навантаження, якщо снапшоти великі й часті.

Розглядання шифрування

Якщо ви використовуєте шифрування, це додає навантаження на CPU. На сучасних CPU з AES-NI це часто нормально. Але «часто» — не «завжди».
Якщо PBS — старий сервер з лабораторії, шифрування може стати вузьким місцем під час відновлення.

Розклад datastore

Тримайте datastore на файловій/блочній стек-структурі, яку ви розумієте. Екзотичні шари (віддалені FS, шароване шифрування,
thin provisioning поверх thin provisioning) породжують непередбачувану поведінку під навантаженням відновлення.

Сторона Proxmox під час відновлення: QEMU, LVM-thin, ZFS zvols і де швидкість вмирає

Люди люблять звинувачувати PBS, бо це «річ бекапу». Але відновлення записує кудись. Це «щось» може бути повільним.

ZFS як цільове сховище

Відновлення великої VM у ZFS zvol означає, що ZFS виділяє блоки, перевіряє суми й записує. Якщо пул цільовий фрагментований,
майже повний або на HDD, це проявиться. Також: якщо у вас sync=always або навантаження змушує синхронні записи,
це може суттєво знизити пропускну здатність.

LVM-thin як ціль

Thin-пули можуть відновлюватися швидко, коли вони здорові. Коли метадані thin під тиском або пул близький до заповнення,
продуктивність може обвалитися. Це відбувається тихо, повільно і в найнепідходящіший момент.

Ceph / репліковане сховище

Відновлення в Ceph означає запис реплікованих об’єктів, потенційно викликаючи backfill чи відновлення, якщо кластер не спокійний.
Швидкість відновлення стає «те, що кластер може безпечно прийняти, не впавши».

Практичні завдання: команди, що означає вивід, і рішення, які ви приймаєте

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

Завдання 1: Визначити, чи PBS обмежений CPU під час відновлення

cr0x@pbs1:~$ top -H -b -n 1 | head -n 25
top - 10:14:21 up 42 days,  3:11,  2 users,  load average: 11.42, 10.98, 9.87
Threads: 412 total,   9 running, 403 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.1 us,  3.2 sy,  0.0 ni,  1.8 id,  2.9 wa,  0.0 hi,  0.0 si,  0.0 st
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
51231 backup    20   0 5348128 612144  28740 R  198.0   3.8  12:41.22 proxmox-backup
51244 backup    20   0 5348128 612144  28740 R  183.5   3.8  12:39.08 proxmox-backup

Що це означає: Якщо потоки proxmox-backup споживають багато CPU, а iowait низький — найімовірніше, ви обмежені CPU (декомпресія, шифрування, контрольні суми).

Рішення: Зменшити рівень стиснення для майбутніх бекапів, масштабувати CPU PBS або перенести datastore на швидше сховище, щоб CPU не гаявся в очікуванні.

Завдання 2: Підтвердити завантаження диска datastore і iowait на PBS

cr0x@pbs1:~$ iostat -xm 1 5
Linux 6.2.16-20-pve (pbs1) 	12/28/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.54    0.00    6.91   41.33    0.00   29.22

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s  w_await aqu-sz  %util
nvme0n1         220.0  85432.0     0.0    0.0    3.12   388.3      15.0   6240.0   8.90   1.20   78.0

Що це означає: Високий iowait і велике завантаження пристрою вказують, що datastore — вузьке місце. Дивіться на r_await — якщо воно велике (десятки мс на SSD, сотні на HDD), читання зупиняються.

Рішення: Перенесіть datastore на швидші носії, додайте шпинделів (RAID10) або зупиніть конкуруючі роботи (verify/GC).

Завдання 3: Перевірити, чи verify або GC конкурують з відновленнями

cr0x@pbs1:~$ systemctl list-units --type=service | egrep 'proxmox-backup-(garbage|verify|prune)'
proxmox-backup-garbage-collection.service loaded active running Proxmox Backup Garbage Collection
proxmox-backup-verify.service              loaded active running Proxmox Backup Verify Job

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

Рішення: Зупиніть або перенесіть ці роботи під час термінових відновлень; налаштуйте вікна робіт відповідно до RTO.

Завдання 4: Переглянути логи завдань PBS для повільних фаз

cr0x@pbs1:~$ proxmox-backup-manager task list --limit 5
┌──────────┬──────────────────────────┬───────────────┬─────────┬──────────┬───────────┐
│  upid    │          starttime       │     worker    │  type   │ status   │ duration  │
╞══════════╪══════════════════════════╪═══════════════╪═════════╪══════════╪═══════════╡
│ UPID:... │ 2025-12-28T09:58:03Z     │ reader        │ restore │ running  │ 00:16:22  │
└──────────┴──────────────────────────┴───────────────┴─────────┴──────────┴───────────┘

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

Рішення: Якщо завдання відновлення довго працюють, а система проста — підозрівайте мережу/клієнта. Якщо система завантажена — підозрівайте сховище/CPU PBS.

Завдання 5: Перевірити вільне місце datastore і ризик фрагментації

cr0x@pbs1:~$ df -h /mnt/datastore
Filesystem      Size  Used Avail Use% Mounted on
rpool/pbsdata   7.1T  6.5T  0.6T  92% /mnt/datastore

Що це означає: Дуже заповнені файлові системи уповільнюють алокації і оновлення метаданих, особливо на CoW файлових системах.

Рішення: Агресивно prune, розширити сховище або додати другий datastore. Тримайте вільний простір; 80–85% — безпечніше.

Завдання 6: Перевірити стан пулу ZFS і затримку на PBS (якщо datastore на ZFS)

cr0x@pbs1:~$ zpool iostat -v 1 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                       6.50T   600G   1200     80   140M  10.2M
  mirror                    6.50T   600G   1200     80   140M  10.2M
    nvme0n1                 -      -       600     40   70.0M  5.1M
    nvme1n1                 -      -       600     40   70.0M  5.1M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Підтверджує, чи vdevs ZFS є обмежувачем і чи читацька пропускна здатність відповідає очікуванням.

Рішення: Якщо пропускна здатність низька, а операцій багато — ви обмежені IOPS; оновіть на NVMe або додайте vdevs (обережно) для кращої паралельності.

Завдання 7: Перевірити тиск ARC (кешування ZFS) на PBS

cr0x@pbs1:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:20:01  3420  1210     35  1100  91    110   9     0   0   28.5G  32.0G
10:20:02  3588  1402     39  1280  91    122   9     0   0   28.5G  32.0G

Що це означає: Високий відсоток miss під час відновлення означає, що ZFS часто звертається на диск. Деякі пропуски нормальні; постійно високі miss% вказують, що RAM обмежує або навантаження не кешується.

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

Завдання 8: Виміряти мережеву пропускну здатність і повторні передачі під час відновлення

cr0x@pve1:~$ ip -s link show vmbr0
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    8123456789  7212345      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    6234567890  6123456      0       0       0       0

Що це означає: Розриви/втрати на мосту/NIC під час відновлення — знак тривоги. Втрати викликають повторні передачі й руйнують пропускну здатність.

Рішення: Виправте фізичний/мережевий шар: узгодьте MTU, налаштуйте буфери комутатора, NIC offloads або перемістіть трафік відновлення з перевантажених сегментів.

Завдання 9: Підтвердити MTU end-to-end (поширений мовчазний вбивця)

cr0x@pve1:~$ ping -M do -s 8972 -c 2 10.10.10.20
PING 10.10.10.20 (10.10.10.20) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.10.10.20 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Що це означає: Цей хост не налаштований на jumbo-кадри. Якщо ви очікували MTU 9000 — його немає.

Рішення: Узгодьте на 1500 всюди або налаштуйте jumbo-фрейми повністю (NIC, мости, комутатори). «Десь» — не коректна MTU.

Завдання 10: Перевірити швидкість запису на клієнті (цільове сховище на PVE)

cr0x@pve1:~$ iostat -xm 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.87   55.21    0.00   29.80

Device            r/s     rkB/s   r_await  w/s     wkB/s   w_await  %util
dm-3              1.0      8.0     2.10  920.0  94208.0   34.90   99.0

Що це означає: Якщо цільовий пристрій близький до ~99% завантаження й iowait високий — відновлення обмежене записом на PVE.

Рішення: Відновіть на швидше сховище, змініть ціль (наприклад, відновити на локальний NVMe і потім мігрувати), або виправте пул/масив.

Завдання 11: Перевірити, чи thin pool майже повний (LVM-thin)

cr0x@pve1:~$ lvs -a -o+seg_monitor,metadata_percent,data_percent vg0
  LV               VG  Attr       LSize   Pool Origin Data%  Meta%  Monitor
  vmdata           vg0 twi-aotz--  2.50t             93.12  78.55  monitored
  [vmdata_tmeta]   vg0 ewi-ao----  4.00g
  [vmdata_tdata]   vg0 ewi-ao----  2.50t

Що це означає: Thin-pool на 93% заповнення — це проблема для продуктивності і ризик. Метадані близько 79% теж не добре.

Рішення: Розширити thin-pool, звільнити місце або перенести відновлення в інше місце. Також слід проводити trimming і моніторинг до того, як ви вперлися в стіну.

Завдання 12: Перевірити заповнення ZFS цільового пулу і ризик фрагментації

cr0x@pve1:~$ zfs list -o name,used,avail,refer,mountpoint
NAME            USED  AVAIL  REFER  MOUNTPOINT
rpool           1.92T   110G   192K  /rpool
rpool/ROOT       32G   110G    32G  /
rpool/vmdata    1.88T   110G   1.88T  -

Що це означає: 110G вільного на багатотерабайтному пулі — «ми живемо ризиковано». Продуктивність ZFS погіршується при заповненні пулу.

Рішення: Звільніть місце або додайте vdev-ємність перед масовими відновленнями; націлюйтеся на пул з запасом простору.

Завдання 13: Підтвердити шлях відновлення і процес на PVE хості

cr0x@pve1:~$ ps aux | egrep 'proxmox-backup-client|qemu-img|vma' | grep -v egrep
root     144233  110  2.1 2154320 342112 ?      Sl   10:02   8:14 proxmox-backup-client restore vm/102/2025-12-28T09:40:12Z drive-scsi0.img.fidx --repository pbs@pam@10.10.10.20:pbs --target /dev/zvol/rpool/vm-102-disk-0

Що це означає: Показує, який інструмент і куди пишуть. Відновлення в zvol проти файлу проти LVM змінює поведінку.

Рішення: Якщо ви пишете в повільний бекенд, змініть ціль відновлення (відновіть у каталог на швидкому NVMe, потім імпортуйте/мігруйте).

Завдання 14: Перевірити очевидні дивні налаштування NIC offload (швидка перевірка)

cr0x@pve1:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Що це означає: Вимкнені offloads підвищують навантаження CPU на пакет. Включені offloads, але з багами, теж можуть шкодити, але почніть з бази.

Рішення: Якщо CPU завантажений у softirq під час відновлення, експериментально вимкніть offloads (обережно) і перевірте версії драйверів/прошивок.

Завдання 15: Примітивний тест пропускної здатності диска на PBS (поза годинами роботи)

cr0x@pbs1:~$ fio --name=readtest --directory=/mnt/datastore --rw=read --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=30 --time_based
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
read: IOPS=820, BW=820MiB/s (860MB/s)(24.0GiB/30001msec)

Що це означає: Це наближує послідовні читання; відновлення може бути більш випадковим. Все ж, якщо datastore не може показати пристойні читання тут, воно не відновлюватиметься швидко.

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

Завдання 16: Виявити повільні диски або помилки на PBS

cr0x@pbs1:~$ dmesg -T | egrep -i 'error|reset|timeout|nvme|ata' | tail -n 10
[Sat Dec 27 22:14:09 2025] nvme nvme1: I/O 123 QID 4 timeout, reset controller
[Sat Dec 27 22:14:10 2025] nvme nvme1: Abort status: 0x371

Що це означає: Таймаути і ресети контролера знищують продуктивність і надійність. Відновлення підсилює цей біль.

Рішення: Замініть нестабільні носії, оновіть прошивку й перестаньте трактувати помилки як «шум».

Три корпоративні історії з практики

Історія 1: Інцидент через неправильне припущення

Середня компанія консолідувала бекапи на PBS і святкувала: вікна бекапу скоротилися, зростання сховища уповільнилося, дашборди виглядали спокійно.
Команда припустила, що відновлення масштабуватиметься так само, бо «це ж просто читання того, що ми записали».

Перший реальний тест трапився під час відмови додатку, коли потрібно було швидко відновити багатотерабайтну VM. Відновлення почалося, а потім повзло.
Графіки мережі показували багато запасу. Графіки CPU були в нормі. Диски datastore PBS були на високих навантаженнях з огидною латентністю читання.

Datastore стояв на великому parity RAID з HDD. Його обрали за співвідношенням ємність/ціна й він чудово справлявся з потоковими записами.
Відновлення ж спричинило патерн читання, схожий на напіввипадковий I/O. Масив поводився так, як ведуть себе parity HDD масиви під таким навантаженням: терпляче страждав.

Вони вирішили проблему, перемістивши активний datastore на дзеркальні SSD (а старі, холодні дані лишили на HDD пулі). Часи відновлення стали передбачуваними.
Неправильне припущення полягало не в PBS; воно полягало в очікуванні, що поведінка читання така ж, як і запису. Сховище ніколи не обіцяло симетрії.

Історія 2: Оптимізація, що вилетіла боком

Інша організація хотіла зекономити на зберіганні бекапів. Хтось запропонував агресивніше підвищити стиснення, бо бекапи «переважно однакові»
і «CPU дешевий». Вони повернули ручку, і використання datastore впало. Здавалося, відмінна зміна.

Місяці потому довелося відновлювати кілька VM одночасно після поганого патча. Відновлення були болісно повільні і тряслися.
CPU PBS був завантажений, але не в хорошому «ефективно використовує ресурси» значенні — швидше «не можу дихати».

Рівень стиснення, який вони обрали, підійшов для нічних бекапів, але відновлення — це денне аварійне навантаження. Декомпресія стала вузьким місцем,
і коли одночасно йшло кілька відновлень, конкуренція за CPU посилила проблему. Сховище було швидким. Мережа була в порядку. CPU — ні.

Виправлення було простим: знизили стиснення до помірного zstd-рівня, додали трохи CPU і — це те, що нікому не подобається чути — почали тестувати відновлення щоквартально.
Витрати на зберігання трохи зросли. RTO значно покращився. «Оптимізація» оптимізувала не ту річ.

Історія 3: Нудна, але правильна практика, що врятувала день

Регульована компанія мала непомітне правило: щоквартально вибирати випадкову VM і робити повне відновлення у ізольований VLAN.
Вони записували час, вузьке місце і кроки, які потрібно зробити. Нікому це не подобалося. Це займало години і не приносило блиску.

Одного кварталу відновлення йшло повільніше, ніж очікували. Тестове середовище показало відмови пакетів на одному порту комутатора і зростання лічильника RX помилок.
VM все одно відновилася — зрештою — але в постмортемі записали: «поправити мережевий шлях, поки це не стало критичним».

Через два місяці хост впав. Вони відновлювали кілька VM під тиском. Відновлення працювали близько до протестованих показників, бо поганий порт комутатора вже замінили.
Ніхто не аплодував. Ніхто не купив торт. Канал інцидентів залишився нудним, що — найкращий результат для операцій.

Практика не була хитрою. Вона була повторюваною. Вона врятувала їх від вивчення мережі під час реальної аварії.

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

1) «Бекапи швидкі, відновлення повільні» (класика)

Симптом: Роботи бекапу виконуються швидко; відновлення повзуть, особливо для великих VM.

Корінна причина: Datastore оптимізовано під послідовний запис, а не під читання чанків (HDD parity RAID, зайнятий пул або низькі IOPS).

Виправлення: Помістіть активний datastore на SSD/NVMe mirror/RAID10. Відокремте «гарячий» datastore для відновлень від холодного архіву.

2) Швидкість відновлення стрибає годину до години

Симптом: Інколи відновлення проходять нормально; інколи — непридатні.

Корінна причина: Конкуренція з verify/GC/prune або спільне сховище з іншими навантаженнями.

Виправлення: Плануйте фонові роботи; ізолюйте сховище PBS; обмежуйте конкуренцію у робочий час.

3) Відновлення зависає на якомусь відсотку і «оцінка» стоїть на місці

Симптом: Прогрес у UI майже не рухається; логи показують довгі паузи.

Корінна причина: Спайки латентності диска, SMR-диски, таймаути контролера або несправні носії, що викликають повтори.

Виправлення: Перевірте dmesg, SMART/NVMe логи і iostat латентності. Замініть нестабільні диски; уникайте SMR для активного datastore.

4) 10GbE лінк, але відновлення видає 80–150 MB/s

Симптом: Мережа «має» робити більше, але пропускна здатність низька.

Корінна причина: Обмеження одного потоку, невідповідність MTU, втрата пакетів, накладні витрати фаєрволу/IPS або насичення softirq CPU.

Виправлення: Перевірте MTU end-to-end; дивіться втрати й повтори; перемістіть трафік; налаштуйте NIC offloads і IRQ affinity за потреби.

5) CPU PBS завантажений під час відновлення

Симптом: Високе використання CPU, низьке завантаження дисків; відновлення повільні.

Корінна причина: Агресивний рівень стиснення, навантаження шифрування або недостатня кількість ядер для паралельних відновлень.

Виправлення: Використовуйте помірний zstd; масштабируйте CPU; обмежуйте паралельні відновлення; розгляньте розділення ingest та restore навантажень (більший PBS або другий PBS).

6) Відновлення в ZFS повільніше, ніж очікувалось

Симптом: PBS в нормі; на PVE високий iowait, записи повільні.

Корінна причина: Цільовий пул майже повний, повільний макет vdev, фрагментація або налаштування sync.

Виправлення: Додайте ємність, тримайте запас простору, відновіть на швидке тимчасове сховище і потім мігруйте; перевірте дизайн ZFS (дзеркала для IOPS).

7) Відновлення в LVM-thin починаються швидко, а потім падають

Симптом: Перші хвилини чудові; потім падіння продуктивності.

Корінна причина: Thin pool або метадані майже вичерпано; I/O метаданих стає вузьким місцем.

Виправлення: Розширити thin pool; звільнити місце; моніторити Data% та Meta%; уникайте високого заповнення thin pool.

8) Кілька одночасних відновлень роблять усе непридатним

Симптом: Одне відновлення — ок; три — катастрофа.

Корінна причина: Спільне вузьке місце (IOPS datastore, CPU PBS, черги мережі або ліміти запису цільового сховища).

Виправлення: Обмежити конкуренцію; поетапні відновлення; оновити спільний вузький елемент; розглянути окремі datastore або PBS-ноди.

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

Покроково: як зробити відновлення швидшими без культових налаштувань

Визначте ціль відновлення: задайте RTO для «одної критичної VM» і «найгірший день: 5 критичних VM». Якщо не можете назвати числа — не зможете налаштуватися.
Запустіть реальний тест відновлення у тихому вікні. Виміряйте пропускну здатність end-to-end (диск PBS, CPU PBS, мережа, диск PVE).
Виключіть конкуренцію: плануйте verify/GC поза вікнами відновлення. Не діліть datastore PBS з VM-навантаженнями.
Визначте вузьке місце за допомогою швидкого плану діагностики. Не оновлюйте три речі одночасно.
Якщо вузьке місце — читання: перемістіть datastore на SSD/NVMe, надавайте перевагу дзеркалам/RAID10, забезпечте достатньо RAM для кешу метаданих.
Якщо вузьке місце — CPU: знизьте рівень стиснення, увімкніть апаратне шифрування (AES), додайте ядра і обмежте паралельні відновлення.
Якщо вузьке місце — мережа: перевірте MTU, усуньте втрати пакетів, переконайтесь у чистоті маршруту (без несподіваної інспекції) і підтвердьте очікувану пропускну здатність одного потоку.
Якщо вузьке місце — запис цілі: відновіть на швидке локальне сховище, а потім мігруйте; виправте headroom пулу ZFS; розширте thin-pool.
Перевірте після кожної зміни і зафіксуйте результат. «Відчувається швидше» — не метрика.
Інституціоналізуйте нудну практику: щоквартальні вправи з відновлення з логами часу і вузьких місць.

Чекліст на день відновлення (коли вже горить)

Тимчасово зупиніть/призупиніть jobs verify і GC PBS, якщо вони конкурують за читання.
Запустіть iostat на PBS і PVE, щоб вирішити: читання чи запис обмежує.
Перевірте завантаження CPU PBS і iowait на PVE.
Перегляньте втрати NIC і ознаки MTU mismatch.
Обмежте одночасні відновлення, поки не зрозумієте вузьке місце.
Якщо цільове сховище повільне — відновіть на швидку тимчасову ціль і потім мігруйте.

Питання й відповіді

1) Чому мої бекапи завершуються швидко, а відновлення тривають вічність?

Бекапи можуть бути інкрементними й дедуплікованими — ви переважно відправляєте змінені чанки. Відновлення відтворює весь образ і може викликати багато читань чанків плюс декомпресію.
На відновлення значно більше впливає читальна IOPS і латентність datastore, ніж на бекап.

2) Швидкість відновлення PBS переважно диск, CPU чи мережа?

Це те, що гірше на шляху відновлення. На практиці дискова латентність читання datastore — найпоширеніший обмежувач, потім — записова продуктивність цілі.
CPU стає обмежувачем, коли стиснення/шифрування важкі або PBS недостатньо потужний.

3) Що обрати: zstd чи lzo для кращих відновлень?

Помірний zstd зазвичай найкращий вибір: хороше стиснення з швидкою декомпресією. lzo знижує навантаження CPU, але збільшує прочитані/передані байти.
Якщо ви обмежені мережею (1GbE), zstd часто відновлює швидше. Якщо CPU — вузьке місце, а сховище/мережа швидкі, lzo може допомогти.

4) Чи дедуплікація сповільнює відновлення?

Дедуп може ускладнити патерн читання, що шкодить на повільних випадкових чтеннях. На SSD/NVMe штраф зазвичай малий.
Дедуплікація зазвичай того варта; просто не ставте datastore на диски, які ненавидять випадкові читання.

5) Чи додавання SLOG-пріскорювача прискорить відновлення?

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

6) Чи запускати verify jobs щодня?

Перевірка цілісності — хороша річ. Але виконувати її у вікнах, що колізують з відновленнями — погано.
Плануйте verify, коли терміновість відновлень мала, і налаштуйте розмір datastore так, щоб verify не займав цілий день.

7) Чому одночасне відновлення багатьох VM таке повільне?

Ви збільшуєте конкуренцію за спільні ресурси: IOPS datastore, CPU PBS, черги мережі та ліміти запису цільового сховища.
Якщо потрібні паралельні відновлення — проектуйте під це: більше IOPS (NVMe дзеркала), більше CPU і чистий мережевий шлях.

8) Краще відновити на локальний диск, а потім мігрувати, ніж відновлювати відразу на спільне сховище?

Часто — так. Відновлення на швидкий локальний NVMe може суттєво зменшити час до першого запуску.
Потім ви можете мігрувати VM на повільніше/репліковане сховище після інциденту, коли емоції спадають.

9) Скільки вільного місця тримати на PBS datastore і ZFS пулах?

Достатньо, щоб ви не жили на краю. Практична ціль — тримати 15–20% запасу на пулах, що потребують продуктивності й передбачуваних алокацій.
Якщо ви на 90%+, готуйтеся до сюрпризів у продуктивності.

10) Яке оновлення дає найбільший ефект для відновлень?

Помістіть datastore PBS на SSD/NVMe у конфігурації, що дає IOPS (дзеркала/RAID10). Масиви HDD parity для ємності — поширене вузьке місце відновлення.
Далі переконайтеся, що цільове сховище може приймати записи з тією швидкістю, з якою ви відновлюєте.

Висновок: наступні кроки, що окупаються

Продуктивність відновлення — не містична. Це конвеєр з передбачуваними вузькими місцями. Якщо відновлення повільні — припиніть гадати й вимірюйте:
латентність читання datastore, CPU PBS, стан мережі і поведінку запису цілі. Зазвичай один ресурс кричить голосніше за інших.

Практичні наступні кроки, що зазвичай дають швидкий ефект:

Плануйте GC/verify так, щоб вони не конкурували з вікнами відновлення.
Перенесіть активний datastore на SSD/NVMe mirror (або RAID10), якщо вам важлива швидкість відновлення.
Виберіть розумне стиснення (помірний zstd) і підтверджуйте його щоквартальними тестами відновлення.
Тримайте запас простору на PBS datastore і цільових пулах; заповнені системи — повільні системи.
Документуйте runbook відновлення, що включає команди швидкої діагностики, щоб ви не дебажили під адреналіном.

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

Схожі статті

Proxmox Backup «Немає вільного простору на пристрої»: чому він падає, хоча місця здається достатньо