Kako odpraviti napako metapodatkov AppStream v CentOS 8

Вступ

У цьому посібнику пояснюється, як налаштувати обслуговування Proxmox Backup Server для довгострокового зберігання резервних копій за допомогою prune jobs і garbage collection. Ви налаштуєте Proxmox Prune configuration, розклад Proxmox Garbage Collection і оціните використання сховища, щоб ваш datastore не зростав доти, доки не займе весь доступний дисковий простір.

Після завершення цього посібника у вас буде налаштована політика prune за розкладом і розклад garbage collection для datastore Proxmox Backup Server, з практичними прикладами retention для щоденних, щотижневих і щомісячних резервних копій.

Передумови

Перед початком переконайтеся, що у вас є:

• Proxmox Backup Server 4.2.x або новіший;
• Налаштований PBS datastore з наявними або запланованими резервними копіями;
• Адміністративний доступ до веб-інтерфейсу Proxmox Backup Server;
• Доступ до shell як root або інший користувач із достатніми правами адміністрування PBS;
• Базове розуміння backup jobs Proxmox VE і namespaces PBS;
• Приблизно 30 хвилин для виконання налаштування.

Цей посібник призначений для системних адміністраторів середнього рівня.

Крок 1: Зрозумійте, як Prune і Garbage Collection працюють разом

У Proxmox Backup Server pruning і garbage collection є окремими операціями обслуговування. Розуміння того, як вони взаємодіють, необхідне для ефективного керування datastore Proxmox.

Prune job визначає, які backup snapshots потрібно зберегти, а які snapshots потрібно видалити з видимої історії резервних копій. Коли PBS виконує prune для snapshot, він видаляє metadata, indexes, logs і notes snapshot. Він не видаляє одразу всі базові backup chunks. Chunks, на які посилаються pruned snapshots, видаляються пізніше під час garbage collection.

Garbage collection (GC) звільняє місце в datastore, видаляючи невикористані chunks із chunk storage. PBS використовує deduplicated chunks, тому один chunk може бути пов'язаний із кількома backup snapshots. Через це PBS не може безпечно видаляти chunks саме в момент, коли snapshot було pruned. Спочатку він має підтвердити, що жоден snapshot, який залишився, або поточний running backup більше не посилається на них.

PBS також використовує grace period для видалення chunks. Під час GC chunks позначаються і очищаються, але chunks усередині grace period відображаються як pending removals і не видаляються одразу. Це захищає running backups і враховує поведінку filesystem access time, особливо з поширеною поведінкою mount relatime.

Крок 2: Перегляньте поточну конфігурацію Datastore

Це можна зробити через CLI або через веб-інтерфейс.

Виведіть список доступних datastores:

proxmox-backup-manager datastore list

Очікуваний вивід: таблиця datastore.

Виберіть datastore, у якому зберігаються ваші резервні копії Proxmox VE. У наведених нижче прикладах замініть <DATASTORE_NAME> на назву вашого datastore.

Перевірте поточний статус garbage collection:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Ви маєте побачити поточний статус GC для datastore. Якщо GC ще ніколи не запускався, у виводі може бути вказано, що попереднього успішного запуску немає.

Виведіть список наявних prune jobs:

proxmox-backup-manager prune-job list

Ви маєте побачити наявні prune jobs або порожній список, якщо prune job ще не налаштовано.

Щоб перевірити це через веб-інтерфейс, перейдіть до Datastore - <DATASTORE_NAME> - Prune & GC Jobs:

Крок 3: Сплануйте політику довгострокового зберігання

Retention policy має відповідати вимогам до відновлення і місткості сховища. Для багатьох планів Proxmox backup retention практична довгострокова політика використовує шаблон grandfather-father-son:

Retention option	Приклад значення	Результат
keep-daily	14	Зберігати одну резервну копію на день протягом 14 backup days
keep-weekly	8	Зберігати одну резервну копію на тиждень протягом 8 backup weeks
keep-monthly	12	Зберігати одну резервну копію на місяць протягом 12 backup months
keep-yearly	2	Зберігати одну резервну копію на рік протягом 2 backup years

PBS retention options обробляються за time buckets. Наприклад, keep-daily зберігає останню резервну копію для кожного retained day, а дні без резервних копій не враховуються. keep-weekly зберігає останню резервну копію для кожного retained ISO week, а тижні без резервних копій не враховуються.

Для щоденного розкладу резервного копіювання почніть з однієї з цих політик:

Політика	Retention settings	Сценарій використання
Conservative	keep-daily 7 keep-weekly 4 keep-monthly 6	Малий datastore або коротка історія відновлення
Balanced	keep-daily 14 keep-weekly 8 keep-monthly 12	Типові резервні копії VM і containers
Long-term	keep-daily 30 keep-weekly 12 keep-monthly 24 keep-yearly 3	Більший datastore або історія, зумовлена compliance-вимогами

Крок 4: Оцініть backup storage перед застосуванням retention

Планування сховища для long-term backup storage не дорівнює множенню повного розміру VM на кількість snapshots. Proxmox Backup Server використовує deduplication, тому кожна нова резервна копія зазвичай зберігає лише змінені chunks плюс metadata. Однак усе одно слід розраховувати консервативну оцінку.

Використовуйте цю формулу:

Орієнтовний обсяг сховища = початкові захищені дані + щоденні змінені дані * еквівалент retained days + запас безпеки

Приклад 1: Balanced retention для групи VM:

Значення	Приклад
Protected VM data	2 TB
Середній обсяг щоденно змінених даних	80 GB
Retention policy	14 daily · 8 weekly · 12 monthly
Запас безпеки	25 percent

Приблизна кількість retained change points:

14 daily + 8 weekly + 12 monthly = 34 restore points

Приблизний обсяг changed data:

80 GB * 34 = 2720 GB

Приблизний загальний обсяг до додавання запасу:

2000 GB + 2720 GB = 4720 GB

Додайте 25 percent safety margin:

4720 GB * 1.25 = 5900 GB

Для цього workload плануйте приблизно 6 TB корисної місткості datastore.

Приклад 2: Політика для меншого datastore:

Значення	Приклад
Protected VM data	1 TB
Середній обсяг щоденно змінених даних	30 GB
Retention policy	7 daily · 4 weekly · 6 monthly
Запас безпеки	25 percent

Приблизна кількість restore points:

7 + 4 + 6 = 17 restore points

Приблизний обсяг сховища:

1000 GB + (30 GB * 17) = 1510 GB
1510 GB * 1.25 = 1887.5 GB

Для цього workload плануйте приблизно 2 TB корисної місткості datastore.

Крок 5: Створіть Prune Job у веб-інтерфейсі

1. Відкрийте веб-інтерфейс Proxmox Backup Server.
2. Виберіть Datastore.
3. Виберіть <DATASTORE_NAME>.
4. Відкрийте вкладку Prune & GC.
5. Натисніть Add Prune Job.
6. Установіть Datastore як <DATASTORE_NAME>.
7. Установіть Namespace, якщо хочете виконувати prune лише для одного namespace.
8. Налаштуйте retention values, наприклад keep-daily як 14, keep-weekly як 8 і keep-monthly як 12.
9. Установіть розклад, наприклад 03:00.
10. Збережіть prune job.

Очікуваний результат: PBS створює scheduled prune job для datastore або namespace. Цей job періодично видаляє backup snapshots, які більше не вибираються вашою retention policy.

Крок 6: Створіть Prune Job з командного рядка

Ви також можете створити такий самий prune job із shell PBS.

Для prune job на рівні всього datastore:

proxmox-backup-manager prune-job create pve-longterm \
  --store <DATASTORE_NAME> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term Proxmox backup retention"

Очікуваний результат: PBS створює prune job з назвою pve-longterm.

Для prune job, специфічного для namespace:

proxmox-backup-manager prune-job create pve-namespace-longterm \
  --store <DATASTORE_NAME> \
  --ns <NAMESPACE> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term retention for namespace"

Очікуваний результат: PBS виконує prune лише для вибраного namespace. Це корисно, коли різні clusters, tenants або environments потребують різних retention policies.

Виведіть список prune job:

proxmox-backup-manager prune-job list

Очікуваний вивід: таблиця prune-job.

Крок 7: Налаштуйте розклад Garbage Collection

Після того як pruning видаляє стару snapshot metadata, GC має запуститися, щоб повернути місце, яке займали невикористані chunks. Щотижневий розклад GC є хорошою початковою точкою для більшості налаштувань.

Установіть щотижневий розклад GC:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --gc-schedule "Sun 04:00"

Ви можете налаштувати його через веб-інтерфейс, перейшовши до Datastore - <DATASTORE_NAME> - Prune & GC Jobs → Garbage Collection Jobs → Edit:

Очікуваний результат: PBS планує garbage collection для datastore щонеділі о 04:00.

Перевірте статус GC:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Очікуваний вивід містить назву datastore та інформацію про останній або наступний запуск GC.

Ви також можете запустити GC вручну:

proxmox-backup-manager garbage-collection start <DATASTORE_NAME>

Очікуваний результат: PBS запускає GC task для datastore.

Крок 8: Виберіть безпечний розклад Prune і GC

Практичний розклад виглядає так:

Task	Приклад розкладу	Причина
Proxmox VE backup job	Щодня о 01:00	Спочатку створює нові резервні копії
PBS prune job	Щодня о 03:00	Видаляє snapshots поза retention
PBS GC job	Щотижня в неділю о 04:00	Повертає місце, яке займали невикористані chunks, після pruning

Такий порядок зберігає нові резервні копії доступними перед видаленням старих snapshots. Він також дає PBS час завершити backup writes перед запуском prune і GC tasks.

Для busy environments уникайте одночасного запуску backup, verification, prune, sync і GC tasks. Рознесіть maintenance jobs у часі, щоб зменшити I/O contention.

Крок 9: Перевірте конфігурацію

Виведіть список prune jobs:

proxmox-backup-manager prune-job list

Переконайтеся, що job має очікуваний datastore, namespace, schedule і keep values.

Покажіть один prune job:

proxmox-backup-manager prune-job show pve-longterm

Очікуваний результат: PBS показує налаштовані retention options.

Перевірте конфігурацію GC:

proxmox-backup-manager garbage-collection list

Очікуваний результат: PBS виводить статус garbage collection для всіх datastores, включно з datastores без GC jobs.

Перевірте використання datastore у веб-інтерфейсі:

• Відкрийте Datastore.
• Виберіть <DATASTORE_NAME>.
• Перегляньте використання datastore і task history.
• Відкрийте Tasks і переконайтеся, що prune і GC jobs завершуються успішно.

Очікуваний результат: Datastore показує scheduled maintenance activity, а старі snapshots видаляються відповідно до налаштованої Proxmox Prune configuration.

Крок 10: Відстежуйте зростання сховища з часом

Після налаштування Prune jobs in PBS відстежуйте використання сховища щонайменше протягом одного повного retention cycle. Наприклад, якщо ви налаштували keep-monthly 12, потрібно кілька місяців даних, перш ніж довгостроковий тренд стане зрозумілим.

Переглядайте ці metrics:

Metric	Що перевіряти
Datastore used space	Підтверджує, чи працює backup storage optimization
Prune task logs	Підтверджує, що snapshots видаляються
GC task logs	Підтверджує, що невикористані chunks видаляються
Pending removals	Показує chunks, які очікують завершення GC grace period
Backup job size trend	Показує, чи зростає обсяг changed data

Якщо datastore продовжує зростати швидше, ніж очікувалося, зменште retention або додайте сховище до того, як filesystem стане повною.

Типові коригування:

Problem	Adjustment
Datastore заповнюється надто швидко	Зменште keep-daily, keep-weekly або keep-monthly
Замало recent restore points	Збільште keep-daily
Monthly history занадто коротка	Збільште keep-monthly
Backups перетинаються з maintenance	Перенесіть prune або GC на пізніший час
GC звільняє мало місця	Переконайтеся, що prune jobs справді видаляють старі snapshots

Відкат змін

Щоб видалити prune job:

proxmox-backup-manager prune-job remove pve-longterm

Очікуваний результат: PBS видаляє конфігурацію prune job.

Щоб вимкнути розклад GC без видалення datastore:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --delete gc-schedule

Очікуваний результат: PBS очищає automatic GC schedule для datastore.

Щоб змінити retention замість видалення prune job:

proxmox-backup-manager prune-job update pve-longterm \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Очікуваний результат: PBS зберігає prune job, але застосовує нову retention policy під час майбутніх prune runs.

Усунення несправностей

GC не звільняє місце одразу

Причина: Prune видалив snapshot metadata, але chunks усе ще використовуються іншими snapshots або перебувають усередині GC grace period.
Виправлення: Дочекайтеся завершення grace period і запустіть GC ще раз пізніше. Перевірте task logs на наявність pending removals.

Prune зберігає більше резервних копій, ніж очікувалося

Причина: keep-daily, keep-weekly і keep-monthly використовують time buckets. Дні, тижні або місяці без резервних копій не враховуються. Retention rules також overlap.
Виправлення: Використайте PBS prune simulator перед зміною production retention. Це допоможе попередньо переглянути поведінку retention перед застосуванням змін.

Datastore усе ще зростає після Prune і GC

Причина: Daily changed data може бути більшим, ніж було оцінено, backups можуть включати нові disks, або retention може бути завеликим для datastore.
Виправлення: Перерахуйте volume estimate, використовуючи фактичні changed data. Зменште retention або розширте сховище.

Prune Job не впливає на Namespace

Причина: Prune job може бути налаштований для неправильного namespace або namespace depth.
Виправлення: Перегляньте налаштування prune job і підтвердьте значення --ns. Якщо потрібно, щоб job застосовувався лише до одного namespace, явно задайте namespace.

Backup Clients усе ще можуть видаляти Backups

Причина: Backup credentials можуть мати delete permissions, або retention може бути налаштований поза PBS.
Виправлення: Використовуйте least privilege для backup clients. Для ransomware resistance віддавайте перевагу PBS-side prune jobs замість надання backup clients прав на видалення.

Висновок

Ви налаштували Proxmox Backup Server maintenance для довгострокового retention, створивши prune job і запланувавши garbage collection. Ви також дізналися, чому chunks не видаляються одразу, як GC завершує datastore cleanup і як оцінити вимоги до сховища перед застосуванням long-term retention.

Як наступні кроки, додайте verification jobs, налаштуйте notifications для failed prune і GC tasks, а також щомісяця переглядайте зростання datastore. Це робить backup storage optimization прогнозованою і запобігає тому, щоб retention settings непомітно зайняли всю доступну місткість.

Версія документа: 1.0
Останнє оновлення: червень 2026
Власник: Technical Documentation Team