Проблеми резервного копіювання/відновлення Proxmox LXC: помилки tar, права доступу та нюанси файлових систем

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

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

1) Підтвердіть, на якій фазі стався збій: створення архіву, стиснення чи розпакування при відновленні

• Якщо файл архіву відсутній або дуже маленький — це проблема створення (помилки читання, права, питання зі снапшотом).
• Якщо архів є, але відновлення падає на початку — зазвичай це xattrs/ACL/мапування власників або те, що цільове сховище не може представити метадані.
• Якщо відновлення падає пізно — дивіться «No space left», виснаження інодів або таймаути на мережевому сховищі.

2) Визначте тип сховища на обох кінцях (rootfs джерела та ціль резервного копіювання)

Rootfs LXC на ZFS поводиться інакше, ніж rootfs на dir. Ціль резервного копіювання на NFS поводиться інакше, ніж ціль на ZFS.
«Це просто файл» — приємна брехня, яку ваше сховище покарає.

3) Перевірте, чи контейнер непровілейований і чи шлях backup/restore зберігає власників

Непровілейовані контейнери залежать від мапування UID/GID. Якщо ви відновлюєте на сховище, яке не в змозі зберегти ці ідентифікатори або xattrs, tar буде скаржитися, а Proxmox перерве операцію.

4) Відтворіть без стиснення і з детальним виводом tar

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

5) Лише потім ганяйте «баги tar»

Tar зазвичай — посланець. Вбивати його не виправить повідомлення.

Як Proxmox робить бекап LXC (і де тут tar)

Бекапи LXC у Proxmox зазвичай керуються vzdump. Для контейнерів стандартним «артефактом» є tar-архів кореневої файлової системи контейнера
плюс метадані (конфіг, точки монтування). Залежно від режиму Proxmox може:

• stop mode: зупинити контейнер, запакувати файлову систему tar консистентно, потім запустити знову.
• snapshot mode: якщо сховище підтримує снапшоти — зробити їх і читати tar із снапшота, поки контейнер працює.
• suspend mode: старіший компроміс; менш поширений і не дуже улюблений.

Головне: навіть якщо ваш rootfs на ZFS, кінцевий бекап часто залишається tar-потоком, якщо ви не обрали формат/сховище з нативною підтримкою снапшотів.
Цей tar-потік несе метадані: права, власників, часові мітки, вузли пристроїв, ACL та розширені атрибути (xattrs).
Якщо на джерелі є можливості, яких не може відобразити цільове сховище або місце відновлення, з’являться збої, що виглядають довільно.

Цікаві факти й історичний контекст (бо в цього всього є корені)

1. Tar старший за Linux на десятиліття. Він створювався для стрічок; поведінка «стрімінгу» — причина часткових архівів, коли щось перериває конвеєр.
2. GNU tar поступово отримував підтримку xattr/ACL. Старі дистрибутиви ставили ACL як опціональний «топінг»; сучасні контейнери сприймають їх як частину ідентичності.
3. Unprivileged LXC нормалізував зміщення UID. Конвенція «root всередині — 100000 зовні» не універсальна, але поширена.
4. Proxmox успадкував дизайн від OpenVZ інструментів. Назва vzdump — скам’янілість з тієї епохи; вона все ще виконує роботу.
5. ZFS снапшоти дешеві; відновлення не завжди. Снапшоти — метадані, а send/receive або розпакування tar — реальний I/O.
6. NFS має багато характерів. v3 vs v4, root_squash і кешування атрибутів можуть перетворити «permission denied» на театральну проблему продуктивності.
7. CIFS/SMB — не POSIX-файлова система. Воно може емулювати Unix-біти режиму, але xattr і вузли пристроїв — це переговори, а не гарантія.
8. Overlay-файлові системи змінили очікування. Контейнери навчились очікувати шарів copy-on-write; tar потребує стабільних інодів і шляхів.

Одна операційна істина, що добре старіє: якщо ви не можете відновити — у вас немає бекапу. Це не поетика, це бухгалтерія.

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

Режими відмов: помилки tar і що вони насправді означають

«tar: Cannot open: Permission denied»

Це рідко означає «tar не має дозволу». Зазвичай це процес бекапу Proxmox на хості, який намагається пройти шлях, до якого хост не може отримати доступ
через idmapped власність, bind-монти або rootfs, який не той, яким ви його вважаєте.
Типові тригери:

• Bind-монт у контейнері з директорії, яка має суворі права на хості.
• NFS-монт з root_squash, де root хоста стає nobody.
• Непровілейований контейнер, де деякі шляхи мають несподівану власність після ручного chown або rsync.

«tar: Cannot set xattr» / «Operation not supported»

Це невідповідність можливостей файлової системи. Ціль розпакування не підтримує простір імен xattr, який tar намагається відновити.
Класичні випадки:

• Відновлення на CIFS без потрібних Unix-розширень.
• Відновлення на NFS-експорт, який обрізає або по-іншому мапить xattr.
• Відновлення у файлову систему, змонтовану з вимкненими xattr/acl (так, люди ще так роблять).

«tar: Cannot change ownership to uid …»

Зазвичай одне з наступного:

• Ви відновлюєте в непровілейований rootfs на файловій системі, яка не любить великі UIDs/GIDs, або відновлення відбувається без правильного контексту мапування.
• Розпакування відбувається від імені користувача, який не може виконувати chown (наприклад, бекап виконується в обмеженому середовищі або через певні мережеві файлові системи).
• Бекап було зроблено з привілейованого контейнера і відновлюють у непровілейований (або навпаки) без коригування очікувань.

«Unexpected EOF in archive»

Tar — це потік. Якщо процес, що пише потік, помер, читач бачить EOF. Кореневі причини:

• Закінчення місця на цільовому сховищі посеред потоку.
• Мережевий глюк до NFS/CIFS, що спричинив помилку запису та розрив пайпа.
• OOM kill або таймаут у стадії стиснення (zstd/gzip).

«File changed as we read it»

Це трапляється, коли ви бекапите робочу файлову систему без бар’єра снапшота. Часті зміни можуть бути безпечними; інші призводять до пошкодженого стану додатку.
Якщо ви бачите це часто — перейдіть у режим снапшота для підтримуваного сховища або використовуйте stop mode для коректності.

Жарт #1: Бекапи як парашути — якщо ви чекаєте, щоб тестувати їх під час стрибка, ви обрали навчальний досвід.

Права доступу: привілейовані vs непровілейовані, idmaps і чому root не завжди root

Контейнери — це не ВМ. Вони поділяють ядро хоста. Proxmox LXC використовує простори імен користувачів Linux для непровілейованих контейнерів.
Це означає:

• Привілейований контейнер: root контейнера мапиться на root хоста (UID 0).
• Непровілейований контейнер: root контейнера мапиться на великий UID хоста (часто 100000). Власність файлів на диску відображає UID хоста, а не контейнера.

Чому це важливо для бекапу/відновлення:

• Tar зберігає числові UID/GID. Якщо ваш бекап містить зсовані UID хоста (наприклад, 100000+), відновлення має відтворити їх точно.
• Деякі файлові системи та експорти не зберігають великі UID коректно або маплять їх дивно.
• Bind-монти можуть створити змішаний світ власності: частина дерева зсована, частина — ні.

Bind-монти — тихий саботажник

Proxmox дозволяє точки монтування контейнера (mp0, mp1 тощо), які біндять шляхи хоста в контейнер.
Це класно, поки ви не робите бекап. Залежно від конфігурації ці шляхи можуть бути включені, виключені або поводитись по-різному під час tar.
Права хоста на джерельний шлях вирішують, що tar може прочитати.

Практична порада: якщо ви використовуєте bind-монти для даних додатку, розглядайте ці дані як окрему домену бекапу з власним методом (снапшот файлової системи, дамп бази даних тощо).
Спроба «просто включити це у vzdump» працює до першої проблеми. І зазвичай це трапляється у вихідні.

Нюанси файлових систем: ZFS, dir, NFS, CIFS, btrfs та інші

ZFS: снапшоти допомагають, але властивості dataset можуть підвісити вас

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

• Плутанина з mountpoint: відновлення у dataset, що не змонтований там, де Proxmox очікує.
• Права dataset: режим ACL і зберігання xattr налаштовані не так, як очікує контейнер.
• Refquota/refreservation: відновлення падає посередині з ENOSPC, хоча пул має місце.

Directory storage («dir»): просто, читабельно і дивовижно легко неправильно налаштувати

Звичайний каталог у файловій системі як сховище часто підходить. Ваш ворог тут не складність; це тонкі параметри монтажу:
noacl, nouser_xattr, або зберігання бекапів на чомусь на кшталт exFAT, бо «це просто диск для бекапів».
ExFAT не розуміє ваших потреб у Linux-метаданих. Воно розуміє лише жаль.

NFS: модель прав — це продукт

Якщо ваші бекапи лежать на NFS, потрібно розуміти:

• root_squash: root хоста стає анонімним; tar не може виконувати chown і може навіть не читати.
• idmapping: NFSv4 відображення за іменами може не збігатися з числовими ID, що призводить до «неправильної власності після відновлення».
• блокування та кешування атрибутів: можуть спричиняти дивні попередження «файл змінився» під час бекапу активних дерев.

CIFS/SMB: підходить для офісних документів, ризиковано для семантики rootfs контейнера

SMB підходить для зберігання архівів (tar.zst файл на шарі), якщо права налаштовані коректно.
Але відновлювати rootfs на CIFS — погана ідея, якщо ви не любите налагодження xattr опівночі.
Якщо змушені: переконайтеся в Unix-розширеннях, підтримці xattr і правильних опціях монтажу. Навіть тоді регулярно тестуйте відновлення.

btrfs: снапшоти є, але операційна зрілість різниться

btrfs може робити снапшоти і send/receive. У Proxmox підтримка btrfs є, але менш поширена, ніж ZFS у реальному житті.
Пастки зазвичай:

• Плутанина з макетом субволюмів, що призводить до «відновлення вдалося, але контейнер не стартує».
• Квоти qgroup, що викликають несподіваний ENOSPC навіть при видимому вільному місці.

Жарт #2: Tar не «ненавидить» вас. Він просто відмовляється брехати про характер вашої файлової системи.

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

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

Завдання 1: Визначити rootfs контейнера і бекенд сховища

cr0x@server:~$ pct config 101 | egrep '^(arch|cores|hostname|ostype|rootfs|unprivileged|mp[0-9]+)'
hostname: app-lxc-01
ostype: debian
arch: amd64
cores: 4
unprivileged: 1
rootfs: local-zfs:subvol-101-disk-0,size=16G
mp0: /srv/data,mp=/var/lib/app-data

Значення: Rootfs — це підволюм ZFS. Контейнер непровілейований. Є bind-монт (mp0) з /srv/data.

Рішення: Очікуйте зсування UID. Розглядайте mp0 окремо; це ймовірне джерело проблем з правами.

Завдання 2: Перевірити конфігурацію сховища для бекапів і його тип

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196529976        42108740       144544184   21.43%
local-zfs         zfspool active        2147483648      126903296      2020580352    5.91%
backup-nfs        nfs     active       1953514588      110154852      1843369736    5.64%

Значення: Бекапи ймовірно йдуть на backup-nfs. NFS означає, що root_squash і поведінка xattr — підозрювані.

Рішення: Підтвердіть опції експорту NFS перш ніж звинувачувати Proxmox або tar.

Завдання 3: Проінспектувати журнал проваленого завдання для першої реальної помилки

cr0x@server:~$ journalctl -u pvedaemon -S -2h | egrep -i 'vzdump|tar:|error|exit'
Dec 26 11:01:02 server pvedaemon[2218]: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
Dec 26 11:01:45 server pvedaemon[2218]: tar: ./var/lib/app-data/cache: Cannot open: Permission denied
Dec 26 11:01:45 server pvedaemon[2218]: tar: Exiting with failure status due to previous errors
Dec 26 11:01:45 server pvedaemon[2218]: ERROR: Backup of VM 101 failed - command 'tar ...' failed: exit code 2

Значення: Шлях, що падає, знаходиться у bind-монті (/var/lib/app-data), який мапиться на /srv/data на хості.

Рішення: Перевірте права на хості на /srv/data та root_squash NFS, якщо він там.

Завдання 4: Перевірити, чи джерело bind-монту знаходиться на NFS/CIFS і з якими опціями

cr0x@server:~$ findmnt -T /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET   SOURCE                  FSTYPE OPTIONS
/srv/data nfs01:/export/appdata  nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.10

Значення: Джерело bind-монту — NFS. Якщо експорту встановлено root_squash, root хоста не зможе прочитати все.

Рішення: Перевірте права експорту. Розгляньте виключення bind-монтів з vzdump і бекапати їх за допомогою нативних снапшотів сховища.

Завдання 5: Підтвердити симптоми root_squash, спробувавши прочитати як root

cr0x@server:~$ sudo -n ls -ld /srv/data /srv/data/cache
drwxr-x--- 10 100000 100000 4096 Dec 26 10:40 /srv/data
drwx------  2 100123 100123 4096 Dec 26 10:45 /srv/data/cache

Значення: Власність зсована (100000+), що відповідає непровілейованому контейнерному розміщенню даних на NFS. Root на хості може й читати, але політика NFS може перезаписати це.

Рішення: Якщо root не може пройти — виправте експорт NFS (no_root_squash для виділеної мережі/хоста резервного копіювання) або змініть підхід до бекапу.

Завдання 6: Перезапустити бекап без стиснення, щоб швидко викрити реальну помилку

cr0x@server:~$ sudo vzdump 101 --storage backup-nfs --mode snapshot --compress none --stdout 0
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress none --stdout 0
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating Proxmox Backup archive 'vzdump-lxc-101-2025_12_26-11_07_10.tar'
ERROR: tar: ./var/lib/app-data/cache: Cannot open: Permission denied
ERROR: tar: Exiting with failure status due to previous errors
INFO: removing partial backup file 'backup-nfs:backup/vzdump-lxc-101-2025_12_26-11_07_10.tar'
ERROR: Backup of VM 101 failed - command 'tar' failed: exit code 2

Значення: Та сама помилка, але лог чистіший. Це не стиснення.

Рішення: Припиніть перемикання компресорів. Виправте права або виключіть цей монтування з бекапу.

Завдання 7: Перевірити точки монтування контейнера і чи вони включені в бекап

cr0x@server:~$ grep -E '^(mp[0-9]+|lxc.mount.entry)' /etc/pve/lxc/101.conf
mp0: /srv/data,mp=/var/lib/app-data

Значення: Цей монтувальник визначено через конфіг Proxmox. За замовчуванням vzdump включатиме його, якщо не вказано інше.

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

Завдання 8: Перевірити можливість зберігання xattr/ACL на цільовій файловій системі бекапу

cr0x@server:~$ findmnt -T /mnt/pve/backup-nfs -o TARGET,FSTYPE,OPTIONS
TARGET            FSTYPE OPTIONS
/mnt/pve/backup-nfs nfs4   rw,relatime,vers=4.1,sec=sys,hard,timeo=600,retrans=2

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

Рішення: Розділіть «може записати файл архіву» і «може відновити метадані». Тестуйте відновлення на цільовому сховищі.

Завдання 9: Перевірити архів без відновлення (виявити пошкодження)

cr0x@server:~$ sudo tar -tf /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst | head
./
./etc/
./etc/hostname
./etc/hosts
./var/
./var/lib/
./var/lib/app-data/
./var/lib/app-data/cache/

Значення: Ви можете перелічити вміст архіву. Якщо це падає з «Unexpected EOF», архів пошкоджений/неповний.

Рішення: Якщо архів пошкоджений: розслідуйте переривання мережі/сховища, не права контейнера.

Завдання 10: Підтвердити вільне місце та іноди на цілі відновлення

cr0x@server:~$ df -h /rpool/data /rpool/data/subvol-101-disk-0
Filesystem      Size  Used Avail Use% Mounted on
rpool           1.8T  1.2T  600G  67% /
rpool/data      600G  410G  190G  69% /rpool/data

cr0x@server:~$ df -i /rpool/data
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
rpool/data            0      0        0     - /rpool/data

Значення: На ZFS відлік інодів інший; відсутність інодів у виводі тут нормальна. Зосередьтесь на квотах dataset і доступному місці.

Рішення: Якщо відновлюєте на ext4/xfs — виснаження інодів реальне; на ZFS перевіряйте властивості квот dataset замість стандартного df.

Завдання 11: Перевірити ZFS refquota, що може фальсифікувати «немає місця»

cr0x@server:~$ zfs get -o name,property,value -H refquota,quota,used,avail rpool/data/subvol-101-disk-0
rpool/data/subvol-101-disk-0	refquota	16G
rpool/data/subvol-101-disk-0	quota	none
rpool/data/subvol-101-disk-0	used	15.8G
rpool/data/subvol-101-disk-0	avail	200M

Значення: Dataset обмежено refquota. Навіть якщо пул має терабайти вільного місця, цей субволюм — обмежений.

Рішення: Збільшіть розмір у Proxmox або підніміть refquota перед відновленням, або відновіть на більший dataset і змініть розмір диска контейнера після.

Завдання 12: Перевірити мапування для непровілейованих контейнерів (на стороні хоста)

cr0x@server:~$ sudo grep -E '^(root|lxc)' /etc/subuid /etc/subgid
/etc/subuid:root:100000:65536
/etc/subgid:root:100000:65536

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

Рішення: Забезпечте однакові subuid/subgid діапазони по всіх вузлах кластера, особливо якщо ви мігруєте/відновлюєте на різних хостах.

Завдання 13: Запустити відновлення у тестовий CTID, щоб перевірити без змін у виробі

cr0x@server:~$ sudo pct restore 999 /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst --storage local-zfs
restoring 'vzdump-lxc-101-2025_12_26-10_00_00.tar.zst' to VM 999 ...
extracting archive '/mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst'
tar: ./var/lib/app-data/cache: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
ERROR: Restore failed - command 'zstd -q -d -c ... | tar ...' failed: exit code 2

Значення: Відновлення падає при розпакуванні вмісту bind-монту. Це доводить, що проблема вмісту архіву і шляху доступу, а не в runtime контейнера.

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

Завдання 14: Підтвердити, чи точки монтування всередині архіву (і чи вони повинні там бути)

cr0x@server:~$ sudo tar -tf /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst | egrep '^./var/lib/app-data' | head
./var/lib/app-data/
./var/lib/app-data/cache/
./var/lib/app-data/cache/tmp.db

Значення: Дані з bind-монту включені в архів.

Рішення: Якщо ці дані живуть на спільному сховищі (NFS) і мають власний життєвий цикл — виключіть їх і бекапайте на рівні того сховища. Інакше виправте доступ хоста для читання.

Завдання 15: Виявити втручання AppArmor/LSM (рідко, але болісно)

cr0x@server:~$ dmesg -T | egrep -i 'apparmor|denied|audit' | tail
[Thu Dec 26 11:12:22 2025] audit: type=1400 audit(1766747542.123:410): apparmor="DENIED" operation="open" profile="lxc-pct" name="/srv/data/cache/tmp.db" pid=31222 comm="tar" requested_mask="r" denied_mask="r" fsuid=0 ouid=100123

Значення: Ядро заборонило читання tar, а не класичні Unix-права. Це проблема політики.

Рішення: Налаштуйте профіль LXC/AppArmor або перемістіть шлях бекапу/відновлення в дозволені політикою локації. Не вимикайте AppArmor як перший крок.

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

Інцидент через хибне припущення: «Bind-монт — частина контейнера, отже він бекапиться»

Середній SaaS працював на Proxmox з акуратно влаштованим парком LXC. Команди додатків використовували bind-монти для всього стану:
/srv/postgres в DB контейнер, /srv/uploads у веб-контейнер і т.д.
Інфраструктурна команда припустила, що оскільки Proxmox показує монтування в конфігу контейнера, воно «включено в бекап».

Зboй почався тихо. Бекапи «успішно» йшли тижнями, бо шляхи bind-монтів були читабельні більшість часу.
Потім змінили експорти NFS: повсюдно ввели root squashing у рамках перевірки безпеки.
Тієї ночі vzdump впав по кількох контейнерах з Permission denied. Планувальник усе ще показував «завдання виконано», і ніхто не помітив.

Через два місяці контейнер було пошкоджено під час оновлення. Відновлення «спрацювало», контейнер завантажився, а додаток стартував — порожній.
Архів містив rootfs, але критичні дані з bind-монту ніколи не були послідовно зафіксовані. Деякі відновлення падали відразу; інші відновлювали застарілий набір файлів.
Це був найгірший тип інциденту: начебто успішне відновлення з неправильним станом.

Рішення було не героїчне. Вони припинили вважати bind-монти частиною області бекапу контейнера.
Бази даних отримали логічні дампи плюс снапшоти сховища. Завантаження — реплікацію об’єктного сховища.
vzdump лишився для rootfs і конфігів, але більше не претендував на всю правду.

Оптимізація, що з backfire: «Почнемо бекап на SMB, бо дешевше і вже є»

Інша організація мала Windows NAS і рішення: консолідувати бекапи там.
Хтось вказав Proxmox зберігати бекапи на SMB-шарі. Це працювало для кількох контейнерів, тож розгорнули ширше.
Витрати виглядали приємно. Таблиця в Excel посміхалась.

Перша тріщина з’явилась під час тестів відновлення. Малі контейнери відновлювались добре; великі — відмовляли випадково з помилками tar:
Cannot set xattr, Operation not supported, іноді Unexpected EOF.
Вони «виправляли» EOF збільшенням таймаутів і відновлювали до зеленого.
Але це не виправлення; це гра з додатковими кроками.

Глибша проблема: семантика SMB і опції монтування різнились по вузлах. Деякі вузли монтували з різним мапуванням uid/gid.
Деякі зберігали xattr, деякі — ні. Той самий бекап відновлювався по-різному залежно від вузла.
Відновлення стало лотереєю з кращим логуванням.

Вони зрештою використали SMB лише як «тупий» репозиторій архівів, створених в іншому місці, але не як файлову систему для відновлення rootfs.
Для відновлень вони розпаковували на ZFS-сховище на хості Proxmox. Проблема зникла. Витрати трохи зросли. Сон покращився.

Нудна, але правильна практика, що врятувала день: рутинні відновлення і «тестовий» діапазон ID

Регульоване середовище мало Proxmox на ZFS і строгий change control. Їхній бекап-процес мав «потаємну» вимогу:
щотижня відновлювати два випадкові контейнери в тестовий діапазон ID (900–999) в ізольованій мережі.
Нікому не подобалось витрачати на це час, але це була політика.

Якось тиждень тест провалився на контейнері, що нещодавно перевели в непровілейований.
Помилки tar з’явилися навколо власності та xattr. Це не стало кризою, бо виявили це в тесті, а не під час інциденту.

Причина була банальна: на одному вузлі після відновлення відсутні або різні діапазони у /etc/subuid.
Бекапи були в порядку. Відновлення залежали від хоста. Виправили мапування, повторили тест і рухались далі.
Справжній виграш: вони знайшли проблему до того, як вона спричинила великий інцидент.

Це нудна правда: тестові відновлення не гламурні, але вони попереджають стресові, публічні відмови.
Геройство не потрібно, коли є рутина.

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

1) Симптом: Бекап падає з «Permission denied» на шляху під /var/lib/...

Корінна причина: Цей шлях — bind-монт з хоста; права хоста (або NFS root_squash) блокують tar.

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

2) Симптом: Відновлення падає з «Cannot set xattr» або «Operation not supported»

Корінна причина: Цільова файловa система/експорт не підтримує xattr/ACL з архіву.

Виправлення: Відновлюйте на POSIX-нативне сховище (ZFS, ext4, xfs). Уникайте відновлення rootfs на CIFS; перевіряйте підтримку xattr на NFS.

3) Симптом: Відновлення падає з «Cannot change ownership» або багато числових UID в логах

Корінна причина: Зсування UID непровілейованого контейнера; середовище відновлення не може представити або застосувати ці власності.

Виправлення: Забезпечте однакові subuid/subgid по вузлах. Відновлюйте на сховище, що підтримує chown і великі UID. Не змішуйте привілейовані/непривілейовані без плану.

4) Симптом: «Unexpected EOF» при переліку або відновленні архіву

Корінна причина: Неповний архів (запис перервано, закінчилось місце, мережевий обрив, процес вбитий).

Виправлення: Перевірте місце на диску, стабільність NFS та системні логи на OOM. Віддавайте перевагу локальному швидкому сховищу для тимчасової стадії бекапу, якщо мережа ненадійна.

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

Корінна причина: Відновлення на файловій системі, яка ремапить власність (деякі NFSv4), або втрата ACL/xattr.

Виправлення: Відновлюйте на ZFS/ext4/xfs локально, потім мігруйте. Або налаштуйте NFS idmapping консистентно і тестуйте.

6) Симптом: Відновлення падає з ENOSPC, хоч пул має місце

Корінна причина: ZFS refquota/quota або btrfs qgroups обмежують dataset/subvolume.

Виправлення: Збільшіть розміри dataset/квоти перед відновленням. Не довіряйте «pool free» як остаточній відповіді.

7) Симптом: Попередження «File changed as we read it», іноді з подальшим пошкодженням додатку

Корінна причина: Бекап зроблено без коректного снапшоту для навантаженого робочого навантаження.

Виправлення: Використовуйте snapshot mode на сховищі з підтримкою снапшотів або stop mode для консистентності. Для баз даних робіть логічні бекапи.

8) Симптом: Відновлення працює на одному вузлі, але падає на іншому

Корінна причина: Невідповідна конфігурація хоста: subuid/subgid, опції монтування, версії плагінів сховища або NFS монтажі.

Виправлення: Стандартизуйте конфігури вузлів, ставте їх як «cattle», і запускайте тестові відновлення на різних вузлах.

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

Покроково: від проваленого логу до корінної причини менш ніж за 30 хвилин

1. Отримайте перший шлях, що впав з journalctl або логу vzdump. Ігноруйте останній рядок помилки; зазвичай він загальний.
2. Спряжіть шлях з конфігом контейнера: чи під mpX це bind-монт? Якщо так — тримайте його як зовнішнє сховище.
3. Підтвердіть типи сховищ (rootfs сховище, сховище бекапів, цільове сховище відновлення) за допомогою pvesm status та findmnt.
4. Перевірте права на хості для точного файлу/каталогу, що впав. Якщо це NFS/CIFS — дивіться політику експорту/шару, а не лише біти режиму.
5. Перезапустіть з відключеним стисненням, щоб отримати детермінований вивід і уникнути шуму CPU.
6. Перевірте цілісність архіву через tar -t перш ніж повторно намагатись відновити.
7. Для непровілейованих контейнерів перевірте консистентність subuid/subgid і уникайте відновлення на не-POSIX файлові системи.
8. Виправте причину, потім зробіть тестове відновлення в новий CTID перед тим, як торкатися production ID.

Операційний чекліст: зробіть відновлення LXC нудним

• Тримайте rootfs контейнера на ZFS або на адекватній локальній POSIX файловій системі.
• Використовуйте снапшотні бекапи, коли підтримується; використовуйте stop backups для сервісів, де важлива коректність.
• Не сподівайтеся на bind-монти для «автоматичного включення» в бекапи. Визначайте зоною відповідальності явно.
• Стандартизуйте /etc/subuid та /etc/subgid на всіх вузлах кластера.
• Архіви зберігайте де завгодно, але відновлюйте на сховище, що зберігає метадані.
• Проводьте рутинні тестові відновлення. Міняйте вузли, що виконують їх.
• Трактуйте помилки бекапу як тривоги, а не як «хтось помітить».

Керівництво з рішень: оберіть потрібний обсяг бекапу

• Rootfs контейнера + конфіг: vzdump підходить. Відновлення швидкі й передбачувані на ZFS/локальному сховищі.
• Станові дані в bind-монтах: бекапте за допомогою системи, що ними володіє (ZFS снапшоти, снапшоти NFS сервера, дампи баз даних).
• Бази даних: віддавайте перевагу логічним бекапам і реплікації перед файловою консистентністю через tar.

FAQ

1) Чому Proxmox використовує tar для бекапів LXC замість тільки снапшотів?

Портативність. Tar-архів можна зберігати будь-де і відновлювати на різні бекенди. Снапшоти залежать від конкретного сховища; tar — це найнижчий спільний знаменник.

2) Чи означає «exit code 2» від tar завжди фатальну помилку бекапу?

У цьому контексті трактуйте як фатальну. Tar використовує код 2 для «фатальних помилок». Proxmox зазвичай позначить бекап як провалений і може видалити частковий результат.

3) Чи можна ігнорувати попередження «file changed as we read it»?

Для зайнятого апсерверу іноді — так. Для баз даних або всього, що транзакційне — ні. Щоб мати консистентні відновлення, використовуйте snapshot mode або stop mode плюс ап-коректні бекапи.

4) Чому непровілейовані контейнери ускладнюють відновлення?

Тому що власність на диску зсуванням (великі UID/GID). Процес відновлення має відтворити ці числові ID і метадані точно. Деякі бекенди цього не роблять.

5) Мої бекапи зберігаються на NFS. Це погано?

Не обов’язково. Зберігання архівів на NFS — поширена практика. Ризики зростають, якщо самі дані контейнера лежать на NFS через bind-монти або якщо ви намагаєтесь відновити rootfs на NFS.

6) Чому відновлення на CIFS іноді падає з помилками xattr/ACL?

CIFS не є POSIX-нативним. Підтримка Linux xattr, ACL і вузлів пристроїв залежить від можливостей сервера та опцій монтажу. Контейнери очікують Linux-семантику.

7) Який найбезпечніший робочий процес відновлення?

Відновіть на новий CTID на локальний ZFS (або ext4/xfs), перевірте завантаження і функціональні тести додатку, потім переключіть трафік і деактивуйте пошкоджений контейнер.
Не відновлюйте на місці, якщо не готові збільшити простій.

8) Чому відновлення падає з «no space left», хоча ZFS пул має місце?

Бо dataset може бути обмежений через refquota або подібне. Відновлення пише в dataset, а не у весь пул.
Перевіряйте avail dataset, а не вільне місце пулу.

9) Як обходитись з bind-монтами в бекапах правильно?

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

10) Чи варто переключити все на привілейовані контейнери, щоб уникнути проблем з UID мапуванням?

Ні. Це обмін зручності на більшу площу ураження при компрометації. Краще виправляти консистентність мапування і сумісність сховища. Привілейовані контейнери — не безкоштовний обід.

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

Коли резервне копіювання/відновлення Proxmox LXC падає з помилками tar, виграшний крок — припинити читати вивід tar, як загадку.
Зазвичай він каже одну з трьох істин: хост не може прочитати шлях, ціль не може представити метадані, або сховище посеред потоку закінчилось чимось.

Зробіть це далі:

1. Сьогодні запустіть тестове відновлення для одного репрезентативного контейнера. Якщо не можете відновити по запиту — трактуйте це як інцидент.
2. Перерахуйте bind-монти по контейнерах і вирішіть, чи кожен з них в області відновлення контейнера.
3. Стандартизуйте subuid/subgid та опції монтування сховищ на всіх вузлах Proxmox. Дрейф — це як «працює на моєму вузлі» стається.
4. Віддавайте перевагу відновленню на ZFS/локальне POSIX-сховище. Використовуйте мережеві шари для зберігання архівів, а не як файлову систему для rootfs.
5. Перетворіть тестові відновлення на рутину. Нудьга — це мета.