Proxmox «зберігання резервних копій недоступне на вузлі»: чому «shared» не означає спільне

Що насправді означає «shared» у Proxmox (і чого воно не означає)

У Proxmox VE «сховище» — це об’єкт конфігурації, визначений у /etc/pve/storage.cfg. Ця конфігурація може бути кластерною (реплікована між вузлами через pmxcfs) або локальною для одного вузла. Прапорець «shared» означає: «Я очікую, що це сховище буде доступне з кількох вузлів, і я відповідно поводитимусь при розміщенні дисків VM, при міграціях та виконанні резервних копій.»

Він не означає, що Proxmox зробить за вас такі речі:

• Монтує NFS/CIFS на кожному вузлі.
• Створить однакові шляхи на всіх вузлах.
• Виправить права доступу, відображення UID/GID або root squashing.
• Гарантує існування мережевого маршруту з кожного вузла.
• Підтримуватиме у синхронізованому стані ваші зовнішні systemd-юнити для монтування.

Прапорець у GUI Proxmox — це контракт. Ви його підписали. Тепер потрібно його виконати.

Є два поширені реальні тлумачення «shared»:

1. Рівень сховища: NFS/CIFS, iSCSI+LVM, FC SAN, Ceph, Gluster, PBS (у своєму сенсі). Кілька вузлів можуть отримувати доступ до одного бекенду.
2. Рівень конфігурації: визначення сховища існує в кластері, тож будь-який вузол може спробувати його використати.

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

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

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

Швидкий план діагностики

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

Перший крок: підтвердьте, який вузол ламається і яке сховище Proxmox вважає вживаним

1. Подивіться історію завдань резервного копіювання: який вузол його виконував? У кластері завдання можуть виконуватися на різних вузлах залежно від місця розташування VM.
2. Визначте ідентифікатор сховища (наприклад, backup-nfs, pbs01).
3. Перевірте, чи Proxmox вважає його «активним» на цьому вузлі.

Другий крок: доведіть, що монтування/шлях існує на проблемному вузлі

1. pvesm status і pvesm path для цього сховища.
2. findmnt для точки монтування.
3. Створіть тестовий файл від root у цільовій директорії.

Третій крок: ізолюйте мережу від прав і відображення ідентичності

1. Мережа: ping, nc (для PBS), showmount (для NFS), SMB-проба для CIFS.
2. Права: спробуйте touch, перевірте власника і режим, перевірте опції експорту NFS (root_squash і інші).
3. Ідентичність: перевірте, під яким користувачем працює процес резервного копіювання; підтвердіть, чи очікує віддалена сторона root або виконує відображення root.

Четвертий крок: перевірте узгодженість конфігурації кластера та симптоми розколу

1. pvecm status для кворуму.
2. Переконайтеся, що вміст /etc/pve/storage.cfg ідентичний на всіх вузлах (зазвичай так і є, якщо pmxcfs працює, або хтось не вніс локальні правки неправильно).
3. Перевірте синхронізацію часу; Kerberos для SMB та деякі TLS-настроювання стають проблемними при великих відхиленнях.

Зупиніться рано, коли знайдете перший зламаний шар. Виправлення прав не допоможе, якщо монтування ніколи не існувало. Перезавантаження не допоможе, якщо ви вказуєте невірне DNS-ім’я з одного вузла.

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

• Факт 1: Кластерна файлова система Proxmox (pmxcfs) — це користувацький реплікований сховище конфігурації. Вона розповсюджує конфігурацію, а не монтування чи стан ядра.
• Факт 2: Атрибут «shared» виник раніше, ніж сучасні очікування «семантики хмари». Він з епохи, коли адміністратори знали, що NFS-монтування — їхній клопіт, а не завдання гіпервізора.
• Факт 3: У Linux монтування — це стан ядра, локальний для вузла. Жоден файл конфігурації кластера не може «поділити» монтування, якщо ви не розгорнули його на кожному вузлі.
• Факт 4: Поведінка NFS root_squash — це безпекове значення за замовчуванням, що часто колізує з програмним забезпеченням резервного копіювання, яке працює від root. Це не баг Proxmox; це ваша політика безпеки, що зустрічає ваші припущення.
• Факт 5: Права CIFS/SMB — багатошаровий торт: серверні ACL, дозволи шару шарів, опції монтування клієнта і іноді відображення ідентичностей. Цікаво, коли все працює.
• Факт 6: Proxmox Backup Server (PBS) — це не файлове монтування; це сховище з API з чанкуванням і дедупом. Помилки доступності там часто мережеві/TLS/автентифікаційні, а не «монтування відсутнє».
• Факт 7: Плагіни сховища Proxmox часто перевіряють шлях, намагаючись отримати доступ до директорій або виконати операції; «не доступне» може означати «не вдається виконати stat директорії», «невірний тип вмісту» або «бекенд недосяжний».
• Факт 8: systemd змінив правила гри для монтувань: x-systemd.automount може зробити монтування «ліниве», що добре для швидкості завантаження і погано для резервних завдань із жорсткими часовими рамками при неправильній конфігурації.

Цитата, яка пасує в кожен посібник on-call:

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

Спільне сховище — одне з тих місць, де надія з’являється в футболці «працює на моєму вузлі».

Жарт №1: «Shared» сховище схоже на «спільну» відповідальність у postmortem: усі погоджуються, що воно існує, але ніхто точно не знає, хто ним володіє.

Чому сховище «недоступне»: реальні режими відмови

1) Визначення сховища кластерне, але бекенд не змонтований на кожному вузлі

Класика. Сховище визначене як dir або NFS/CIFS, але лише на одному вузлі є фактичне монтування або директорія. Інший вузол намагається виконати резервну копію і знаходить порожню директорію, відсутню точку монтування або локальний шлях, який не є тим, що ви думаєте.

2) Монтування існує, але змонтовано по-різному (опції, версії, шляхи)

NFSv3 на одному вузлі і NFSv4 на іншому. Різні rsize/wsize. Різний параметр vers=. Різний кеш облікових даних для SMB. Або гірше: один вузол змонтував інший експорт на тій самій точці монтування. GUI не кричить; він просто згодом падає.

3) Права: root squashed, невідповідність ACL або невірний власник

VZDump і багато операцій Proxmox працюють від root. Якщо ваш NFS-сервер відображає root в nobody і ваша директорія не доступна для запису для цього користувача, Proxmox отримує помилку вводу/виводу або доступу і повідомляє «не доступне» або помилку резервного копіювання. Ви можете бачити сховище як «активне», але записи провалюються.

4) Асиметрія DNS/маршрутизації між вузлами

Вузол A може розв’язувати nas01 на правильну IP. Вузол B розв’язує його на стару IP, іншу VLAN або мертву інтерфейс. Або один вузол маршрутизований через фаєрвол, який блокує порти NFS. Сховище «працює», поки завдання не потрапить на невірний вузол.

5) Проблеми стану кластера: втрата кворуму або дивна поведінка pmxcfs

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

6) Ціль резервного копіювання не є «сховищем» в сенсі файлової системи (PBS)

Збої PBS виглядають як помилки сховища в GUI тому, що Proxmox трактує його як бекенд сховища. Але корінні причини інші: прострочені підписи, проблеми TLS-довіреності, відкликані токени доступу, видалене сховище або заблокований мережевий порт.

7) Порядок завантаження та «nofail» монтування створюють часову бомбу

nofail у /etc/fstab дозволяє вузлу завантажитись навіть якщо NAS відсутній. Чудово. Але тепер вузол «увімкнений» і може запланувати резервні копії, тоді як директорія резервних копій фактично просто порожня локальна папка. Це не резервна копія; це перфоманс-арт.

Жарт №2: Резервна копія, що записується в незмонтовану директорію — це катастрофа Шредінгера: вона одночасно вдалася і провалилася, поки не настала потреба у відновленні.

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

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

Завдання 1: Визначити статус сховища з точки зору Proxmox

cr0x@pve2:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       98.00GiB        21.13GiB        71.87GiB   21.56%
backup-nfs        nfs     inactive            0B             0B              0B    0.00%
pbs01             pbs     active             n/a            n/a             n/a      n/a

Що це означає: Proxmox вважає backup-nfs неактивним на цьому вузлі. Це не проблема VM; це проблема монтування/досяжності.

Рішення: Пропускайте налагодження на рівні VM. Виправляйте бекенд сховища перш за все.

Завдання 2: Підтвердити, що конфігурація сховища існує і позначена як shared

cr0x@pve2:~$ grep -A6 -n "backup-nfs" /etc/pve/storage.cfg
18:nfs: backup-nfs
19:        export /exports/pve-backups
20:        path /mnt/pve/backup-nfs
21:        server nas01
22:        content backup
23:        prune-backups keep-last=7
24:        shared 1

Що це означає: Сховище сконфігуровано кластерно як NFS, тип вмісту «backup», і shared 1.

Рішення: Тепер доведіть, що path справді змонтований і доступний для запису.

Завдання 3: Запитайте Proxmox, де він очікує шлях

cr0x@pve2:~$ pvesm path backup-nfs
/mnt/pve/backup-nfs

Що це означає: Це точка монтування, яку Proxmox використовуватиме.

Рішення: Перевірте стан монтування ядра для цього шляху.

Завдання 4: Перевірити, що монтування реальне (а не лише порожня директорія)

cr0x@pve2:~$ findmnt /mnt/pve/backup-nfs

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

Рішення: Якщо не змонтовано — перевірте /etc/fstab та systemd-юнити; якщо змонтовано — переходьте до перевірки прав доступу та з’єднання.

Завдання 5: Порівняйте з відомо-робочим вузлом, щоб вловити «така ж назва, інше монтування»

cr0x@pve1:~$ findmnt /mnt/pve/backup-nfs
TARGET               SOURCE                FSTYPE OPTIONS
/mnt/pve/backup-nfs  nas01:/exports/pve-backups nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Що це означає: Ось як виглядає «добре»: правильний сервер, правильний експорт, правильна точка монтування.

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

Завдання 6: Спробуйте змонтувати і зафіксуйте реальну помилку

cr0x@pve2:~$ mount -av
/                        : ignored
/mnt/pve/backup-nfs       : mount.nfs4: Connection timed out

Що це означає: Проблема доступності мережі до nas01 (маршрут, фаєрвол, DNS або NAS недоступний).

Рішення: Зупиніться і налагодьте мережу перед тим, як торкатися прав чи налаштувань Proxmox.

Завдання 7: Перевірте симетрію DNS і маршрутизації

cr0x@pve2:~$ getent hosts nas01
10.20.30.50   nas01

Що це означає: Вузол розв’язує nas01 в IP. Це не доводить, що це правильний IP.

Рішення: Порівняйте вивід між вузлами. Якщо різні — виправте DNS/hosts. Якщо однакові — перевірте з’єднання до тієї IP-адреси.

Завдання 8: Доведіть мережеву досяжність (ICMP — недостатньо, але початок)

cr0x@pve2:~$ ping -c 2 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 56(84) bytes of data.
64 bytes from 10.20.30.50: icmp_seq=1 ttl=63 time=0.462 ms
64 bytes from 10.20.30.50: icmp_seq=2 ttl=63 time=0.497 ms

--- 10.20.30.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 0.462/0.479/0.497/0.017 ms

Що це означає: Хост досяжний, але NFS все ще може бути заблокований.

Рішення: Тестуйте NFS спеціально (portmapper для v3, 2049 для v4).

Завдання 9: Перевірте доступність служби NFS

cr0x@pve2:~$ nc -vz 10.20.30.50 2049
Connection to 10.20.30.50 2049 port [tcp/nfs] succeeded!

Що це означає: TCP-порт NFSv4 досяжний. Якщо це не так — це проблема фаєрволу/маршруту або сервіс NAS.

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

Завдання 10: Перевірте, що експорт існує (погляд з боку сервера через showmount)

cr0x@pve2:~$ showmount -e nas01
Export list for nas01:
/exports/pve-backups 10.20.30.0/24

Що це означає: NAS стверджує, що експортує шлях для вашої підмережі.

Рішення: Якщо ваш вузол не в тій підмережі (інша VLAN) — ви знайшли невідповідність.

Завдання 11: Якщо змонтовано — перевірте запис як root (реальність резервного копіювання)

cr0x@pve2:~$ sudo sh -c 'touch /mnt/pve/backup-nfs/.pve-write-test && ls -l /mnt/pve/backup-nfs/.pve-write-test'
-rw-r--r-- 1 root root 0 Dec 26 03:12 /mnt/pve/backup-nfs/.pve-write-test

Що це означає: Root може створювати файли. Це мінімум для сховища резервних копій.

Рішення: Якщо це завершується «Permission denied», перевірте опції експорту NFS і права директорії.

Завдання 12: Виявлення root squashing (поширено для NFS) з боку клієнта

cr0x@pve2:~$ stat -c "%U %G %a %n" /mnt/pve/backup-nfs
nobody nogroup 755 /mnt/pve/backup-nfs

Що це означає: Сервер може відображати root у nobody, а режим директорії не дозволяє запис.

Рішення: або коригуйте налаштування експорту (обережно), або створіть виділеного користувача для бекапів і уніфікуйте UID/GID між вузлами і NAS.

Завдання 13: Перевірте стан «змонтовано але stale» (флюкти NFS)

cr0x@pve2:~$ timeout 5 ls -la /mnt/pve/backup-nfs | head
total 16
drwxr-xr-x  2 root root 4096 Dec 26 02:10 .
drwxr-xr-x 10 root root 4096 Dec 26 01:55 ..
-rw-r--r--  1 root root    0 Dec 26 03:12 .pve-write-test

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

Рішення: Досліджуйте стабільність мережі, навантаження NFS-сервера, розгляньте жорсткі монтування з розумними таймаутами; уникайте «soft» для інтегритету бекапів.

Завдання 14: Для CIFS/SMB-сховищ перевірте опції монтування та використання облікових даних

cr0x@pve3:~$ findmnt /mnt/pve/backup-smb
TARGET               SOURCE                       FSTYPE OPTIONS
/mnt/pve/backup-smb  //files01/backups            cifs   rw,relatime,vers=3.1.1,cache=strict,username=svc_pve,uid=0,gid=0,file_mode=0640,dir_mode=0750

Що це означає: SMB-монтування існує і відображає власність на root. Це поширено для цілей резервних копій Proxmox.

Рішення: Якщо на вузлі відсутнє це монтування або використані інші облікові дані — стандартизуйте через /etc/fstab або systemd-юнит для монтування, розгорнутий однаково на всіх вузлах.

Завдання 15: Для сховища Proxmox Backup Server перевірте доступність API і автентифікацію

cr0x@pve2:~$ nc -vz pbs01 8007
Connection to pbs01 8007 port [tcp/*] succeeded!

Що це означає: Мережевий шлях до API PBS відкрито. Це перший крок.

Рішення: Якщо заблоковано — виправте фаєрвол/VLAN. Якщо відкрито — перевірте конфігурацію сховища Proxmox і сертифікати/печатки.

Завдання 16: Перевірте логи завдання резервного копіювання для точної помилки, пов’язаної зі сховищем

cr0x@pve2:~$ journalctl -u pvedaemon -u pvescheduler --since "today" | grep -i backup | tail -n 12
Dec 26 02:01:01 pve2 pvescheduler[1890]: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot
Dec 26 02:01:02 pve2 vzdump[2033]: ERROR: storage 'backup-nfs' is not available on node 'pve2'
Dec 26 02:01:02 pve2 vzdump[2033]: INFO: Failed at 2025-12-26 02:01:02

Що це означає: Помилка походить від інструмента резервного копіювання, що виконує перевірки сховища. Це не помилка знімка VM; це доступність сховища.

Рішення: Зосередьтеся на тому, чому pvesm status показує inactive або чому перевірка шляху провалюється.

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

cr0x@pve2:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 03:18:10 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000002
Ring ID:          1.10
Quorate:          Yes

Що це означає: Кластер має кворум. Ви не налагоджуєте сховище під час розділення кластера (добре).

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

Завдання 18: Перевірте синхронізацію часу (тиха причина TLS і SMB-проблем)

cr0x@pve2:~$ timedatectl
               Local time: Fri 2025-12-26 03:19:44 UTC
           Universal time: Fri 2025-12-26 03:19:44 UTC
                 RTC time: Fri 2025-12-26 03:19:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізовано. Це зменшує ймовірність помилок TLS при роботі з PBS або тонких випадків аутентифікації SMB.

Рішення: Якщо час розсинхронізований — виправте час спочатку. Це нудно і це працює.

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

cr0x@pve2:~$ grep -n "backup-nfs" /etc/fstab
12:nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,hard,timeo=600,retrans=2,_netdev 0 0

Що це означає: Є запис в fstab. Опції мають значення.

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

Завдання 20: Зверніть увагу на небезпечну комбінацію «nofail» + локальна директорія

cr0x@pve2:~$ grep -n "backup-nfs" /etc/fstab
12:nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,nofail,_netdev 0 0

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

Рішення: Замініть на systemd automount або забезпечте явну залежність так, щоб служби не продовжували роботу без сховища (деталі в розділі чеклістів).

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

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

У них був тривузловий кластер Proxmox і одне «резервне» сховище, що вказувало на NFS-шару. Адмін, який налаштовував, зробив «правильно» в GUI: додав NFS-сховище, поставив «Shared», обрав вміст «VZDump backup file». Усі кивнули.

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

Потім у вікні обслуговування перемістили партію VM на вузол 2. Наступні нічні бекапи виконувались на вузлі 2. Сховище повідомило «недоступне на вузлі». Хтось повторно запустив завдання вручну на вузлі 1 і назвав це «тимчасово». Через два дні вузол 1 несподівано перезавантажився, і бізнес виявив, що «тимчасово» означає «назавжди».

Корінь проблеми не був екзотичним: лише на вузлі 1 був запис у /etc/fstab для NFS-шари. Вузли 2 і 3 мали директорію /mnt/pve/backup-nfs (створену Proxmox), але вона не була змонтована. Команда припускала, що конфігурація кластера робить це «спільним». Ні, не робить.

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

Міні-історія 2: Оптимізація, що обернулась проти них

Інша компанія хотіла швидше завантажуватись і менше інцидентів «вузол зависає при очікуванні NAS». Вони додали nofail до NFS-монтувань і кілька systemd-патчів, щоб гіпервізор піднімався навіть якщо сховище недоступне.

Часи завантаження покращилися. На папері. Насправді вони обміняли одну модель відмови на хитрішу: вузли піднімались, GUI Proxmox виглядав здоровим, і завдання бекапу запускались. Але в ті ранки, коли NAS був повільний відповісти, монтування не встигало. Точка монтування існувала як звичайна директорія, тому завдання писали на локальний диск.

Локальний диск заповнився. VM почали пригортатися. Логи закипіли. Команда зберігання отримала сповіщення про «продуктивність NAS», хоча NAS був в порядку — Proxmox тихо перенаправив навантаження на локальний диск, бо монтування відсутнє.

Вони виправили це, використавши x-systemd.automount (доступ ініціює монтування), позбувшись ризику «запису в локальну директорію», зробивши точку монтування власністю root з режимом 000 коли не змонтовано, і додавши pre-backup хук для перевірки стану монтування. Мораль: оптимізація завантаження без урахування семантики відмов створює привидні системи.

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

Фінансова компанія використовувала Proxmox з PBS як основною ціллю резервних копій і NFS як вторинний «експорт». Вони були не захопливі. Вони усе документували і тестували відновлення щоквартально. Ось чому вони спали спокійно.

Одного вікенду прошивка ядра комутатора внесла зміну ACL, яка блокувала TCP/8007 з одного стояка. Два з чотирьох вузлів Proxmox могли дістатися PBS; два — ні. Резервні копії почали падати лише для VM, що працювали на ізольованих вузлах.

Вони виявили проблему за годину, бо їхній моніторинг не дивився лише «результат завдання бекапу». Він перевіряв досяжність сховища з кожного вузла. Сповіщення повідомляло: «pve3 не може дістатися pbs01:8007». Ніяких припущень, ніякої археології.

Вони тимчасово прикріпили бекап-завдання до здорових вузлів, потім відкатали зміну ACL. Після цього додали пункт у чекліст зміни: «перевірити доступність PBS з кожного гіпервізора». Сухо. Правильно. Врятувало ситуацію.

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

1) Симптом: «сховище недоступне на вузлі» лише на одному вузлі

Корінна причина: Монтування існує лише на деяких вузлах, або DNS розв’язується по-різному на різних вузлах.

Виправлення: Стандартизуйте монтування через /etc/fstab або systemd-юнити на всіх вузлах; перевіряйте за допомогою findmnt і getent hosts на кожному вузлі.

2) Симптом: сховище показує «active», але бекапи падають з помилками доступу або «cannot create file»

Корінна причина: NFS root_squash, невідповідність SMB ACL або неправильний власник/режим у цільовій директорії.

Виправлення: Визначте модель безпеки: або дозволити записи root в експорті (обережно), або використовувати виділеного сервісного користувача з однаковим UID/GID; потім тестуйте touch від root.

3) Симптом: бекапи «успішні», але місце займається на локальному диску, а не на NAS

Корінна причина: Монтування відсутнє; записи пішли у точку монтування локального файлового дерева (часто через nofail на старті).

Виправлення: Усуньте пастку. Використовуйте systemd automount або забезпечте доступність монтування перед запуском планувальника; зробіть точку монтування незаписуваною коли не змонтовано; моніторьте «змонтовано» замість «директорія існує».

4) Симптом: NFS-монтування працює вручну, але не під час завантаження

Корінна причина: Мережа не готова коли спроба монтування відбувається; відсутній _netdev або проблеми з порядком systemd.

Виправлення: Додайте _netdev, розгляньте x-systemd.automount і забезпечте network-online.target при потребі. Перевірте через перезавантаження.

5) Симптом: лише сховище на PBS падає, файлові сховища в порядку

Корінна причина: Порт заблоковано, помилка довіри/TLS fingerprint, відкликаний токен автентифікації або datastore перейменовано/видалено на PBS.

Виправлення: Перевірте з’єднання до TCP/8007, конфігурацію сховища в Proxmox, повторно підтвердіть fingerprint якщо він змінився свідомо, і переконайтесь, що datastore існує.

6) Симптом: сховище періодично «inactive» при навантаженні на NFS

Корінна причина: Мережеві флюкти, насичення NFS-сервера, stale handles або надто агресивні таймаути.

Виправлення: Стабілізуйте мережу, тонко налаштуйте NFS-сервер, використовуйте жорсткі монтування з розумними таймаутами і розгляньте відокремлення трафіку резервного копіювання в окрему VLAN/інтерфейс.

7) Симптом: після додавання нового вузла бекапи падають лише на ньому

Корінна причина: Новий вузол не отримав налаштування монтування на рівні ОС, правил фаєрволу, DNS search domains або довірчі корені СА.

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

8) Симптом: конфігурація сховища виглядає вірно, але вузол поводиться як ніби він не в кластері

Корінна причина: Втрата кворуму, проблеми corosync або pmxcfs.

Виправлення: Відновіть здоров’я кластера першочергово. Перевірте pvecm status, мережу між вузлами і стабільність кільця corosync.

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

Покроково: зробіть «shared» справжнім спільним (NFS/CIFS директорії)

1. Виберіть один канонічний ідентифікатор сховища і точку монтування. Наприклад: backup-nfs змонтовано в /mnt/pve/backup-nfs.

   Не створюйте варіацій на вузлах типу /mnt/pve/backup-nfs2 «на зараз». «На зараз» — це шлях до археологічних робіт.

2. Стандартизуйте розв’язання імен. Використовуйте getent hosts nas01 на всіх вузлах і переконайтеся, що воно розв’язується однаково. Якщо потрібно зафіксувати, використовуйте /etc/hosts уніфіковано.

3. Розгорніть однакову конфігурацію монтування на всі вузли. Використовуйте /etc/fstab або systemd-юнити. Ключ — ідентична поведінка при перезавантаженні.

   Мінімальний приклад для NFSv4:

   cr0x@pve1:~$ sudo sh -c 'printf "%s\n" "nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,hard,timeo=600,retrans=2,_netdev 0 0" >> /etc/fstab'
   

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

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

   Приклад опцій у fstab:

   cr0x@pve1:~$ sudo sed -i 's#nfs4 rw,hard,timeo=600,retrans=2,_netdev#nfs4 rw,hard,timeo=600,retrans=2,_netdev,x-systemd.automount,x-systemd.idle-timeout=600#' /etc/fstab
   

   Рішення: Якщо ваші вікна резервного копіювання жорсткі, перевірте латентність automount під навантаженням.

5. Забезпечте правило «не змонтовано = не записувано». Практичний прийом: зробіть точку монтування власністю root і режим 000 коли не змонтовано, а монтування накладається і дає потрібні права. Це зменшить сюрпризи «записи пішли локально». Тестуйте обережно, щоб Proxmox міг змонтувати.

6. Перевірте на кожному вузлі: монтування існує, запис працює, латентність прийнятна.

   cr0x@pve2:~$ sudo mount -a && findmnt /mnt/pve/backup-nfs && sudo sh -c 'dd if=/dev/zero of=/mnt/pve/backup-nfs/.speedtest bs=1M count=64 conv=fdatasync' 
   64+0 records in
   64+0 records out
   67108864 bytes (67 MB, 64 MiB) copied, 0.88 s, 76.6 MB/s
   

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

7. Переконайтеся, що Proxmox бачить його активним скрізь.

   cr0x@pve3:~$ pvesm status | grep backup-nfs
   backup-nfs        nfs     active        9.09TiB         3.21TiB         5.88TiB   35.31%
   

   Рішення: Тільки після цього можна думати про налаштування розкладу завдань резервного копіювання.

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

Покроково: PBS-backed «storage not available»

1. Підтвердьте TCP-доступність до PBS на порті 8007 з кожного вузла. Використовуйте nc -vz.
2. Переконайтеся, що сховище активно в pvesm status. Якщо inactive — зазвичай це питання з’єднання або автентифікації.
3. Перевірте синхронізацію часу. TLS не любить подорожі в часі.
4. Переконайтесь, що PBS datastore існує і не було перейменування. Конфіг сховища може пережити те, на що він вказує.
5. Будьте суворими щодо сертифікатів і fingerprint. Якщо fingerprint змінився несподівано — трактуйте це як подію безпеки до доведення зворотного.

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

1. Віддавайте перевагу PBS для дедупа та цілісності. Використовуйте файлові шари як вторинний експорт/реплікацію, а не єдину нитку порятунку.
2. Тримайте локальний fallback тільки якщо його моніторити. Локальна директорія може врятувати під час простою NAS, але лише якщо ви моніторите тиск на диск і швидко ротаєте.
3. Тестуйте відновлення. Не одного разу. Регулярно. Резервна копія, яку ви не відновлювали, — це чутка.

FAQ

1) Що означає «сховище недоступне на вузлі» у Proxmox?

Це означає, що вузол, що виконує операцію (часто vzdump), не може отримати доступ до цього бекенду сховища в даний момент. Зазвичай: не змонтовано, недосяжно, невірні облікові дані або відмова в доступі.

2) Якщо сховище позначено «Shared», чому Proxmox не змонтує його скрізь?

Тому що Proxmox управляє визначеннями сховища, а не станом монтувань ядра. Монтування — це стан ОС. Ви маєте налаштувати монтування на кожному вузлі (або використовувати бекенд, що апаратно є спільним, наприклад Ceph).

3) Чи можна вирішити це, знявши прапорець «Shared»?

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

4) Чому це іноді відбувається не завжди?

Тому що частина завдань запускаються на вузлі, що не має доступу до сховища, або монтування нестабільні (затримки automount, мережеві проблиски, навантаження NAS). Періодичні відмови — все одно відмови; вони просто чекають вашого найгіршого дня.

5) У чому різниця між NFS-сховищем для бекапів і сховищем PBS у Proxmox?

NFS — це змонтований шлях файлової системи. PBS — API-орієнтоване сховище резервних копій з дедупом, стисненням, валідацією та політикою pruning. Налагодження доступності PBS ближче до налагодження прикладної залежності, а не монтування.

6) Мій NFS-шар змонтувався, але бекапи падають з «Permission denied». Що робити?

Перевірте root_squash і права директорії. Процеси резервного копіювання Proxmox часто потребують запису від root. Або дозвольте записи root в експорті (зважте ризики) або використайте виділеного сервісного користувача з однаковими UID/GID і відповідними правами.

7) Як запобігти запису бекапів на локальний диск, коли NFS-монтування відсутнє?

Не покладайтеся на наявність директорії. Забезпечте перевірки монтування: використовуйте systemd automount і/або робіть точку монтування незаписуваною коли не змонтовано, і моніторьте «змонтовано» плюс «тест запису». Уникайте легковажного використання nofail без захисних механізмів.

8) Чи впливає кворум кластера на доступність сховища?

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

9) Чи нормально мати різні опції монтування на різних вузлах якщо «все ще працює»?

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

10) Чи варто використовувати CIFS/SMB для бекапів Proxmox?

Можна, але у Linux-середовищах гіпервізорів це зазвичай більш крихке рішення ніж NFS через складнощі автентифікації та ACL. Якщо немає вибору — стандартизуйте опції монтування і облікові дані по всіх вузлах і тестуйте поведінку при відмовах.

Висновок: наступні кроки, що запобігають повторенню

«Зберігання резервних копій недоступне на вузлі» — це Proxmox, що каже вам правду. Неприємна частина в тому, що правда живе під GUI: монтування, мережі, права, відображення ідентичності та порядок завантаження.

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

1. Виберіть проблемний вузол і виконайте швидкий план діагностики. Підтвердіть, чи сховище inactive, незмонтоване, недосяжне або незаписуване.
2. Стандартизуйте монтування на кожному вузлі. Та ж назва сервера, той самий експорт/шар, та сама точка монтування, ті самі опції.
3. Усуньте пастку «записи пішли локально». Якщо використовуєте nofail, компенсуйте його automount і моніторингом.
4. Додайте моніторинг по вузлах. Перевіряйте монтування + записуваність + очікуваний тип файлової системи, а не лише «завдання бекапу вдалося».
5. Тестуйте відновлення. Не тому що це весело. Тому що це дешевше, ніж вчитися під час простою.

Якщо вам потрібна одна ментальна модель: прапорець «Shared» — це обіцянка, яку ви даєте Proxmox. Дотримуйтесь її, і резервні копії стануть нудними. Порушуйте — і резервні копії стануть щотижневим сюрпризом.