Proxmox на ZFS: стратегія резервного копіювання, що не бреше (знімки проти реальних резервних копій)

December 28, 2025 • February 3, 2026 • Читання: 5 хв • Views: 7

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

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

Резервні копії — це продукт: вони повинні забезпечувати відновлення. ZFS-знімки — це функція: вони забезпечують зручність. Перестаньте їх плутати.
Ось жорсткий план дій, що тримає кластери Proxmox у чесності.

Основне твердження: знімки — це не резервні копії

ZFS-знімок — це довідка про стан у часі на блоки в тому самому пулі. Він чудовий для швидкого відкату та моментів «упс».
Але він живе і вмирає разом з пулом. Якщо пул загинув, ваші знімки теж зникли. Якщо пул зашифровано і ключ втрачено, ваші знімки «є» так само, як файли на диску, який не можна розблокувати: технічно — є, духовно — є, але операційно — ні.

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

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

Жарт #1: Знімок — це як кнопка збереження, яка працює тільки якщо ваш ноутбук не впав в океан. Чудова функція, сумнівне аварійне відновлення.

Цікаві факти та коротка історія (що допомагає у рішеннях)

ZFS-знімки — це copy-on-write: вони не «заморожують» дані копіюванням; вони зберігають посилання на блоки і записують нові блоки при змінах.
ZFS спроектовано з end-to-end контрольними сумами: блоки даних і метаданих перевіряються контрольними сумами, тому тиха корупція виявляється під час читання та scrub.
Спадщина Solaris має значення: ZFS виріс в ентерпрайз-середовищах, де «відкат» і «реплікація» були різними поняттями — знімки і send/receive виконують різні ролі.
zfs send — це потокова операція на основі знімків: реплікація та багато робочих процесів «на зразок бекапу» покладаються на знімки як одиницю передачі.
ZFS scrubs — це патрульні читання: вони не є резервними копіями, але допомагають знаходити бітову корупцію до того, як вона стане подією відновлення.
Proxmox історично покладався на vzdump: класичні резервні копії були архівами файлів на цільовому сховищі; сучасні розгортання все частіше використовують Proxmox Backup Server (PBS) для шардування, дедуплікації та перевірок.
Знімки стали популярними через їх дешевизну: відчуття «майже нульової вартості» призводить до того, що команди зловживають ними як збереженням історії, а потім дивуються обліку простору.
RAID — це не резервна копія — і досі: RAID (включно з RAIDZ) зменшує час простою при відмові диска, але нічого не робить для логічного видалення, програм-вимогувачів або «ой, я стер датасет».

Модель загроз: від чого ви насправді захищаєтеся

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

1) Людський фактор (т.зв. «я — причина відмови»)

Випадкові видалення, знищення неправильного датасету, повторна інсталяція неправильного вузла, форматування неправильного диска. Це не рідкісна подія; це регулярний податок.
Знімки відмінні для цього коли пул здоровий.

2) Втрата домену відмови сховища

HBA помирає і виводить з ладу кілька дисків, збій бекплейну, баг у прошивці, корупція пула або повільне жахіття, коли пул не імпортується після перезавантаження.
Якщо ваші знімки на цьому пулі, вони просто стануть гарною пам’ятною табличкою.

3) Ransomware і компрометація облікових даних

Якщо нападник отримає root на гіпервізорі, він може видалити знімки. Може видалити локальні резервні копії. Може одним рядком виконати zfs destroy вашої історії.
Вам потрібні незмінність і розділення облікових даних. Тут PBS відмінно підходить, але лише якщо його розгорнуто з розумними межами автентифікації.

4) «Усе працює» до моменту невідомості: невпевненість у відновленні

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

5) Регресії продуктивності, що роблять бекапи окремою інцидентною причиною

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

Як Proxmox використовує ZFS (і чому це важливо для бекапів)

Proxmox зазвичай зберігає диски VM як ZVOLs (блочні пристрої), коли ви обираєте ZFS-сторідж. Контейнери можуть використовувати датасети.
Різниця важлива: резервні копії ZVOL і датасетів поводяться по-різному, особливо для знімків і використання простору.

VM на ZVOLs: швидкі знімки, складний простір

Диск VM як ZVOL — це блочний пристрій з volblocksize (часто 8K/16K). Записи походять із файлової системи гостя, а не із семантики, відомої ZFS.
Знімки зберігатимуть старі блоки; довге утримання може створити серйозний тиск на простір у write-heavy VM (бази даних дуже люблять цьому сприяти).

Контейнери на датасетах: більше видимості, але не магія

Датасети можна чисто знімати і реплікувати, і ZFS може приймати кращі рішення щодо стиснення виходячи з recordsize.
Але контейнери все одно страждають від того, що «все на тому самому пулі», тобто знімки не врятують вас від втрати пула.

Резервні копії Proxmox: `vzdump` проти Proxmox Backup Server

vzdump створює архіви (.vma.zst, .tar.zst тощо) на цільовому сховищі. Він може використовувати знімки для консистентності під час копіювання.
PBS зберігає резервні копії по чанках, дедуплікує між VM, підтримує шифрування і (за потреби) політики зберігання, що не потребують ручного видалення старих tarball.

Найкращі налаштування часто поєднують обидві концепції:
локальні ZFS-знімки для швидкого відкату і оперативних помилок;
PBS (або інше віддалене сховище) для реального аварійного відновлення.

Знімки: чим вони хороші, а чого точно не роблять

Вони відмінні для:

Швидкого відкату після невдалих оновлень пакетів, поламаних налаштувань VM або розгортання додатку, що підірвалося.
Короткострокових засобів безпеки під час ризикових операцій: міграцій, змін файлової системи, змін схеми.
Вхідних даних для реплікації: знімки — це одиниця інкрементальної передачі з zfs send -i.

Вони не дуже хороші для:

Втрати пула: вони не виходять за межі пула.
Компрометації облікових даних: root може їх знищити.
Довготривалого зберігання без планування ємності: старі блоки фіксують простір; ваш пул «таємниче» заповнюється.
Відновлення з консистентністю додатка: crash-consistent знімок часто підходить для журналюваних файлових систем, але не завжди для баз даних без координації.

Утримання знімків має бути коротким і цілеспрямованим. Години — до днів, можливо кілька тижнів для вікна «ой» — залежно від швидкості змін.
Якщо ви зберігаєте місяці знімків на продакшен-пулах, ви не робите «резервні копії». Ви робите «витік простору з API».

Реальні резервні копії: що «має значення» в продакшені

Справжня резервна копія має відповідати трьом умовам:

Розділення: зберігається оф-хост або принаймні оф-пул, бажано оф-сайт. Різні облікові дані, різний радіус ураження.
Відновлюваність: ви можете відновити в чисте середовище в межах RTO, який прийнятний для бізнесу.
Перевірка: ви нещодавно виконували тестові відновлення. Не «перевірили логи», не «передивилися контрольні суми», а фактично завантажили чи перевірили цілісність даних.

У світі Proxmox найпоширеніші реалізації «справжньої резервної копії»:

Proxmox Backup Server: найкращий стандарт для багатьох команд: дедуплікація, шифрування, обрізка і завдання перевірки.
vzdump на NFS/SMB/інший ZFS-бокс: робочий та простий варіант, але чесно оцініть незмінність і перевірку.
ZFS send/receive на ціль резервного копіювання: потужний, прозорий, швидкий для інкременталів; також легко неправильно налаштувати його як синхронізовану катастрофу.

«Резервні копії без репетицій відновлення» — це театральність для відповідності. І так, театр має бюджети.

Парафразовано W. Edwards Deming: Без вимірювання ви не керуєте — ви просто гадаєте. Резервні копії — це вимірювання через відновлення.

Дизайн резервного копіювання, що витримує погані дні

Ось стратегія, що працює для малих команд і масштабується без зміни суті:

Шар 1: локальні ZFS-знімки для швидкого відкату

Тримайте їх недовготривалими.
Створюйте знімки перед ризиковими змінами і за розкладом (наприклад, щогодини протягом 24 год, щодня протягом 7 днів).
Автоматизуйте з інструментом знімків або власним cron, але дотримуйтеся послідовного найменування.

Шар 2: резервні копії на окрему систему (рекомендується PBS)

PBS на окремому обладнанні, бажано в іншому стояку/живленні, якщо можливо.
Використовуйте окремі облікові дані; не монтуйте датастор як RW з гіпервізора «бо так зручніше».
Увімкніть шифрування під час бекапу, якщо модель загроз включає крадіжку сховища бекапів.

Шар 3: копія оф-сайт (реплікація або синхронізація)

Або синхронізація PBS на другий PBS, або ZFS-реплікація на інший ZFS-ціль, або експорт бекапів в об’єктне сховище через контрольований пайплайн.
Переконайтеся, що цей шар не є дзеркалом видалень. Затримена реплікація — це фіча, а не баг.

Retention: припиніть робити вигляд

Retention — це політика, заснована на:
регуляторних вимогах, толерантності бізнесу та витратах на зберігання.
Розумна базова конфігурація:

Локальні знімки: 24–72 години щогодинних + 7–14 днів щоденних (коригуйте за швидкістю записів).
PBS резервні копії: 14–30 днів щоденних + 3–12 місяців щотижневих/щомісячних, залежно від визначення бізнесу «ой».
Оф-сайт: принаймні щотижня, бажано щодня, із довшим зберіганням для вікон відновлення після ransomware.

Консистентність: вирішіть, що ви маєте на увазі

Для багатьох VM crash-consistent достатньо. Для баз даних бажана application-consistent: flush, freeze або використання нативних бекапів бази.
ZFS не знає, що таке «транзакція». Він знає блоки.

Жарт #2: «Ми миттєво реплікуємо на DR-сайт» — це версія бекапу фрази «я завжди відповідаю на повідомлення миттєво». Вражає, поки не пожалкуєш про надіслані дані.

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

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

Завдання 1: Перевірте здоров’я пула перед тим, як звинувачувати бекапи

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 02:11:40 with 0 errors on Sun Dec 22 03:00:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Що це означає: Ваш пул здоровий, scrubs завершуються, і немає помилок контрольних сум.
Рішення: Продовжуйте налаштування знімків/бекапів; ви не боретеся з корупцією знизу. Якщо бачите DEGRADED, FAULTED або помилки контрольних сум, виправте це першою чергою — турботливий бекап на хворому пулі лише погіршить ситуацію.

Завдання 2: Перевірте ємність і чи фіксують знімки простір

cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots -r rpool/data
NAME                  USED  AVAIL  REFER  USEDBYSNAPSHOTS
rpool/data            3.2T   410G    96K            0B
rpool/data/vm-101     420G   410G   110G          210G
rpool/data/vm-102     610G   410G   240G          290G

Що це означає: Для цих ZVOL датасетів велика частина використаного простору — «used by snapshots». Це старі блоки, що утримуються.
Рішення: Посиліть політику утримання знімків або перемістіть довготривале зберігання до PBS/оф-хост. Розгляньте, чи варто write-heavy VM розміщувати на окремому пулі або з іншим графіком.

Завдання 3: Подивіться ваші знімки і чи адекватні імена

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -r rpool/data/vm-101 | tail -n 5
rpool/data/vm-101@auto-2025-12-27_0100  Sun Dec 27 01:00  1.2G
rpool/data/vm-101@auto-2025-12-27_0200  Sun Dec 27 02:00  1.0G
rpool/data/vm-101@auto-2025-12-27_0300  Sun Dec 27 03:00  980M
rpool/data/vm-101@auto-2025-12-27_0400  Sun Dec 27 04:00  1.1G
rpool/data/vm-101@pre-upgrade           Sat Dec 27 04:22  0B

Що це означає: У вас регулярні знімки плюс ручний «pre-upgrade» знімок. Добре.
Рішення: Переконайтеся, що утримання відповідає наміру. Поступове зростання «used» — нормальне явище; різкі стрибки вказують на великі зміни (оновлення гостя, активність БД).

Завдання 4: Швидко ідентифікуйте найгірших «їдців» знімків

cr0x@server:~$ zfs list -o name,usedbysnapshots -s usedbysnapshots -r rpool/data | tail -n 5
rpool/data/vm-215     180G
rpool/data/vm-102     290G
rpool/data/vm-101     210G
rpool/data/vm-330     340G
rpool/data/vm-407     390G

Що це означає: Ці датасети фіксують найбільше простору знімками.
Рішення: Спочатку перегляньте політику утримання і підхід до бекапів для цих VM. Якщо вам потрібна довша історія, не тримайте її на первинному пулі.

Завдання 5: Підтвердіть властивості ZVOL, що впливають на бекап/реплікацію

cr0x@server:~$ zfs get -o name,property,value -s local,default volblocksize,compression,recordsize rpool/data/vm-101
NAME               PROPERTY      VALUE
rpool/data/vm-101   volblocksize  16K
rpool/data/vm-101   compression   zstd

Що це означає: ZVOL використовує 16K volblocksize, стиснення увімкнено. Recordsize не застосовується до ZVOL.
Рішення: Не змінюйте volblocksize після розгортання, якщо не розумієте наслідків. Стиснення зазвичай корисне; вимірюйте CPU і латентність, якщо ви на межі.

Завдання 6: Перевірте розклад і результати scrub

cr0x@server:~$ zpool get scrubtime rpool
NAME   PROPERTY  VALUE                  SOURCE
rpool  scrubtime Sun Dec 22 03:00 2025  -

Що це означає: Зареєстровано останній час scrub. Scrub виявляє латентні помилки до того, як вони знадобляться при відновленні або rebuild.
Рішення: Якщо ви не робите scrub щомісяця (або частіше для великих/старих дисків), заплануйте його. Якщо scrubs не завершуються або падають — це червоний сигнал.

Завдання 7: Перевірте тиск ARC перед тим, як звинувачувати «повільні бекапи»

cr0x@server:~$ arc_summary | egrep "ARC Size|ARC Target|Cache Hits|Cache Misses"
ARC Size:                               31.2 GiB
ARC Target Size:                        32.0 GiB
Cache Hits:                             92.1%
Cache Misses:                           7.9%

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

Завдання 8: Спостерігайте за I/O латентністю під час бекапів

cr0x@server:~$ zpool iostat -v rpool 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        3.1T   410G    820   1600   110M   220M
  mirror-0                   3.1T   410G    820   1600   110M   220M
    ata-SAMSUNG_SSD_1           -      -    410    800    55M   110M
    ata-SAMSUNG_SSD_2           -      -    410    800    55M   110M
--------------------------  -----  -----  -----  -----  -----  -----

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

Завдання 9: Підтвердіть визначення сторіджів Proxmox (щоб не бекапити випадково «local»)

cr0x@server:~$ pvesm status
Name             Type     Status     Total     Used     Available        %
local             dir     active      94G      12G         82G       12.8%
local-zfs         zfspool active     3.5T     3.1T        410G       88.3%
pbs-prod          pbs     active      18T      6.2T       11.8T      34.4%

Що це означає: У вас є datastore PBS. Добре. Локальний dir сторідж не є ціллю бекапу, якщо тільки він не на окремому обладнанні (зазвичай ні).
Рішення: Переконайтеся, що розкладані завдання вказують на pbs-prod, а не на local або local-zfs.

Завдання 10: Перевірте робочі завдання бекапу і їх цілі

cr0x@server:~$ cat /etc/pve/jobs.cfg | sed -n '1,120p'
backup: nightly-pbs
        enabled 1
        schedule 03:15
        storage pbs-prod
        mode snapshot
        compress zstd
        mailnotification always
        prune-backups keep-daily=14,keep-weekly=8,keep-monthly=6

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

Завдання 11: Виконайте ручний vzdump для однієї VM і прочитайте результат

cr0x@server:~$ vzdump 101 --storage pbs-prod --mode snapshot --compress zstd --notes-template '{{vmid}} {{name}}'
INFO: starting new backup job: vzdump 101 --storage pbs-prod --mode snapshot --compress zstd
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2025-12-28 03:22:11
INFO: status = running
INFO: VM Name: app-prod-01
INFO: including disk 'scsi0' 'local-zfs:vm-101-disk-0' 110G
INFO: creating Proxmox Backup Server archive 'vm/101/2025-12-28T03:22:11Z'
INFO: transferred 33.1 GiB in 04:18 min, average speed 131.2 MiB/s
INFO: backup successful
INFO: Backup finished at 2025-12-28 03:26:30
INFO: Finished Backup of VM 101 (00:04:19)

Що це означає: Успіх — не лише «код виходу 0»; це «архів створено на PBS» з правдоподібною пропускною здатністю і тривалістю.
Рішення: Якщо швидкість дуже низька — перевірте iostat пула, мережу і навантаження PBS. Якщо в логах зазначено, що збережено локально — негайно виправте ціль завдання.

Завдання 12: Перевірте доступність PBS з вузла Proxmox (базова досяжність + автентифікація)

cr0x@server:~$ pvesm list pbs-prod | head
Volid                                                        Format  Type         Size  VMID
pbs-prod:backup/vm/101/2025-12-28T03:22:11Z                   pbs     backup   35567616   101
pbs-prod:backup/vm/102/2025-12-28T03:15:01Z                   pbs     backup   74448896   102
pbs-prod:backup/vm/215/2025-12-28T03:18:45Z                   pbs     backup   118382592  215

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

Завдання 13: Перевірте адекватність реплікації ZFS (якщо ви використовуєте send/receive)

cr0x@server:~$ zfs send -nP rpool/data/vm-101@auto-2025-12-27_0400 | head
size	11811160064

Що це означає: Dry-run показує розмір стріму. Це дозволяє прогнозувати час реплікації та пропускну здатність.
Рішення: Якщо розмір величезний для «невеликої зміни», можливо ви не робите інкрементальні відправки, або VM інтенсивно перезатирає блоки. Підлаштуйте графік і утримання або перейдіть на PBS для ефективності дедуплікації.

Завдання 14: Підтвердіть, що ви справді можете отримати стрім на ціль (і не перезаписуєте прод)

cr0x@server:~$ ssh root@backupzfs "zfs list -o name,used,avail -r bpool/replica | head"
NAME                 USED  AVAIL
bpool/replica        1.1T  7.8T
bpool/replica/rpool  1.1T  7.8T

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

Завдання 15: Виконайте тестове відновлення VM в ізольований VMID (єдиний тест, що має значення)

cr0x@server:~$ qmrestore pbs-prod:backup/vm/101/2025-12-28T03:22:11Z 9101 --storage local-zfs
restore vma archive: vm/101/2025-12-28T03:22:11Z
creating VM 9101 on target node
  restoring disk scsi0 size 110G to local-zfs:vm-9101-disk-0
progress 15% (read 5.0 GiB, write 5.0 GiB)
progress 62% (read 21.0 GiB, write 21.0 GiB)
progress 100% (read 33.1 GiB, write 33.1 GiB)
restore successful

Що це означає: Ви можете відновити. Не «в теорії», не «логи зелені», а фактичне створення VM і матеріалізація диску.
Рішення: Запустіть її в ізольованій мережі, перевірте стан застосунку, потім видаліть. Плануйте це мінімум щомісяця для критичних сервісів.

Завдання 16: Перевірте кореляцію навантаження знімків/бекапів і латентності VM (швидкий перегляд)

cr0x@server:~$ iostat -x 5 3
Linux 6.8.12 (server)   12/28/2025

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.55    8.40    0.00   72.95

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0  1400.0  95000  210000   9.80   0.35  58.00

Що це означає: Підвищене %iowait і await показують, що система чекає на сховище. Під час бекапів це може бути очікувано; тривале високе await корелює з уповільненням VM.
Рішення: Якщо await підскакує до десятків/сотень мс, зменшіть паралельність бекапів, змініть графік або розділіть I/O бекапів від продуктивного сховища.

План швидкої діагностики

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

Перший крок: підтвердіть, що ви бекапите в потрібне місце

Перевірте конфіг завдань Proxmox: ціль сховища, режим, обрізка.
Підтвердіть, що ціль досяжна і має вільне місце.

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

Дискова латентність: zpool iostat, iostat -x
CPU-навантаження: top і «чи навантажує стиснення ядра?»
Мережа: ip -s link, ss -s або лічильники переключателя
Навантага PBS: завдання перевірки датастору, garbage collection, паралельні клієнти

Третій крок: перевірте тиск знімків і ємність пула

zfs list -o usedbysnapshots щоб знайти заблокований простір.
zpool list для загальної ємності; уникайте життя понад ~80–85% на зайнятих пулах.

Четвертий крок: перевірте механіку відновлення

Виберіть одну VM і виконайте тестове відновлення на тимчасовий VMID.
Якщо відновлення повільне, ймовірно той самий вузький горловий елемент, просто навпаки (читання з цілі бекапу).

П’ятий крок: зменшіть паралельність перш ніж переробляти світ

Багато інцидентів бекапів в Proxmox — самостворені через одночасний запуск забагато бекапів.
Паралельність — це керований параметр. Користуйтеся ним.

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

1) «У нас є знімки, отже ми застраховані.»

Симптом: Пул не імпортується, і все — диски VM і знімки — недоступні.

Корінна причина: Знімки ніколи не виходили за межі домену відмови пула.

Виправлення: Впровадьте PBS або оф-хост ZFS-реплікацію. Вимагайте щомісячних тестових відновлень як умову для називання чогось «забекапленим».

2) Завдання бекапу зелені, але відновлення падають

Симптом: Ви бачите записи бекапів, але при відновленні з’являються помилки (відсутні чанки, помилки автентифікації, пошкоджені архіви).

Корінна причина: Нема тестових відновлень; проблеми накопичуються тихо (права, помилки обрізки датастору, нестабільна мережа).

Виправлення: Додайте заплановані тести відновлення. Для PBS запускайте завдання верифікації і слідкуйте за помилками. Виправте межі автентифікації та мережеву нестабільність.

3) Пул ZFS заповнюється несподівано

Симптом: df показує місця десь, але ZFS повідомляє низький AVAIL. Записи VM починають падати.

Корінна причина: Утримання знімків фіксує блоки; write-heavy VM утримують старі блоки. Також часто: життя при 90%+ використання пула.

Виправлення: Зменшіть утримання знімків. Перемістіть довготривале зберігання до PBS. Тримайте пули під ~80–85% для продуктивності і контролю фрагментації.

4) Реплікація «працює», а потім ви розумієте, що вона реплікувала катастрофу

Симптом: Видалення або шифрування ransomware швидко з’явилося на репліці.

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

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

5) Бекапи викликають стрибки латентності VM

Симптом: Тайм-аути застосунків під час вікна бекапу; графіки латентності сховища стрибають.

Корінна причина: Завдання бекапу конкурують за IOPS і кеш; замало паралельності; одночасні scrubs/resilver.

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

6) «Ми зашифрували пул, отже бекапи безпечні»

Симптом: Ціль бекапу незашифрована або ключі зберігаються на тому самому гіпервізорі.

Корінна причина: Плутання шифрування «на місці» з контролем доступу; керування ключами як післядумка.

Виправлення: Шифруйте бекапи під час створення (PBS це підтримує). Зберігайте ключі окремо. Обмежте, хто може видаляти бекапи і яким чином.

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

Міні-історія 1: Інцидент через хибне припущення

Середня компанія запускала Proxmox на потужному хості з дзеркальними SSD. У них були погодинні ZFS-знімки за два тижні.
Команда вірила, що вони «застраховані», бо відкати не раз рятували після невдалих розгортань додатків.

Потім стався неплановий ребут після проблем з живленням. Пул не імпортувався коректно. У них були boot environment, знімки
і впевненість. Чого не було — другої копії дисків VM ніде.

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

Постмортем був неприємний, бо «хибне припущення» було не технічним; воно було семантичним. Вони називали знімки «резервними копіями».
Коли мова була виправлена, архітектура змінилася. PBS розгорнули на окремому обладнанні, тести відновлення стали регулярними, а знімки повернулися до ролі локальних засобів безпеки.

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

Інший магазин вирішив, що бекапи надто повільні, тож вони женули пропускну здатність. Збільшили паралельність бекапів і налаштували стиснення максимально агресивно.
Вікно бекапів скоротилося. Графіки виглядали чудово. Усі аплодували.

Через два тижні користувачі почали скаржитися на випадкові стрибки латентності рано-вранці. Здавалось, ніщо не «впало», але все працювало прилипло.
Команда перевірила CPU — ок. Мережу — ок. Потім дискову латентність: жахливо.

Оптимізація перетворила бекапи на тривалий шторм випадкових читань/записів саме тоді, коли в гостях працювали нічні пакетні завдання.
ZFS робив свою роботу, але пул був фрагментований і завантажений. Бекапи конкурували з продакшеном, і продакшен програв.

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

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

Команда фінансових послуг мала звичку, що виглядала як паперова тяганина: щомісяця один інженер відновлював дві критичні VM з PBS в ізольовану мережу.
Вони перевіряли health checks сервісів, заходили в додаток, потім руйнували тестові VM. Це займало годину і не давало яскравих графіків.

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

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

Фішка: щомісячний ритуал відновлення раніше критикували як «марну роботу».
Після інциденту ніхто більше його не сумнівався. Нудьга — це фіча, коли будівля горить.

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

Покроково: побудуйте стратегію резервного копіювання, що не бреше

Визначте RPO/RTO для кожного сервісу. Якщо ви не можете сказати «ми можемо втратити X годин і бути недоступні Y годин», ви не зможете чесно вибрати інструменти.
Тримайте локальні знімки короткими. Використовуйте їх для відкату, а не як історію.
Розгорніть PBS на окремому обладнанні. Різні диски, інше живлення, якщо можливо. Окремі облікові дані.
Заплануйте бекапи поза піковим I/O. Уникайте накладання на scrubs, resilver та важкі пакетні задачі.
Налаштуйте retention у системі бекапу. Обрізка на PBS (або еквіваленті), щоб політика була примусовою і видимою.
Увімкніть шифрування там, де це має сенс. Особливо якщо бекапи оф-сайт або доступні багатьом системам.
Робіть щомісячні репетиції відновлення. Відновіть VM на новий VMID, завантажте, перевірте, потім видаліть.
Моніторте нудні сигнали. Ємність пулу, завершення scrub, тривалість завдань бекапу, тривалість відновлення, помилки верифікації.
Документуйте runbook відновлення. Де лежать бекапи, хто має доступ, як відновити мережу, в якому порядку відновлювати залежності.

Чекліст: перед тим, як довіряти налаштуванню

Резервні копії зберігаються оф-хост та оф-пул
Окремі облікові дані для видалення бекапів
Налаштовані retention і обрізка
Принаймні одне успішне тестове відновлення за останні 30 днів
Заплановані і завершені ZFS scrubs
Ємність пулу під контролем (не на 90% заповнена)
Вікна бекапів не шкодять продуктивній латентності

Чекліст: коли ви змінюєте щось ризикове

Зробіть ручний знімок з людською назвою (@pre-upgrade)
Підтвердіть наявність останнього успішного PBS-бекапу для критичних VM
Переконайтеся, що зараз можна дістатися цілі бекапу
Майте план відкату і план відновлення — це різні плани

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

1) Чи можуть ZFS-знімки колись вистачити як резервні копії?

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

2) Якщо я реплікую ZFS-знімки на інший хост, чи це резервна копія?

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

3) Чи використовувати Proxmox Backup Server чи vzdump на NFS?

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

4) Чи потрібні мені і знімки, і резервні копії?

На практиці — так. Знімки для швидкого відкату і управління змінами. Резервні копії для аварійного відновлення і аудиторного зберігання.
Намагання змусити одне виконувати роль іншого зазвичай приносить біль.

5) Скільки знімків тримати на продакшен-пулі?

Тримайте мінімально необхідну кількість для відкату. Для багатьох середовищ: щогодини на 24–72 години і щоденно на 7–14 днів.
Якщо потрібні місяці — тримайте їх оф-хост у системі бекапу.

6) Мій пул на 90% заповнений, але «все ще працює». Чому ви наполягаєте звернути увагу?

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

7) Як зробити бекапи резистентними до ransomware?

Використовуйте розділення облікових даних, незмінність (де доступна), затримані/офлайн копії і систему бекапу, яку не можна видалити з компрометованих гіпервізорів.
Також: репетиції відновлення, бо відновлення після ransomware — це в основному «наскільки швидко ми можемо відновити чисто».

8) Чи замінюють ZFS scrubs резервні копії?

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

9) Який найважливіший метрик для бекапів?

Час відновлення для репрезентативного навантаження. Не тривалість бекапу, не коефіцієнт дедуплікації. Бізнес відчуває час відновлення.

10) Що робити, якщо бекапи з часом сповільнюються?

Перевірте ємність (включно з фіксацією простору знімками), перевірте латентність під час вікна бекапу і перевірте паралельність. Потім перевірте ціль бекапу.
Повільні бекапи часто є симптомом «пул занадто заповнений» або «занадто багато задач одночасно», а не якоїсь містичної прокльоної сили.

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

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

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

Обрайте одну критичну VM і цього тижня зробіть тестове відновлення з системи бекапу. Заміряйте час. Запишіть кроки.
Аудитуйте, куди потрапляють ваші бекапи. Якщо щось вказує «local» на тому ж хості — вважайте це зручністю, а не захистом.
Виміряйте простір, фіксований знімками, і зменшіть утримання для найгірших випадків.
Заплануйте scrubs і переконайтеся, що вони завершуються.
Впровадьте оф-хост бекапи (рекомендується PBS) з обрізкою і верифікацією, та окремими обліковими даними для видалення.

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