Файлова система Proxmox стала лише для читання: чому це трапляється і як відновити

Що насправді означає «тільки для читання» в Proxmox

«Тільки для читання» — це не одне єдине явище. На хості Proxmox може бути:

• Коренева файлова система (зазвичай ext4 або ZFS root, іноді XFS), змонтована як лише для читання ядром після помилок.
• Файлова система з даними (dataset ZFS, ext4/XFS на LVM, NFS/Ceph-маунт), яка переходить у режим лише для читання, поки хост залишається записуваним.
• pmxcfs (файлова система кластера Proxmox, змонтована в /etc/pve), яка відмовляє у записах при відсутності кворуму або проблемах з локальною базою.
• Поведеннєвий рівень додатка, який виглядає як проблема файлової системи (наприклад, ZFS dataset readonly=on або бекенд сховища, що повертає EROFS).

Ядро переводить маунт в режим лише для читання, коли вважає, що подальші записи можуть пошкодити метадані. Це не Linux, що драматизує; це Linux, який відмовляється стати вашим співучасником.

Правило №1: визначте, який маунт є лише для читання і що генерує шлях помилки (VFS, драйвер файлової системи, блоковий рівень або сервіс кластера). Якщо ви пропустите це, витратите годину на перемонтування не того і будете відчувати себе продуктивним, тоді як нічого не зміниться.

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

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

• Це /? /var? /etc/pve? ZFS dataset на кшталт rpool/data? Маунтований NFS-ресурс?
• Спробуйте маленький запис у проблемній гілці (ще нічого не «виправляйте»). Це проба.

Другий: зафіксуйте історію ядра, поки вона не зникла

• dmesg -T і journalctl -k -b покажуть, чи бачив ядро I/O-помилки, корупцію файлової системи, призупинення пулу ZFS або примусове вимкнення.
• Шукайте: Buffer I/O error, EXT4-fs error, XFS (…): Corruption detected, blk_update_request, ata/nvme ресети, ZFS: pool I/O suspended.

Третій: вирішіть, це «сховище хворе» чи «файлова система хворіє»

• Сховище хворе: I/O-помилки, тайм-аути, ресети, попередження SMART, помилки медіа NVMe. Спочатку лагодьте апарат/кабелі/контролер. Запуск fsck на диску, що активно відмовляє, — як перетворити невелику подряпину на ампутацію.
• Файлова система хворіє: здоров’я пристрою чисте, але є помилки метаданих. Тоді ремонтуйте (fsck/xfs_repair/zpool clear залежно від стеку).
• Кластер/кворум хворіє: лише /etc/pve лише для читання, і логи показують втрату кворуму. Це політичне, а не фізичне питання.

Прийміть рішення швидко: стабілізуйте, збережіть докази, а потім ремонтуйте. Ваша ціль — не допустити каскадного пошкодження (диски VM, логи, бази даних), одночасно відновлюючи сервіс.

Чому файлові системи переходять у режим лише для читання (реальні сценарії відмов)

1) Реальні I/O-помилки диска (найпоширеніша «справжня» причина)

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

• Погані сектори на HDD або знос NAND на SSD
• Ресети контролера NVMe або баги у прошивці
• Проблеми з SATA-кабелем (так, вони ще трапляються)
• Збої RAID-контролера або проблеми з кешем/батареєю
• Втрати живлення, що призводять до паніки пристрою

В Proxmox перша підказка зазвичай з’являється в dmesg задовго до того, як ви побачите «тільки для читання» на рівні маунта.

2) Корупція метаданих файлової системи (ext4/XFS)

ext4 має політику поведінки при помилках. Звичні налаштування: перемонтувати в режим лише для читання при помилці. XFS схильна до примусового вимкнення при виявленні корупції. Обидві системи роблять вам послугу — просто не дуже зручну.

3) Проблеми пула ZFS: призупинені I/O, faulted vdev або зникнення пристроїв

ZFS не «перемонтовує» лише для читання так само, як ext4. Натомість він може призупинити I/O, щоб захистити цілісність, коли не може безпечно виконувати записи. З погляду VM це схоже: операції зависають або повертають помилку, і Proxmox починає логувати збої сховища.

4) Виснаження простору або інодів (виглядає як read-only, якщо не читати помилку)

Повна файлова система зазвичай повертає No space left on device, а не read-only. Але багато інструментів та людей інтерпретують «не можна записати» як «тільки для читання». На хості Proxmox /var може заповнитися через логи, резервні копії, дампи або контейнерні «бігаючі» записи.

5) pmxcfs (/etc/pve) лише для читання через втрату кворуму

/etc/pve — це FUSE-орієнтована файлова система кластера (pmxcfs). Коли кластер втрачає кворум, Proxmox захищає вас від split-brain, роблячи конфігурацію кластера лише для читання. Люди помилково діагностують це як збій диска, бо рядок помилки ідентичний.

6) «Оптимізації», що створюють крихкість

Кешування записів без захисту від втрати живлення, агресивні налаштування discard, відключені бар’єри, екзотичні режими RAID, дешеві USB-boot пристрої… усе це може породити «неочікувані» перемонтування в ro під час навантаження або аварій живлення. Несподіванка — лише для того, хто так налаштував.

Жарт №1: Сховище — як стрибки з парашутом: більшість часу нудно, а захопливі моменти рідко повторюються з хорошим результатом.

Цікаві факти та історія, якою можна скористатися

1. Походження ext4 з «errors=remount-ro» йде ще від ext2/ext3: якщо метадані підозрілі, зупиніть записи, щоб зберегти можливість відновлення.
2. XFS народився в SGI для великих систем; його поведінка «примусове вимкнення» — свідомий вибір «краще померти, ніж зіпсувати дані».
3. Linux VFS використовує EROFS («Error Read-Only File System») як загальний сигнал — різні причини можуть виглядати однаково для користувача.
4. /etc/pve у Proxmox — це не просто каталог у звичному сенсі. Це розподілене сховище конфігів, виставлене як файлова система через FUSE (pmxcfs).
5. Правила кворуму старші за Proxmox: розподілені системи десятиліттями використовують голосування більшості, щоб уникнути split-brain. Proxmox просто робить це надто помітним.
6. ZFS ставить безтурботну корупцію даних на перше місце; модель контрольних сум end-to-end — причина його популярності в опса та ж причина його строгості при збоях пристроїв.
7. SMART не був створений для ідеального прогнозування; це радше «погодний прогноз для дисків». Корисний, але не чарівний.
8. Кеші записів змінили гру відмов: сучасні SSD та контролери можуть підтверджувати запис до його незворотності. Без захисту від втрати живлення — плата за цілісність даних проявиться пізніше.
9. FUSE-файлові системи можуть стати «лише для читання» з причин, не пов’язаних із дисками, бо демон може відмовити у записах, коли його модель цілісності під загрозою.

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

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

Завдання 1: Доведіть, який маунт лише для читання

cr0x@server:~$ mount | egrep ' on / | on /var | on /etc/pve |type zfs|type ext4|type xfs'
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

Значення: root змонтовано як (ro,...). /etc/pve все ще rw.

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

Завдання 2: Спробуйте контрольований запис у проблемний шлях

cr0x@server:~$ touch /root/.rw-test
touch: cannot touch '/root/.rw-test': Read-only file system

Значення: помилка реальна і походить від VFS/FS, а не прав доступу.

Рішення: припиніть непотрібні записи (резервні копії, лог-шторм), і зберіть докази перед перезавантаженням.

Завдання 3: Прочитайте повідомлення ядра, щоб знайти тригер

cr0x@server:~$ dmesg -T | tail -n 40
[Thu Dec 26 10:41:09 2025] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 10:41:09 2025] blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 10:41:09 2025] EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 10:41:09 2025] EXT4-fs (dm-0): Remounting filesystem read-only

Значення: це почалося як помилка на рівні блоків (dev sda), що потім спричинило аборт журналу ext4 і перемонтування в ro.

Рішення: вважайте апаратний шлях підозрілим до доведення протилежного. Робіть SMART, перевірку кабелів/контролера; уникайте fsck, поки пристрій нестабільний.

Завдання 4: Підтвердіть поточний бут і збережіть постійні логи

cr0x@server:~$ journalctl -k -b | egrep -i 'error|ext4|xfs|nvme|ata|timeout|reset|zfs|I/O' | tail -n 60
Dec 26 10:41:09 server kernel: blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE)
Dec 26 10:41:09 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start: Detected aborted journal
Dec 26 10:41:09 server kernel: EXT4-fs (dm-0): Remounting filesystem read-only

Значення: та сама історія, що й у dmesg, але тепер у журналі (корисно після перезавантаження).

Рішення: переходьте до перевірок здоров’я пристрою; плануйте вікно обслуговування, якщо диск підтинається.

Завдання 5: Визначте стек блокових пристроїв (dm-0 → LVM → фізичний диск)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,UUID
NAME           TYPE   SIZE FSTYPE      MOUNTPOINTS                UUID
sda            disk  1.8T
├─sda1         part  1007K
├─sda2         part     1G vfat        /boot/efi                 2B1A-9C3D
└─sda3         part   1.8T LVM2_member                          1dGk2A-...
  ├─pve-root   lvm     96G ext4        /                         4d9a7a0e-...
  ├─pve-swap   lvm      8G swap        [SWAP]                    0f19...
  └─pve-data   lvm    1.7T LVM2_member
    └─pve-vm--data-lvpool lvm 1.7T

Значення: коренева файлова система розташована на логічному томі LVM pve-root, під яким лежить sda3.

Рішення: перевірте фізичний диск (/dev/sda) перш за все. Гарний LVM-стек не врятує від вмираючого диска.

Завдання 6: Перевірка SMART (SATA/SAS) — чи не бреше диск?

cr0x@server:~$ smartctl -a /dev/sda
SMART overall-health self-assessment test result: FAILED!
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always   FAILING_NOW 2048
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       128
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       128

Значення: цей диск не просто деградований — він активно відмовляє. Pending і uncorrectable сектори сильно корелюють з I/O-помилками.

Рішення: перестаньте довіряти пристрою. Пріоритезуйте евакуацію даних та заміну. Не запускайте write-heavy ремонти без крайньої необхідності.

Завдання 7: Здоров’я NVMe (якщо ви завантажуєтеся з NVMe)

cr0x@server:~$ nvme smart-log /dev/nvme0
critical_warning                    : 0x00
media_errors                        : 12
num_err_log_entries                 : 58
percentage_used                     : 87%

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

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

Завдання 8: Перевірте, чи саме /etc/pve лише для читання (виявлення кворуму)

cr0x@server:~$ touch /etc/pve/.pmxcfs-test
touch: cannot touch '/etc/pve/.pmxcfs-test': Read-only file system

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

Рішення: робіть перевірки кластера, а не дисків, якщо інші маунти не впали.

Завдання 9: Стан кластера та кворум

cr0x@server:~$ pvecm status
Quorum information
------------------
Date:             Thu Dec 26 11:02:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          No

Значення: немає кворуму. Proxmox захищатиме запис конфігів кластера.

Рішення: відновіть коректність мережі corosync / поверніть вузли онлайн / обережно змініть expected votes для аварійної роботи. Не намагайтесь «chmod вирішити» проблему.

Завдання 10: Перевірка сервісів pmxcfs / corosync

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Active: active (running)

Значення: сервіси запущені, але кворум все ще може бути втраченим. Не плутайте «active» з «healthy».

Рішення: вирішуйте мережеві питання та перевіряйте pvecm status після змін.

Завдання 11: Швидка перевірка здоров’я ZFS (якщо ви використовуєте ZFS)

cr0x@server:~$ zpool status -x
pool 'rpool' is DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.

Значення: член vdev став недоступним або нечитаємим. На mirrors/raidz ви можете ще працювати, але ви на позиченому часі.

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

Завдання 12: Детальний статус ZFS із помилками та мапінгом пристроїв

cr0x@server:~$ zpool status -v rpool
  pool: rpool
 state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       UNAVAIL      0     0     0  cannot open

errors: No known data errors

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

Рішення: розглядайте інцидент серйозно. Знайдіть причину UNAVAIL (HBA reset? бекплейн? померлий SSD). Замініть і прогоніть scrub.

Завдання 13: Перевірка логів на «prизупинений I/O» ZFS

cr0x@server:~$ journalctl -k -b | egrep -i 'zfs|suspend|zio|I/O' | tail -n 40
Dec 26 10:55:01 server kernel: ZFS: vdev IO failure, zio pipeline stalled
Dec 26 10:55:01 server kernel: ZFS: pool rpool has encountered an uncorrectable I/O failure and has been suspended.

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

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

Завдання 14: Швидко виявити «просто заповнений» диск

cr0x@server:~$ df -hT /
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/pve-root ext4   94G   94G     0 100% /

Значення: root заповнений. Саме це не має перемонтувати ro, але спричинить масові помилки запису.

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

Завдання 15: Підтвердіть політику помилок ext4 і опції маунту

cr0x@server:~$ tune2fs -l /dev/mapper/pve-root | egrep -i 'Filesystem state|Errors behavior|Last error'
Filesystem state:         clean
Errors behavior:          Remount read-only
Last error time:          Thu Dec 26 10:41:09 2025

Значення: ext4 налаштований перемонтовуватися в ro при помилках; час останньої помилки відповідає інциденту.

Рішення: плануйте офлайн fsck після стабілізації апаратури. Не змінюйте поведінку помилок як «фікс» — це як вийняти батарейку з пожежного сигналу, бо вона пищить.

Завдання 16: Підтвердіть деталі примусового вимкнення XFS (якщо XFS)

cr0x@server:~$ journalctl -k -b | egrep -i 'xfs|shutdown|metadata|corrupt' | tail -n 40
Dec 26 10:39:12 server kernel: XFS (dm-0): Corruption detected. Unmount and run xfs_repair
Dec 26 10:39:12 server kernel: XFS (dm-0): xfs_do_force_shutdown(0x2) called from xfs_reclaim_inodes+0x2b0/0x2f0

Значення: XFS виявив корупцію і примусово вимкнувся, щоб уникнути подальшої шкоди.

Рішення: заплануйте простої для відмонтування та запуску xfs_repair (часто з rescue-режиму). Знову: спочатку перевірте апарат.

Це ядро діагностики. Тепер поговоримо про відновлення, не погіршуючи ситуацію.

Відновлення за стеком зберігання: ext4/XFS, ZFS, LVM, pmxcfs

Випадок A: ext4 коренева або дата-файлова система перемонтована як лише для читання

ext4 переходить у режим лише для читання при виявленні внутрішньої невідповідності (часто спричиненої I/O-помилками). Ваші пріоритети:

1. Зупиніть сервіси з інтенсивними записами, щоб зменшити навантаження.
2. Збережіть логи (kernel і syslog).
3. Підтвердіть здоров’я базового сховища (SMART, dmesg ресети).
4. Ремонт офлайн (fsck) після того, як ви довіряєте блоковому рівню.

Спроба перемонтувати на запис (тільки тимчасово)

Якщо ядро перемонтувало в ro через помилки ext4, remount rw може не вдатися — або вдасться тимчасово, а потім знову впаде. Розглядайте це як «отримати логи та критичні конфіги», а не як «повернутися до нормальної роботи».

cr0x@server:~$ mount -o remount,rw /
mount: /: cannot remount /dev/mapper/pve-root read-write, is write-protected.

Значення: ядро відмовляє у remount rw, бо файлова система в помилковому стані.

Рішення: потрібен офлайн-ремонт. Не сперечайтеся з ядром. Воно переможе, і ви втратите дані.

Підготовка до офлайн fsck (більш безпечний підхід)

Зазвичай ви не можете запускати fsck для змонтованої кореневої файлової системи. Плануйте завантаження в rescue-середовище або режим одного користувача з відмонтованим root.

У термінах Proxmox це часто: завантажитись з ISO/віртуального USB через IPMI, або скористатися grub recovery, якщо ви впевнені в процесі.

Після завантаження в rescue, виконайте:

cr0x@server:~$ fsck.ext4 -f -y /dev/mapper/pve-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/pve-root: recovering journal
/dev/mapper/pve-root: Clearing orphaned inode 131082
/dev/mapper/pve-root: FIXED.

Значення: журнал відновлено; знайдені й виправлені сирітські іноди; fsck повідомляє про виправлення.

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

Коли fsck — не перший крок

Якщо SMART падає або dmesg показує ресети/тайм-аути, fsck може прискорити відмову через інтенсивні операції читання/запису. У цьому випадку:

• Створіть образ/скопіюйте те, що можна (диски VM, конфіг), на здоровий пристрій.
• Замініть апарат.
• Потім виконайте ремонт, якщо потрібно.

Випадок B: примусове вимкнення XFS

XFS-ремонт виконується за допомогою xfs_repair. Він має запускатися з відмонтованою файловою системою. Якщо це кореневий диск — знову rescue-режим.

cr0x@server:~$ xfs_repair /dev/mapper/pve-root
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 7 - verify and correct link counts...
done

Значення: журнал був скинутий, і метадані скориговано.

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

Випадок C: проблеми пула ZFS (degraded, faulted, suspended I/O)

ZFS не соромиться. Якщо він вважає, що записи не можуть бути безпечно виконані, він може призупинити I/O. Саме тоді Proxmox починає поводитися так, ніби все знаходиться у привидному стані: диски VM зависають, задачі не завершуються, і ви отримуєте тайм-аути всюди.

Крок 1: status, не гадати

cr0x@server:~$ zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
errors: Permanent errors have been detected in the following files:
        rpool/data/vm-101-disk-0

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

Рішення: зупиніть цю VM, відновіть з бекапу/репліки. Не «скрабте сильніше» — scrub не вигадає відсутні біти.

Крок 2: замініть відсутній/фолтований пристрій (приклад)

cr0x@server:~$ zpool replace rpool ata-SAMSUNG_SSD_2 /dev/disk/by-id/ata-SAMSUNG_SSD_NEW

Значення: ZFS починає resilver на новий пристрій.

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

Крок 3: очистити помилки після апаратного ремонту

cr0x@server:~$ zpool clear rpool

Значення: очищає лічильники помилок; самі дані це не поправляє.

Рішення: запустіть scrub, щоб валідувати та відновити з надлишку.

Крок 4: scrub і інтерпретація результатів

cr0x@server:~$ zpool scrub rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
scan: scrub repaired 0B in 00:12:31 with 0 errors on Thu Dec 26 12:03:44 2025

Значення: scrub не знайшов помилок (добре). Якщо він щось ремонтував, ви б побачили ненульовий обсяг відновлених байт; якщо не зміг — побачите помилки.

Рішення: якщо помилки залишаються: перевірте кабелі/HBA і розгляньте тест ОЗП (ZFS часто виказує погану пам’ять).

Випадок D: проблеми LVM або device-mapper, що спричиняють read-only

Іноді файлова система невинна; нижчий блоковий пристрій переходить у помилковий стан. Перевірте повідомлення dm і LVM:

cr0x@server:~$ dmsetup info -C
Name             Maj Min Stat Open Targ Event  UUID
pve-root         252   0 L--w   1    1      0  LVM-...

Значення: прапор Stat може підказати стан пристрою (це варіюється). Важливіше — поєднати з логами ядра щодо «device mapper: thin: …» або «I/O error on dm-0».

Рішення: якщо метадані thin-pool повні або пошкоджені — потрібні специфічні фікси для LVM-thin і ймовірно простій. Не імпровізуйте.

Випадок E: /etc/pve лише для читання (pmxcfs / кворум)

Класична пастка Proxmox: усе інше записуване, але ви не можете редагувати конфіг VM, конфіг сховища або додати вузол. Помилка говорить «лише для читання». Люди звинувачують диски. Тим часом кластер просто не має кворуму.

Підтвердьте маунт pmxcfs і кворум

cr0x@server:~$ mount | grep /etc/pve
pve-cluster on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

cr0x@server:~$ pvecm status | egrep 'Quorate|Nodes|Expected votes|Total votes'
Nodes:            2
Expected votes:   3
Total votes:      2
Quorate:          No

Значення: маунт pmxcfs каже rw, але стан кластера не має кворуму; Proxmox все ще відмовляє у записах конфігів.

Рішення: відновіть кворум, повернувши вузли або виправивши мережу corosync. Зміни очікуваних голосів робіть лише якщо розумієте ризики split-brain.

Аварійно: встановити expected votes (користуватися з повагою)

cr0x@server:~$ pvecm expected 2

Значення: ви кажете corosync очікувати менше голосів, щоб залишкові вузли набули кворуму.

Рішення: застосовуйте лише коли впевнені, що пропажні вузли не повернуться і не створять розбіжні конфіги. Це важіль «повернути продакшн», а не щоденна зручність.

Жарт №2: Кворум — це корпоративне засідання, де нічого не затверджують, якщо недостатньо людей, і дивним чином це краще за хаос.

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

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

Команда побачила «Read-only file system», редагуючи конфіг VM. Звісно, вони звинуватили boot SSD. Хтось відкрив тікет на зміну диска. Тим часом вузол нормально обслуговував VM, і SMART був у нормі.

Старший адміністратор спробував створити файл у /tmp — і в ньому вийшло. Той самий тест у /etc/pve завершився невдачею. Ця деталь мала б одразу закрити дискусію, але припущення вже вкорінилося: «read-only означає диск».

Вони врешті виконали pvecm status і знайшли, що кластер втратив кворум після зміни мережі: трафік corosync ішов тим же bonded інтерфейсом, що й голосний backup VLAN, і multicast/UDP втрати пакети, спричиняючи флаттер членства. pmxcfs захистив стан кластера, відмовившись у записах. Саме те, для чого він і призначений.

Виправлення було нудним: винести corosync на окремий VLAN і перевірити MTU та втрати пакетів. Диск міняти не довелося. Найкраща лінія розбору по суті була проста: «Ми трактували проблему розподіленої системи як проблему диска». Це і є неправильне припущення в одній фразі.

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

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

Через місяці технічних робіт сталося невелике коливання живлення. Батарея кеша RAID була, але не здорова; вона голосувала попередження, які ніхто не моніторив. Контролер підтвердив записи, що ще не були надійно зафіксовані, і після перезавантаження коренева файлова система піднялася з проблемами журналу. ext4 виявив це і перемонтував корінь в ro під час завантаження.

Відновлення було брудним: rescue-boot, fsck, а потім дні переслідування тонких симптомів корупції на рівні VM. Не все було втрачене, але довіру було підірвано. Оптимізація заощадила мілісекунди і коштувала вихідних.

Зміни були не в тонкому налаштуванні продуктивності, а в управлінні: будь-яка зміна, що торкається порядку записів, вимагала явної моделі відновлення після втрати живлення та моніторингу стану батареї/модуля кешу. Швидкість — це добре. Швидкість із брехнею — шлях до кар’єрного розвитку, якого ви не просили.

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

Інший магазин тримав Proxmox на ZFS mirror, мав щотижневі scrub і робив одне дуже непривабливе: регулярно відпрацьовував відновлення. Не раз — регулярно. Резервні копії не були «галочкою», вони були частиною операційної рутіни.

Одного ранку вузол почав логувати NVMe media errors. ZFS повідомив, що пристрій став нестабільним, але пул залишився онлайн завдяки mirror. Команда не чекала катастрофи. Вони переміщали найактивніші VM з вузла, замінили NVMe і почали resilver.

Під час resilver в одному VM-диску з’явилася постійна помилка на конкретному блоці. Це — заголовок жахіття, якби не практика. Вони зупинили VM, відновили з бекапу минулої ночі і продовжили. Прості роботи обмежили час простою однієї робочого навантаження, і радіус ураження залишився малим.

Рятівний крок не був у магічній команді. Це була відпрацьована м’язова пам’ять: scrub, моніторинг, міграція, заміна, відновлення. Ніякої драми. Нудьга перемогла, бо нудьга була підготовлена.

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

1) «Не можу редагувати конфіг VM» → проблема pmxcfs/кворум → відновити кворум кластера

• Симптоми: записи не проходять лише в /etc/pve; VM продовжують працювати; перевірки дисків в нормі.
• Корінь: кластер не має кворуму або corosync нестабільний.
• Виправлення: pvecm status, відновіть підключення вузлів; в екстрених випадках змініть expected votes обдумано. Потім перевірте запис у /etc/pve.

2) Корінь перейшов у ro після I/O-помилок → вмираючий диск/кабель/HBA → виправляйте апаратний шлях спочатку

• Симптоми: blk_update_request, тайм-аути, ATA ресети, NVMe ресети; аборт журналу ext4.
• Корінь: нестабільний блоковий пристрій.
• Виправлення: SMART/NVMe логи; перепід’єднати/замінити кабель; оновити прошивку; замінити пристрій. Лише потім fsck/ремонт.

3) ZFS пул «призупинено» → повторні помилки пристрою → зупиніть записи, замініть, clear, scrub

• Симптоми: задачі зависають; логи ZFS показують suspended pool; zpool status показує UNAVAIL/FAULTED.
• Корінь: ZFS зустрів нездатну виправити I/O і призупинився, щоб зберегти цілісність.
• Виправлення: стабілізуйте апарат; замініть фейловий vdev; zpool clear; scrub. Відновіть уражені диски VM з бекапу, якщо є постійні помилки.

4) «Тільки для читання», але насправді диск заповнений → зростання логів/бекапів → звільніть місце, знайдіть джерело росту

• Симптоми: записи падають; df -h показує 100%; логи величезні.
• Корінь: файлова система заповнена або вичерпані іноди.
• Виправлення: видаліть великі файли (/var/log, старі ISO, старі ядра), налаштуйте ротацію логів, перемістіть резервні копії, і додайте пороги моніторингу.

5) Петля ремонту: fsck «виправляє», але ro повертається → продовжуються базові помилки → зупиніться і усуньте корінь

• Симптоми: після перезавантаження/ремонту, протягом кількох годин система знову remount ro.
• Корінь: відмовляюче апаратне забезпечення, погана пам’ять, флюктуючий контролер або проблеми з живленням.
• Виправлення: апаратна діагностика, memtest у вікні обслуговування, оновлення прошивок, перегляд ланцюга живлення (PSU/UPS).

6) Спроба форсувати rw в продакшні → більше корупції → прийміть простій і ремонтуйте правильно

• Симптоми: періодичне відновлення після mount -o remount,rw, а потім погіршення помилок.
• Корінь: лікування симптомів; ігнорування захисту цілісності.
• Виправлення: плановий простій, офлайн-ремонт, відновлення з бекапу, якщо потрібно. Ви не домовляєтесь з фізикою.

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

Контрольний список A: коли коренева файлова система хоста Proxmox лише для читання

1. Стабілізуйте: призупиніть важкі задачі. Якщо VM працюють — зупиніть бекапи/міграції. Уникайте лог-штормів.
2. Ідентифікуйте маунти: підтвердіть, який маунт ro (mount, findmnt).
3. Зберіть докази: dmesg -T, journalctl -k -b, збережіть копії поза хостом, якщо можливо.
4. Перевірте здоров’я сховища: smartctl або nvme smart-log; зафіксуйте ресети/тайм-аути.
5. Вирішіть:
   • Якщо апарат хворий: евакуюйте дані і замініть обладнання.
   • Якщо апарат чистий: плануйте офлайн fsck/xfs_repair.
6. Ремонт офлайн: завантажте rescue, запустіть інструмент ремонту файлової системи, перезавантажте.
7. Валідація: стежте за логами на повторення; прогоніть контрольоване навантаження; заплануйте подальші дії.

Контрольний список B: коли лише /etc/pve поводиться як лише для читання

1. Перевірте масштаб проблеми: тест запису в /tmp і /etc/pve.
2. Перевірте кворум: pvecm status.
3. Перевірте здоров’я corosync: втрата пакетів, VLAN, MTU, режим bonding, налаштування комутаторів.
4. Відновіть кворум: поверніть вузли, виправте мережу. Використовуйте expected votes лише як аварійний важіль.
5. Валідація: створіть/змініть некритичний конфіг у /etc/pve або торкніться файлу.

Контрольний список C: коли ZFS незадоволений (degraded/suspended/errors)

1. Отримайте статус: zpool status -v і зробіть знімок.
2. Зупиніть шкоду: призупиніть записи VM, якщо пул призупинений або кидає помилки.
3. Підтвердіть мапінг пристроїв: зіставте by-id з фізичними місцями; перевірте журнали HBA/бекплейна.
4. Замініть/відремонтуйте пристрій: перепід’єднайте, замініть, виконайте zpool replace при потребі.
5. Очистіть і прогоніть scrub: zpool clear, потім zpool scrub.
6. Обробіть постійні помилки: відновіть уражені диски VM з бекапу/репліки; не ігноруйте проблему.

Єдиний операційний принцип (вартий запам’ятати)

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

Одна цитата, бо це найближче, що у нашій сфері має вигляд священного писання:

«Hope is not a strategy.» — Gen. Gordon R. Sullivan

Поширені запитання

1) Чому Linux перемонтовує ext4 в режим лише для читання замість краху?

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

2) Чи можу я просто виконати mount -o remount,rw / і продовжувати роботу?

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

3) Якщо /etc/pve лише для читання, чи означає це, що мій диск зламаний?

Не обов’язково. pmxcfs може блокувати записи через втрату кворуму або стан кластера. Перевірте записи в іншому місці (наприклад, /tmp), потім виконайте pvecm status.

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

Якщо лише /etc/pve не дозволяє записи, а решта системи записувана — це зазвичай проблема кворуму/pmxcfs. Якщо root або /var — ro, зазвичай це файлова система/апарат. Підтвердіть за допомогою mount і pvecm status.

5) ZFS каже «permanent errors». Чи зможе scrub це виправити?

Ні. «Permanent errors» означає, що ZFS не зміг реконструювати дані з надлишку. Потрібно відновити уражений файл/том з резервної копії або репліки.

6) SMART диска в нормі, але ext4 все одно remount ro. Що ще може бути?

SMART може пропустити транзитні або шляхові помилки. Шукайте SATA/NVMe ресети, помилки контролера, погані кабелі/бекплейн, проблеми з живленням і (іноді) погану пам’ять.

7) Чи слід перезавантажувати негайно, коли бачу read-only?

Не автоматично. Спочатку зберіть логи (dmesg, journalctl) і перевірте масштаб проблеми. Перезавантаження може стерти цінні докази, а при відмові апаратури воно може перетворити хворий стан у мертвий.

8) Як запобігти цьому в майбутньому?

Ви не запобіжите всім відмовам. Ви зменшите сюрпризи та радіус ураження: моніторте SMART/NVMe помилки, стежте за dmesg на ресети, тримайте вільний простір, проганяйте scrub ZFS, тестуйте відновлення і ізолюйте мережу corosync.

9) Чи ext4 або ZFS «кращий» для уникнення read-only інцидентів?

Вони відмовляють по-різному. ext4 часто перемонтовує в ro при виявленні помилок; ZFS зазвичай продовжує роботу, поки не стикнеться з незаперечними проблемами, після чого стає суворим (призупиняє I/O) і дає відмінну діагностику. Вибирайте за вашою операційною зрілістю: ZFS винагороджує дисципліну; ext4 простіший, але менш самодокументований.

Наступні кроки, які вам справді слід виконати

Якщо ви зараз посеред інциденту:

1. Пройдіть швидкий план діагностики: ідентифікуйте маунт, прочитайте логи ядра, вирішіть «сховище проти файлової системи проти кворуму».
2. Якщо бачите I/O-помилки: вважайте апарат виною, поки не доведено протилежне. Збережіть SMART/NVMe логи і плануйте заміну.
3. Якщо це метадані ext4/XFS: заплануйте офлайн-вікно для ремонту. Не «remount і молитися».
4. Якщо це /etc/pve: відновіть кворум. Виправте мережу corosync. Не міняйте диски, щоб вирішити питання голосування.
5. Якщо це ZFS: інтерпретуйте zpool status -v буквально. Замініть пошкоджені пристрої, запустіть scrub і відновіть все з постійними помилками з бекапу/репліки.

Потім, після відновлення сервісу, зробіть нудну роботу: додайте моніторинг для I/O-помилок ядра і ресетів пристроїв, налаштуйте алерти на знос дисків/помилки медіа, встановіть пороги вільного простору для / і /var, і ставте corosync як контрольну площину, яку потрібно берегти. Продакшн не винагороджує героїзм. Він винагороджує системи, що відмовляють передбачувано і відновлюються швидко.