Ви запланували резервні копії, побачили кілька успішних запусків і відклали це в розділ «вирішено».
Потім тест відновлення (або гірше — реальний інцидент) показав, що резервні копії падали вже кілька днів з повідомленнями про
chunks, місце, блокування або «unexpected EOF». Це еквівалент того, коли в будівлі пищить детектор диму, а ніхто не помічає.
Proxmox Backup Server (PBS) — це якісна інженерія, але це все ж система з власною логікою: дедуплікація чанків, індекси, снапшоти,
garbage collection і datastore, який суворо дотримується фізичних обмежень. Коли резервні копії падають, зазвичай маємо одну з
чотирьох причин: недостатньо місця, відсутність інодів, некоректна поведінка сховища або невідповідність метаданих/індексу. Трюк — швидко визначити,
що саме і діяти, не посиливши проблему.
Як насправді виглядають відмови PBS (і чому це заплутує)
Повідомлення PBS часто містять слова «chunks», «indexes», «catalog», «snapshot», «datastore» або «verification».
Якщо ви звикли до бекапів у стилі копіювання файлів, це здається зайво абстрактним. У PBS потік бекапу розрізається на
чанки (змінного розміру), хешується і дедуплікується. Метадані (індекси) зіставляють образ VM/CT із цими чанками. Для відновлення
потрібні й дані, й метадані.
Отже, відмови можуть з’являтися щонайменше на п’яти рівнях:
- Транспорт/автентифікація: PVE не може автентифікуватися на PBS або TLS ламається.
- Репозиторій/датастор: шлях не записуваний, датастор заблоковано, неправильні дозволи.
- Ємність: байти, іноди або обмеження «зарезервованого простору» зупиняють запис посеред потоку.
- Цілісність сховища: базовий диск повертає I/O помилки або файловий менеджер починає «брехати».
- Невідповідність індексу/чанку: відсутній chunk, пошкоджений індекс, помилки верифікації.
Ваша задача як відповідальної особи — спершу знайти найжорсткіше обмеження. Не ганяйтеся за текстом помилки;
шукайте вузьке місце, яке робить ту помилку неминучою.
Швидкий план діагностики (перевірити 1/2/3)
Якщо у вас є десять хвилин до наступної сварки на нараді, зробіть це в порядку. План оптимізований під «що ламається найчастіше»
і «що можна підтвердити найшвидше», а не під елегантність.
1) Перевірка реальності ємності: байти, іноди та стан пулу
- На PBS: перевірте вільне місце (
df -h) і іноди (df -i) на монті датастору. - Якщо ZFS: перевірте
zpool list,zpool statusі використання dataset (zfs list). - Шукайте стан «80–90% заповнення». На CoW системах саме там продуктивність і фрагментація стають проблемою.
2) Швидко ідентифікуйте невдалу задачу та клас помилки
- На PVE: читайте лог задач у UI, але підтвердіть через
journalctlдля контексту й часових міток. - На PBS: читайте
journalctl -u proxmox-backup. Та сама помилка може виглядати ясніше на стороні сервера. - Визначте: це простір, дозволи/блокування, I/O чи цілісність chunk/index?
3) Припиніть шкоду: призупиніть задачі, захистіть те, що ще добре
- Якщо датастор майже повний: зупиніть задачі бекапу, заплануйте prune/GC усвідомлено і не запускайте «верифікацію всього» прямо зараз.
- Якщо пул деградований або видає checksum помилки: зупиніть записи, виправте апаратну частину, а потім верифікуйте.
- Якщо це плутанина з блокуваннями/дозволами: очищуйте застарілі блокування обережно (не видаляйте випадкові файли), а потім запустіть одну задачу.
Одна операційна істина: коли не вистачає місця, все виглядає як корупція. Коли є корупція, все виглядає як проблема простору.
Ваша задача — відокремити одне від іншого.
Цікаві факти та контекст (що пояснює дивні явища)
- Дедупліковані бекапи — не «менші файли». PBS зберігає дані як чанки, на які посилаються індекси. Використання місця залежить від повторного використання чанків, а не від розміру файлу.
- Chunking визначається за вмістом. Як і в класичних системах дедуплікації, PBS розбиває дані на основі rolling hash, що допомагає дедуплікації навіть при зміщенні блоків.
- «Verification» — це важлива функція. Багато стеків бекапу сприймають перевірку цілісності як опцію і рідко її запускають. PBS очікує, що ви верифікуєте.
- Garbage collection окремо від prune. Prune видаляє посилання на снапшоти; GC звільнює чанки, на які більше нема посилань. Люди часто забувають про другий крок.
- CoW-файлові системи не люблять бути на 95%. ZFS і btrfs потребують вільного простору для метаданих і алокацій; «df показує 5% вільного» — це не заспокійливо.
- Вичерпання інодів ще існує. Можна мати терабайти вільного місця і при цьому не вміти записувати файли, якщо файловій системі бракує інодів (особливо при великій кількості маленьких chunk-файлів).
- Бекапи навантажують інші I/O-шляхи, ніж продакшн. Послідовні читання з дисків VM плюс випадкові записи в датастор можуть виявити баги контролера/прошивки, які звичайні навантаження не показують.
- Безшумна корупція — реальна загроза. Сучасні системи бекапу припускають bit rot; контрольні суми і верифікація існують тому, що диски іноді «брешуть».
- Більшість проблем «PBS повільний» — це питання розмітки сховища. Неправильний ashift, малий recordsize або один HDD, який намагається поводитися як масив, зроблять PBS підозрілим.
Практичні завдання: команди, виводи, рішення
Це реальні завдання, які ви можете виконати сьогодні. Кожне включає: команду, що типово означає вивід, і рішення, яке ви приймаєте.
Запускайте команди на потрібному хості (PVE vs PBS). Не використовуйте руйнівні опції, поки не класифікуєте тип відмови.
Завдання 1: Підтвердити шлях монтування датастору і вільне місце (PBS)
cr0x@pbs:~$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 917G 812G 59G 94% /
tmpfs tmpfs 32G 0 32G 0% /dev/shm
Значення: 94% використання — небезпечна зона для записів бекапу й внутрішніх операцій файлової системи.
Рішення: зупинити або перерозподілити задачі, виконати prune/GC і звільнити місце перед повторним запуском великих бекапів.
Завдання 2: Перевірити використання інодів (PBS)
cr0x@pbs:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 61054976 60980012 74964 100% /
Значення: Іноди вичерпано. Записи не вдаються навіть при наявності байтів.
Рішення: виконати prune старих снапшотів, запустити GC і розглянути міграцію датастору на файлову систему/датасет з більшою кількістю інодів. Також перегляньте макет chunk/index та політику збереження.
Завдання 3: Визначити, який датастор налаштовано (PBS)
cr0x@pbs:~$ proxmox-backup-manager datastore list
┌───────────┬───────────────┬────────────┬───────────┐
│ Name │ Path │ PruneOpts │ Comment │
╞═══════════╪═══════════════╪════════════╪═══════════╡
│ mainstore │ /mnt/datastore│ keep-daily │ primary │
└───────────┴───────────────┴────────────┴───────────┘
Значення: Тепер ви знаєте шлях для перевірки через df, ls та інструменти файлової системи.
Рішення: зосередьте діагностику на правильному монті, а не на припущенні «/ виглядає повним».
Завдання 4: Перевірити стан пулу ZFS (PBS, якщо застосовно)
cr0x@pbs:~$ zpool status
pool: tank
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.
scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 19 03:12:10 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
sdb ONLINE 0 0 2
sdc ONLINE 0 0 1
sdd ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/pbs@somefile
Значення: існують checksum-помилки. Це не «баг PBS»; це подія цілісності сховища.
Рішення: призупиніть інтенсивні записи, виправте апаратуру, запустіть scrub знову, потім виконайте верифікацію PBS і сплануйте відновлення уражених снапшотів.
Завдання 5: Знайти помилку бекапу в логах PBS (PBS)
cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | tail -n 30
Dec 26 01:12:01 pbs proxmox-backup[2211]: upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pbs proxmox-backup[2211]: failed to finalize backup: unable to write index
Dec 26 01:12:01 pbs proxmox-backup[2211]: job failed: datastore "mainstore" is full
Значення: явний ENOSPC і невдача запису індексу. Чанки могли записатися, але метадані не вдалося зафіналізувати.
Рішення: спочатку звільнити простір, потім повторити. Також заплануйте prune/GC, щоб не отримати те саме наступного тижня.
Завдання 6: Перевірити контекст помилки на боці PVE (PVE)
cr0x@pve1:~$ journalctl --since "today" | grep -E "vzdump|proxmox-backup-client" | tail -n 20
Dec 26 01:11:58 pve1 vzdump[18277]: INFO: starting new backup job: vzdump 101 --mode snapshot --storage pbs-main --notes-template '{{guestname}}'
Dec 26 01:12:01 pve1 vzdump[18277]: ERROR: Backup of VM 101 failed - upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pve1 vzdump[18277]: INFO: Failed at 2025-12-26 01:12:01
Значення: той самий ENOSPC з’являється й тут. Не треба шукати мережевих примар.
Рішення: не запускати нові бекапи, поки не буде очищено простір у датасторі.
Завдання 7: Переконатися, що монтування не «бреше» (PBS, часто з NFS/iSCSI)
cr0x@pbs:~$ mount | grep /mnt/datastore
192.0.2.50:/export/pbs on /mnt/datastore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)
Значення: Датастор знаходиться на NFS. Це може працювати, але саме там народжуються історії про «відсутні чанки».
Рішення: якщо бачите корупцію чанків або переривчасті I/O, серйозно розгляньте перенесення PBS-датасторів на локальні диски або стек зі скрізною перевіркою контрольних сум.
Завдання 8: Перевірити на помилки I/O файлової системи (PBS)
cr0x@pbs:~$ dmesg -T | tail -n 20
[Thu Dec 26 01:10:44 2025] blk_update_request: I/O error, dev sda, sector 194512345 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 01:10:44 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 01:10:44 2025] EXT4-fs (sda2): Remounting filesystem read-only
Значення: Диск або контролер спричинив remount у read-only. PBS почне давати дивні помилки після цього.
Рішення: зупиніть задачі бекапу, виправте апарат, виконати fsck за потреби і лише потім намагайтеся робити нові бекапи. Вважайте, що останні бекапи неповні, поки їх не верифіковано.
Завдання 9: Перевірити статус і використання датастору (PBS)
cr0x@pbs:~$ proxmox-backup-manager datastore status mainstore
┌──────────────┬──────────────────────────────┐
│ Key │ Value │
╞══════════════╪══════════════════════════════╡
│ name │ mainstore │
│ path │ /mnt/datastore │
│ total │ 8.00 TiB │
│ used │ 7.62 TiB │
│ avail │ 0.38 TiB │
│ read-only │ false │
└──────────────┴──────────────────────────────┘
Значення: Лишилося 0.38 TiB. Це може швидко зникнути при великих повних бекапах або через ріст метаданих/індексів.
Рішення: посилити політику збереження, додати ємність або розподілити навантаження між датасторами. Не спирайтеся лише на «dedup врятує нас».
Завдання 10: Запустити вибіркову верифікацію (PBS)
cr0x@pbs:~$ proxmox-backup-manager verify start mainstore --ns vm --group vm/101
starting verification of datastore 'mainstore'
verifying group 'vm/101'
OK: verified snapshot 'vm/101/2025-12-25T01:10:02Z'
FAILED: snapshot 'vm/101/2025-12-26T01:10:02Z' - missing chunk "3f2c...d91a"
TASK OK: verify datastore mainstore
Значення: Один снапшот має відсутній chunk. Це або втрата на рівні сховища, перерваний запис або невідповідність індексу/чанку.
Рішення: збережіть стан датастору (не «чистіть» випадкові файли), перевірте здоров’я сховища і сплануйте повторний запуск бекапу після вирішення проблем з місцем/стабільністю.
Завдання 11: Симуляція prune перед видаленням (PBS)
cr0x@pbs:~$ proxmox-backup-manager prune list mainstore --ns vm --group vm/101 --dry-run
found 14 snapshots
would keep: 7
would remove: 7
remove vm/101/2025-12-01T01:10:02Z
remove vm/101/2025-12-02T01:10:02Z
remove vm/101/2025-12-03T01:10:02Z
Значення: Ви бачите, що політика видалить, не виконуючи фактичної операції.
Рішення: якщо місця критично, виконайте prune, потім GC. Якщо є юридичні/комплаєнс вимоги, зупиніться і погодьте політику зі стейкхолдерами.
Завдання 12: Запустити garbage collection (PBS)
cr0x@pbs:~$ proxmox-backup-manager garbage-collection start mainstore
starting garbage collection on datastore 'mainstore'
found 18234 unreferenced chunks
removed 18190 chunks, reclaimed 412.7 GiB
TASK OK: garbage collection
Значення: Місце звільнено. Це крок, про який люди забувають після prune.
Рішення: перевірте вільний простір; лише потім відновлюйте розклади бекапів.
Завдання 13: Перевірити тиск кількості файлів у датасторі (PBS)
cr0x@pbs:~$ find /mnt/datastore/.chunks -type f | wc -l
58492312
Значення: Десятки мільйонів файлів можуть навантажувати таблиці інодів, пошук по директоріях і навіть резервне копіювання самого сервера резервних копій.
Рішення: якщо у вас ext4 з вичерпанням інодів або проблемами продуктивності, сплануйте міграцію датастору (кращий коефіцієнт інодів або дизайн ZFS dataset) і перегляньте політику збереження.
Завдання 14: Підтвердити підключення і автентифікацію репозиторію (PVE)
cr0x@pve1:~$ proxmox-backup-client login pbs01 --repository backup@pbs@pbs01:mainstore
Password for "backup@pbs@pbs01":
Login succeeded.
Значення: Автентифікація і мережа працюють. Якщо задачі все ще падають, ймовірніше справа в ємності або цілісності, а не в облікових даних.
Рішення: не міняйте паролі у паніці — поверніться до діагностики датастору.
Завдання 15: Перевірити симптоми застарілих блокувань (PBS)
cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | grep -i lock | tail -n 10
Dec 26 00:59:03 pbs proxmox-backup[2144]: unable to acquire lock on snapshot: resource busy
Dec 26 00:59:03 pbs proxmox-backup[2144]: backup failed: datastore is locked by another task
Значення: Інша задача (backup, verify, GC, prune) утримує блокування або попередня задача впала і лишила стан.
Рішення: перевірте запущені задачі в UI і на хості; не видаляйте lock-файли навмання. Якщо задача зависла, спочатку вирішіть проблему I/O.
Завдання 16: Підтвердити синхронізацію часу (PVE і PBS)
cr0x@pbs:~$ timedatectl
Local time: Fri 2025-12-26 01:20:11 UTC
Universal time: Fri 2025-12-26 01:20:11 UTC
RTC time: Fri 2025-12-26 01:20:11
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Значення: Час синхронізовано. Це важливіше, ніж здається: прострочені сертифікати, «снапшоти з майбутнього» і дивні розклади можуть виглядати як проблеми зі сховищем.
Рішення: якщо годинники неправильні, виправте NTP, а потім повторіть невдалі операції.
Помилки chunk: що вони означають і що робити
Помилки чанків проявляються як «missing chunk», «checksum mismatch», «unable to decode chunk» або помилки фіналізації індексу.
Розглядайте це як спектр: від нешкідливо неповних снапшотів (задача впала до коміту) до реальної корупції сховища.
Відсутній chunk
Типовий симптом: verify повідомляє про missing chunks; відновлення падає для конкретного снапшоту.
Поширені корені проблеми:
- Перерваний запис бекапу (ENOSPC посеред потоку, збій сервера, файлову систему перемонтовано RO).
- Невідповідність базового сховища (NFS глюки, RAID-контролер, який «бреше» кешем, ненадійний диск).
- Ручне чищення («я видалив старі файли chunk, щоб звільнити місце». Так не робіть.)
Що робити:
- Підтвердьте, що файловий диск здоровий: перевірте
dmesg, SMART, логи RAID, ZFS scrubs. - Перевірте, чи постраждав тільки найновіший снапшот. Якщо так і це збігається з ENOSPC або крашом — перезапустіть бекап після вирішення ємності.
- Якщо missing chunks в декількох снапшотах за різний час — вважайте, що сховище втрачає записи або пошкоджує дані. Зупиніться і виправляйте базове сховище перш ніж продовжувати.
Несумісність контрольних сум / помилки декоду
Тут вже не можна звинувачувати PBS — це ентропія. Контрольні суми існують саме тому, що накопичувачі іноді повертають неправильні біти.
Корені: погана RAM (так, буває), диск повертає застарілі дані або проблема з контролером/прошивкою. У віртуалізованому PBS може втручатися стек зберігання гіпервізора.
Що робити: виконайте scrub і тест сховища; прогнати тест пам’яті, якщо корупція повторюється; верифікуйте нещодавні снапшоти; для уражених робочих навантажень забезпечте другу копію (інший PBS, tape, object store тощо).
Помилки запису індексу / фіналізації
Часто з’являється як «unable to write index», «failed to finalize backup», «unexpected EOF». Потік бекапу може завантажити багато чанків,
але провалитися в кінці, коли потрібно зафіксувати індекс/каталог. Якщо місця мало, саме цей фінальний коміт ви і втрачаєте.
Що робити: розглядайте помилки індексу як «бекап недійсний, поки не верифіковано». Виправте ємність або стан RO файлової системи, перезапустіть бекап і потім верифікуйте.
Жарт №1: Відсутній chunk — це як відсутній носок: дратує, загадково і завжди зникає, коли ви вже спізнюєтесь.
Помилки місця: не лише «диск заповнений»
«No space left on device» — прямолінійно. Проблема в тому, що Linux може кинути цю помилку через щонайменше чотири різні типи «місця», і PBS
продемонструє її саме тоді, коли намагається закомітити дані або метадані. Ось пастки простору, які вдаряють по операторам PBS у продакшні.
1) Вичерпання байтів (класичне заповнення диска)
Просто: df -h показує 100%. Але цікавіше, коли «ще не 100%, але фактично повний».
ZFS, btrfs і навіть ext4 при сильній фрагментації можуть поводитися погано задовго до 100%.
Правило: не експлуатуйте дедуп-датастор більше ~80–85% тривалий час, якщо вам важлива продуктивність і успішний GC.
Можна тимчасово підвищуватися, але якщо ви «живете там», отримаєте тайм-аути і дивну поведінку.
2) Вичерпання інодів
Сховища PBS можуть створювати величезну кількість файлів. Деякі файлові системи (і вибір метрики інодів) це «накажуть».
Якщо df -i високо, ви можете отримати ENOSPC, хоча df -h виглядає нормально.
Виправлення: prune і GC, щоб зменшити кількість чанків, а потім планувати міграцію датастору з урахуванням великої кількості файлів. Якщо будуєте з нуля — проектуйте під тиск інодів.
3) Обмеження місця для метаданих/транзакцій (реальність CoW)
На ZFS можна мати «вільне місце», але не достатньо суміжного простору (або не вистачає метаданихного резерву) для ефективних алокацій.
Заповнений пул може спричинити повільний GC, тож ви не зможете звільнити місце швидко, щоб розблокувати бекапи. Це стає циклом.
Виправлення: тримайте пули з запасом; не думайте, що «вміщається» — це успіх. Додавайте vdev/ємність до того, як ви наберете обрив. Розглядайте спеціальні vdev лише якщо розумієте ризики зон відмови.
4) «Зарезервовані блоки» і простір лише для root (нюанс ext4)
ext4 зазвичай резервує відсоток блоків для root. Якщо PBS працює від root (часто), він все одно може писати там, куди інші процеси не можуть.
Або навпаки — залежно від користувача сервісу та монтування. Це може створити часткові й заплутані відмови.
Виправлення: розберіться з налаштуваннями резерву та правами сервісу. Але не «відключайте» резерви безпечності просто щоб втиснути ще кілька бекапів. Так ви ризикуєте отримати мертву систему о 3 ранку.
Блокування, дозволи і «вчора працювало»
Системи бекапу — це машини станів з гострими краями. Блокування потрібні, щоб запобігти одночасним змінам одного й того ж набору снапшотів.
Коли блокування застарівають або дозволи змінюються на льоту, відмови виглядають випадковими.
Помилки дозволів (шлях датастору, власність, опції монтування)
Симптоми: «permission denied», «read-only filesystem», «failed to create directory» або миттєві відмови задач.
Реальність: «Я можу записати як root» — не те саме, що «сервіс PBS може записати у своєму контексті виконання».
Також NFS-експорт може тихо змінити поведінку після перезавантаження або мережевої події.
Виправлення: підтвердьте опції монтування, реальні права на шлях та що файлову систему можна записувати стабільно.
Помилки блокувань
Блокування часто є симптомом, а не хворобою. Довготривала верифікація, завислий GC або файловий система з I/O-латентністю можуть утримувати блокування і спричиняти відмови бекапів.
Правильний крок — не «видалити блокування», а знайти причину, чому задача зависла.
Ідея в парафразі від Werner Vogels (CTO Amazon): «Все ламається постійно; проектуйте системи так, щоб відмови були рутинними, а не катастрофічними».
Prune і garbage collection: повільний поїзд
У PBS політика збереження — це двоступінчастий танець:
- Prune видаляє посилання на снапшоти відповідно до політики.
- Garbage collection звільнює чанки, на які більше нема посилань.
Якщо ви тільки prune-ите, датастор може виглядати зайнятим. Якщо тільки GC — нічого не відбувається, бо снапшоти все ще посилаються на чанки.
Якщо робити обидва при пулі на 95% і в нездоровому стані, обидві операції стануть повільними та крихкими.
Операційні поради (суб’єктивно, бо це потрібно)
- Плануйте prune і GC під час низького I/O вікна, але не так рідко, щоб потрапляти в кризу.
- Не накладайте важку верифікацію на GC у дрібних системах. Диски всю ніч «переб’ються» між собою.
- Тримайте реалістичні політики збереження. «Залишати все назавжди» — це запит купити більше місця, а не політика.
- Верифікуйте відновлення, а не лише бекапи. Верифікація ловить відсутні чанки; тести відновлення ловлять операційні проблеми (ключі, дозволи, мережа).
Жарт №2: Garbage collection — як корпоративне бюджетування: нічого не звільняється, поки хтось не доведе, що це справді не використовується.
Три корпоративні міні-історії з поля бою резервного копіювання
Міні-історія 1: Інцидент через хибне припущення
Середня компанія запускала PBS на новій полиці зберігання. Команда припустила, що «RAID-контролер з батарейним кешем» достатній для безпечних записів.
Також вважали, що оскільки продакшн VM працюють, записи бекапу «менш важливі» і можуть терпіти іноді збої.
Першим знаком проблем стали помилки верифікації: missing chunks розкидані по різних групах VM. Не лише останній снапшот.
Відновлення іноді працювало, іноді — ні. Люди звинувачували оновлення PBS, потім мережу, потім «складність дедупа».
Переломний момент настав, коли зв’язали часові мітки verify PBS з логами контролера, які показали попередження про destage кеша і іноді ресети.
Записи бекапу — високопродуктивні та сплескові; вони вдаряли по контролеру інакше, ніж VM-навантаження. Масив іноді підтверджував записи,
а потім втратив їх під час вікна ресету. PBS зробив свою роботу: пожалівся, коли чанків потім не виявилось.
Виправлення було буденним: оновлення прошивки, заміна контролера і перенесення PBS-датастору на ZFS з end-to-end checksum на хості з ECC RAM.
Верифікація перестала ламатися. Також додали другу репліку PBS для критичних навантажень, бо «одна копія» — не стратегія.
Міні-історія 2: Оптимізація, яка зіграла злий жарт
Інша команда хотіла прискорити бекапи. Вони помістили PBS-датастор на NFS-шару, яку обслуговував швидкий NAS. На папері — відмінно: багато місця,
легке розширення, підтримка від storage-команди. Налаштували rsize/wsize, відчували себе розумними і святкували.
Місяць усе було добре. Потім періодично з’являлися «unable to decode chunk» і деякі снапшоти, які не вдавалось верифікувати.
Збої були спорадичними — класичне «це мережа» відчуття. Storage-команда наполягала, що NAS здоровий. Віртуалізаційна команда наполягала, що PBS надто вибагливий.
Справжня причина була тонкою: переривчасті NFS-стали під час операцій з метаданими і подія фейловеру, яка на короткий час змінила поведінку експорту.
Файли чанків і індекси чутливі до часткових записів і таймінгів. NAS був оптимізований для великих послідовних файлів, а не для мільйонів відносно малих об’єктів чанків
з постійною мета-ємнісною активністю.
Вони відкочували оптимізацію і розмістили датастор на локальних ZFS-дзеркалах з адекватним запасом вільного місця. Бекапи трохи «сповільнилися» в метриках,
але стали стабільними і верифікованими. Найкращий показник — «відновлення працює», а не «гарний графік».
Міні-історія 3: Нудна, але правильна практика, що врятувала день
Регульована компанія мала нудну звичку: щотижневі тести відновлення однієї VM на кластер, по черзі.
Це не була вогняна тривога — просто заплановане завдання з тикетом, чек-боксом і людиною, що прикріплювала скріншот консолі та файл контрольної суми.
Одного тижня тест відновлення впав через missing chunk у найновішому снапшоті, але старі снапшоти відновлювалися нормально.
Оператор терміново ескалував, і команда призупинила нові бекапи, щоб не заглушити ситуацію додатковим шумом.
Вони виявили, що датастор висить близько 92% зайнятості і GC не звільняв місце, бо prune виконувався, але GC був запланований на інше вікно
і постійно таймаутив через надто завантажені диски. Система не була корумпованою — вона просто задихалася.
Вони звільнили місце, запустили GC, повторили невдалий бекап і верифікували його. Без драм. Головне, що тест відновлення зловив проблему
до того, як реальний інцидент змусив відновлювати під тиском.
Урок: «нудна» практика — не про бекапи. Вона про доведення, що бекапи придатні до відновлення.
Поширені помилки: симптом → корінь → виправлення
1) «No space left on device» під час фіналізації
Симптоми: бекап завантажує більшість даних, але падає наприкінці; логи містять повідомлення про finalize індексу.
Корінь: датастор забитий; метадані/індексу потрібне місце для коміту.
Виправлення: prune снапшотів, запустити GC, тримати датастор в межах адекватного використання; повторити й верифікувати.
2) Бекапи падають, хоча df -h показує достатньо місця
Симптоми: ENOSPC, але «60% вільного».
Корінь: вичерпання інодів або обмеження квот/резервацій.
Виправлення: перевірити df -i; на ZFS перевірити quotas/reservations; зменшити кількість снапшотів через prune; планувати міграцію, якщо макет інодів неправильний.
3) «Missing chunk» тільки в найновішому снапшоті
Симптоми: лише останній снапшот не верифікується; старі — OK.
Корінь: перерваний бекап (місце закінчилось, краш, файлову систему перемонтовано RO).
Виправлення: виправити ємність/здоров’я; перезапустити бекап; знову верифікувати; налаштувати алерти на ENOSPC і RO remounts.
4) «Missing chunk» розкиданий у багатьох снапшотах
Симптоми: verify-помилки в часі й групах.
Корінь: базова корупція сховища або ненадійна поведінка віддаленої файлової системи.
Виправлення: зупинити записи, виконати діагностику сховища (scrub, SMART, логи контролера), усунути проблему апаратури, потім перевірити і заново створити бекапи.
5) Бекапи зависають або повзуть, потім падають через таймаути
Симптоми: задачі працюють надто довго; GC ніколи не завершується; іноді з’являються lock-повідомлення.
Корінь: датастор занадто заповнений (біль CoW-болю), або диски насичені одночасними verify/GC/backup.
Виправлення: зменшити паралельність; рознести вікна верифікації; тримати запас вільного місця; перемістити датастор на швидші диски або додати vdev.
6) «Datastore is locked»
Симптоми: нові задачі падають відразу; логи згадують блокування.
Корінь: інша задача запущена, або задача зависла через I/O.
Виправлення: знайти запущені задачі; вирішити I/O-проблеми; не видаляти стан вручну; запустити одну тестову задачу для перевірки.
7) «Read-only filesystem» під час бекапу
Симптоми: раптові масові відмови; dmesg показує remount RO ext4 або помилку ZFS.
Корінь: помилки апаратного I/O або реакція файлової системи на корупцію.
Виправлення: зупинитися, полагодити апарат/файлову систему, потім верифікувати консистентність датастору і можливість відновлення.
8) «Authentication failed» після «без змін»
Симптоми: задачі падають на старті; логін не проходить; TLS-помилки.
Корінь: прострочені сертифікати, зсув часу, незгоджені паролі або помилка в рядку репозиторію.
Виправлення: перевірити timedatectl; перевірити репозиторій; повторно автентифікуватися через proxmox-backup-client login; оновити облікові дані в конфігурації PVE.
Чеклісти / покроковий план
Чекліст A: Коли бекапи почали падати сьогодні ввечері
- Зупинити кровотечу: призупиніть розклади бекапів, якщо відмови пов’язані з місцем або I/O.
- Класифікувати: простір (байти/іноди), цілісність (I/O, checksum), блокування/дозволи або автентифікація/мережа.
- Підтвердити стан монтування датастору:
df -hT,df -i,mount,dmesg. - Прочитати логи на боці сервера:
journalctl -u proxmox-backupбіля часової мітки помилки. - Якщо ENOSPC: зробіть prune (dry-run спочатку), потім GC. Перевірте вільне місце.
- Якщо I/O помилки: зупиніть записи, виправте сховище, потім верифікуйте снапшоти.
- Повторно запустіть один бекап для репрезентативної VM/CT і одразу верифікуйте його.
Чекліст B: Коли потрібно безпечно звільнити місце
- Показати політику збереження і виконати prune dry-run для групи, яку можна видалити безпечно.
- Виконати prune снапшотів усвідомлено (не видаляти файли навмання).
- Запустити garbage collection, щоб звільнити чанки.
- Перевірити вільні байти та іноди.
- Підкорегувати політику зберігання, щоб не повторювати таку авралійність щотижня.
Чекліст C: Коли верифікація повідомляє про помилки чанків
- Визначити, чи це тільки найновіший снапшот, чи розкидано історично.
- Перевірити
dmesgі здоров’я сховища (ZFS scrub / SMART / логи RAID). - Якщо тільки новий і корелює з ENOSPC/крашем: виправити причину, повторити бекап і верифікувати.
- Якщо розкидано: розглядайте це як інцидент цілісності сховища. Зупиніть записи. Усуньте апаратні/сховищні проблеми.
- Після усунення: запустіть широкомасштабну верифікацію і виконайте тести відновлення для критичних навантажень.
FAQ
1) Чому PBS говорить про «chunks» замість файлів?
PBS дедуплікує й верифікує на рівні чанків. Ваш бекап — це набір індексів, які посилаються на хешовані чанки, а не один монолітний файл.
Ось чому відсутні чанки ламають відновлення, навіть якщо «більшість даних завантажено».
2) Якщо я виконаю prune, чому місце не звільняється одразу?
Тому що prune видаляє лише посилання; він не видаляє спільні чанки, які можуть використовуватися іншими снапшотами. Garbage collection — це те, що реально звільняє
ненадані чанки.
3) Чи можна зберігати датастори PBS на NFS?
Можна, але це питання ризиків. Якщо ваш NFS-сервер дуже стабільний і налаштований для метаданонавантажених робіт, це може працювати.
На практиці багато історій про «missing chunk» ведуть до віддалених файлових систем під навантаженням або під час фейловеру.
4) Якої цільової вільної ємності слід дотримуватися?
Для стабільної роботи й передбачуваного GC плануйте тримати помітний запас. Якщо ви регулярно понад ~85% використання, очікуйте уповільнень і відмов,
особливо на CoW файлових системах. Розмірюйте ємність і політику збереження відповідно.
5) У мене ENOSPC, але все ще бачу вільне місце. Як так?
Іноди, квоти, резервації або специфічні обмеження файлової системи можуть спричинити ENOSPC. Завжди перевіряйте df -i, а якщо використовуєте ZFS — перегляньте quotas/reservations dataset.
6) Чи варто запускати верифікацію щодня?
Верифікація корисна, але вона створює I/O. У дрібних системах плануйте її так, щоб не перекриватися з важкими бекапами або GC.
Для критичних даних часті верифікації плюс періодичні тести відновлення кращі за сліпу віру.
7) Чи безпечно виправити «datastore is locked» видаленням lock-файлів?
Зазвичай ні. Блокування часто утримуються тому, що задача працює або зависла через I/O. Видалення блокувань може створити неконсистентний стан.
Знайдіть задачу, знайдіть причину її зависання, а потім вирішуйте.
8) Чи означають завжди помилки чанків, що моє сховище пошкоджене?
Не завжди. Якщо найновіший снапшот не верифікується через ENOSPC або краш, можна отримати missing chunks тільки в ньому.
Якщо помилки чанків з’являються по всій історії, вважайте, що сховище ненадійне, поки не доведено інше.
9) Яка найкраща звичка, щоб уникнути несподіваних відмов бекапу?
Налаштуйте алерти на використання датастору (байти і іноди) і регулярно виконуйте тести відновлення. Логи про успішні бекапи заспокоюють; тести відновлення дають доказ придатності.
Наступні кроки (робіть це, а не те)
Якщо ви зараз маєте проблеми з PBS, зробіть ці кроки в порядку:
- Отримайте тверді докази: витягніть помилку з боку PBS через
journalctl -u proxmox-backupі класифікуйте її (простір vs цілісність vs блокування vs автентифікація). - Виправте ємність першочергово: байти та іноди. Виконайте prune з dry-run. Потім запустіть garbage collection. Перевірте використання.
- Верифікуйте після відновлення: запустіть вибіркову верифікацію по ураженим групам; не думайте, що «наступний бекап пройшов» — це означає, що все гаразд.
- Перестаньте довіряти нестабільному сховищу: якщо бачите реальні патерни корупції, призупиніть записи і лікуйте стек зберігання, перш ніж створювати ще сумнівні копії.
- Зробіть відмову буденною: додайте алерти на використання і RO remounts, плануйте prune/GC розумно і виконуйте тести відновлення.
Мета — не героїчне відновлення. Мета — така передбачувана система бекапу, що дивує лише те, як рідко вам доводиться про неї думати.
І коли вона ламається, вона має ламатися голосно, швидко і з достатньою інформацією, щоб відновити без паніки.