Proxmox Backup «Немає вільного простору на пристрої»: чому він падає, хоча місця здається достатньо

Що насправді означає «Немає вільного простору на пристрої»

У Linux за повідомленням стоїть код помилки ENOSPC. Це не означає «наклалося фізичне сховище».
Це означає: «ядро відхилило запис, бо файловій системі, блочному пристрою або квоті/ліміту це не дозволено».
Відмова може статися з кількох причин:

• Закінчилися байти у цільовій файловій системі або пулі.
• Закінчилися inode (поширено на ext4/xfs при мільйонах дрібних файлів; PBS може створювати багато чанків).
• Закінчився простір для метаданих (спеціальні пристрої ZFS, btree-вузли, журнали або просто фрагментація та «слоп»).
• Резервовані блоки (файлові системи ext зберігають резерв; ZFS потребує headroom).
• Квоти / project-квоти / quota dataset досягнуті ще до того, як «вся диск» здається повним.
• Подвійне копіювання при записі (CoW) (снапшоти перетворюють видалення на «ще використовується», а перезапис — на нові алокації).
• Інша файлова система, ніж ви думаєте (tmp-директорія на невеликому розділі; кореневий диск контейнера замість змонтованого сховища).

Proxmox додає свої особливості. Резервні копії використовують тимчасові файли, снапшоти, і (якщо ви застосовуєте Proxmox Backup Server) chunk-store, який поводиться
радше як контент-адресне сховище, а не папка tar-файлів. Тому у вас може бути 2 ТБ «вільно», і водночас неможливо виділити наступні 128 КБ.

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

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

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

1) Визначте, де саме не вдалось записати (датастор PBS? NFS? локальна папка?)

• Подивіться в лог завдання Proxmox: чи згадується шлях під /var/lib/vz, змонтована шара, чи datastore PBS?
• На PBS помилки часто з’являються в переглядачі завдань і journalctl з контекстом «chunk» або «datastore».

2) Перевірте байти й inode на цільовій файловій системі

• df -h (байти)
• df -i (inode)

3) Якщо задіяно ZFS — перевірте стан пулу і ємність по-справжньому

• zpool list та zpool get autoexpand,ashift
• zfs list -o space для dataset, що фактично містить датастор/бекапи
• Якщо пул >80–85% заповнений, вважайте його «фактично повним» для записових навантажень.

4) Якщо PBS: запустіть prune і garbage collection, потім перевірте знову

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

5) Перевірте тимчасові директорії та точки монтування

• Резервні копії можуть писати тимчасові файли в /var/tmp, /tmp або в налаштований tmpdir.
• Якщо /tmp — невеликий tmpfs, великі jobs vzdump можуть падати, навіть якщо цільове сховище має терабайти вільного місця.

6) Якщо це віддалена ціль (NFS/SMB): перевірте квоти та експорти на сервері

• «Клієнт показує вільне місце» — це не юридично обов’язковий контракт.
• Квоти, снапшоти або політики резервування на NAS можуть повертати ENOSPC, хоча шара виглядає просторою.

Реальні режими відмов (і чому ваше «вільне місце» брешуть)

Режим відмов A: вичерпання inode (так, у 2025 році)

Inode — це «слоти файлів» файлової системи. Як тільки вони закінчуються, ви не можете створити нові файли — навіть при гігабайтах вільних.
PBS-датастори можуть створювати багато файлів (чанки, індекси, метадані). Якщо розмістити датастор на ext4 з поганим співвідношенням inode,
або якщо система працює роками з великою кількістю змін, тиск на inode стає реальним.

Ознака: df -h виглядає добре, а df -i — на 100%. Бекапи падають при викликах «create» або «write».

Практична порада: для PBS віддавайте перевагу ZFS (із здоровим headroom) або XFS з плануванням. ext4 підходить — поки не перестає підходити, а це часто трапляється у п’ятницю ввечері.

Режим відмов B: поведінка ZFS при «повному» пулі (все стає погано до 100%)

ZFS — copy-on-write. Це чудово для цілісності та снапшотів і іноді жахливо для «потрібно додати багато даних зараз».
Коли пул сильно використовують, алокації вимагають більше оновлень метаданих, більше пошуків, і виникає фрагментація. Продуктивність падає як зі скелі.
Врешті-решт ви досягнете точки, де пул не може надійно виділити блоки потрібного розміру. Можливі ENOSPC або зависання транзакційних груп.

Специфічна пастка: люди ставляться до ZFS як до ext4 — використовують його до 95% і очікують нормальної поведінки. Так не буде.
Якщо вам потрібна надійність і передбачуваність бекапів — тримайте ZFS-пули комфортно нижче зони ризику. Мій стандарт: починаю нервувати при 80%, діяти при 85%.

Режим відмов C: квоти/резервації dataset (пул в порядку; ваш dataset — ні)

Може бути пул ZFS із 10 ТБ вільними, а dataset з quota=1T, який повний. Те ж саме з XFS project-квотами.
Proxmox і PBS часто ставлять люди, які «прибирали» і встановили квоти «щоб бекапи не зжували все».
Потім вони забули. Квота пам’ятає.

Також резервації працюють навпаки: dataset може резервувати простір і голодувати інші dataset. Якщо ваш цільовий датастор раптом не може писати — перевірте і квоту, і резервацію.

Режим відмов D: снапшоти тримають місце в заручниках

Снапшоти — це не друга копія. Це обіцянка: «старі блоки лишаються доступними». Коли ви видаляєте або перезаписуєте дані після створення снапшота,
старі блоки залишаються зацікавленими. Ваше «вільне місце» не повертається. Це видно в ZFS як USEDDS/USEDREFRESERV/USEDSNAP.

У PBS prune видаляє посилання на снапшоти в каталозі; garbage collection видаляє чанки, які більше не посилаються.
Якщо ви лише робите prune, але ніколи не запускаєте GC, використання диску практично не впаде. Якщо GC не може запуститися через дефіцит місця, ви потрапляєте у глухий кут: потрібне місце, щоб звільнити місце.

Режим відмов E: тимчасовий простір, tmpfs і «не там, куди ви думаєте»

Proxmox VE бекапи (vzdump) часто пишуть на цільове сховище, але можуть також проміжно сторувати дані, створювати логи й використовувати тимчасовий простір.
Якщо ваш /tmp — малий tmpfs (поширено), або /var знаходиться на невеликому кореневому диску, бекап може впасти задовго до заповнення цільового диску.

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

Режим відмов F: тонке провізіювання та overcommit (LVM-thin, ZVOLs, SAN)

Тонке провізіювання робить усе схожим на просторе, поки не стало ні. LVM-thin пули можуть досягти 100% використання даних або метаданих.
SAN/NAS бекенди можуть overcommit-ити, і перший запис, який потребує реальні блоки, падає. Деякі середовища повертають ENOSPC; інші — I/O помилки.

Небезпека: у вас може бути «вільне місце» всередині VM-диска, тоді як тонкий пул, що його хостить, закінчився. Бекапи, які роблять снапшот і читають диск, не обов’язково впадуть; бекапи, що пишуть у той же перенавантажений пул — впадуть.

Режим відмов G: віддалене сховище брешуть (NFS/SMB особливості, снапшоти сервера, квоти)

NFS клієнти кешують атрибути. SMB іноді «бреше» опущенням. А сервер може застосовувати квоти або політики резервування, невидимі клієнту.
Якщо ваш вузол Proxmox каже «No space left on device», а UI NAS показує «2 ТБ вільно», повірте в помилку і розслідуйте обмеження на сервері.

Режим відмов H: накладні витрати PBS chunk store і «місце, яке ви не можете використати»

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

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

Режим відмов I: коренева файлова система повна (і вона тягне ваш job за собою)

Навіть якщо бекапи пишуть на окремий монтуємий розділ, системі все одно потрібне місце для логів, журналу, тимчасових файлів, lock-файлів і іноді метаданих снапшотів.
Якщо /var/log або системний журнал заповнять кореневу файлову систему, ви побачите каскад пов’язаних відмов.
Бекапи — просто перше, що ви помітите.

Режим відмов J: «видалено, але файл відкритий»

Класична пастка Unix: процес тримає файл відкритим; ви його видаляєте; простір не звільняється, поки процес не закриє файл.
Тож ви чистите, бачите «вільне місце не змінилося», і наступний бекап все ще падає.
PBS і компоненти Proxmox зазвичай поводяться коректно, але логери, дебагери або сторонні агенти можуть тримати великі файли відкритими.

Одна операційна думка для запам’ятовування, перефразована з ідеї James Hamilton (AWS): «Вимірюйте все, що можете, і автоматизуйте решту».
Якщо у вас немає алертів на використання inode, ємність ZFS та метадані тонких пулів — ви обираєте неприємні сюрпризи.

Цікаві факти та коротка історія (те, що пояснює сьогоднішні дивності)

1. ENOSPC старше за більшість ваших серверів. Код помилки походить з раннього Unix; «пристрій» означав підґрунтя файлової системи, а не лише диски.
2. Inode були спроєктовані, коли диски були малі. Ранні Unix-файлові системи попередньо виділяли таблиці inode; вичерпання inode до байтів — це спадщина, яка не хоче вмирати.
3. ext-файлові системи за замовчуванням резервують блоки. Традиційно ~5% резерву для root, щоб система залишалась працездатною і зменшувалась фрагментація; це дивує на дата-томах.
4. ZFS потребує headroom для CoW. Висока зайнятість підвищує фрагментацію і метадані; «100% повний» не є практичною ціллю.
5. Тонке провізіювання популяризувало «виглядало вільним». Платформи віртуалізації зробили overcommit нормою; адміністратори з болем дізналися, що «виділено» і «використано» — не те саме.
6. PBS робить ставку на дедуплікацію, а не на файли. Його chunk store міняє читабельні файли бекапів на цілісність і ефективність; прибирання вимагає prune + GC, а не просто видалення файлів.
7. Garbage collection часто потребує тимчасового простору. Багатьом системам треба трохи вільного простору, щоб переструктурувати метадані і безпечно звільнити блоки; доведення до нуля може заблокувати прибирання.
8. Кешування атрибутів NFS може вводити в оману моніторинг. Погляд клієнта на вільне місце і застосування правил сервером можуть розходитися, особливо з квотами й снапшотами.
9. «Вільне» файлової системи не завжди придатне до використання. Між резервованими блоками, розмірами блоків і метаданими ви можете бути «вільними», але не здатними виділити потрібні екстенти.

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

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

Завдання 1: Знайти шлях, де сталося падіння, у логах Proxmox

cr0x@server:~$ journalctl -u pvedaemon -u pvescheduler --since "2 hours ago" | tail -n 30
Dec 26 01:12:19 pve01 pvescheduler[1883]: starting new backup job: vzdump 101 102 --storage pbs01 --mode snapshot
Dec 26 01:13:44 pve01 vzdump[22109]: ERROR: Backup of VM 101 failed - write error: No space left on device
Dec 26 01:13:44 pve01 vzdump[22109]: INFO: Failed at: /var/tmp/vzdumptmp12345
Dec 26 01:13:44 pve01 pvedaemon[1765]: VM 101 qmp command failed - backup aborted

Значення: Відмова сталася при записі в /var/tmp, а не на ціль бекапу. Це перший розвилок у розслідуванні.

Рішення: Перевірте кореневу файлову систему і тимчасовий простір, а не ємність PBS.

Завдання 2: Перевірити використання байтів на всіх змонтованих файлових системах

cr0x@server:~$ df -hT
Filesystem                        Type   Size  Used Avail Use% Mounted on
/dev/mapper/pve-root              ext4    96G   95G   0G 100% /
tmpfs                             tmpfs  32G  1.2G   31G   4% /run
rpool/ROOT/pve-1                  zfs     96G   95G   0G 100% /
rpool/data                        zfs    1.8T  1.1T  700G  62% /rpool/data
192.0.2.10:/exports/pbsstore      nfs4    20T   15T  5.0T  75% /mnt/pbsstore

Значення: Root повний. Також зауважте, що приклад із змішаними монтами показує, як люди плутаються; зосередьтеся на монтажі, пов’язаному з шляхом відмови.

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

Завдання 3: Перевірити вичерпання inode (тихий вбивця)

cr0x@server:~$ df -i
Filesystem                        Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/pve-root             6553600 6553201     399  100% /
192.0.2.10:/exports/pbsstore    134217728 210345 134007383    1% /mnt/pbsstore

Значення: Коренева файлова система фактично без inode. Це може ламати встановлення пакетів, ротацію логів і створення тимчасових файлів для бекапів.

Рішення: Знайдіть каталоги з великою кількістю inode (часто /var/log, /var/lib або сховище контейнерів) і очистіть або розширте їх.

Завдання 4: Швидко знайти шляхи з великою кількістю inode

cr0x@server:~$ sudo du --inodes -x -d 2 /var | sort -n | tail -n 10
1200    /var/cache
8421    /var/tmp
15300   /var/log
1204500 /var/lib
1209800 /var

Значення: /var/lib споживає inode як хобі. На Proxmox це може бути образи контейнерів, кеші або зайві каталоги.

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

Завдання 5: Підтвердити, де vzdump стафує тимчасові дані

cr0x@server:~$ grep -R "tmpdir" -n /etc/vzdump.conf /etc/pve/* 2>/dev/null
/etc/vzdump.conf:2:tmpdir: /var/tmp

Значення: Тимчасова директорія бекапу розташована на корені. Це ок поки корінь не малий або не зайнятий.

Рішення: Перемістіть tmpdir на окремий розділ з місцем (і відслідковуйте його).

Завдання 6: Перевірити, чи /tmp — tmpfs і який його розмір

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,SIZE,USED,AVAIL /tmp
tmpfs tmpfs 2.0G 1.9G 100M

Значення: /tmp — tmpfs 2 ГБ і практично повний. Будь-який інструмент, що використовує /tmp для стадінгу, швидко впаде.

Рішення: Очистіть вміст tmpfs, збільште розмір tmpfs або налаштуйте Proxmox на інше тимчасове місце.

Завдання 7: Якщо задіяно PBS — перевірити використання датастору з боку PBS

cr0x@server:~$ proxmox-backup-manager datastore list
┌───────────┬───────────────┬───────────────┬─────────────┐
│ Name      │ Path          │ Comment       │ Maintenance │
╞═══════════╪═══════════════╪═══════════════╪═════════════╡
│ store1    │ /mnt/store1   │ main datastore│ false       │
└───────────┴───────────────┴───────────────┴─────────────┘

Значення: Датастор знаходиться в /mnt/store1. Тепер ви знаєте, які обмеження файлової системи мають значення.

Рішення: Перевірте df і inode на цьому монті; потім статус prune/GC PBS.

Завдання 8: Перевірити байти й inode датастору на хості PBS

cr0x@server:~$ df -hT /mnt/store1
Filesystem     Type  Size  Used Avail Use% Mounted on
rpool/store1   zfs   8.0T  7.4T  600G  93% /mnt/store1

Значення: 93% на ZFS — це «ви живете ризиковано». GC і нові записи можуть провалюватись.

Рішення: Звільніть місце негайно (prune+GC, видаліть старі групи, додайте ємність). Потім впровадьте політику headroom.

Завдання 9: Розподіл місця ZFS по пулу і dataset (що насправді споживає місце)

cr0x@server:~$ zfs list -o name,used,avail,refer,usedsnap,usedds,usedrefreserv,logicalused -r rpool/store1
NAME           USED  AVAIL  REFER  USEDSNAP  USEDDS  USEDREFRESERV  LOGICALUSED
rpool/store1  7.40T   600G  7.10T     900G   6.50T            0B       12.8T

Значення: Снапшоти тримають 900 ГБ. Це може бути нормою або неконтрольованою політикою збереження. Logical used показує ефект дедуплікації/компресії.

Рішення: Перегляньте політику збереження та чи очищуються снапшоти (PBS prune) і чи звільняються чанки (GC). Розгляньте додавання ємності перед тонкою налаштуванням.

Завдання 10: Перевірити ємність пулу ZFS і сигнали фрагментації

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
rpool  8.00T  7.45T   550G         -    61%    93%  1.00x  ONLINE

Значення: 93% заповнення і 61% фрагментація. Записи будуть болісними; алокація метаданих може зазнати невдачі ще до 100%.

Рішення: Знизьте завантаження пулу. Не намагайтесь «оптимізувати» це програмно; звільніть місце або додайте vdev.

Завдання 11: Перевірити квоти й резервації dataset (невидима стіна)

cr0x@server:~$ zfs get -o name,property,value -H quota,refquota,reservation,refreservation rpool/store1
rpool/store1	quota	7.5T
rpool/store1	refquota	none
rpool/store1	reservation	none
rpool/store1	refreservation	none

Значення: Квота dataset — 7.5T. Ви на 7.4T використання, отже по суті місця немає, навіть якщо пул має більше місця в іншому місці.

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

Завдання 12: Симуляція prune PBS (подивитися, що було б видалено)

cr0x@server:~$ proxmox-backup-manager prune-job run nightly --dry-run
Starting prune on datastore 'store1'
Group 'vm/101' - would keep 14 backups, remove 6 backups
Group 'vm/102' - would keep 14 backups, remove 4 backups
Prune dry-run completed successfully

Значення: Політика prune видалить деякі снапшоти. Добре. Але сам prune не завжди звільняє місце, поки не з’явиться GC.

Рішення: Запустіть prune у безпечному вікні, потім GC і підтвердіть зниження використання місця.

Завдання 13: Запустити garbage collection PBS і прочитати результат

cr0x@server:~$ proxmox-backup-manager datastore gc store1
Starting garbage collection on datastore 'store1'
Removed 18432 unreferenced chunks (68.4 GiB)
GC finished in 00:12:09

Значення: Ви звільнили ≈68 GiB. Якщо звільнилось майже нічого, або політика збереження занадто агресивна, або більшість чанків ще посилаються.

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

Завдання 14: Виявити видалені, але ще відкриті файли, що їдять місце

cr0x@server:~$ sudo lsof +L1 | head -n 10
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
rsyslogd  912 syslog  7w   REG  252,0 2147483648     0  53123 /var/log/syslog.1 (deleted)

Значення: 2 ГБ лог видалено, але досі відкрито rsyslogd. Простір не повернеться, поки процес не закриє файл.

Рішення: Обережно перезапустіть процес, що тримає файл (або налаштуйте ротацію логів). Потім перевірте df знову.

Завдання 15: Для LVM-thin — перевірити data і metadata thin pool

cr0x@server:~$ sudo lvs -a -o +seg_monitor,metadata_percent,data_percent vg0
  LV              VG  Attr       LSize   Pool       Origin Data%  Meta%  Monitor
  thinpool        vg0 twi-aotz--  3.00t                      92.31  99.87 monitored
  thinpool_tmeta  vg0 ewi-aotz--  8.00g
  thinpool_tdata  vg0 lwi-aotz--  3.00t

Значення: Метадані thin pool на 99.87%. Це стан «на межі вибуху». Записи можуть впасти, навіть якщо Data% не 100%.

Рішення: Розширте метадані thin pool негайно і припиніть overcommit без моніторингу.

Завдання 16: Перевірити, що ваш монтаж цільового сховища дійсно змонтований

cr0x@server:~$ findmnt /mnt/pbsstore
TARGET        SOURCE                      FSTYPE OPTIONS
/mnt/pbsstore 192.0.2.10:/exports/pbsstore nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Значення: Воно змонтовано. Якби ні — Proxmox міг би писати в порожню директорію на корені і непомітно її заповнювати.

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

Три міні-історії з корпоративного життя (анонімізовані, правдоподібні і болісно звичні)

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

Середня компанія запускала Proxmox VE з бекапами на NFS-шару на поважному NAS. Команда операцій дивилась на дашборд NAS:
терабайти вільні, все в зеленому — ніхто не турбувався. Потім у понеділок вранці: кілька VM-бекапів провалились з «No space left on device».
Люди негайно звинуватили Proxmox — бо так зазвичай роблять, коли втомлені.

Неправильне припущення було тонким: вони вважали, що вигляд клієнта про вільне місце співпадає з політикою сервера.
NAS мав ввімкнені по-шарні квоти — встановлені місяці тому під час реорганізації сховища. Фізичної ємності вистачало,
але ліміт по шарі було вичерпано. NFS правильно повернув ENOSPC.

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

Кінцеве рішення було нудним: підвищити квоту шару, зменшити ретеншн снапшотів і узгодити політику збереження Proxmox з тим, що робив NAS.
Постмортем включив нове правило: будь-яка цільове сховище повинно мати задокументовані квоти і снапшоти в тому самому місці, де описано бекап-завдання.

Операційний висновок: коли бекенд каже «ні», повірте йому. Потім перевірте квоти і снапшоти на сервері, а не тільки df на клієнті.

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

Інша організація вирішила «оптимізувати» місце PBS, запустивши датастор майже до краю. Вони отримали вигоди дедуплікації, і все виглядало добре на папері.
Мета була 95% використання — бо «ми платимо за кожен терабайт». Фінанси аплодували. Інженер зі сховищ заперечував, але його перемогли.

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

Корінь проблеми був не лише в «заповненому диску». Це була поведінка ZFS при високій фрагментації і низькому headroom.
GC потребував створення й оновлення метаданих, і ці алокації стали ненадійними. Система була технічно онлайн, але функціонально крихкою.

Виправлення — додати ємність і ввести жорстку внутрішню політику: алерти при 75%, дія при 80–85% і заборона «піджати до 95% на тиждень».
Той «тиждень» завжди розтягується на квартал.

Операційний висновок: цілі використання — це цілі надійності. Якщо ви бюджетуєте 95% заповнення — ви бюджетуєте невідомі режими відмов, які неможливо безпечно протестувати.

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

Третя команда запускала Proxmox з PBS на ZFS. Їх практика була надміру нудною: щотижневий огляд ємності, алерти на завантаження пулу ZFS і inode,
і типовий runbook: prune, GC, підтвердити місце, тільки тоді розширювати ретеншн. Вони також мали невеликий «аварійний» буфер квоти dataset,
який можна було тимчасово підвищити під час інцидентів.

Однієї ночі розробник випадково записав логи в змонтований каталог поруч із шляхом бекапу з контейнера з неправильно налаштованим bind-mount.
PBS почав накопичувати небажані файли поруч із шляхом датастору (не всередині). Бекап почав падати, і перша сторінка розбудила on-call.

On-call не гадала. Вони слідували runbook: перевірили точки монтування, df -i, використання dataset ZFS. Знайшли винну папку,
зупинили контейнер, прибрали і запустили PBS GC. Бекапи відновилися до ранкової зміни.

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

Операційний висновок: «нудне» — це характеристика. Якщо ваша система бекапу вимагає креативу о 2:00, вона не спроєктована — її імпровізують.

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

1) Симптом: df показує 30% вільно; бекапи падають миттєво

Корінь: вичерпання inode на цільовій файловій системі (або на root/temp).

Виправлення: Запустіть df -i. Якщо inode заповнені — видаліть inode-важкі файли, проведіть ротацію логів або перемістіть датастор PBS на файлову систему, розраховану на багато файлів.

2) Симптом: PBS prune виконався, але місце не повернулося

Корінь: prune видалив посилання на снапшоти, але чанки залишаються до запуску garbage collection; або більшість чанків все ще посилаються іншими бекапами.

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

3) Симптом: ZFS пул на 92% і все стає повільним, потім ENOSPC

Корінь: тиск на алокацію і метадані ZFS при високому використанні; фрагментація і CoW-накладні витрати.

Виправлення: Зменште використання пулу (видаліть дані, prune+GC, додайте vdevs). Встановіть алерти значно нижче «повного».

4) Симптом: лог завдання Proxmox згадує /var/tmp або /tmp

Корінь: тимчасова директорія на малому розділі або tmpfs заповнений.

Виправлення: Перемістіть tmpdir в /etc/vzdump.conf на більший монтаж; очистіть tmp; збільште tmpfs за потреби.

5) Симптом: пул має місце, dataset каже «ні»

Корінь: ZFS dataset quota/refquota досягнуті; або XFS project-квота.

Виправлення: Перевірте квоти і резервації. Підніміть/видаліть квоту або виділіть окремий dataset, розмірений під цілі утримання.

6) Симптом: «Видалив старі бекапи», але використання диску не змінилось

Корінь: снапшоти (ZFS або NAS) тримають блоки; або видалені, але відкриті файли; або чанки PBS все ще посилаються.

Виправлення: Перевірте використання снапшотів, запустіть prune+GC і перевірте lsof +L1 для відкритих видалених файлів.

7) Симптом: бекапи на NFS падають, але UI NAS показує місце

Корінь: серверні квоти на шарі, політика резервування або ретеншн снапшотів; іноді експорту налаштовано неправильно.

Виправлення: Перевірте квоти/снапшоти на NAS, а не лише df на клієнті. Підтвердьте монтаж через findmnt.

8) Симптом: LVM-thin, що бекапить диски VM, показує «вільно», але бекапи падають при записі в локальне сховище

Корінь: метадані thin pool заповнені (часто до заповнення даних).

Виправлення: Моніторьте data_percent і metadata_percent; збільшіть метадані; зменшіть кількість снапшотів; припиніть overcommit без алертів.

9) Симптом: коренева файлова система знову заповнюється після «очищення»

Корінь: бекапи пишуть у не змонтовану директорію (монтаж упав), або логи ростуть, або runaway тимчасові файли.

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

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

Покроково: відновлення після «No space left on device» сьогодні

1. Зупиніть кровотечу. Призупиніть розклади бекапів, щоб не перетворити проблему з місцем у проблему з навантаженням.
2. Знайдіть шлях відмови. З логів завдання визначте, чи відмова на корені/тимчасі, цільовому сховищі або датасторі.
3. Перевірте байти і inode. Запустіть df -hT і df -i на проблемному монті і на /.
4. Якщо корінь повний: очистіть великі логи, старі ядра, кеші; виправте ротацію логів; подумайте про переміщення тимчасових директорій.
5. Якщо inode вичерпані: видаліть inode-важкі сміття; знайдіть порушників за допомогою du --inodes; розгляньте перенесення датастору на іншу ФС.
6. Якщо ZFS пул >85%: негайно звільніть місце. Сприймайте це як інцидент. Запустіть prune+GC (PBS) і/або видаліть старі dataset-и.
7. Якщо PBS: виконайте prune, потім garbage collection, потім перевірте використання місця.
8. Якщо віддалене сховище: перевірте серверні квоти та снапшоти; підтвердіть, що експорт не обмежений.
9. Повторно запустіть один бекап вручну. Переконайтесь у виправленні на одному VM перед відновленням розкладів.

Щоб запобігти: операційні запобіжники, які працюють

• SLO ємності: Визначте цільове максимальне використання (ZFS: 80–85% для write-heavy PBS). Зробіть це політикою, а не порадою.
• Алерт на inode: моніторинг використання inode — необхідність для сховищ бекапу з великою кількістю файлів.
• Алерт на метадані thin pool: стежте за metadata_percent. 80% — це сторінка, а не просто email.
• Заплануйте prune+GC і зробіть їх прозорими: якщо GC не виконується успішно кілька днів, ризик накопичується.
• Перевірка монтажів: переконайтесь, що цілі бекапів змонтовані перед запуском jobs; фейл-фест, якщо ні.
• Розділяйте системні та бекапні шляхи: не дозволяйте бекапам залежати від малого кореневого розділу для тимчасових записів.

Чого уникати (бо здається розумно, поки не зламається)

• Запускати ZFS-пули майже повними, бо «дедуплікація нас врятує». Може врятувати — поки ні, і тоді це не лінійний збій.
• Встановлювати квоти замість моніторингу. Квоти корисні, але не замінюють спостереження.
• Видаляти випадкові файли в шляхах датастору PBS. Використовуйте інструменти PBS; датастор — не смітник.
• Припускати, що «df клієнта» відображає істину NFS сервера.

FAQ

1) Чому Proxmox каже «No space left on device», коли df показує вільне місце?

Бо невдалий запис може потрапляти в іншу файлову систему (наприклад /var/tmp), або у вас закінчилися inode, або досягнуто квоти,
або ZFS не може надійно алокувати через високе завантаження пулу.

2) Це баг Proxmox?

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

3) Для PBS, чому видалення старих бекапів не звільняє місце негайно?

PBS — chunk-based. Видалення бекапів (prune) знімає посилання; простір звільняється, коли garbage collection видаляє непосилувані чанки.
Якщо більшість чанків все ще посилаються іншими бекапами, місце не зменшиться суттєво.

4) Скільки вільного місця тримати на ZFS-пулі для PBS?

Тримайте значний headroom. Для надійності — намагайтесь залишатись нижче ≈80–85% використання. Вище цього очікуйте ненадійної роботи GC і записів.
Точне число залежить від навантаження і конфігурації vdev, але «95% нормально» — це фантазія.

5) Чи може вичерпання inode статися на ZFS?

ZFS не має фіксованої таблиці inode як ext4; все ж можна вичерпати інші метадані. Тому «df -i на 100%» — це здебільшого проблема ext-серії.
На ZFS слід більше фокусуватись на ємності пулу/dataset і поведінці метаданих.

6) У чому різниця між PBS prune і garbage collection?

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

7) Чому бекапи падають, коли NAS каже, що місця є?

Квоти і снапшоти. NAS може застосовувати шард-лвл квоту або резервувати місце. Снапшоти можуть тримати видалені дані «використаними».
NFS/SMB клієнти також кешують атрибути; сервер — джерело істини.

8) Як дізнатись, чи Proxmox пише в не змонтовану директорію?

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

9) Чи може тонке провізіювання спричинити ENOSPC під час бекапів, навіть якщо ціль віддалена?

Так — якщо запис іде в локальне сховище (тимчасові файли, логи) на тонко-пулі, або якщо тонкий пул також хостить датастор.
Також вичерпання метаданих thin pool може зламати записи в несподіваних місцях.

10) Чи варто просто додати більший диск і забути?

Часто так — ємність дешевша за час простоя. Але не зупиняйтесь лише на цьому: додайте моніторинг для конкретного обмеження, яке стало причиною (inode, headroom ZFS,
квоти, metadata thin pool) або ви повернетесь сюди з більшим диском і тією самою несподіванкою.

Висновок: наступні дії, які варто виконати

«No space left on device» — це категорія діагнозу, а не вимір. Виправлення майже ніколи не зводиться до «видаліть випадковий файл і пощастить».
Знайдіть, де саме не вдалось записати, потім перевірте обмеження, яке там застосовується: байти, inode, квоти, headroom ZFS, metadata тонких пулів або політика на сервері.

Виконайте наступні кроки у порядку:

1. За логами визначте точний шлях і хост відмови (PVE вузол проти PBS сервера).
2. Запустіть df -hT і df -i на цій файловій системі й на /.
3. Якщо задіяно ZFS — сприймайте >85% використання як інцидент і зменшіть завантаження.
4. Якщо задіяно PBS — запустіть prune, потім GC; підтвердіть звільнене місце за допомогою zfs list -o space або df.
5. Додайте моніторинг для обмеження, яке зламалося, з порогами, що вимагають дії до обриву.

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