Proxmox PBS: резервні копії успішні, а відновлення зазнають невдачі — чеклист, який це виявляє

Помилка відновлення: модель мислення, яка справді допомагає

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

Резервні копії — це переважно «шлях запису», а відновлення — «шлях читання під навантаженням»

Резервні копії зазвичай — це послідовні записи плюс деякі оновлення метаданих. Відновлення посилює читання: багато майже випадкових читів чанків, декомпресія, опціональна перевірка й більша чутливість до затримки. Якщо ваш бекенд сховища має особливості (кешування атрибутів NFS, невідповідний ZFS recordsize, thin-provisioned SAN, який «бреше», RAID-контролер з несподіваними політиками кешування), відновлення їх знайде.

Три шари мають співпадати: ідентичність, цілісність і місцезнаходження

• Ідентичність: Ви повинні бути авторизовані (ACL PBS), і клієнт має предʼявляти очікувані облікові дані або токен API. Інструменти відновлення часто працюють під іншою ідентичністю, ніж завдання резервного копіювання.
• Цілісність: Сховище чанків має бути консистентним. Відсутні чанки, пошкоджені чанки або неповний збір сміття можуть проявитися лише під час відновлення або verify.
• Місцезнаходження: Мережевий маршрут, DNS, фаєрвол, MTU, проксі, довіра TLS і час мають збігатися. Бекапи могли проходити одним шляхом; відновлення може йти іншим (особливо коли відновлюють на інший вузол).

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

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

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

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

1. Миттєва жорстка помилка: відмова в доступі, помилка автентифікації, невідповідність відбитка, репозиторій не знайдено, помилки TLS.
2. Жорстка помилка в середині потоку: відсутні чанки, помилки контрольної суми, помилки вводу/виводу, файлову систему змонтовано в режимі тільки для читання.
3. Мʼяка помилка (зависання/повільність): застрягло на 0%, «все ще працює», ETA фантастичний.

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

1. Хто виконує відновлення? Та сама PBS user/token, що й у job бекапу? Той самий простір імен? Такий самий шлях ACL?
2. Куди ви відновлюєте? Інший Proxmox вузол, інша мережа, інша цільова система зберігання?
3. Чи PBS під навантаженням від prune/GC/verify? Ці завдання можуть бути «нормальними» під час бекапів і вкрай суворими під час відновлень.

Третій крок: оберіть один трек глибокого розслідування

• Трек автентифікації/ACL/TLS, якщо помилка виникає до руху даних.
• Трек цілісності датастору, якщо ви бачите відсутні/пошкоджені чанки, помилки verify або збої при читанні під час відновлення.
• Трек продуктивності сховища, якщо відновлення повільні/зависають і датастор розташований на NFS/Ceph/ZFS-on-RAID.
• Мережевий трек, якщо ви бачите таймаути, ресети, дивні MTU або відновлення ламаються лише з одного вузла.

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

• PBS використовує сховище чанків з дедуплікацією: відновлення можуть залежати від чанків, створених тижнями раніше, а не тільки від вчорашнього бекапу.
• Prune і garbage collection — різні поняття: prune видаляє посилання на снапшоти; GC звільняє необʼєктовані чанки пізніше. Снапшот може зникнути «логічно» раніше ніж простір буде звільнено «фізично».
• Verify — це не просто кнопка для спокою: це ваша рання система попередження про пошкодження чанків або неповні записи, які не проявилися під час бекапу.
• Інкрементальні бекапи зменшують навантаження на запис, але можуть збільшити глибину залежностей при відновленні: чим більше ви покладаєтесь на історію, тим більше вам потрібна довготривала цілісність чанків.
• Шифрування на стороні клієнта змінює характер помилок: неправильний ключ або відсутній файл ключа часто виглядає як «дані є, але їх неможливо прочитати», і це дослівно правда.
• Відновлення чутливі до затримок: датастор на сховищі з великою затримкою (або NFS з поганими опціями) може робити бекапи нормальними, але відновлення — катастрофічними через посилене читання.
• Простори імен і ACL — сильні й гострі: легко надати права на бекап, але не надати права на перегляд/відновлення, особливо коли токени звужені.
• Час важливіший, ніж думають: TLS, валідація квитків і кореляція логів стають складними, коли вузли розходяться в часі. Ви можете «автентифікуватися», але при цьому ламати довгі сесії передачі.
• «Бекап успішний» часто означає «сервер прийняв потік»: це не гарантує, що бекенд сховища зберіг його правильно для подальшого читання (привіт, ненадійні диски та семантика NFS).

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

Ці завдання можна виконати на типовій конфігурації Proxmox VE + PBS. Налаштуйте імена хостів, назви датасторів та ідентифікатори. Кожне завдання містить: команду, що означає вивід, і яке рішення прийняти далі.

Завдання 1: Перевірити стан сервісу PBS (на сервері)

cr0x@pbs01:~$ systemctl status proxmox-backup
● proxmox-backup.service - Proxmox Backup Server API and daemon
     Loaded: loaded (/lib/systemd/system/proxmox-backup.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:11:02 UTC; 3h 12min ago
       Docs: man:proxmox-backup-api(1)
             man:proxmox-backup-proxy(1)
   Main PID: 1123 (proxmox-backup)
      Tasks: 14 (limit: 154225)
     Memory: 312.4M
        CPU: 19min 22.341s
     CGroup: /system.slice/proxmox-backup.service
             ├─1123 proxmox-backup-api
             └─1131 proxmox-backup-proxy

Значення: Якщо сервіс не active/running, відновлення будуть падати творчими способами (таймаути, 500, connection refused).

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

Завдання 2: Читайте логи в час відновлення, а не логі бекапу

cr0x@pbs01:~$ journalctl -u proxmox-backup --since "30 min ago" --no-pager
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: authentication failed for user 'backup@pbs'
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: permission check failed: missing Datastore.Read on /datastore/vmstore
Feb 04 11:52:21 pbs01 proxmox-backup-api[1123]: client disconnected (TLS error: alert bad certificate)

Значення: PBS часто каже вам точно, яка умова прав або TLS не пройшла. «Datastore.Read missing» — класичний пробіл лише для відновлення.

Рішення: Якщо ви бачите помилки auth/ACL/TLS тут — зупиніться і виправте ідентичність/довіру перед тим, як торкатися сховища.

Завдання 3: Підтвердьте, що датастор змонтований і доступний для запису (хост PBS)

cr0x@pbs01:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
vmstore      dir        active      70368744177664    4966055936000   65402688241664    7%

Значення: «active» — добре. Якщо він відсутній/inactive, PBS може приймати метадані, але не зможе читати чанки або впаде в середині відновлення.

Рішення: Якщо inactive — виправте монтування (NFS впав, ZFS pool degraded, права) перш ніж знову намагатися відновлення.

Завдання 4: Перевірити помилки на рівні файлової системи (remount read-only — реальна річ)

cr0x@pbs01:~$ dmesg -T | tail -n 20
[Mon Feb  4 11:41:07 2026] EXT4-fs error (device sdb1): ext4_find_entry:1453: inode #262145: comm proxmox-backup: reading directory lblock 0
[Mon Feb  4 11:41:07 2026] Aborting journal on device sdb1-8.
[Mon Feb  4 11:41:07 2026] EXT4-fs (sdb1): Remounting filesystem read-only

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

Рішення: Трактуйте це як інцидент зі сховищем. Зупиніть записи PBS, відремонтуйте ФС, валідaйте цілісність датастору після цього.

Завдання 5: Перевірити синхронізацію часу (TLS і довгі сесії ненавидять дрейф)

cr0x@pbs01:~$ timedatectl
               Local time: Tue 2026-02-04 12:03:44 UTC
           Universal time: Tue 2026-02-04 12:03:44 UTC
                 RTC time: Tue 2026-02-04 12:03:45
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Якщо «System clock synchronized: no» на PBS або PVE вузлах — очікуйте дивні поведінки сертифікатів, закінчення дії токенів і проблеми з кореляцією логів.

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

Завдання 6: Підтвердити API-зʼєднання та відбиток сертифіката (довіра на боці клієнта)

cr0x@pve01:~$ proxmox-backup-manager cert info
Subject Name: /CN=pbs01
Issuer Name: /CN=pbs01
Valid Since: 2025-09-14 09:20:48
Valid Until: 2035-09-12 09:20:48
Fingerprint (sha256): 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21

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

Рішення: Якщо PBS було відновлено або сертифікат змінився — заново довірте новий відбиток на PVE вузлах (і задокументуйте це).

Завдання 7: Перевірити конфігурацію репозиторію на вузлі, що виконує відновлення

cr0x@pve01:~$ cat /etc/pve/storage.cfg
pbs: pbs-vmstore
        datastore vmstore
        server pbs01
        content backup
        fingerprint 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21
        username backup@pbs
        token backup-token
        namespace prod

Значення: Відновлення виконуються з погляду PVE вузла. Неправильний простір імен, неправильний username/token або застарілий відбиток зламають відновлення, навіть якщо бекапи з іншого вузла все ще працюють.

Рішення: Уніфікуйте storage.cfg на всіх вузлах, що можуть виконувати відновлення. Не припускайте, що «вузол, що робить бекап», — те саме, що «вузол для відновлення».

Завдання 8: Перевірити ACL PBS на права відновлення (на сервері)

cr0x@pbs01:~$ proxmox-backup-manager acl list
/path /datastore/vmstore, user backup@pbs, role DatastoreBackup
/path /datastore/vmstore, user restore-ops@pbs, role DatastoreReader
/path /, user root@pam, role Administrator

Значення: Роль на кшталт «DatastoreBackup» може бути достатньою для бекапів, але не для перегляду/відновлення, залежно від налаштувань і інструментів. Для відновлення зазвичай потрібні права Reader або більше.

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

Завдання 9: Перерахувати снапшоти і впевнитися, що ви відновлюєте те, що думаєте

cr0x@pbs01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod | head
vm/101/2026-02-03T01:00:12Z
vm/101/2026-02-02T01:00:10Z
vm/101/2026-02-01T01:00:09Z
ct/203/2026-02-03T01:10:05Z
ct/203/2026-02-02T01:10:02Z

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

Рішення: Підтвердьте простір імен і тип групи бекапу (vm vs ct vs host). Не витрачайте годину на відновлення не того обʼєкта.

Завдання 10: Запустити verify датастору і інтерпретувати результати (трек цілісності)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify vmstore --ignore-verified 1
starting datastore verify: vmstore
found 8123 snapshot(s)
verified 131072 chunks (12.5 GiB)
ERROR: missing chunk 3a2f0f9d3c0a... referenced by vm/101/2026-02-03T01:00:12Z
ERROR: verification failed: 1 errors found

Значення: «missing chunk» — не косметична проблема. Цей снапшот (і, можливо, інші) не можна повністю відновити.

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

Завдання 11: Перевірити розклад prune/GC і поточні запущені завдання (трек конкуренції)

cr0x@pbs01:~$ proxmox-backup-manager task list --running 1
UPID:pbs01:0000A1B3:0001C2D4:67A1F2C3:garbage_collection:vmstore:root@pam:
UPID:pbs01:0000A1C0:0001C2F1:67A1F2DA:verify:vmstore:root@pam:

Значення: GC + verify під час великого відновлення — це як планувати дорожні роботи під час евакуації. Може працювати, але це вибір.

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

Завдання 12: Заміряти латентність I/O датастору простим способом (чи «бреше» сховище?)

cr0x@pbs01:~$ iostat -x 1 5
Linux 6.5.11 (pbs01)  02/04/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.12    0.00    2.98   22.45    0.00   70.45

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sdb              82.0   310.0  9120.0 50240.0  87.35   3.12  99.80

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

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

Завдання 13: Підтвердити стабільність мережі та припущення щодо MTU (трек таймаутів)

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

--- pbs01 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Значення: Хтось припустив, що jumbo frames є end-to-end. Вони помилилися. Бекапи можуть терпіти фрагментацію або інші моделі потоку; відновлення може потрапити на шлях, що цього не дозволяє.

Рішення: Або виправте MTU на всьому шляху, або припиніть приміщати і використовуйте 1500 всюди. Змішаний MTU — генератор повільної катастрофи.

Завдання 14: Підтвердити DNS і зворотний DNS (нудний винуватець)

cr0x@pve01:~$ getent hosts pbs01
10.10.10.20     pbs01 pbs01.internal

Значення: Якщо розвʼязування імен відрізняється між вузлами, ви можете довіряти одному імені сертифіката, але підключатися по-іншому або маршрутизувати по-різному для відновлення.

Рішення: Уніфікуйте спосіб, яким PVE вузли звертаються до PBS (імʼя vs IP) і зробіть CN/SAN сертифіката відповідним цій реальності.

Завдання 15: Спробувати змонтувати снапшот як файлову систему (перевіряє шлях читання без перезапису VM)

cr0x@pve01:~$ proxmox-backup-client mount vm/101/2026-02-03T01:00:12Z drive-scsi0 --repository backup@pbs@pbs01:vmstore --ns prod /mnt/pbs-test
mounted file system at "/mnt/pbs-test"

Значення: Якщо mount падає з missing chunks або помилками прав — ви відтворили помилку відновлення в безпечний спосіб.

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

Завдання 16: Інспектувати власність групи бекапу і режим шифрування (коли ключі — проблема)

cr0x@pve01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod --output-format json | head -n 5
[
  {"backup-id":"101","backup-time":1706922012,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706835610,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706749209,"backup-type":"vm","comment":null},
  {"backup-id":"203","backup-time":1706922605,"backup-type":"ct","comment":null},

Значення: Перелік снапшотів працює, але відновлення може все одно впасти, якщо ключі шифрування відсутні на хості відновлення. Перелік метаданих — дешевший, ніж розшифровка payload.

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

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

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

1) «Відмова в доступі» під час відновлення, але бекапи виконуються щодня

Симптом: Відновлення падає миттєво; в логах видно відсутність Datastore.Read або прав на простір імен.

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

Виправлення: Надати ідентичності для відновлення права читання на шлях датастору та правильний простір імен. Вирівняти /etc/pve/storage.cfg на всіх вузлах. Надавайте перевагу окремій ролі «restore-ops» з контрольованим обсягом прав.

2) «Невідповідність відбитка» після обслуговування PBS

Симптом: Клієнт відмовляється підключитися; помилки про fingerprint або bad certificate.

Корінь: Сертифікат PBS було регенеровано (перевстановлення, зміна hostname), але PVE вузли досі довіряють старому відбитку в storage.cfg.

Виправлення: Оновіть відбиток скрізь. Стандартизувати ідентичність PBS (стабільне імʼя хоста) і трактувати регенерацію сертифіката як зміну під контролем змін.

3) Відновлення падає посередині з «missing chunk» або помилками verify

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

Корінь: Пошкодження базового сховища, неповні записи, помилки файлової системи, ненадійні диски або датастор було переміщено/скопійовано неправильно (rsync без xattrs/прав, невідповідність снапшотів).

Виправлення: Зупиніть навантаження на запис, виправте шар сховища (SMART, RAID, ZFS scrub, fsck де потрібно), запустіть verify, знайдіть останній працездатний снапшот і відновлюйте з нього. Якщо є реплікований датастор — переключіться на нього.

4) Відновлення «зависає» або надзвичайно повільне; бекапи нормальні

Симптом: Завдання відновлення працює, але прогрес повзучий; iowait стрибає; PBS відчувається повільним.

Корінь: Посилене читання зустрічається зі «повільним» сховищем (затримки NFS, SMR диски, перевантажений HDD RAID, ZFS налаштований на пропускну здатність, а не на латентність), або одночасно працюють prune/GC/verify.

Виправлення: Призупиніть важкі роботи під час відновлень, виміряйте латентність дисків (iostat), перемістіть датастор на сховище, спроєктоване для випадкових читань (SSD, кеш, адекватний RAID). Якщо на NFS — перегляньте опції монтування і продуктивність NFS сервера.

5) «Снапшот існує, але не знаходиться» в UI або CLI

Симптом: Бекапи зʼявляються в одному вигляді, але не там, де потрібен процес відновлення; помилки «group not found».

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

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

6) Відновлення впадає тільки з одного Proxmox вузла

Симптом: Відновлення працює з pve02, але падає з pve01 з таймаутами або помилками TLS.

Корінь: Дрейф конфігурації по вузлах storage.cfg, правила фаєрволу, маршрутизація, DNS або MTU на конкретному шляху.

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

7) Відновлення ламається після «оптимізації» політик retention/GC

Симптом: Після зміни розкладу prune або політик зберігання старі відновлення не працюють, або відновлення повільні під час робочих годин.

Корінь: GC перемістився в піковий час, або prune видалив снапшоти, які ви вважали доступними. Іноді «keep-last» здається достатнім, поки не виявиться, що потрібні «keep-daily» для відповідності.

Виправлення: Плануйте GC і verify у неробочий час. Моделюйте політики зберігання згідно реальних вимог відновлення (RPO/RTO та аудит), а не лише під тиском зайнятості диску.

Три корпоративні міні-історії (як це падає в реальному житті)

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

Компанія мала чистий Proxmox кластер і одиночний PBS аплайанс на достатньо швидкому сховищі. Бекапи були зеленими місяцями. Ніхто не хвилювався. Потім впав хост і їм потрібно було відновити продакшн VM на іншому вузлі. Відновлення впало миттєво: відмова в доступі.

Помилка була тонка: «токен, що може робити бекап, також може відновлювати» — не завжди справедливо. Їхній токен для бекапу був суворо скоупований (хороша ідея), але мав права лише для workflow бекапу. Відновлення ніколи не тестували з неосновного вузла, і токен у /etc/pve/storage.cfg на інших вузлах був… інший. Інженер кілька тижнів тому скопіював уривок конфігу і використав заглушкового користувача без прав читання датастору.

Вони марнували час на дебаг сховища і мережі, бо логи бекапу були бездоганні. Тим часом логи PBS були прямолінійні: missing Datastore.Read. Після вирівнювання конфігурації репозиторію на всіх вузлах і створення виділеної ролі для відновлення з явними ACL — відновлення відразу запрацювали.

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

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

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

NFS бекенд мав нормальну пропускну спроможність, але посередню латентність під конкурентним навантаженням. Відновлення засипало його читаннями чанків, поки файлсервер ще обслуговував домашні директорії й CI-артефакти. Під час вікна відновлення GC також запустився, бо хтось переніс обслуговування на денний час. Це перетворило повільне відновлення на безнадійне.

Вони пробували налаштувати опції монтування NFS і додали мережеву пропускну здатність. Це трохи допомогло, але не достатньо. Проблема була в фізиці: відновлення на основі чанків з дедуплікацією — не послідовне навантаження, і воно карає за латентність і продуктивність метаданих. Зрештою вони повернули PBS на локальне сховище на SSD і перенесли GC/verify у неробочий час.

Урок: оптимізація для «успішного бекапу» — не оптимізація для «відновлення бізнесу». Це повʼязані, але не тотожні цілі.

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

Регульоване середовище. Безліч процесів. Тип місця, де не можна просто «SSH і подивитися, що станеться». Команда сховища наполягала на квартальних тестах відновлення з доказами: відновлення в ізольовану мережу, перевірка завантаження і порівняння контрольних сум відомого датасету. Всім це не подобалося, бо робота передбачувана і ніхто за це не просунеться по кар’єрі.

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

Корінь виявився в періодичних помилках дисків на PBS-хості, що ще не дали очевидних алертів. SMART показники повільно росли, але система «працювала». Verify зловив це. Тест відновлення довів, що це важливо. Вони замінили диски, пере-перевірили і задокументували інцидент.

Коли через місяці знадобилося реальне відновлення, воно спрацювало. Ніхто не святкував. Ось у чому суть.

Чеклисти / покроковий план (зробіть відновлення нудними)

Чеклист A: Коли відновлення зараз падає (тріаж)

1. Зафіксуйте точну помилку з UI/CLI відновлення і з журналу PBS навколо того ж timestamp.
2. Класифікуйте: auth/ACL/TLS vs missing chunks vs timeout/slow vs помилки цільового сховища.
3. Підтвердьте ідентичність: той самий user/token/namespace на вузлі, що виконує відновлення.
4. Підтвердьте стан датастору: змонтований, доступний для запису, немає remount read-only, немає деградації пулу.
5. Перегляньте запущені завдання: призупиніть GC/verify, якщо потрібно швидке відновлення.
6. Зробіть безпечний тест: змонтуйте снапшот як файлову систему (підтверджує шлях читання) перед повним відновленням VM.
7. Якщо є помилки цілісності: запустіть datastore verify, визначте масштаб ураження, оберіть останню відому робочу точку відновлення.

Чеклист B: Щотижнева гігієна, що запобігає «зелені бекапи, мертві відновлення»

1. Регулярно запускати datastore verify за розкладом, відповідним розміру датастору і швидкості змін. Ротація по снапшотах за потреби.
2. Переглянути розклад prune і GC, щоб вони ніколи не конкурували з вікнами відновлення або піковими годинами продукції.
3. Перевіряти здоровʼя сховища (SMART, RAID, ZFS scrub) і налаштувати алерти на ранні ознаки проблем, а не лише на відмови.
4. Уніфікувати конфіг репозиторію на всіх PVE вузлах; дрейф конфігурацій трактувати як дефект.
5. Проводити тренування з відновлення (mount + селективне відновлення файлу + повне відновлення VM щокварталу мінімум).

Чеклист C: Жорсткі рішення щодо захисту (що я б робив насправді)

• Розділити ідентичності: один токен для job бекапів, інший — для операцій відновлення; обидва з найменшими правами, але без самосаботажу.
• Віддати перевагу локальному SSD-датаcтору для PBS, якщо цікавить RTO. NFS може працювати, але потрібно проєктувати під латентність і метадані, а не лише під пропускну здатність.
• Використовувати реплікацію, якщо датастор важливий: це страховка від корупції і одиночного відмови хоста. Бекапи, які не можна відновити, — це мистецтво, а не захист.
• Запланувати verify + GC усвідомлено: у неробочий час і ніколи не перетинати з піком інжесту бекапів, якщо можна уникнути.
• Задокументувати процес роботи з відбитками сертифікатів і трактувати відновлення PBS як зміну, яка вимагає кроків знову-довіри.

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

Одна операційна цитата, щоб тримати вас у тонусі

Все падає, весь час. — Werner Vogels

Вона коротка, не втішна і операційно коректна. Проєктуйте практику відновлення, виходячи з цього.

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

1) Чому бекапи можуть проходити, якщо датастор має проблеми з цілісністю?

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

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

Використайте proxmox-backup-client mount проти свіжого снапшоту і перегляньте кілька файлів. Це перевіряє автентифікацію, доступ до простору імен, читання чанків і декомпресію з мінімальним ризиком.

3) Чи погана ідея використовувати NFS для датасторів PBS?

Не обовʼязково, але легко помилитися. Бекапи дружні до запису; відновлення чутливі до латентності читання. Якщо ваш NFS-сервер шариться з іншими навантаженнями, має стрибки латентності або дивні кеші — відновлення постраждають першими. Якщо ви мусите використовувати NFS, виміряйте продуктивність відновлення під навантаженням і плануйте обслуговування обережно.

4) Як простори імен викликають проблеми «відновлення не знайдено»?

Простори імен розділяють групи бекапів. Якщо PVE вузол налаштовано на namespace prod, а бекапи записані в кореневий простір імен (або інший), перелік може відрізнятися, і відновлення не знайде снапшот там, де ви очікуєте. Завжди підтверджуйте через snapshot list з тим самим --ns.

5) Який звʼязок між prune та garbage collection?

Prune видаляє посилання на снапшоти згідно політик зберігання. Garbage collection звільняє чанки, які більше не посилаються. Ви можете агресивно виконати prune і ще не звільнити простір, поки GC не пройде. Навпаки, запуск GC у невдалий час може позбавити ресурсів відновлення і бекапів.

6) Відновлення падає лише з одного вузла. Що порівнювати спочатку?

/etc/pve/storage.cfg (username/token/namespace/fingerprint), розвʼязування DNS (getent hosts), відмінності в маршрутизації/фаєрволі і налаштування MTU. Практично дрейф конфігурацій по вузлах — найпоширеніший винуватець.

7) Як часто запускати datastore verify?

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

8) Що зазвичай означає «missing chunk», і чи можна це виправити?

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

9) Чи потрібні окремі токени для бекапу і відновлення?

Вам не обовʼязково потрібні, але бажано. Це зменшує площу ураження і робить аудит осмисленим. Головне — не звужувати токен бекапу так, щоб ніхто не міг швидко відновити при потребі.

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

Дедупліковані відновлення інтенсивно читають чанки і можуть бути випадково-орієнтованими по I/O. Бекапи, як правило, більш послідовні й толерантні. Якщо бекенд сховища має високу латентність або насичується, відновлення відчують це першими.

Наступні кроки (що робити цього тижня)

1. Проведіть вправу відновлення з неосновного вузла: змонтуйте снапшот, потім відновіть одну VM у ізольовану мережу. Задокументуйте кроки і час.
2. Заплануйте verify і GC усвідомлено: у неробочий час, без перетину з інжестом бекапів і не під час вашого реалістичного вікна відновлення.
3. Аудит ідентичностей та ACL: забезпечте шлях відновлення правом Datastore.Read і доступом до правильного простору імен. Перестаньте покладатися на «працювало для бекапів».
4. Виміряйте латентність сховища під навантаженням, схожим на відновлення: якщо iostat показує поганий await, розглядайте це як проблему дизайну сховища, а не помилку PBS.
5. Уніфікуйте конфігурацію репозиторію: один і той самий відбиток, однакові конвенції простору імен, однакова політика токенів на всіх PVE вузлах.

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