Proxmox: Резервне копіювання Windows VM без проблем з VSS — Практичний робочий процес

Чого ви насправді прагнете досягти (і від чого припинити вдавати)

Послідовність — це спектр, а не бінарна величина

Коли люди сперечаються про «crash-consistent vs application-consistent», вони часто пропускають практичне питання: як саме має виглядати відновлення, щоб задовольнити ваші бізнесові RTO/RPO та аудиторські вимоги?

Для Windows VM «application-consistent» зазвичай означає, що гостьова ОС встигла скинути буфери файлової системи і координуватися з додатками через VSS. Це може бути чудово. Але це також пастка: VSS — це розподілена система всередині однієї VM, з кількома writers, і кожен writer може зіпсувати вам вечір.

Crash-consistent знімки не є по суті злочинними. Якщо ваша робоче навантаження толерантне (багато з них такі) і ви тестуєте відновлення, вони можуть бути абсолютно прийнятними. Проблема не в crash-consistency; проблема в тому, що ви вважаєте, ніби маєте application-consistency, коли насправді її немає.

Резервні копії — це навантаження на сховище, а не просто галочка

Завдання резервного копіювання в Proxmox — це не «просто скопіювати VM». Це координований I/O-шторм: багато читань, багато записів, обчислення контрольних сум (якщо ви робите все правильно), і все це на розкладі, який конфліктує з усім іншим, що вам важливо (нічне обслуговування, антивірусні сканування, ETL-джоби, контрольні точки баз даних і те одне Windows Update, яке ніяк не відступає).

Ваш робочий процес резервних копій живе або вмирає залежно від поведінки сховища: знімки, dirty bitmap, стиснення, chunking, глибина черги та чи вистачає вашому сховищу швидкості, щоб поглинути те, що ви йому даєте.

Найнадійніша система — та, що падає голосно й рано

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

Одна цитата для прищіпки над монітором

Werner Vogels (парафразована ідея): «Все ламається весь час; проектуйте під відмови.»

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

Цікаві факти та трохи історії (тому що це пояснює біль)

1. VSS дебютував з Windows XP/Server 2003 як спроба Microsoft стандартизувати координацію знімків між додатками. Модель writers потужна, але також і єдиний пункт колективного розчарування.
2. VSS — це не інструмент резервного копіювання; це фреймворк координації. Ваш продукт резервного копіювання (або агент) все одно має виконувати фактичне переміщення даних.
3. Збої «writer» часто є вторинними симптомами. Писар бази даних падає через повільне сховище; системний writer — через пошкоджені COM-права; сторонній writer — через падіння минулого вівторка, про яке ніхто не дізнався.
4. Знімки гіпервізора — це не знімки VSS Windows. Proxmox може зробити знімок віртуального диска без відома Windows. Це crash-consistent. Якщо потрібне координоване скидання Windows — потрібна співпраця гостя.
5. QEMU Guest Agent став стандартним шляхом «співпраці гостя» в екосистемі KVM, замінивши старі й більш хитромудрі підходи. Коли він працює — це приємна нудьга.
6. VirtIO драйвери змінили гру для KVM на Windows. Вони значно покращили продуктивність, але також принесли клас багів «неправильна версія драйвера + неправильний режим кешу = дивна I/O-поведінка».
7. ZFS-знімки дешеві; реплікація ZFS не є магією. Знімки — це операції над метаданими; рахунок за продуктивність з’являється, коли ви читаєте й передаєте змінені блоки у великому обсязі.
8. Proxmox Backup Server (PBS) будується навколо content-addressed chunking. Саме тому він добре дедуплікує й саме тому слабкий CPU може стати вашим вузьким місцем раніше, ніж диски.
9. Windows «Fast Startup» створений для десктопів. У VM він часто сприяє плутанині з завантаженням і поведінкою диска після відновлення.

Практичний робочий процес: менше помилок VSS, менше сюрпризів

Визначайте ціль послідовності для кожної VM (будьте явними)

Припиніть намагатися зробити кожну Windows VM «application-consistent» через VSS, якщо це не є необхідним. Категоризуйте:

• Tier A (повинно бути app-consistent): SQL Server, Exchange (якщо він ще є — співчуваю), AD DS контролери домену (особливі правила), бізнес-додатки з суворою транзакційною цілісністю.
• Tier B (бажано app-consistent): файлові сервери, IIS, загальні сервери додатків.
• Tier C (достатньо crash-consistent): безстанні веб-ноди, CI-ранери, jump box, середовища розробки/тестування, десктопи.

Ваші інструменти резервного копіювання можуть відрізнятися для різних рівнів. Це не є єрессю; це інженерія.

За замовчуванням: Proxmox Backup Server + QEMU Guest Agent (без залежності від VSS)

Якщо ваша головна проблема — VSS, найбільш прагматичний крок — роз’єднати «резервне копіювання VM» від «quiesce додатків». Використовуйте PBS (або принаймні vzdump до адекватного цільового сховища) з guest agent freeze/thaw для цілісності файлової системи, а консистентність додатків обробляйте всередині VM за потреби (резервні копії SQL тощо).

Це зводить VSS до місць, де VSS дійсно потрібен, замість того, щоб робити його обов’язковою залежністю для кожного нічного знімка.

Для Tier A: робіть резервні копії на рівні додатків, а потім VM

Для SQL Server робіть SQL-aware резервні копії (full/diff/log). Для AD DS розумійте USN/семантику відновлення і уникайте сценаріїв «ой, ми повернули DC назад». Потім робіть VM-резервні копії для швидкого bare-metal відновлення. VM-резервні копії корисні; вони не є єдиним джерелом істини для транзакційної коректності.

Налаштування Proxmox, які важливі (і ті, що здебільшого не важливі)

Поведение резервного копіювання в Proxmox залежить від:

• Режим резервного копіювання: snapshot vs suspend vs stop. Для Windows зазвичай найкращий snapshot — якщо ваше сховище та поведінка гостевого агента здорові.
• Тип сховища: ZFS, LVM-thin, Ceph, NFS. Кожен змінює семантику знімків і I/O-моделі.
• Режим кешування диска та I/O thread: неправильні вибори можуть посилити затримки під навантаженням резервного копіювання.
• Мережевий шлях до PBS: якщо ви робите резервні копії по мережі, ви щойно додали другий вузький профіль та другу домену відмови.

Гігієна гостя Windows, що зменшує «таємничі» помилки VSS

Навіть якщо ви вирішите не покладатися на VSS для кожної VM, Windows все одно виграє від базової гігієни:

• Встановіть актуальні VirtIO драйвери (storage + network) і тримайте їх узгодженими з версіями Proxmox/QEMU.
• Встановіть і увімкніть QEMU Guest Agent і перевірте, що він дійсно підключений.
• Підтримуйте стабільну синхронізацію часу Windows (ієрархія домену, без конкурентних джерел часу).
• Вимкніть «Fast Startup» для серверних VM. Це вам не допомагає.
• Тримайте достатньо вільного місця на диску. Конвеєри знімків/резервних копій поводяться погано, коли томи заповнені на 98%.

Жарт #1: VSS Writers — це як той співробітник, який «тільки п’ять хвилин» і потім блокує всю релізну гілку.

Підхід «спочатку сховище»: робіть резервні копії сховища

Якщо ви використовуєте PBS — ставтеся до нього як до продуктивного сховища. Це означає:

• За можливості розділяйте завантажувальну/системну зону та датастор.
• Використовуйте ZFS або корпоративний RAID з правильним кешуванням запису (battery-backed для апаратного RAID; або просто ZFS і спіть спокійніше).
• Моніторте завдання верифікації і стан датастора так само, як моніторите базу даних.
• Тестуйте відновлення регулярно. Не щоквартально. Регулярно.

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

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

Завдання 1 — Перевірте, чи Proxmox бачить гостевого агента (чи може VM співпрацювати)

cr0x@server:~$ qm guest cmd 101 ping
{"return":{}}

Що це означає: Агент встановлено, він запущений у Windows, і virtio-serial канал працює.

Рішення: Якщо це не вдається (таймаут або «guest agent not running»), виправте агента перед тим, як звинувачувати резервні копії. Без нього freeze/thaw і коректна координація не відбудуться.

Завдання 2 — Підтвердіть, що конфіг файлу VM вам не саботує (agent flag, disk bus)

cr0x@server:~$ qm config 101 | egrep -i 'agent|scsi|virtio|cache|iothread'
agent: 1
scsi0: zfspool:vm-101-disk-0,cache=none,discard=on,iothread=1,ssd=1
scsihw: virtio-scsi-single

Що це означає: Агент увімкнено; диск на virtio-scsi; режим кешу none; iothread увімкнено.

Рішення: Надавайте перевагу virtio-scsi + cache=none для більшості серверних робочих навантажень. Якщо в 2026 році ви бачите IDE/SATA для системних дисків — це технічний борг з відсотками.

Завдання 3 — Перевірте стан цільового сховища резервних копій (стан datastore PBS)

cr0x@server:~$ proxmox-backup-manager datastore list
┌───────────┬──────────────┬────────┬──────────────┬──────────┐
│ Name      │ Path         │ Prune  │ GC           │ Comment  │
╞═══════════╪══════════════╪════════╪══════════════╪══════════╡
│ pbs-zfs   │ /datastore   │ keep…  │ daily        │ main     │
└───────────┴──────────────┴────────┴──────────────┴──────────┘

Що це означає: Datastore існує і управляється.

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

Завдання 4 — Перевірте завантаження датастора (тиск по ємності викликає дивності)

cr0x@server:~$ df -h /datastore
Filesystem      Size  Used Avail Use% Mounted on
rpool/datastore 7.3T  6.1T  1.2T  84% /datastore

Що це означає: 84% використано. Це ще не пожежа, але неприємний запах.

Рішення: Вище ~85–90% для ZFS-цільових ресурсів — продуктивність і техобслуговування можуть погіршуватися. Скоротіть ретеншн, додайте місця або розділіть навантаження між датасторами.

Завдання 5 — Перевірте стан ZFS pool на хості Proxmox (тиха корупція — кар’єрний ризик)

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

Що це означає: Немає відомих помилок пристроїв, resilvers або повідомлень про пошкодження даних.

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

Завдання 6 — Перегляньте властивості ZFS dataset, що впливають на I/O при бекапі

cr0x@server:~$ zfs get -o name,property,value compression,atime,recordsize,sync rpool/data
NAME       PROPERTY     VALUE
rpool/data compression  lz4
rpool/data atime        off
rpool/data recordsize   128K
rpool/data sync         standard

Що це означає: Розумні налаштування за замовчуванням для зберігання VM (lz4, atime off).

Рішення: Якщо sync=always встановлено на VM-датасетах без SLOG, резервні копії зі знімками можуть повільно працювати. Якщо compression=off, ви марнуєте I/O і місце для багатьох Windows-навантажень.

Завдання 7 — Запустіть вручну резервну копію однієї VM і спостерігайте поведінку

cr0x@server:~$ vzdump 101 --mode snapshot --storage pbs --compress zstd --notes-template '{{guestname}} {{vmid}}'
INFO: starting new backup job: vzdump 101 --mode snapshot --storage pbs --compress zstd
INFO: Backup started at 2026-02-04 01:12:30
INFO: status = running
INFO: VM Name: WIN-APP01
INFO: include disk 'scsi0' 'zfspool:vm-101-disk-0' 200G
INFO: creating Proxmox Backup Server archive 'vm/101/2026-02-04T01:12:30Z'
INFO: starting kvm to execute backup task
INFO: transferred 24.1 GiB in 00:03:12 (128.5 MiB/s)
INFO: backup finished successfully
INFO: Backup ended at 2026-02-04 01:15:45

Що це означає: Snapshot backup завершився; пропускна здатність виглядає реалістичною.

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

Завдання 8 — Визначте, чи мережа є обмежувальним фактором (стан лінку хоста)

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
bond0            UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33

Що це означає: Інтерфейси підняті.

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

Завдання 9 — Заміряйте реальну мережеву пропускну здатність до PBS (не відчуття)

cr0x@server:~$ iperf3 -c pbs01 -t 10
Connecting to host pbs01, port 5201
[  5] local 10.10.10.21 port 54218 connected to 10.10.10.31 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec  9.35 GBytes  8.03 Gbits/sec  12   1.25 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  9.35 GBytes  8.03 Gbits/sec  12             sender
[  5]   0.00-10.00  sec  9.34 GBytes  8.02 Gbits/sec                  receiver

Що це означає: ~8 Gbit/s на 10G-лінку, з деякими повторними передачами.

Рішення: Якщо тут 900 Mbit/s на «10G», ваша проблема не в VSS. Це кабелі, налаштування NIC, налаштування комутатора, MTU або креативна конфігурація bond.

Завдання 10 — Спостерігайте за I/O-затримкою хоста під час бекапів (істина в iostat)

cr0x@server:~$ iostat -x 2 5
Linux 6.8.12 (pve01) 	02/04/2026 	_x86_64_	(32 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         420.0   310.0 51200.0 42800.0   4.2    0.3   28.0
sdb              12.0    90.0   480.0  9200.0  45.6    1.2   96.0

Що це означає: sdb насичено з високим await. Це вузьке місце. NVMe виглядає добре.

Рішення: Якщо ваше VM-сховище або ціль PBS лежить на насиченому пристрої, резервні копії будуть повільними, а операції знімків можуть таймаутитися. Виправте повільний дисковий шлях перш ніж «налаштовувати» рівні стиснення.

Завдання 11 — Перевірте логи задач Proxmox на предмет таймаутів знімків та збоїв агента

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:000A1C2D:1F3A3E10:65C000B2:vzdump:101:root@pam:
status: running
command: vzdump 101 --mode snapshot --storage pbs --compress zstd

Що це означає: Завдання активне; UPID — ваш ідентифікатор для детальнішого перегляду.

Рішення: Якщо завдання зависає тут — дивіться на дискові затримки та ingest PBS. Якщо воно падає — зафіксуйте точні рядки помилок, не підсумовуйте їх в Slack як «backup broken».

Завдання 12 — Перегляньте журнал на предмет помилок, повʼязаних з бекапом (ядро, сховище, NFS, PBS)

cr0x@server:~$ journalctl -u pvedaemon -u pvescheduler -u pveproxy --since "1 hour ago" | tail -n 40
Feb 04 01:14:10 pve01 pvedaemon[2387]: INFO: starting task UPID:pve01:000A1C2D:...
Feb 04 01:15:21 pve01 pvedaemon[2387]: INFO: VM 101 qmp command 'guest-fsfreeze-freeze' succeeded
Feb 04 01:15:23 pve01 pvedaemon[2387]: INFO: VM 101 qmp command 'guest-fsfreeze-thaw' succeeded
Feb 04 01:15:45 pve01 pvedaemon[2387]: INFO: end task UPID:pve01:000A1C2D:...: OK

Що це означає: Freeze/thaw пройшли успішно; резервне копіювання завершилося.

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

Завдання 13 — Підтвердіть стан VSS writer на Windows (коли він вам потрібен)

cr0x@server:~$ qm guest exec 101 -- powershell -NoProfile -Command "vssadmin list writers"
{
  "exitcode": 0,
  "exited": 1,
  "out-data": "Writer name: 'System Writer'\r\n   State: [1] Stable\r\n   Last error: No error\r\n\r\nWriter name: 'WMI Writer'\r\n   State: [1] Stable\r\n   Last error: No error\r\n",
  "err-data": ""
}

Що це означає: Writers наразі стабільні.

Рішення: Якщо writer застряг у failed стані, інколи допомагає перезапуск відповідної служби. Але якщо це повторюється — розглядайте це як баг додатка, а не як баг резервного копіювання.

Завдання 14 — Перевірте журнали подій Windows щодо підказок VSS (не робіть гадань)

cr0x@server:~$ qm guest exec 101 -- powershell -NoProfile -Command "Get-WinEvent -LogName Application -MaxEvents 20 | ?{$_.ProviderName -match 'VSS|Volsnap'} | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Format-List"
{
  "exitcode": 0,
  "exited": 1,
  "out-data": "TimeCreated : 2/4/2026 1:02:11 AM\r\nProviderName: VSS\r\nId          : 8193\r\nLevelDisplayName : Error\r\nMessage     : Volume Shadow Copy Service error: Unexpected error calling routine...\r\n",
  "err-data": ""
}

Що це означає: Маєте помилку VSS з ID, який можна зіставити з типовими шаблонами відмов.

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

Завдання 15 — Перевірте статус валідації PBS (виявлення корупції — не опціонально)

cr0x@server:~$ proxmox-backup-manager task list --since "1 day ago" | head
┌────────────┬─────────┬───────────┬──────────┬──────────┬────────┐
│ Starttime  │ Endtime │ Worker ID │ Type     │ Status   │ User   │
╞════════════╪═════════╪═══════════╪══════════╪══════════╪════════╡
│ 01:30:00   │ 02:10:12│ verify    │ verify   │ OK       │ root@pam │
│ 01:00:00   │ 01:12:02│ prune     │ prune    │ OK       │ root@pam │
└────────────┴─────────┴────────────┴──────────┴──────────┴────────┘

Що це означає: Верифікація пройшла і була успішною.

Рішення: Якщо verify падає — ставтесь до цього як до ознаки помилки диска, поки не доведено інше. Просто перезапускати її і сподіватися — не варіант.

Завдання 16 — Протестуйте відновлення (єдина метрика, що має значення)

cr0x@server:~$ qmrestore /mnt/pbs/vm/101/2026-02-04T01:12:30Z 901 --storage zfspool
restore vma archive: PBS snapshot 'vm/101/2026-02-04T01:12:30Z'
creating VM 901
restore image: zfspool:vm-901-disk-0
progress 10%... 50%... 100%
restore successful

Що це означає: Ви можете відновити реальну VM з набору резервних копій.

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

Плейбук швидкої діагностики: знайти вузьке місце за хвилини

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

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

• Завдання резервного копіювання падає швидко (секунди до хвилини): автентифікація, права, шлях до сховища, недоступний PBS datastore, відсутній агент.
• Завдання резервного копіювання зависає або повзе (хвилини до годин): затримка диска, ingest PBS CPU/disk, мережевий пропуск, операції знімків блокує сховище.
• Резервна копія «успішна», але відновлення зламане: проблеми консистентності, файлової системи на рівні гостя, або ви резервували не те (виключені диски, неправильний VMID тощо).

Друге: ізолюйте домен вузького місця (диск хоста, диск PBS, CPU, мережа, гість)

1. Затримка хостового сховища: запускайте iostat -x під час бекапу. Високий await і ~100% %util на релевантних пристроях означає I/O-bound.
2. Сторона ingest PBS: якщо диски хоста у порядку, перевірте CPU та диск PBS. Chunking + стиснення + шифрування може зробити вузьким місцем CPU на скромному обладнанні.
3. Мережева пропускна здатність: запускайте iperf3 між хостом і PBS. Якщо повільно — бекапи будуть повільними. Сюрприз.
4. Співпраця гостя: якщо знімки падають або таймаутяться на freeze, перевірте підключення QEMU guest agent і стабільність Windows.

Третє: ідентифікуйте конкретну точку пропуску

• Якщо латентність стрибає на збереженні VM: перемістіть вікна бекапу, зменшіть конкуренцію, використайте швидші vdev, або ізолюйте читання бекапу від продуктивного I/O (різні пули).
• Якщо PBS завантажений по CPU: розгляньте більше ядер, перевірте налаштування BIOS живлення, переконайтеся, що AES-NI доступний при шифруванні, налаштуйте рівні стиснення (зменшіть рівні zstd) або зменшіть конкуренцію.
• Якщо мережева ланка — вузьке місце: виправте MTU, LACP, буфери комутатора, NIC offloads; або не надсилайте бекапи через перевантажений лінк під час критичних задач.
• Якщо VSS — вузьке місце: перестаньте робити VSS вашою дефолтною залежністю. Використовуйте QGA freeze для базової цілісності; використовуйте app-native бекапи для Tier A.

Жарт #2: Якщо продуктивність бекапу «залежить від погоди», вітаю — ви побудували хмару, тільки без бюджету.

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

1) Резервні копії періодично падають з «guest-fsfreeze-freeze timeout»

Симптоми: Логи Proxmox показують таймаут команди freeze; VM інакше «в порядку».

Корінна причина: QEMU Guest Agent не встановлено правильно, служба застрягла всередині Windows, або virtio-serial канал відсутній/заблокований. Іноді агент встановлено, але не увімкнено в конфігурації Proxmox.

Виправлення: Переконайтеся, що agent: 1 у конфігурації VM, перевірте qm guest cmd <vmid> ping, перевстановіть/оновіть QGA у Windows і підтвердіть наявність пристрою VirtIO serial у Device Manager.

2) Резервні копії «успішні», але відновлення Windows завантажується з CHKDSK або має dirty томи

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

Корінна причина: Ви робите crash-consistent знімки навантажень з інтенсивними записами і очікуєте application-consistency. Або налаштування кешу/диска Windows небезпечні й буфери не скидалися при знімку.

Виправлення: Використовуйте мінімум QGA freeze/thaw. Для Tier A робіть app-native резервні копії (SQL) і вважайте VM-резервні копії швидкими образами для відновлення, а не транзакційними журналами.

3) VSS writer «System Writer» падає лише під час вікон резервного копіювання

Симптоми: VSS стабільний опівдні, зламаний опівночі. Event ID 8193/12289 з’являється навколо часу бекапу.

Корінна причина: Тиск ресурсів: стрибки затримки сховища, антивірусні сканування VSS-знімків або сторонній VSS-провайдер заважає.

Виправлення: Зменшіть конкуренцію бекапів, перемістіть вікно бекапу, додайте IOPS, виключте VSS-пов’язані каталоги з AV згідно з рекомендаціями вендора та видаліть непотрібні VSS-провайдери за потреби.

4) Резервні копії дуже повільні після «покращення стиснення»

Симптоми: Пропускна здатність падає; CPU підскакує; завдання перекриваються в робочий час.

Корінна причина: Рівень стиснення надто високий для доступного CPU (на хості або PBS). Chunking + стиснення — це робота CPU, а не безкоштовне місце.

Виправлення: Використовуйте розумне стиснення (за замовчуванням zstd часто підходить). Масштабуйте CPU або зменшіть конкуренцію. Не «оптимізуйте» без вимірів.

5) PBS datastore заповнюється, хоча pruning налаштовано

Симптоми: Використання сховища росте; prune запускається «OK», але місце не звільняється.

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

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

6) Snapshot backups зупиняють VM (користувачі помічають зависання)

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

Корінна причина: Затримка сховища і поведінка commit-знімку під навантаженням; іноді налаштування write cache або недостатній SLOG для синхронно-важких робочих навантажень на ZFS.

Виправлення: Зменшіть конкуренцію, ізолюйте I/O бекапу, забезпечте правильний ZFS-розподіл (mirrors для IOPS) і уникайте патологічних sync-настроїв. Перевірте режим кешу диска і конфігурацію iothread.

7) Відновлення повільні, хоча бекапи були швидкі

Симптоми: Інгест бекапу швидкий, відновлення повзе.

Корінна причина: Цільове сховище відновлення повільніше за джерело; або тиск ZFS ARC, фрагментація або повільний vdev.

Виправлення: Заміряйте шлях відновлення. Якщо ви відновлюєте на продуктивне сховище — воно має бути достатньо швидким, щоб відновити VM на вимогу. «Бекапи швидкі» не означає «відновлення швидке».

Три міні-історії з корпоративного світу (ті, що дістаються у спадок)

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

Вони мали чистий Proxmox-кластер, блискучий PBS, і нічні резервні копії по всьому периметру. Дашборд резервних копій більшість часу був зеленим. Менеджмент був задоволений. Операційна команда могла займатися «більш стратегічними ініціативами», що корпоративною мовою означає «ми не наймаємо».

Потім одна Windows файловий сервер VM вивалився. Нічого надзвичайного — просто невдале оновлення в поєднанні з крашем драйвера. Відновлення з останньої ночі в новому VMID, підключили мережу — користувачі повернулися через 20 хвилин. Оплески. Тікет закрито.

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

Неправильне припущення: вони вірили, що резервні копії були application-consistent, бо продукт казав «snapshot backup». Насправді на тій VM гостевий агент не працював. Вони робили crash-consistent знімки під час інтенсивних записів, і відновлення іноді повертало файлову систему у стан, що не відповідав очікуванням користувачів. Не завжди. Але досить часто, щоб лякати.

Виправлення було не драматичним. Вони встановили і перевірили QEMU Guest Agent, переключили робочий процес для файлових серверів на freeze/thaw і додали рутину тестового відновлення. Найскладніше було змінити культуру: «зелені завдання бекапу» перестали бути метою. Метою стали верифіковані відновлення.

Міні-історія 2: Оптимізація, що зіграла проти

Інша команда помітила, що вікна резервного копіювання заходили в робочий час. Хтось — з добрими намірами й навичками — вирішив «оптимізувати стиснення». Вони підняли рівні zstd і включили шифрування всюди, бо «безпека». Обидві цілі справжні. Проблема в тому, що залізо байдуже до ваших намірів.

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

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

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

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

Одна команда мала звичку, що виглядала старомодно: щомісяця вони проводили drill відновлення для невеликого набору представницьких Windows VM. Не просто «відновлення завершено», а «VM завантажується, сервіси стартують, перевірки додатків пройшли». Вони ротаційно тестували різні системи і вели короткий ранбук того, що означає «добре».

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

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

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

Практика не виглядала витончено. Проте саме вона дозволила їм спокійно пережити вихідні, які могли стати приводом для оновлення резюме.

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

Покроково: встановіть базову, низькодраматичну конфігурацію

1. Класифікуйте VM за рівнями (A/B/C) згідно з вимогами консистентності додатків.
2. Встановіть VirtIO драйвери і QEMU Guest Agent в кожну Windows VM. Перевіряйте через qm guest cmd <vmid> ping.
3. Стандартизуйтесь конфігурацію дисків: контролер virtio-scsi, cache=none, увімкніть iothread де доречно.
4. Виберіть цілі резервного копіювання свідомо:
   • PBS для дедуплікації, верифікації і керованого ретеншну.
   • За можливості відокремлюйте датастор/пул; коли бекапи конкурують з продукцією — це відома халепа.
5. Встановіть політику ретеншну, що відповідає ємності (daily/weekly/monthly) і переконайтеся, що розклади prune + GC існують.
6. Обмежте конкуренцію спочатку. Почніть з малого, виміряйте, потім масштабуйтесь. Не починайте з «всі VM одночасно».
7. Реалізуйте тести відновлення:
   • Щонайменше один тест завантаження відновлення щотижня по ротації.
   • Для Tier A: включіть перевірки на рівні додатків.

Чек-лист: налаштування Windows VM, що зменшують дивності при бекапі

• QEMU Guest Agent встановлено, запущено і увімкнено в Proxmox.
• VirtIO storage драйвери оновлені; уникайте застарілих контролерів для системних дисків.
• Вимкнено Fast Startup для серверних VM.
• Забезпечте адекватний вільний простір на томах (не жити на 95% заповнення).
• Перевірені виключення AV для операцій бекапу/знімків там, де це застосовно (обережно, не бездумно).
• Синхронізація часу узгоджена (ієрархія домену; уникайте конкурентних джерел синхронізації).

Чек-лист: операційна гігієна PBS

• Задачі верифікації заплановані і моніторяться.
• Існують розклади prune і GC, і вони завершуються.
• Моніторинг використання датастора; підтримується запас ємності.
• Періодичні тести відновлення виконуються з PBS, а не з «якоїсь іншої копії».
• Апаратне забезпечення має достатній CPU для chunking/compression/encryption.

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

1) Чи можна робити резервні копії Windows VM на Proxmox зовсім без VSS?

Так. Резервні копії на рівні VM можуть бути crash-consistent, а з QEMU Guest Agent freeze/thaw вони можуть бути консистентними на рівні файлової системи без VSS. Для транзакційних додатків використовуйте нативні бекапи додатків.

2) Чи достатній QEMU Guest Agent для серверів Windows?

Для координації freeze/thaw і коректного завершення — так, якщо встановлений правильно і актуальний. Він не замінює SQL-aware бекапи або інші специфічні засоби захисту додатків.

3) Який режим Proxmox використовувати: snapshot, suspend чи stop для Windows?

Режим snapshot — рекомендований за замовчуванням. Suspend/stop можуть покращити консистентність, але збільшують час простою або stun. Використовуйте stop тільки якщо приймаєте даунтайм або не довіряєте стану гостя.

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

Зазвичай щось змінилося. Заповнилася ємність, зросла фрагментація ZFS, сповільнилась GC PBS, зросли мережеві повтори або конкуренція бекапів. Спочатку виміряйте I/O-затримку і перевірте розклади.

5) Чи потрібно вимикати Windows Fast Startup на серверних VM?

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

6) Скільки одночасних задач резервного копіювання запускати?

Почніть з 1–2 на хост, вимірюйте затримку сховища і тривалість бекапу, потім масштабуйтесь. Якщо затримка зростає і VM лагають — ви перестаралися. Конкуренція — не риса характеру.

7) Верифікація PBS іноді падає. Це «нормально»?

Ні. Ставтесь до збоїв верифікації як до сигналу про проблеми зі сховищем, памʼяттю або дисками, поки не доведено інше. Періодична корупція не покращується оптимізмом.

8) Чи прийнятні crash-consistent бекапи для контролерів домену Active Directory?

Будьте обережні. AD має специфічні семантики відновлення. Якщо ви покладаєтесь на VM-знімки/резервні копії, перевірте підхід і розгляньте системні бекапи і процедури авторитетного/неавторитетного відновлення.

9) Чи варто бекапити на NFS замість PBS?

Можна, але ви втрачаєте workflow PBS з chunking/dedupe/verification. NFS може підійти, якщо воно надійне і моніториться, але часто стає джерелом «працює, допоки не перестане» інцидентів.

10) Яке одне найцінніше покращення я можу зробити?

Тестування відновлення. Друге за цінністю — інструментування: знати, чи ви обмежені диском, CPU чи мережею під час бекапів.

Висновок: практичні наступні кроки

Якщо ваші Windows-бекапи на Proxmox — це хоррор-антологія в стилі VSS, припиніть робити VSS універсальною залежністю. Використовуйте робочий процес, який за замовчуванням робить VM-рівневі бекапи з кооперацією гостевого агента, і залишайте VSS та application-aware бекапи для систем, яким вони справді потрібні.

Зробіть наступне:

1. Виберіть 3 Windows VM: одна Tier A, одна Tier B, одна Tier C. Перевірте підключення QEMU Guest Agent і налаштування дисків/контролера.
2. Запустіть ручні бекапи, спостерігаючи iostat і мережеву пропускну здатність. Ідентифікуйте реальний домен вузького місця.
3. Налаштуйте в PBS верифікацію + prune/GC розклади (і налаштуйте оповіщення про збої).
4. Виконайте одне тестове відновлення цього тижня. Завантажте VM. Підтвердіть, що сервіс працює. Запишіть, що означає «добре».
5. Потім масштабуйтесь: коригуйте конкуренцію, ретеншн і апаратні ресурси на основі виміряних обмежень, а не надії.

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