PBS: Безпечне підключення до PVE через API та шифрування

Вступ

У цьому tutorial пояснюється, як підключити Proxmox VE до Proxmox Backup Server за допомогою Proxmox API-токенів, прав доступу, обмежених namespace, і клієнтського шифрування. Такий підхід покращує безпеку Proxmox VE, оскільки Proxmox VE не потрібен повний пароль користувача PBS, а backup server не потребує доступу до незашифрованих даних backup VM.

Ви налаштуєте безпечну автентифікацію за API-токеном, зареєструєте сховище Proxmox Backup Server у Proxmox VE, увімкнете клієнтське шифрування backup і налаштуєте розклади prune та garbage collection, щоб datastore не зайняв увесь доступний простір.

Передумови

Цільова аудиторія: системні адміністратори середнього рівня.
Орієнтовний час виконання: 45-60 хвилин.
Кінцева мета: наприкінці цього tutorial у вас буде безпечний Proxmox backup repository, підключений до Proxmox VE з обмеженим доступом через API-токен, зашифрованими backup VM і параметрами retention, що відповідають місткості вашого сховища.

Необхідне середовище:

Proxmox VE 8.x або новіша версія.
Proxmox Backup Server 3.x або новіша версія.
Адміністративний доступ до web interface або shell Proxmox VE.
Адміністративний доступ до web interface або shell Proxmox Backup Server.
Наявний PBS datastore.
Мережева доступність від Proxmox VE до PBS через TCP port 8007.
Достатня місткість datastore для запланованого backup retention window.

Приклади значень, які використовуються в цьому tutorial:

Placeholder	Приклад значення	Опис
`<PBS_HOST>`	`pbs.example.com`	Hostname або IP address PBS
`<PBS_PORT>`	`8007`	Стандартний PBS API port
`<DATASTORE>`	`backup-store`	Ім'я PBS datastore
`<NAMESPACE>`	`pve-prod`	Namespace для цього джерела Proxmox VE
`<PBS_USER>`	`pve-backup@pbs`	PBS user, створений для Proxmox VE
`<TOKEN_NAME>`	`pve-token`	Ім'я API-токена
`<TOKEN_ID>`	`pve-backup@pbs!pve-token`	Повний PBS API token ID
`<PVE_STORAGE_ID>`	`pbs-secure`	Storage ID, який відображається в Proxmox VE
`<PBS_FINGERPRINT>`	`AA:BB:CC:...`	Fingerprint сертифіката PBS

Info

API-токени Proxmox Backup Server складаються з token ID і secret. Secret відображається лише один раз під час створення токена, тому одразу збережіть його в password manager. У документації Proxmox зазначено, що API-токени корисні для простого відкликання доступу та для обмеження прав на рівні окремого клієнта.

Крок 1: Сплануйте безпечну архітектуру Proxmox Backup

Перед зміною будь-якої конфігурації визначте, як Proxmox VE має отримувати доступ до PBS.

Використовуйте таку архітектуру:

Компонент	Рекомендоване налаштування
Автентифікація	API-токен замість пароля користувача
Область доступу	Datastore namespace, а не весь datastore
PBS role	DatastoreBackup плюс DatastoreReader, якщо потрібен перегляд для restore
Шифрування	Клієнтське шифрування увімкнено в Proxmox VE
Retention	PBS prune job або datastore retention policy
Очищення простору	Запланований garbage collection після pruning
Реакція на компрометацію	Відкликати токен і створити заміну

Ця архітектура відповідає принципу найменших привілеїв. Proxmox Backup Server використовує role-based і path-based permissions. Доступ можна призначити до конкретного datastore або namespace path, наприклад /datastore/<DATASTORE>/<NAMESPACE>.

Крок 2: Створіть окремого PBS user

Увійдіть у shell PBS як root або інший administrator.

Створіть окремого PBS realm user для Proxmox VE:

proxmox-backup-manager user create <PBS_USER> \ --comment "Proxmox VE backup user"

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

User '<PBS_USER>' created.

Перевірте, що користувач існує:

proxmox-backup-manager user list

Очікуваний результат:

userid enable expire comment <PBS_USER> 1 Proxmox VE backup user root@pam 1 Superuser

Info

Новостворений PBS user або API-токен за замовчуванням не має жодних permissions. Потрібно явно призначити доступ, перш ніж Proxmox VE зможе його використовувати.

Крок 3: Створіть namespace для backup Proxmox VE

Namespace дає змогу відокремити один host або cluster Proxmox VE від інших backup sources в межах того самого datastore. Це корисно для безпечної Proxmox backup authentication, оскільки permissions можна обмежити лише цим namespace.

Ви можете створити namespace через PBS web interface:

Відкрийте PBS web interface.
Перейдіть до Datastore.
Виберіть <DATASTORE>.
Відкрийте Content.
Натисніть Add Namespace.
Введіть <NAMESPACE>.
Натисніть Create.

Очікуваний результат: PBS створить namespace у вибраному datastore.

Якщо ви віддаєте перевагу command line, використайте команду namespace з PBS client:

proxmox-backup-client namespace create <NAMESPACE> \
  --repository root@pam@localhost:<DATASTORE>

Info

Під час створення простору імен необхідно ввести пароль. Для автоматизованих скриптів встановіть змінні середовища PBS_PASSWORD та PBS_FINGERPRINT.

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

Namespace '<NAMESPACE>' created.

Крок 4: Згенеруйте API-токен

Створіть токен API для користувача PBS через веб-інтерфейс, перейшовши до Configuration → Access Control → API Token → Add:

Або ж згенеруйте токен API для користувача PBS через CLI:

proxmox-backup-manager user generate-token <PBS_USER> <TOKEN_NAME>

Очікуваний output:

{
  "tokenid": "<TOKEN_ID>",
  "value": "<TOKEN_SECRET>"
}

Одразу збережіть <TOKEN_SECRET>. Його неможливо буде показати повторно після створення.

Warning

Не вставляйте token secret у chat systems, документацію, shell history, ticket systems або screenshots. Зберігайте його в password manager або іншому затвердженому secrets store.

Крок 5: Призначте права за принципом найменших привілеїв

Permissions API-токена в PBS обчислюються з token ACL, а потім перетинаються з permissions parent user. На практиці і користувач, і токен повинні мати відповідний доступ, а токен ніколи не може робити більше, ніж його parent user.

Надайте parent user backup access лише до потрібного namespace:

proxmox-backup-manager acl update \
  /datastore/<DATASTORE>/<NAMESPACE> DatastoreBackup \
  --auth-id <PBS_USER>

Надайте токену таку саму backup role:

proxmox-backup-manager acl update \
  /datastore/<DATASTORE>/<NAMESPACE> DatastoreBackup \
  --auth-id <TOKEN_ID>

Якщо потрібно, щоб Proxmox VE міг переглядати та відновлювати наявні owned backups з того самого namespace, також додайте DatastoreReader:

proxmox-backup-manager acl update \
  /datastore/<DATASTORE>/<NAMESPACE> DatastoreReader \
  --auth-id <PBS_USER>

proxmox-backup-manager acl update \
  /datastore/<DATASTORE>/<NAMESPACE> DatastoreReader \
  --auth-id <TOKEN_ID>

Перевірте ACL:

proxmox-backup-manager acl list

Очікуваний output:

ugid                         path                                      roleid
<PBS_USER>                   /datastore/<DATASTORE>/<NAMESPACE>       DatastoreBackup
<TOKEN_ID>                   /datastore/<DATASTORE>/<NAMESPACE>       DatastoreBackup
<PBS_USER>                   /datastore/<DATASTORE>/<NAMESPACE>       DatastoreReader
<TOKEN_ID>                   /datastore/<DATASTORE>/<NAMESPACE>       DatastoreReader

Не призначайте Admin або DatastoreAdmin backup token Proxmox VE, якщо для цього немає конкретної операційної причини. Для більшості зашифрованих VM backups namespace-scoped token із DatastoreBackup і необов'язковим DatastoreReader є безпечнішою Proxmox backup best practice.

Крок 6: Запишіть PBS certificate fingerprint

Якщо PBS використовує self-signed certificate, Proxmox VE має довіряти PBS fingerprint.

На PBS server виконайте:

proxmox-backup-manager cert info | grep Fingerprint

Очікуваний output:

Fingerprint (sha256): <PBS_FINGERPRINT>

Збережіть fingerprint для наступного кроку.

Info

Документація Proxmox показує workflow з fingerprint для self-signed PBS certificates під час додавання PBS storage до Proxmox VE.

Крок 7: Додайте PBS storage до Proxmox VE

Увійдіть у shell Proxmox VE як root.

Додайте PBS storage, використовуючи API token ID як username. Введіть token secret, коли з'явиться prompt:

pvesm add pbs <PVE_STORAGE_ID> \
  --server <PBS_HOST> \
  --port <PBS_PORT> \
  --datastore <DATASTORE> \
  --namespace <NAMESPACE> \
  --username <TOKEN_ID> \
  --fingerprint <PBS_FINGERPRINT> \
  --password

Коли з'явиться prompt, вставте API token secret:

Enter Password: <TOKEN_SECRET>

Очікуваний результат: Proxmox VE додасть конфігурацію PBS storage.

Перевірте storage:

pvesm status --storage <PVE_STORAGE_ID>

Очікуваний output:

Name Type Status Total Used Available % <PVE_STORAGE_ID> pbs active ...

При використанні токена API з обмеженням простору імен значення Total, Used і Available можуть відображатися як 0, навіть якщо статус active. Така поведінка є нормальною.

Також це можна налаштувати через Proxmox VE web interface:

Відкрийте Datacenter.
Перейдіть до Storage.
Натисніть Add.
Виберіть Proxmox Backup Server.
Установіть ID як <PVE_STORAGE_ID>.
Установіть Server як <PBS_HOST>.
Установіть Datastore як <DATASTORE>.
Установіть Namespace як <NAMESPACE>.
Установіть Username як <TOKEN_ID>.
Установіть Password як API token secret.
Установіть Fingerprint як <PBS_FINGERPRINT>, якщо потрібно.
Натисніть Add.

Очікуваний результат: storage з'явиться у storage Proxmox VE і матиме статус active.

Крок 8: Увімкніть клієнтське шифрування

Клієнтське шифрування захищає backup data до того, як вони залишають Proxmox VE. PBS зберігає encrypted VM backups, але encryption key залишається на боці Proxmox VE. Це покращує безпеку Proxmox VE backup, оскільки скомпрометований PBS datastore сам по собі не розкриває вміст VM disks.

Через Proxmox VE web interface:

Відкрийте Datacenter.
Перейдіть до Storage.
Виберіть <PVE_STORAGE_ID>.
Натисніть Edit.
Перейдіть на вкладку Encryption і виберіть Auto-generate a client encryption key.
Згенеруйте новий ключ, якщо це новий безпечний backup repository.
Збережіть backup copy encryption key у password manager або offline secret vault.
Натисніть OK.

Очікуваний результат: нові backups у цьому PBS storage будуть зашифровані на боці client.

Danger

Втрата encryption key може зробити encrypted backups невідновлюваними. Зберігайте key окремо від Proxmox VE host і протестуйте restore access, перш ніж покладатися на backup set.

Рекомендоване поводження з key:

Практика	Причина
Зберігайте key поза Proxmox VE cluster	Захищає від втрати cluster
Обмежте file permissions	Зменшує локальний exposure
Створіть offline backup key	Забезпечує disaster recovery
Не зберігайте key лише на PBS	Втрата або компрометація PBS не повинна блокувати recovery
Протестуйте restore з key	Підтверджує, що recovery працює до інциденту

Крок 9: Створіть Proxmox VE backup job

Створіть backup job, який записує дані в encrypted PBS storage.

Через Proxmox VE web interface:

Відкрийте Datacenter.
Перейдіть до Backup.
Натисніть Add.
Виберіть nodes, VMs або containers, які потрібно захистити.
Установіть Storage як <PVE_STORAGE_ID>.
Виберіть schedule, наприклад щодня о 02:00.
Установіть mode відповідно до вашого workload.
Залиште retention порожнім, якщо pruning буде керувати PBS.
Натисніть Create.

Очікуваний результат: Proxmox VE створить запланований backup job, який записує encrypted backups у PBS.

Тримайте retention в одному місці. Для більшості PBS designs налаштовуйте retention на PBS за допомогою prune jobs або datastore retention settings, а retention у Proxmox VE job залишайте порожнім. Це запобігає плутанині через накладання retention у Proxmox VE і PBS pruning.

Крок 10: Налаштуйте параметри prune

Pruning визначає, які backup snapshots залишаються видимими та доступними для restore. Він не видаляє одразу всі unreferenced chunks із disk. PBS prune jobs можна налаштувати на вкладці Prune & GC або за допомогою proxmox-backup-manager prune-job. У документації Proxmox зазначено, що конфігурація prune job зберігається в /etc/proxmox-backup/prune.cfg.

Поширена retention policy для щоденних VM backups:

Параметр	Значення	Значення
`keep-daily`	7	Зберігати один backup на день за останні 7 днів
`keep-weekly`	4	Зберігати один backup на тиждень за останні 4 тижні
`keep-monthly`	6	Зберігати один backup на місяць за останні 6 місяців

Налаштуйте цю policy на datastore:

proxmox-backup-manager prune-job create <JOB_ID> \
  --store <DATASTORE> \
  --ns <NAMESPACE> \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune-schedule "03:00"

Очікуваний результат: PBS застосує retention і запускатиме pruning щодня о 03:00.

Для меншого datastore використовуйте коротшу policy:

proxmox-backup-manager prune-job create <JOB_ID> \
  --store <DATASTORE> \
  --ns <NAMESPACE> \
  --keep-daily 3 \
  --keep-weekly 2 \
  --keep-monthly 1 \
  --prune-schedule "03:00"

Очікуваний результат: PBS зберігатиме менше restore points і споживатиме менше простору.

Warning

Не задавайте великі значення, як-от keep-daily 90, keep-weekly 52 і keep-monthly 36, якщо ви не розрахували потрібну capacity. Backup deduplication допомагає, але вона не робить storage безмежним.

Крок 11: Оцініть обсяг backup storage

PBS дедуплікує chunks, тому споживання storage не дорівнює простому множенню повного розміру VM на кількість backups. Однак вам все одно потрібна консервативна оцінка.

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

Estimated required capacity = initial full protected data + changed data per backup * retained backup points + safety margin

Приклад 1: Невелике середовище

Значення	Величина
Protected VM data	600 GiB
Average daily change rate	3 percent
Changed data per day	18 GiB
Retention	7 daily, 4 weekly, 6 monthly
Approximate retained points	17
Changed data estimate	306 GiB
Safety margin	30 percent

Calculation:

600 GiB + (18 GiB * 17) = 906 GiB
906 GiB * 1.30 = 1177.8 GiB

Рекомендована datastore capacity: щонайменше 1.2 TiB, бажано 1.5 TiB або більше.

Приклад 2: Більше production environment

Значення	Величина
Protected VM data	4 TiB
Average daily change rate	5 percent
Changed data per backup	204.8 GiB
Retention	14 daily, 8 weekly, 12 monthly
Approximate retained points	34
Changed data estimate	6.8 TiB
Safety margin	30 percent

Calculation:

4 TiB + (204.8 GiB * 34) = 10.8 TiB
10.8 TiB * 1.30 = 14.04 TiB

Рекомендована datastore capacity: щонайменше 14 TiB, бажано 16 TiB або більше.

Info

Ці приклади навмисно консервативні. Фактичне використання залежить від VM churn, поведінки guest filesystem, compression, deduplication, backup frequency і того, як часто великі файли перезаписуються всередині guest systems.

Крок 12: Налаштуйте Garbage Collection

Garbage collection (GC) - це процес, який фактично видаляє unreferenced chunks із datastore. Pruning видаляє backup snapshots відповідно до retention rules, але chunks можуть залишатися на disk, якщо інші snapshots все ще посилаються на них або якщо вони все ще перебувають у safety window.

PBS garbage collection має дві фази:

Фаза	Що відбувається
Mark	PBS читає index files і оновлює access time для referenced chunks
Sweep	PBS сканує chunks і видаляє chunks, старші за cutoff time, якщо жоден snapshot на них не посилається

PBS використовує cutoff на основі найстарішого running backup writer або 24 годин і 5 хвилин до часу старту GC. Chunks усередині цього grace period логуються як pending removals замість негайного видалення. Це захищає currently running backups і враховує поведінку filesystem relatime.

Заплануйте GC після pruning:

proxmox-backup-manager datastore update <DATASTORE> \
  --gc-schedule "04:30"

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

Рекомендований schedule для щоденного backup о 02:00:

Задача	Орієнтовний час	Призначення
Proxmox VE backup	02:00	Створити encrypted VM backups
PBS prune	03:00	Застосувати retention policy
PBS garbage collection	04:30	Безпечно повернути unreferenced chunks

Warning

Запуск GC одразу після prune не гарантує негайного звільнення disk space. Деякі chunks навмисно зберігаються як pending removals, доки вони не стануть достатньо старими для безпечного видалення.

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

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

Запустіть GC вручну, коли потрібно:

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

Очікуваний результат: PBS запустить datastore-level garbage collection task. Офіційна документація PBS також надає ці команди й опцію web UI на вкладці datastore Prune & GC.

Крок 13: Запустіть тестовий backup

Запустіть backup job вручну з Proxmox VE:

Відкрийте Datacenter.
Перейдіть до Backup.
Виберіть backup job.
Натисніть Run now.
Підтвердьте дію.

Очікуваний результат: backup task завершиться успішно.

Також можна перевірити з shell Proxmox VE:

pvesm status --storage <PVE_STORAGE_ID>

Очікуваний output:

Name              Type     Status
<PVE_STORAGE_ID>  pbs      active

На PBS відкрийте:

Datastore.
<DATASTORE>.
Content.
<NAMESPACE>.

Очікуваний результат: новий backup VM або container з'явиться в namespace.

Перевірка

Перевірте token permissions на PBS:

proxmox-backup-manager user permissions <TOKEN_ID> \
  --path /datastore/<DATASTORE>/<NAMESPACE>

Очікуваний результат: токен показує datastore permissions лише для target namespace.

Перевірте storage access з Proxmox VE:

pvesm status --storage <PVE_STORAGE_ID>

Очікуваний результат:

<PVE_STORAGE_ID> pbs active

Перевірте, що backups зашифровані:

Відкрийте Proxmox VE.
Виберіть VM backup на PBS storage.
Підтвердьте, що restore operations доступні з Proxmox VE.
Підтвердьте, що key має backup copy поза cluster.

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

proxmox-backup-manager datastore show <DATASTORE>

Очікуваний результат: конфігурація datastore показує розклади prune і garbage collection.

Що робити, якщо API-токен скомпрометовано

Якщо token secret розкрито, негайно відкличте його.

На PBS видаліть токен:

proxmox-backup-manager user delete-token <PBS_USER> <TOKEN_NAME>

Очікуваний результат: PBS видалить токен.

Потім створіть replacement token:

proxmox-backup-manager user generate-token <PBS_USER> <NEW_TOKEN_NAME>
proxmox-backup-manager acl update /datastore/<DATASTORE>/<NAMESPACE> DatastoreBackup --auth-id '<PBS_USER>!<NEW_TOKEN_NAME>'
proxmox-backup-manager acl update /datastore/<DATASTORE>/<NAMESPACE> DatastoreReader --auth-id '<PBS_USER>!<NEW_TOKEN_NAME>'

Оновіть password для Proxmox VE storage:

pvesm set <PVE_STORAGE_ID> --username '<PBS_USER>!<NEW_TOKEN_NAME>'
pvesm set <PVE_STORAGE_ID> --password

Коли з'явиться prompt, вставте новий token secret.

Очікуваний результат: Proxmox VE використовуватиме новий токен для secure API token authentication.

Info

API-токени призначені для простого відкликання, коли client скомпрометований. Це одна з головних причин використовувати tokens замість зберігання user password у Proxmox VE.

Відкат змін

Danger

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

Видаліть запис Proxmox VE storage:

pvesm remove <PVE_STORAGE_ID>

Очікуваний результат: Proxmox VE видалить конфігурацію PBS storage. Наявні backups на PBS залишаться в datastore.

Видаліть API-токен:

proxmox-backup-manager user delete-token <PBS_USER> <TOKEN_NAME>

Очікуваний результат: PBS відкличе API-токен.

Видаліть ACL entries:

proxmox-backup-manager acl update /datastore/<DATASTORE>/<NAMESPACE> DatastoreReader \
  --auth-id <ID> --delete 1

proxmox-backup-manager acl update /datastore/<DATASTORE>/<NAMESPACE> DatastoreBackup \
  --auth-id <ID> --delete 1

Очікуваний результат: PBS видалить namespace permissions.

Видаліть dedicated user, якщо він більше не потрібен:

proxmox-backup-manager user remove <PBS_USER>

Очікуваний результат: PBS видалить користувача.

Warning

Не видаляйте namespace або datastore, якщо ви не маєте наміру видалити backup data. Видалення access configuration відрізняється від видалення backups.

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

Proxmox VE показує PBS Storage як Inactive

Перевірте network access:

nc -vz <PBS_HOST> 8007

Очікуваний output:

Connection to <PBS_HOST> 8007 port [tcp/*] succeeded!

Перевірте PBS fingerprint:

proxmox-backup-manager cert info | grep Fingerprint

Якщо fingerprint змінився, оновіть його в Proxmox VE:

pvesm set <PVE_STORAGE_ID> --fingerprint <PBS_FINGERPRINT>

Автентифікація з API-токеном не проходить

Підтвердьте, що username - це повний token ID:

<PBS_USER>!<TOKEN_NAME>

Приклад:

pve-backup@pbs!pve-token

Підтвердьте, що поле password містить token secret, а не PBS user password.

Підтвердьте permissions:

proxmox-backup-manager acl list

Токен повинен мати ACL entries на namespace path, а parent user також повинен мати сумісні permissions.

Backup завершується помилками permissions

Перевірте namespace path:

/datastore/<DATASTORE>/<NAMESPACE>

Не використовуйте filesystem path datastore, наприклад /mnt/datastore/<DATASTORE>, під час призначення ACL. PBS ACL paths використовують формат /datastore/<DATASTORE>.

Datastore продовжує зростати після Pruning

Зазвичай це очікувано, якщо GC ще не запускався або якщо chunks все ще перебувають у safety window. PBS не видаляє chunks одразу після prune, оскільки chunks можуть усе ще використовуватися іншими snapshots або бути захищені GC cutoff window.

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

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

Якщо GC не заплановано, налаштуйте його:

proxmox-backup-manager datastore update <DATASTORE> \
  --gc-schedule "04:30"

Encrypted Backups не відновлюються

Підтвердьте, що Proxmox VE storage все ще має доступ до encryption key.

Перевірте свій внутрішній backup key inventory. Якщо original Proxmox VE cluster втрачено, для restore потрібен збережений encryption key. Без нього client-side backup encryption може унеможливити recovery.

Висновок

Ви налаштували безпечне підключення Proxmox Backup Server з Proxmox VE за допомогою dedicated PBS user, Proxmox API tokens, namespace-limited permissions і client-side encryption. Ви також налаштували розклади prune і garbage collection, щоб backup encryption у Proxmox setup залишалося стійким зі зростанням backup history.

Ця конфігурація покращує Proxmox VE backup authentication, захищає encrypted VM backups від server-side exposure і надає практичний secure backup repository для довгострокової Proxmox Backup Server configuration.

Рекомендовані наступні кроки: