Debian 13: /etc/pve виглядає порожнім після перезавантаження — чому монтування не вдається та як відновити

Що таке /etc/pve насправді (і чому воно «зникає»)

На Proxmox VE /etc/pve — це не просто «директорія з файлами». Це точка монтування Proxmox Cluster File System, pmxcfs.
Це користувацький файловий шар (FUSE), який подає конфігурацію кластера як єдине дерево, підкріплене внутрішньою базою даних і синхронізоване через кластерні повідомлення.

Коли pmxcfs не змонтований, у системі все ще є буквальна директорія /etc/pve — бо Linux потребує куди монтувати.
Ця директорія зазвичай порожня або містить лише те, що залишилось на ранньому етапі завантаження. Отже, ви не бачите «втрачених конфігів», ви бачите «не змонтовано».

Сутність у тому, що помилки монтування й «порожні» конфіги часто супроводжуються проблемами зі стореджем:
пул ZFS не імпортований, томи LVM не активовані, iSCSI сесії не залогінені, NFS не змонтований, Ceph не готовий або systemd запустив сервіси в неправильному порядку.
Один конкурсний запуск під час завантаження — і ваш стек управління працює з відсутньою частиною шару.

Є цитата, яку опрацювання дається людям ціною власного досвіду: «Надія — не стратегія.» — Джин Кранс.
Це не про конкретний сторедж, але болісно актуально, коли хтось каже: «Може, після ще одного перезавантаження все буде добре.»

Жарт №1: Якщо ваш план відновлення — «перезавантажувати, поки працюватиме», вітаю — ви винайшли ігровий автомат з гіршими шансами.

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

Це найкоротший шлях від «/etc/pve порожнє» до «я точно знаю, що зламалося». Робіть у цьому порядку. Не імпровізуйте.

1) Підтвердьте, чи змонтовано /etc/pve (не просто «порожньо»)

• Якщо це не FUSE-монтування, ви дивитесь у підлеглу директорію.
• Якщо змонтовано, проблема ймовірно в кворумі, corosync або конфлікті прав/блокувань — не в монтуванні.

2) Перевірте стан pmxcfs і журнали

• Якщо pmxcfs не працює — виправляйте це в першу чергу. Все інше — шум.
• Якщо pmxcfs працює, перевірте, чи він не жаліється на корупцію бази, lock-файли або стан кластера.

3) Перевірте corosync і кворум (у кластерах)

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

4) Перевірте готовність стореджу та порядок запуску systemd

• Якщо ZFS не імпортувався або LVM не активувався, монтування/сервіси, що залежать від них, зазнають краху.
• Виправте готовність стореджу, потім чисто перезапустіть залежні сервіси.

5) Вирішіть: відновлювати на місці або відновлювати з бекапів

• Якщо база pmxcfs пошкоджена, можливо доведеться відтворити стан вузла з інших вузлів або з резервних копій.
• Якщо це просто «не змонтовано», виправте сервіс і рухайтесь далі.

Реальні режими збою (і як вони виглядають)

Режим збою A: pmxcfs ніколи не змонтувався

Це класичний випадок «/etc/pve порожнє». Директорія існує, але FUSE-монтування не відбулося.
Причини включають те, що сервіс pmxcfs не запустився, відразу впав або був заблокований очікуванням чогось іншого.

Що ви побачите:

• mount не показує pmxcfs.
• systemctl status pve-cluster показує failed.
• journalctl містить помилки старту (часто проблеми з lock/db).

Режим збою B: corosync не працює або втраченo кворум

У кластері pmxcfs залежить від кластерних комунікацій. Якщо corosync не може сформувати членство або втрачено кворум,
pmxcfs може перейти в режим тільки для читання, працювати частково або блокувати певні операції. Іноді /etc/pve все ще змонтоване,
але записи не проходять і інструменти управління поводяться як по сирому цементу.

Режим збою C: сторедж не відновився, а сервіси все одно стартували

Debian 13 принесла нові поведінки systemd і зміни таймінгів, плюс те, що ваша апаратура/прошивка вирішила цього тижня.
Проста проблема порядку завантаження може зробити сторедж «пізнім»:

• ZFS-пули не автоімпортовано через зміну імен пристроїв або якщо пул востаннє був імпортований на іншому хості.
• VG LVM не активувався, бо multipath-пристрої з’являються після спроби активації.
• NFS-монтування блокуються тим, що network-online не означає «мережа дійсно доступна».
• iSCSI логіни не відбулися достатньо рано.

Результат — вторинний хаос: стореджі зникли в UI, ВМ не стартують, резервні копії падають, і адміністратори неправильно діагностують «Proxmox зжер мій конфіг».
Конфіг ще на місці; просто об’єкти, на які він посилається, відсутні.

Режим збою D: корупція бази даних або стану pmxcfs

Менш поширене, але реальне. Раптова втрата живлення, заповнений диск, несправна пам’ять або агресивні налаштування файлової системи можуть пошкодити файли стану.
Ви побачите явні помилки щодо бази pmxcfs, неможливість завантажити стан або повторювані падіння.

Режим збою E: ви на неправильному вузлі або в неправильному root

Бачив випадки, коли люди «виправляли» пустий /etc/pve, перебуваючи в chroot’і рятувального середовища або завантажившись у неправильний root-розділ.
Файлова система в порядку; оператор просто не на тій системі, яку він думає.

Жарт №2: Ніщо не робить системного адміністратора смиренним, як усвідомлення, що він лагодив не ту машину 20 хвилин.

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

Це реальні дії, які можна виконати на продуктивному сервері о 3:00 ночі. Кожна містить:
команду, що означає вивід, і рішення, яке ви приймаєте.
Виконуйте від root або з sudo де потрібно.

Завдання 1: Перевірити, чи /etc/pve є монтом (і якого типу)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /etc/pve
/etc/pve pmxcfs fuse rw,nosuid,nodev,relatime,user_id=0,group_id=0

Значення: Якщо ви бачите pmxcfs fuse, воно змонтоване й живе. Якщо нічого не показано або вказано ext4/xfs,
ви в підлеглій директорії і pmxcfs не змонтовано.

Рішення: Якщо не змонтовано, не шукайте «відсутні файли», починайте виправляти pve-cluster/pmxcfs.

Завдання 2: Перевірити, чи pmxcfs запущений і чи не впав

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Sun 2025-12-28 02:41:18 UTC; 2min 9s ago
    Process: 813 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)

Значення: Він не працює; вийшов з помилкою.

Рішення: Далі дивіться журнали. Не перезапускайте наосліп — зрозумійте причину помилки (DB, lock, права, кворум).

Завдання 3: Прочитати логи pve-cluster за причиною

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 28 02:41:18 server pmxcfs[813]: [main] notice: starting pmxcfs
Dec 28 02:41:18 server pmxcfs[813]: [main] error: unable to open database '/var/lib/pve-cluster/config.db': Input/output error
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Значення: Це не проблема монтування; це питання стану/вводу-виводу. Той «Input/output error» може вказувати на диск, файлову систему або підлягаючий сторедж.

Рішення: Негайно перевірте здоров’я дисків і помилки файлової системи; уникайте повторних перезапусків, які можуть погіршити корупцію.

Завдання 4: Підтвердити, що ви на очікуваному корені файлової системи (не rescue, не неправильний LV)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /
/ /dev/mapper/pve-root ext4

Значення: Ви на pve-root. Якщо бачите щось на кшталт /dev/sda1 несподівано або live/rescue overlay,
ви не там, де думаєте.

Рішення: Якщо неправильний root — зупиніться і завантажте правильний розділ; не «ремонтуйте» конфіги в неправильному середовищі.

Завдання 5: Перевірити статус corosync і членство (для кластерів)

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Sun 2025-12-28 02:39:02 UTC; 4min 25s ago

Значення: Corosync працює. Це не гарантує кворум, але це початок.

Рішення: Якщо corosync мертвий — налагодьте мережу/інтерфейси/фаєрвол та конфіг corosync перед тим, як звинувачувати pmxcfs.

Завдання 6: Явно перевірити кворум

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   14
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 02:43:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Значення: Немає кворуму. У цьому стані багато кластерних операцій заблоковані, щоб уникнути split-brain.

Рішення: Відновіть кворум, піднявши достатню кількість вузлів або виправивши з’єднання. Уникайте «форсування» кворуму, якщо не приймаєте ризики.

Завдання 7: Дивитися, чи pmxcfs змонтований в режимі лише для читання (тонка пастка)

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /etc/pve
/etc/pve fuse rw,nosuid,nodev,relatime

Значення: Тут видно rw, отже прапори монтування не примушують лише читання.
Якщо бачите ro або записи не працюють, ймовірно проблема в кворумі або в проблемах вводу-виводу.

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

Завдання 8: Підтвердити, що сервіси стореджу не впали під час завантаження (системний triage)

cr0x@server:~$ systemctl --failed --no-pager
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● zfs-import-cache.service     loaded failed failed  Import ZFS pools by cache file
● pve-storage.service          loaded failed failed  Proxmox VE storage daemon

Значення: Є конкретні відмови: імпорт ZFS і pve-storage.

Рішення: Виправляйте імпорт ZFS у першу чергу; потім перезапустіть pve-storage і перевірте стореджі.

Завдання 9: Перевірити, чи імпортовано ZFS-пули

cr0x@server:~$ zpool status
no pools available

Значення: Пулів не імпортовано. Це зламає будь-який сторедж, визначений на цих пулах.

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

Завдання 10: Обережно спробувати імпорт ZFS-пулу (спочатку read-only, якщо підозрілий)

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool  ONLINE
          sda3 ONLINE

Значення: Пул доступний для імпорту.

Рішення: Якщо це boot-пул — імпортуйте нормально; якщо підозрюєте пошкодження — імпортуйте у режимі лише для читання для інспекції.

cr0x@server:~$ zpool import -f rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME  STATE     READ WRITE CKSUM
        rpool ONLINE       0     0     0
          sda3 ONLINE       0     0     0

Значення: Пул повернувся. Тепер залежні сервіси мають шанс.

Рішення: Перезапустіть сервіси, що впали через відсутність ZFS (зазвичай pve-storage, іноді pvedaemon/pveproxy, якщо вони залежать від конфігів/стореджів).

Завдання 11: У випадках LVM — перевірити, чи VG активний

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   3   0 wz--n- 930.00g 120.00g

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

Рішення: Якщо відсутній — перевірте виявлення пристроїв (multipath/raid). Якщо існує, але неактивний — активуйте.

Завдання 12: Активувати LVM-томи (тільки якщо впевнені, що це безпечно)

cr0x@server:~$ vgchange -ay pve
  1 logical volume(s) in volume group "pve" now active

Значення: LVs активні; монтування й сервіси, що залежать від них, можуть продовжити роботу.

Рішення: Якщо активація провалюється — не лайтеся грубо. Дослідіть відсутні PV, multipath і dmesg.

Завдання 13: Мережеві стореджі — перевірити, чи network-online справді готовий

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
     Active: active (exited) since Sun 2025-12-28 02:38:40 UTC; 6min ago

Значення: Він каже «online», але це означає лише, що інтерфейси сконфігуровані, а не те, що ваш gateway/DNS/сторедж VLAN досяжні.

Рішення: Тестуйте доступність кінцевої точки стореджу явно.

Завдання 14: Перевірити NFS-монтування і помилки монтування

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET          SOURCE                 FSTYPE OPTIONS
/mnt/pve/backup nas01:/export/backup   nfs4   rw,relatime,vers=4.2,proto=tcp

Значення: Якщо монтування відсутнє — сторедж недоступний. Якщо присутнє — дивіться в інше місце.

Рішення: Якщо відсутнє, перевірте journalctl -b на помилки монтування; виправте DNS, маршрутизацію, фаєрвол або автентифікацію.

Завдання 15: Випадки iSCSI — підтвердити наявність сесій

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2003-01.org.linux-iscsi.nas01:storage.lun1 (non-flash)

Значення: Сесія існує. Якщо це порожньо, LUNи не з’являться, і LVM/ZFS-on-iSCSI зазнають краху.

Рішення: Якщо відсутні — виконайте повторний логін і забезпечте правильний порядок запуску (iscsid до активації LVM).

Завдання 16: Шукати очевидні помилки диска або файлової системи за проблемами БД pmxcfs

cr0x@server:~$ dmesg -T | tail -n 20
[Sun Dec 28 02:41:10 2025] blk_update_request: I/O error, dev sda, sector 194567890 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Sun Dec 28 02:41:10 2025] EXT4-fs error (device dm-0): ext4_find_entry:1535: inode #262401: comm pmxcfs: reading directory lblock 0

Значення: Це не «Proxmox дивний». Це ядро каже, що сторедж відмовляє.

Рішення: Трактуйте це як інцидент: припиніть ризикові записи, перевірте рівень дисків/RAID/ZFS і плануйте ремонт.

Завдання 17: Підтвердити вміст /etc/pve через шар управління

cr0x@server:~$ pvesh get /cluster/resources --type vm | head
vmid  status  name       node    type
100   running web-01     node1    qemu
101   stopped db-01      node1    qemu

Значення: Якщо pvesh може читати ресурси кластера, pmxcfs ймовірно функціонує.

Рішення: Якщо це не працює — фокусуйтесь на pmxcfs/corosync. Якщо працює, але стореджі відсутні — фокусуйтесь на стеку стореджу.

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

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /etc/pve
/etc/pve pmxcfs fuse

Значення: pmxcfs знову змонтовано.

Рішення: Перевірте кворум і сторедж. Потім підтвердьте, що очікувані конфіги присутні перед запуском ВМ.

Завдання 19: Перевірити, що конфіги вузлів існують (не лише монтування)

cr0x@server:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 .
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 ..
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 node1

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

Рішення: Якщо вузол відсутній — перевірте членство corosync і відповідність hostname; не починайте сліпо змінювати конфіги.

Завдання 20: Виявити проблеми з порядком завантаження для монтажу/сервісів

cr0x@server:~$ systemd-analyze critical-chain pve-storage.service
pve-storage.service +3.201s
└─network-online.target +2.998s
  └─systemd-networkd-wait-online.service +2.950s
    └─systemd-networkd.service +1.102s
      └─systemd-udevd.service +0.421s

Значення: pve-storage чекав на «network-online», що може або не означати готовність вашого сторедж-шляху.

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

Три короткі історії з корпоративної практики (бо це повторюється)

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

Середня компанія мігрувала два гіпервізорні вузли на новий хардвер і повторно використала старі IP для управління. Вікно змін було обмеженим.
Хтось перезавантажив один вузол, щоб «перевірити налаштування BIOS», і повернувся до порожнього /etc/pve. Паніка швидко поширилася, бо в UI не було конфігів ВМ.

Неправильне припущення було простим: «Якщо /etc/pve порожнє, конфіг вилетів з диска».
Вони почали відновлювати випадкові бекапи в /etc і редагувати /etc/fstab, щоб «полагодити монтування», що не мало відношення до pmxcfs.
На Proxmox це як ремонтувати тостер, перефарбовуючи кухню.

Насправді причина була в corosync. Під час міграції інтерфейси перейменувалися (predictable naming),
але corosync.conf залишив посилання на старий NIC. Corosync не сформував членство, кворум втрачено, і pmxcfs не піднявся коректно.
«Порожня» директорія була просто незмонтованою точкою.

Відновлення пройшло чисто, коли вони припинили гадати: виправили імена інтерфейсів, перезапустили corosync, підтвердили кворум, перезапустили pve-cluster.
Все «з’явилось» миттєво. Єдина тривала шкода — набір ручних правок, які довелось відкотити.

Висновок: ставтесь до /etc/pve як до сервісного кінцевого пункту. Якщо воно порожнє — це помилка сервісу, поки не доведено інше.

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

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

Після непланового відключення живлення кілька вузлів перезавантажились одночасно. Деякі стартували нормально; інші показали відсутні стореджі,
а декілька мали відоме порожнє /etc/pve під час раннього розслідування. Причина була не містичною.

iSCSI сесії ще не встановилися під час запуску активації LVM. LVM не побачив PV, тому не активував VG.
Серіси, що залежали від цих томів, стартували і «запам’ятали» відсутній стан. Коли iSCSI нарешті підключився,
ніхто не повторив активацію коректно. Система була «вгору», але в напівреальному стані.

Виправлення вимагало відкату «оптимізації»: примусової порядкування між логіном iscsid і активацією томів, і припинення уявлення,
що network-ready означає storage-ready. Також додали цілеспрямовані повторні спроби для стореджу, а не хаотичні рестарти стеку.

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

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

Регульоване середовище (уявіть собі документи з зубами) вело Proxmox-кластер зі строгим контролем змін.
Вони систематично робили дві невигадливі речі: (1) нічні резервні копії /etc/pve та критичних хост-конфігів,
і (2) щоквартальні тренування з відновлення, де хтось крім звичайного оператора відтворював вузол.

Вузол перезавантажився після оновлення ядра і не зміг змонтувати pmxcfs через підлягаючу дискову помилку, яка пошкодила базу pmxcfs.
Це не було питанням «перезапустити сервіс». Локальний стан вузла був недостовірним.

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

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

Висновок: регулярні бекапи + відпрацьоване відновлення перемагають «племінну пам’ять» щоразу.

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

1) Симптом: /etc/pve порожнє після перезавантаження

Корінна причина: pmxcfs не змонтовано (pve-cluster впав) або ви перебуваєте в підлеглій директорії.

Виправлення: findmnt /etc/pve і systemctl status pve-cluster. Виправте причину за логами, потім перезапустіть pve-cluster.

2) Симптом: /etc/pve присутнє, але записи не працюють (permission denied / read-only)

Корінна причина: Кластер не має кворуму; pmxcfs може відмовлятися від записів, щоб уникнути split-brain.

Виправлення: Відновіть кворум (підніміть вузли, виправте мережу corosync). Не «форсуйте» кворум, якщо не розумієте наслідків.

3) Симптом: UI показує відсутні стореджі, ВМ не стартують, але /etc/pve в порядку

Корінна причина: Сторедж не готовий: ZFS не імпортовано, LVM не активовано, NFS/iSCSI не змонтовані/не залогінені.

Виправлення: Діагностика на шарі стореджу перш за все (zpool status, vgs, findmnt, iscsiadm).
Потім перезапустіть pve-storage і перевірте визначення стореджів.

4) Симптом: pve-cluster впав з помилками БД

Корінна причина: IO-помилки диска, корупція файлової системи або корупція бази pmxcfs.

Виправлення: Припиніть трешити сервіс. Перевірте dmesg на IO-помилки і ремонтуйте підлягаючий файловий шар/апарат.
Відновіть стан pmxcfs з здорового вузла або бекапів за потреби.

5) Симптом: Все працює, поки ви не перезавантажите; після цього знову ламається

Корінна причина: Проблеми порядку завантаження/systemd race conditions; відсутні залежності для мережевих стореджів або повільні пристрої.

Виправлення: Використайте systemd-analyze critical-chain. Додайте коректні залежності юнітів і таймаути.
Уникайте хаків на кшталт «sleep 30», якщо не бажаєте жити в минулому.

6) Симптом: Порожній /etc/pve при завантаженні з rescue ISO

Корінна причина: Ви не завантажили встановлену систему. pmxcfs не працює. Звісно, воно порожнє.

Виправлення: Змонтуйте реальний root і chroot тільки якщо треба; інакше завантажтеся нормально і діагностуйте там.

7) Симптом: Ім’я вузла змінилося; кластер виглядає «новим»

Корінна причина: Несумісність hostname з конфігом кластера; шляхи pmxcfs залежать від імен вузлів.

Виправлення: Відновіть правильний hostname і резолюцію hosts; переконайтеся, що corosync і Proxmox бачать очікуване ім’я вузла.

Контрольні списки / покроковий план

Чекліст A: кроки відновлення при «/etc/pve порожнє» (безпечно та швидко)

1. Підтвердьте монтування: findmnt /etc/pve.
   Якщо не pmxcfs — вважайте це відмовою сервісу.
2. Перевірте pve-cluster: systemctl status pve-cluster і journalctl -u pve-cluster -b.
   Журнали зазвичай підкажуть, що не так. Довіряйте їм.
3. Перевірте кластер: systemctl status corosync і pvecm status.
   Якщо немає кворуму — відновіть його перед спробою записів.
4. Перевірка стореджу: systemctl --failed, потім перевірте ZFS/LVM/NFS/iSCSI за потреби.
   Виправте готовність стореджу (імпорти, активації, монтування).
5. Перезапускайте у правильному порядку:
   спочатку сервіси стореджу (zfs-import, iscsid, remote-fs), потім pve-storage, потім pve-cluster за потреби.
6. Підтвердіть: ls /etc/pve, pvesh get /cluster/resources і впевніться, що стореджі відображаються.
7. Лише потім: запускайте ВМ або знову вмикайте HA-ресурси.

Чекліст B: коли зупинитися і оголосити апаратний/сторедж-інцидент

1. dmesg показує I/O-помилки, скиди або помилки файлової системи.
2. SMART/RAID показують деградовані масиви або помилки медіа (використовуйте вендорні інструменти).
3. Помилки БД pmxcfs співпадають з повідомленнями ядра про диск.
4. Проблема повертається після «ремонту» сервісів без будь-яких змін конфігів.

Якщо щось із цього істинне, ваш пріоритет — цілісність та стабільність даних, а не «домовитись з зеленими індикаторами в UI».

Чекліст C: запобігання сюрпризам після перезавантаження (нудні контрольні заходи, що працюють)

1. Додайте явні systemd-залежності для вашого стеку стореджу (iSCSI перед LVM, досяжність мережі перед NFS).
2. Уникайте крихких шляхів пристроїв; віддавайте перевагу стабільним ідентифікаторам (WWN, by-id). Якщо використовуєте multipath — зробіть його детермінованим.
3. Забезпечте непарну кількість голосів у кластері або належний quorum-пристрій.
4. Тримайте бекапи /etc/pve і регулярно тестуйте відновлення, а не під час інциденту.
5. Практикуйте перезавантаження: іноді перезавантажуйте по одному вузлу в робочий час. Якщо це лякає — це і є суть.

Цікавинки та історичний контекст

• pmxcfs — це FUSE-файлова система. Саме тому /etc/pve може «зникати» без видалення — це точка монтування для користувацького процесу.
• Запобігання split-brain визначає дизайн. Кластерні стеки часто блокують записи без кворуму, бо альтернатива — тихе руйнування стану між вузлами.
• Corosync — довгожитель у Linux HA. Він використовується як шар кластерних повідомлень у різних HA-екосистемах, не лише в Proxmox.
• systemd змінив мислення про порядок завантаження. Перехід від послідовних init-скриптів до паралельної активації юнітів зробив race-умови частішими й тоншими.
• network-online ≠ network-reachable. systemd може оголосити перемогу, тоді як ваш сторедж-VLAN ще веде переговори, бракує маршруту або DNS неправильний.
• ZFS-імпорти консервативні за дизайном. ZFS відмовиться автоімпортувати пул у деяких обставинах, щоб уникнути одночасного імпорту того ж пулу на кількох системах.
• Точки монтування — просто директорії, поки не змонтовано. Linux охоче покаже вам порожній mountpoint; він не попередить, що «зазвичай це інша файлова система».
• Розміщення конфігів кластера — це компроміс. Централізація конфігурації підвищує узгодженість, але піднімає планку для кворуму і здоров’я кластера; тому локальні fallback-механізми можуть бути обмежені.
• Готовність стореджу під час завантаження — багаторівнева проблема. Прошивка, ініціалізація HBA, multipath, udev, мережа, автентифікація та імпорт ФС мають синхронізуватись.

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

1) Чи видалено мій Proxmox-конфіг, якщо /etc/pve порожнє?

Зазвичай ні. Найпоширеніша ситуація — pmxcfs не змонтовано, тож ви бачите підлеглу порожню директорію.
Підтвердіть за допомогою findmnt /etc/pve.

2) Чому це з’являється після перезавантаження, а не під час нормальної роботи?

Перезавантаження перетасовує таймінги: виявлення пристроїв, готовність мережі, членство в кластері і порядок запуску сервісів.
Під час роботи системи ці гонки ввічливі; під час завантаження — грубі.

3) Чи можна просто відтворити /etc/pve і скопіювати файли назад?

Не робіть цього. /etc/pve — точка монтування для pmxcfs. Копіювання файлів у підлеглу директорію не вирішить справжньої проблеми
і може ускладнити подальшу діагностику.

4) Що, якщо pmxcfs змонтований, але GUI все одно неправильний?

Тоді зосередьтесь на кворумі й здоров’ї corosync або на готовності стореджу. Змонтований pmxcfs означає, що кінцева точка файлосистеми існує;
це не гарантує, що кластерні операції дозволені або що стореджі доступні.

5) Чи безпечно перезапускати pve-cluster та corosync на продуктивному вузлі?

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

6) Мій кластер «не кворумний». Чи можна змусити його?

Можна, але ви можете пошкодувати. Форсування кворуму може дозволити записи, що призведуть до split-brain, коли інша частина повернеться.
Робіть це лише якщо впевнені, що інша сторона дійсно зникла, і приймаєте подальшу роботу з примирення.

7) Чому помилки стореджу роблять /etc/pve схожим на порожнє?

Це не прямий причинник — pmxcfs окремий. Але помилки стореджу часто співпадають з таймінговими проблемами завантаження і відмовами сервісів,
і дають подібні симптоми: відсутні диски ВМ, відсутні стореджі, впалі сервіси і загальне відчуття, що реальність необов’язкова.

8) Яка команда найкорисніша першою?

findmnt /etc/pve. Вона скаже, чи маєте справу з проблемою монтування/сервісу або ганяєтеся по порожній директорії.

9) Як запобігти цьому на Debian 13 у майбутньому?

Зробіть порядок завантаження явним для залежностей стореджу, забезпечте стабільне іменування пристроїв, перевірте інтерфейси corosync після оновлень
і регулярно тестуйте перезавантаження.

10) Якщо база pmxcfs пошкоджена, чи потрібно перевстановлювати?

Не завжди, але іноді перевстановлення і повторне приєднання вузла до кластера — найчистіший шлях, особливо якщо є також IO-помилки.
Розглядайте корупцію в поєднанні з IO-помилками спершу як апаратну/сторедж-проблему.

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

Коли /etc/pve виглядає порожнім після перезавантаження на Debian 13, спочатку припускайте проблему монтування/сервісу, а не втрату даних.
Підтвердіть, чи змонтовано pmxcfs. Читайте журнали. Перевірте кворум. Потім перевірте готовність стореджу і порядок systemd.
Така послідовність економить години, бо швидко звужує зону збоїв.

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

1. Пройдіть швидкий план діагностики і зафіксуйте, що впало (pmxcfs, corosync/kvorum, ZFS/LVM, віддалені монтування).
2. Якщо проблема в порядку завантаження — виправте це через коректні systemd-залежності, а не «sleep»-хаки.
3. Якщо бачите IO-помилки — трактуйте як інцидент зі стореджем і припиніть «перезапускати, поки працює».
4. Заплануйте тренування з перезавантаження і з відновлення конфігів. День, коли ви практикуєтеся — це день, коли ви спокійні.