Proxmox Backup Server vs Veeam для VMware: що краще для швидкого відновлення та простої експлуатації

Рішення за 60 секунд

Якщо ваше середовище сильно завантажене VMware і вам потрібні перевірені робочі процеси «запустіть мене зараз» (Instant VM Recovery, детальні відновлення, елементи застосунків, широка екосистема, варіанти стрічки/хмари, багато запобіжних заходів), Veeam зазвичай є безпечнішим вибором. Він не завжди елегантний. Але він перевірений у тих режимах відмов, які найчастіше трапляються в VMware‑середовищах.

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

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

Жарт №1: Резервні копії — як парашут: мати його — чудово, виявити, що він запакований неправильно — це захопливо погано.

Факти та контекст для нарад

• Знімки VMware змінили дизайн бекапів. Сучасні інструменти образного рівня для VMware залежать від знімків VM, щоб отримати консистентне точкове відображення, а потім перемістити дані кудись інше.
• Changed Block Tracking (CBT) був переломним моментом. CBT дозволив швидкі інкрементальні копії, відстежуючи змінені області диска. Він також породив клас «тихих неправильних інкременталів», коли CBT інвалідований або має баг — тому потрібні періодичні фул‑джоби або перевірка синтетичних фулів.
• Дедуплікація з «приємної» стала «обов’язковою» з ростом спавну VM. Але вона перемістила вузьке місце з ємності диска на CPU, RAM і випадкові I/O патерни.
• ZFS популяризував підхід «цілісність передусім» для бюджетного апаратного забезпечення. Контрольні суми та корекція через scrub змінили очікування: сховище не повинно тихо псути ваші резервні копії.
• Іммутованість стала мейнстримом через те, що рансомваре почав атакувати бекапи. Коли зловмисники навчилися видаляти репозиторії і каталоги, «air gap» і іммутованість перестали бути просто маркетингом.
• Архітектура proxy/repository у Veeam виросла з обмежень ери Windows. Вона модульна, бо мала бути такою: різні режими транспорту, різне сховище, різні мережі, багато сценаріїв розгортання.
• PBS з самого початку будувався на контент-адресованих чанках. Він зберігає дедупліковані чанки зі сильними контрольними сумами і пропонує просту модель: datastore, namespace, verify, prune.
• Функції «миттєвого відновлення» старші, ніж здається. Монтування бекапу як запущеної VM — це по суті віртуалізація зберігання: концепція зріла, реалізація складна.
• Linux‑репозиторії стали кращою практикою для Veeam з часом, в основному тому, що XFS/Reflink та жорсткіші патерни репозиторіїв краще підходять до сучасних загроз, ніж «Windows share».

Що насправді означає «швидке відновлення» (і що його уповільнює)

Час відновлення — це не одне число. Це конвеєр:

1. Швидко знайти метадані: каталог, індекси, ланцюги бекапів.
2. Швидко прочитати дані бекапу: пропускна здатність репозиторію, випадковий I/O, регістрація дедуплікації, декомпресія.
3. Швидко записати в продукцію: продуктивність datastore, мережа, поведінка контролера зберігання.
4. Зробити завантажувальним: різниці драйверів, консистентність застосунків, особливості AD/SQL/Exchange тощо.

Невидимі вбивці:

• Малий випадковий I/O на репозиторії (бази даних дедуплікації, сховища чанків, пошуки метаданих).
• Нестача CPU (декомпресія/шифрування/відновлення дедуплікації не безкоштовні).
• Перевантаження мережі (10GbE, що поводиться як 1GbE, коли буфер комутатора плаче).
• Патологія ланцюжка знімків (стоп під час видалення знімків, спайки латентності сховища).
• «Відновлення в те саме зламане місце» (запис назад у datastore, який вже страждає від високої затримки).

Швидкі відновлення походять від нудного принципу: зробіть шлях відновлення найпростішим шляхом. Функції не долають фізику. Вони обходять її.

Архітектури: як PBS і Veeam фактично рухають байти

PBS на практиці

PBS — це спеціалізований сервер резервного копіювання з datastore’ами. Резервні копії дробляться на чанки, стискуються і дедуплікуються. Цілісність — першокласна: чанки мають контрольні суми; ви можете верифікувати datastores і виявляти корупцію на ранньому етапі. Операційно він відчувається як сховище‑аплайанс, що випадково говорить «резервне копіювання».

Для VMware типовий підхід такий: процес бекапу читає дані VM (часто через агенти або інтеграційні інструменти) і записує їх у PBS. PBS сам по собі не є «натисни далі і захисти все» набором для VMware в тому ж сенсі, як Veeam. Він відмінно виконує свою задачу: зберігати і видавати бекапи швидко і надійно. Історія інтеграції може вимагати більше інженерії в залежності від вашого середовища.

Veeam для VMware на практиці

Veeam — це платформа: backup server, проксі, репозиторії, scale-out repositories (SOBR), різні транспорти (HotAdd, NBD, Direct SAN), application-aware обробка і довгий список режимів відновлення. Він спроектований так, щоб опинитися в центрі корпоративного хаосу і все одно виконати роботу.

Компроміс: більше ручок, більше рухомих частин, більше речей для патчів, більше моделей прав доступу, більше сертифікатів, більше «чому цей сервіс використовує той порт». Ви отримуєте потужність, але також отримуєте відповідальність.

Наслідок для швидкості відновлення:

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

Наслідок для експлуатації:

• PBS — як аплайанс. Менше компонентів. Чітка ментальна модель.
• Veeam — як система. Потрібні стандарти: найменування, структура репозиторіїв, розміщення проксі, управління обліками та контроль змін.

Шляхи відновлення, які мають значення: повна ВМ, рівень файлів і моменти «ой»

Повне відновлення ВМ (RTO — король)

Перевага Veeam — широта робочих процесів відновлення і операційна шліфованість навколо них. Instant VM Recovery (запуск ВМ безпосередньо з репозиторію) може радикально зменшити RTO, коли продукційне сховище повільне, мертве або політично недоступне. Ризик у тому, що «миттєве» може стати «миттєво повільним», якщо репозиторій не побудований під I/O патерни ВМ.

PBS може відновлювати ефективно, якщо ваш конвеєр записує назад у VMware‑сховище з лінійною швидкістю і ви не застрягли у метаданійній трясці. Але PBS не створює магічно запущену ВМ з дедуплікованого сховища без навколишньої оркестрації, орієнтованої на VMware. Якщо ви очікуєте «одне натискання» для миттєвого завантаження VMware, Veeam, ймовірно, сьогодні частіше дасть те, що вам потрібно.

Відновлення на рівні файлів (найпоширеніший запит)

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

Елементи застосунків (тут час йде в нікуди)

Відновлення об’єктів AD, точково для SQL, відновлення елементів поштової скриньки Exchange: саме тут корпоративні вендори бекапів заробляють свою ціну. Veeam сильний тут, бо інвестував роки в application-aware обробку і інструменти відновлення. PBS може бути частиною стратегії, але вам, можливо, доведеться зшивати разом нативні бекапи застосунків, скрипти та валідацію власноруч.

Рансомваре та «я не довіряю середовищу» відновлення

Іммутовані бекапи та загартовані репозиторії — зараз стандарт. Veeam має сильні патерни для hardened Linux репозиторіїв та вікон іммутованості. PBS, будучи рідним для Linux із верифікацією контрольних сум і чіткою моделлю datastore, підходить для побудови надійних, стійких до модифікацій дизайнів — особливо в поєднанні з обмеженим адміністративним доступом та офлайн‑реплікацією.

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

Проста експлуатація: що ви робитимете щотижня

Швидкі відновлення — переважно наслідок простих операцій, виконуваних послідовно.

Як виглядає «просто» з PBS

• Моніторити використання datastore, кількість чанків, графіки verify, графіки prune.
• Підтримувати ZFS: scrubs, SMART, налаштування ARC, вибір recordsize.
• Тестувати відновлення, реально відновлюючи (а не милуючись дашбордами).
• Реплікувати на другий PBS або офлайн‑ціль із суворим контролем доступу.

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

Як виглядає «просто» з Veeam

• Підтримувати ланцюги бекапів, репозиторії, екстенти SOBR та іммутованість.
• Патчити backup server і компоненти. Тримати сертифікати та обліки в порядку.
• Слідкувати за навантаженням проксі та продуктивністю транспорту (HotAdd vs NBD vs Direct SAN).
• Запускати SureBackup / роботи валідації, щоб не виявляти зламані відновлення під час простою.

Експлуатація Veeam відчувається як «керування невеликим сервісом». Якщо робити правильно — гладко. Якщо робити по‑філософськи — виростає зуби.

Цитата про надійність, яка важить

Надія — це не стратегія. — парафразована ідея, поширено пов’язана з лідерством в операціях (широко використовується в культурі надійності)

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

Практичні завдання: команди, виводи та рішення (12+)

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

Завдання 1: Доведіть, що репозиторій не страждає від нестачі CPU (PBS)

cr0x@pbs01:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core'
CPU(s):                          16
Model name:                      AMD EPYC 7302P 16-Core Processor
Thread(s) per core:              2
Core(s) per socket:              16

Що це означає: Достатньо ядер для компресії/шифрування та метаданих. Якщо ви бачите 2–4 ядра тут, відновлення здаватимуться повільними навіть із швидкими дисками.

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

Завдання 2: Перевірте запас RAM і поведінку swap (PBS/Veeam Linux repo)

cr0x@pbs01:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        18Gi        12Gi       1.2Gi        34Gi        45Gi
Swap:          4.0Gi          0B       4.0Gi

Що це означає: Добре. «Available» високе і swap не використовується. Якщо swap активний — під час відновлень ймовірні спайки затримки.

Рішення: Якщо swap використовується під час відновлень — додайте RAM і налаштуйте пам’ять для ресурсомістких сервісів. Для ZFS перевірте, щоб ARC не душив систему.

Завдання 3: Підтвердіть здоров’я ZFS pool (PBS на ZFS)

cr0x@pbs01:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-SSD1                ONLINE       0     0     0
            ata-SSD2                ONLINE       0     0     0
            ata-SSD3                ONLINE       0     0     0
            ata-SSD4                ONLINE       0     0     0

errors: No known data errors

Що це означає: Scrub чистий, помилок контрольних сум немає. Якщо ви бачите CKSUM‑помилки — ваше «повільне відновлення» може насправді бути «обладнання брешить».

Рішення: Будь‑які помилки контрольних сум: припиніть тюнінг і почніть заміну компонентів. Резервні копії на ненадійному сховищі — дороге галюцинація.

Завдання 4: Слідкуйте за насиченням I/O (обидва)

cr0x@pbs01:~$ iostat -xm 2 3
Linux 6.2.16 (pbs01)  12/28/2025  _x86_64_ (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          5.2    210.4    980   52240   2.10  48.5
nvme1n1          4.9    208.8    910   51800   2.04  46.9

Що це означає: Використання менше 80% і await ~2ms — здорово. Якщо %util при 100% з ростом await — репозиторій є вузьким місцем.

Рішення: Якщо насичено: перейдіть на швидше сховище, додайте vdev’и, виправте RAID‑розклад або відокремте метадані/metadata‑важкі навантаження на SSD/NVMe.

Завдання 5: Перевіряйте цілісність datastore регулярно (PBS)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify backup-store
Starting datastore verification...
Checked 124988 chunks, 0 errors, 0 corruptions detected
Verification finished successfully

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

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

Завдання 6: Проінспектуйте стан prune та реальність ретеншну (PBS)

cr0x@pbs01:~$ proxmox-backup-manager prune-job list
ID   Store        Schedule          Keep Last  Keep Daily  Keep Weekly  Keep Monthly
1    backup-store 02:30             7          14          8            12

Що це означає: Ретеншн явно налаштований. Якщо prune відсутній або падає — datastores будуть рости, поки ви не дізнаєтесь про це по аварії.

Рішення: Якщо використання зростає неочікувано — перевірте, чи prune виконується і чи «keep» відповідає вимогам відповідності та розрахунку ємності.

Завдання 7: Підтвердіть мережевий шлях і невідповідності MTU (обидва)

cr0x@veeamproxy01:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc
ens224           UP             00:50:56:dd:ee:ff

cr0x@veeamproxy01:~$ ip -d link show ens224 | egrep 'mtu|state'
2: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP mode DEFAULT group default qlen 1000

Що це означає: Jumbo frames увімкнені на одному інтерфейсі. Це нормально лише якщо весь шлях їх підтримує.

Рішення: Якщо відновлення дивно повільні або зростають ретрансляції, уніфікуйте MTU по‑шляхові (всі 9000 або всі 1500) і перетестуйте.

Завдання 8: Заміряйте реальну пропускну здатність за допомогою iperf3 (обидва)

cr0x@pbs01:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

cr0x@esxjump01:~$ iperf3 -c pbs01 -P 4
[SUM]   0.00-10.00  sec  37.5 GBytes  32.2 Gbits/sec                  receiver

Що це означає: Мережа не є вашим вузьким місцем. Якщо ви отримуєте 3–5 Gbits/sec на «10Gb» мережі — починайте шукати проблеми в комутаторі, відключення NIC offloads або конгестію.

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

Завдання 9: Перевірте затримку диска на VMware datastore (орієнтовано на симптоми)

cr0x@esx01:~$ esxcli storage core device stats get -d naa.600508b1001c3ad5
Device: naa.600508b1001c3ad5
  Successful Commands:  18922301
  Failed Commands:      0
  Read Latency (ms):    3.12
  Write Latency (ms):   18.47

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

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

Завдання 10: Ідентифікуйте транспорт Veeam proxy та вузькі місця (Windows Veeam server)

cr0x@veeam-win:~$ powershell -NoProfile -Command "Get-Service Veeam* | Select Name,Status | Format-Table -Auto"
Name                           Status
----                           ------
VeeamBackupSvc                 Running
VeeamBrokerSvc                 Running
VeeamCatalogSvc                Running
VeeamCloudSvc                  Running

Що це означає: Основні сервіси працюють. Якщо завдання відновлення зависають на «Initializing», це перший крок: підтвердьте, що сервіси живі, перш ніж ганятися за привидами сховища.

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

Завдання 11: Валідуйте опції монтування для іммутованого Linux‑репозиторія (Veeam Linux repo)

cr0x@veeamrepo01:~$ mount | grep /backup
/dev/sdb1 on /backup type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,prjquota)

Що це означає: XFS змонтовано з project quotas (часто використовується в hardened repository патернах). Якщо цього немає — іммутованість і контроль простору можуть працювати не так, як очікується.

Рішення: Якщо опції монтування не відповідають вашому hardened дизайну — зупиніться і виправте. Безпекові функції, що не ввімкнені, — просто театр.

Завдання 12: Підтвердіть вільне місце в репозиторії та інодійну цілісність інодів (обидва)

cr0x@veeamrepo01:~$ df -h /backup
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        80T   61T   19T  77% /backup

Що це означає: 77% використано — загалом нормально. Багато систем деградують операційно, коли сховище майже повне; prune і операції злиття можуть спричиняти піки.

Рішення: Якщо ви вище ~85–90% на репозиторіях — плануйте ємність, перш ніж «оптимізувати». Робота на межі ємності створює потворні сюрпризи під час відновлення.

Завдання 13: Помітити втрату пакетів і ретрансляції (класика повільних відновлень)

cr0x@pbs01:~$ ss -ti dst :5201 | head -n 12
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0      0      10.10.20.10:5201   10.10.20.50:50944
	 cubic wscale:7,7 rto:204 rtt:0.402/0.033 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:560 bytes_acked:24389425 segs_out:31233 segs_in:29112 send 99.1Mbps lastsnd:4 lastrcv:4 lastack:4 pacing_rate 198Mbps retrans:12/31320

Що це означає: Існують ретрансляції. Кілька нормальні; багато — ні. Втрата перетворює «10GbE» на «чому мій відновлення лише 12%».

Рішення: Якщо під час вікон відновлення зростають ретрансляції — перевірте MTU‑невідповідність, помилки на портах комутатора, прошивку NIC і конгестію.

Завдання 14: Виявити налаштування ZFS compression/dataset, що вам шкодять (PBS)

cr0x@pbs01:~$ zfs get -o name,property,value compression,recordsize tank/pbs
NAME      PROPERTY     VALUE
tank/pbs  compression  zstd
tank/pbs  recordsize   128K

Що це означає: Розумні дефолти для багатьох бекап‑навантажень. Якщо recordsize крихітний — зростає наклад на метадані; якщо стиснення вимкнено — ви платите за ємність і I/O.

Рішення: Не налаштовуйте випадково. Якщо відновлення CPU‑обмежене — тестуйте зміну рівня стиснення. Якщо відновлення I/O‑обмежене — уникайте налаштувань, що вибухово збільшують IOPS.

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

cr0x@pbs01:~$ timedatectl status | egrep 'System clock synchronized|NTP service|Time zone'
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

Що це означає: Час нормальний. Точки відновлення, ретеншн та дійсність сертифікатів можуть піти крахом, коли час дрейфує.

Рішення: Якщо час не синхронізовано — виправте NTP спочатку. Потім перегляньте «таємничі» проблеми з ретеншном і автентифікацією.

Три корпоративні міні-історії з передової

1) Інцидент, спричинений неправильною припущенням: «Мережа в порядку»

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

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

Під час реального відновлення — VM застосунку з жорстким RTO — пропускна здатність скакнула. Команда бекапу ескалувала до сховища, сховище — до VMware, VMware — до мережі. Усі прийшли з графіками. Ніхто не мав єдиного end‑to‑end виміру.

Коли вони запустили тривале iperf3 під час вікна відновлення, правда проявилася: мікропави і падіння буфера на порту top‑of‑rack комутатора, що обслуговував репозиторій. Воно не було «вимкнено». Воно просто тихо карало трафік у найгірший момент.

Виправлення конфігурації порту і узгодження MTU енд‑ту‑енд зробили більше для часу відновлення, ніж будь‑який тюнінг репозиторію. Урок закріпився: вимірюйте шлях, яким ви відновлюєте, а не шлях, який ви сподіваєтесь мати.

2) Оптимізація, що повернулася бумерангом: «Максимальна дедуплікація скрізь»

Інша компанія гналася за економією. Вони пишалися коефіцієнтами дедуплікації. Вони налаштували все на максимальну компресію і агресивну дедуплікацію, потім хвалилися зменшенням ємності на квартальних звітах. Репозиторій виглядав як диво.

Потім оновлення кластера пішло не так і їм потрібно було швидко відновити кілька середніх VM. Відновлення спочатку були швидкими, а потім застрягли. CPU на репозиторії прижався; черги I/O виросли; затримка пішла від мілісекунд до «йдіть випийте кави».

Оптимізація була математично правильною і операційно неправильною: їхнє апаратне забезпечення репозиторію було розраховане на інгест бекапів, а не на реєстрацію регістрацій дедуплікації під час масових відновлень. Максимальна компресія означала максимальні витрати CPU саме тоді, коли потрібна була пропускна здатність.

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

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

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

Одна організація мала репутацію нудної. Контроль змін. Вікна патчів. Документація, що дратує своєю актуальністю. Щомісяця вони проганяли тести відновлення: одне повне відновлення ВМ, одне відновлення файлу, одне відновлення елементу застосунку і одне тестове відновлення в альтернативну мережу.

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

Коли рансомваре вдарив по бізнес‑підрозділу, план реагування вже був у м’язовій пам’яті. Вони відновили критичні системи в ізольований сегмент мережі, підтвердили цілісність, потім спланували повернення. Таймінг не був «героїчним». Він був рівним.

Вони все одно втратили час. Усі втрачають. Але вони не загубили сюжет. Ніякої імпровізації, ніякого «хтось пам’ятає пароль від репозиторію», ніякого лютого пошуку відсутніх драйверів.

Ось що купує проста експлуатація: менше сюрпризів. У кризі нудьга — це функція.

Плейбук швидкої діагностики

Коли відновлення повільні, у вас немає часу на філософію. Потрібно знайти вузьке місце за 15 хвилин, а не після розбору польотів.

Перший крок: визначте, де саме ви повільні (читання, запис або обчислення)

• Чи репозиторій насичений на читання? Перевірте iostat -xm на репозиторії під час відновлення. Шукайте високий %util і зростаючий await.
• Чи продукційний запис насичений? Перевірте затримки datastore на ESXi. Висока затримка запису означає «відновлення в швидкозасипаюче болото».
• Чи CPU прижатий? Перевірте CPU на репозиторії і проксі/backup server. Високе навантаження user CPU під час відновлення часто означає наклад декомпресії/шифрування.

Другий крок: підтвердіть, що мережа не брешить

• Запустіть iperf3 між джерелом і ціллю відновлення.
• Перевірте ретрансляції за допомогою ss -ti (Linux) і лічильники портів комутатора, якщо доступні.
• Підтвердіть MTU енд‑ту‑енд. Змішаний MTU — класична проблема «працює, але повільно».

Третій крок: перевірте ланцюг бекапу і стан метаданих

• Для PBS: запускайте розклади datastore verify і шукайте помилки; переконайтеся, що prune не застряг і сховище не близьке до заповнення.
• Для Veeam: підтвердіть сервіси, доступність репозиторію і що ланцюг завдань не в дивному стані (наприклад, пошкоджені інкременти, відсутні екстенти).

Четвертий крок: ізолюйте тестовим контролюваним відновленням

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

Поширені помилки (симптом → корінь → виправлення)

1) Симптом: «Миттєве відновлення миттєве… але болісно повільне»

Корінь: Сховище репозиторію оптимізоване під послідовний інгест бекапів, а не під випадкові читання, потрібні для запуску ВМ.

Виправлення: Помістіть «міттєві» робочі навантаження на швидкі носії (NVMe/SSD), окремі екстенти, або прийміть, що миттєве відновлення — інструмент тріажу, а не довготривале робоче середовище.

2) Симптом: Швидкість відновлення сильно змінюється день у день

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

Виправлення: Вимірюйте пропускну здатність у вікнах відновлення (iperf3), перевіряйте ретрансляції, впровадьте QoS або ізолюйте трафік бекапів, і уникайте відновлення в зайнятий datastore.

3) Симптом: Бекапи успішні, відновлення падають через корупцію або відсутні точки

Корінь: Відсутність рутинної верифікації; помилки підлеглого сховища; зламані ланцюги.

Виправлення: PBS: розклад verify і scrubs; замінюйте диски, що падають. Veeam: увімкніть health checks, періодичні active fulls/synthetic з верифікацією і запускайте тести відновлення.

4) Симптом: Репозиторій «неочікувано» заповнюється і джоби починають падати

Корінь: Неправильна конфігурація retention/prune, вимкнене очищення або вікна іммутованості, що виходять за рамки планування ємності.

Виправлення: Аудит ретеншну і іммутованості, перевірка prune/merge операцій, встановлення порогів ємності та оповіщень до 85–90% використання.

5) Симптом: Знімки VMware зростають і VMs «stun» під час вікон бекапу/відновлення

Корінь: Видалення знімків важке для сховища; довгі ланцюги знімків через повільні читання бекапу; проблеми з CBT або quiescing.

Виправлення: Покращіть швидкість читання бекапу (режим транспорту, розміщення проксі), тримайте знімки короткоживучими і перевірте налаштування quiescing для VM/застосунків.

6) Симптом: «Відновили, але застосунок зламаний»

Корінь: Crash‑consistent бекапи там, де потрібна була application‑consistent, або відсутні залежності (DNS/AD/синхронізація часу).

Виправлення: Використовуйте application‑aware обробку там, де потрібно, документуйте порядок залежностей і валідуйте відновлення застосунків у тестах.

7) Симптом: Команда безпеки каже, що бекапи не стійкі до рансомваре

Корінь: Інфраструктура бекапів ділиться адміністраторськими обліками з продукцією, репозиторії можна видалити або іммутованість не справді застосована.

Виправлення: Розділяйте ідентичності, впровадьте іммутованість/hardened репозиторії, обмежте доступ до shell і підтримуйте офлайн/офсайт копію з незалежними обліками.

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

План A: Якщо ви обираєте Veeam і хочете швидкі відновлення без драм

1. Проєктуйте для відновлення, а не для бекапу. Обирайте репозиторій, який може впоратися з випадковими читаннями (SSD/NVMe‑tiering допомагає).
2. Розміщення проксі — робіть свідомо. Уникайте «одного проксі‑VM на тому ж перевантаженому хості». Використовуйте кілька проксі, якщо важлива паралельність.
3. Стандартизуйтесь на режим транспорту. Протестуйте HotAdd vs NBD vs Direct SAN у вашому середовищі і задокументуйте переможця.
4. Побудуйте іммутованість правильно. Hardened Linux repository патерни, окремі обліки і суворий доступ. Ніякого спільного domain admin.
5. Встановіть операційні SLO. Наприклад: «Відновити VM рівня 1 за X хвилин у тестових умовах».
6. Автоматизуйте тестування відновлень. Використовуйте роботи валідації і періодичні повні відновлення. Поставте це в календар, а не на настрій.
7. Повідомлення про стан репозиторію. Вільне місце, помилки завдань і дивна поведінка ланцюгів. Спіймайте це до аварії.

План B: Якщо ви обираєте PBS як ваше зберігання бекапів і прагнете простоти експлуатації

1. Трохи перепроектуйте диски та RAM. Dedupe‑сховища люблять RAM і стабільні IOPS.
2. Використовуйте ZFS професійно. Регулярні scrubs, SMART‑моніторинг, розумний ashift і без «таємного RAID‑контролера», що зображає write‑hole.
3. Плануйте verify і prune. Робіть перевірки цілісності рутинними, а не героїчними.
4. Розділіть домени відмов. Реплікуйте на інший PBS або незалежну ціль. Уникайте «той самий стояк, той самий комутатор, то сама лінія живлення».
5. Документуйте runbook для відновлень. Точно як ви відновлюєте у VMware, включно з обліками, мережею і місцем посадки відновлених VM.
6. Тестуйте відновлення щомісяця. Повне ВМ, файли і принаймні одне відновлення специфічного застосунку.
7. Обмежте область впливу адміністраторів. Адміністратори бекапів не повинні одночасно мати обліки, що можуть миттєво все видалити.

План C: Гібридний підхід, що часто перемагає

Якщо ви прагматичні (і це добре), ви помітите: Veeam і PBS не повинні бути взаємовиключними за духом. Багато команд досягають успіху за такою схемою:

• Veeam для оркестрації, нативної для VMware, і робочих процесів відновлення.
• Дисципліна Linux/ZFS/PBS‑подібна для репозиторіїв: перевірки цілісності, передбачувана продуктивність, принципи іммутованості.

Навіть якщо PBS не ваш основний оркестратор бекапів для VMware, ви все одно можете перейняти його філософію: verify, prune, checksum, replicate і тримати все простим.

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

1) Хто швидший у відновленнях: PBS чи Veeam?

Veeam швидший, щоб «отримати щось запущеним» у багатьох VMware‑середовищах, тому що Instant VM Recovery зрілий. PBS може бути надзвичайно швидким у поверненні даних, коли конвеєр спроектований добре. Практична відповідь: Veeam виграє за модальностями відновлення; PBS виграє за передбачуваною поведінкою сховища, коли його правильно змонтовано.

2) Який один найбільший предиктор продуктивності відновлення?

Продуктивність читання репозиторію під випадковим I/O плюс затримка запису продукційного datastore. Якщо одне з них погане — відновлення будуть погані. Фічі не врятують.

3) Чи можна досягти стійкості до рансомваре за допомогою обох?

Так, але це треба реалізувати. Veeam зазвичай використовує hardened Linux репозиторії і вікна іммутованості. PBS підтримує валідацію цілісності і може бути розгорнутий із суворим контролем доступу та реплікацією в ізольовану ціль. Слабке місце зазвичай — ідентичність і доступ, а не ПЗ.

4) Чому відновлення падають, коли бекапи «успішні»?

Бо «успіх завдання бекапу» часто означає «дані переміщені», а не «дані придатні до відновлення». Потрібна верифікація (PBS verify / scrubs ZFS) і рутинні тести відновлення (Veeam verification/SureBackup‑подібні) щоб виявити мовчазні помилки.

5) Чи завжди варто використовувати дедуплікацію для VMware бекапів?

Зазвичай так для економії ємності, але вона може погіршити продуктивність відновлення, якщо CPU і IOPS не достатні для ре­гістрації. Якщо ваш RTO строгий, розгляньте менш агресивні налаштування компресії/дедуплікації або швидше compute/сховище в репозиторії.

6) Чи варто відновлювати на той самий datastore?

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

7) Яка найпоширеніша операційна помилка з Veeam?

Спавл: забагато проксі/репозиторіїв без стандартів, плюс непослідовне патчування і гігієна обліків. В результаті ви отримуєте потужну систему, про яку важко думати під час інциденту.

8) Яка найпоширеніша операційна помилка з PBS?

Недооцінка інженерії сховища. Люди ставлять його як магічну коробку дедуплікації і розгортають на посередніх дисках, сумнівних RAID‑контролерах або на недостатньо потужному обладнанні. PBS скаже вам правду — бути повільним.

9) Чи потрібен 10GbE (або більше) для швидких відновлень?

Якщо у вас великі VM і строгі RTO — так, принаймні 10GbE, часто більше. Але ширина каналу без низької втрати і узгодженого MTU — просто паперовий тигр. Вимірюйте пропуск і ретрансляції у вікнах відновлення.

10) Як зробити операції відновлення «простими» для on‑call?

Напишіть runbook з: куди відновлювати, як валідувати завантаження/здоров’я застосунків, хто погоджує мережеве розміщення і що означає «завершено». Потім проводьте щомісячні тренування. Простота — це навичка, не покупка.

Наступні кроки, які ви дійсно можете виконати

1. Оберіть ваш основний робочий процес відновлення. Якщо вам стандартно потрібне миттєве завантаження з бекапів — робіть ухил у бік Veeam.
2. Протестуйте шлях відновлення. Запустіть iperf3, перевірте iostat репозиторію і затримки ESXi datastore. Виправте найповільніший ланцюг першим.
3. Впровадьте верифікацію. PBS datastore verify + ZFS scrubs або Veeam health checks і розкладні тести відновлення. Робіть це регулярно.
4. Спроектуйте іммутованість і контроль доступу навмисно. Розділяйте обліки, зменшуйте область впливу і тримайте принаймні одну копію поза досяжністю скомпрометованої продуктивної ідентичності.
5. Зробіть один повний drill з відновлення ВМ цього місяця. Не файл‑відновлення. Не скріншот. Реальна VM, що завантажується з чек‑лістом валідації.

Якщо хочете прямолінійну рекомендацію: більшість VMware‑організацій повинні починати з Veeam заради операційної безпеки, а потім застосувати дисципліну типу PBS до шару репозиторію. Якщо у вас вже сильні Linux/сховищні операції і ви цінуєте простіший бекап‑ядро, PBS може стати чистим, швидким і зберігаючим здоровий глузд вибором — за умови, що ви проінженерили інтеграцію з VMware і тестуєте відновлення як справу честі.