Proxmox Backup Server на VPS: налаштування PBS

Що насправді дає Proxmox Backup Server на VPS

Proxmox Backup Server (PBS) на VPS — це віддалене сховище, яке використовує той самий протокол, що й ваш кластер Proxmox VE (virtual environment). Тому кожна резервна копія після першої є інкрементною, дедуплікованою між гостьовими системами, шифрується до передавання за межі вашої мережі та може бути перевірена після створення. Ви орендуєте VPS із блоковим томом, встановлюєте PBS на Debian 13, створюєте на цьому томі одне сховище даних і додаєте його в Proxmox VE як сховище типу pbs. Встановлення займає десять хвилин. Але саме подальші налаштування — простори імен, збірка сміття, зберігання ключів і фактичне виконання відновлення — визначають, чи буде ця резервна копія корисною через рік.

Причина використовувати PBS замість копіювання файлів vzdump на орендований диск — сховище фрагментів. Клієнт розділяє диск кожної гостьової системи на фрагменти розміром приблизно 4 MiB, обчислює для них хеші та передає лише ті фрагменти, яких ще немає у сховищі даних. Для запущеної віртуальної машини QEMU після першої резервної копії відстежує змінені блоки за допомогою dirty bitmap, тому під час наступного запуску з локального диска зчитуються лише ці блоки. Гостьова система обсягом 200 GB, у якій щодня змінюється 3 GB даних, передає приблизно 3 GB на день. Саме це дає змогу використовувати домашній uplink разом з орендованим томом і пояснює, чому VPS як віддалене сховище резервних копій кращий за запасний диск у будинку друга. Якщо ви ще вирішуєте, де розмістити сам гіпервізор, окремо розгляньте питання Proxmox удома чи на орендованому VPS.

Розрахуйте обсяг тому до його оренди

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

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Ці рядки є розрахунковим прикладом, а не вимірюванням. Перегляньте використаний простір у df -h всередині кожної гостьової системи. Добову зміну визначте за розміром другої та третьої резервних копій у журналі завдання PBS після їх створення.

Поштова гостьова система з прикладу використовує 120 GB і змінюється приблизно на 3.0 GB на день. Тому для тридцяти щоденних знімків потрібно приблизно 210 GB: одна повна копія плюс зміни за тридцять днів. Додайте останній стовпець для всіх 3 гостьових систем — загальний обсяг становитиме приблизно 619 GB. Додайте ще п’яту частину на індекси, метадані та вільний простір, потрібний для роботи garbage collection. Це вказує на том обсягом 1 TB.

Решта конфігурації невелика. PBS нормально працює з 2 GB RAM і комфортно — з 4 GB, оскільки ресурсоємні операції виконуються на стороні кластера: вузол Proxmox VE читає диски гостьових систем, виконує розбиття на фрагменти та обчислює хеші. VPS записує фрагменти та запускає два ресурсоємні завдання: garbage collection і verification. Орендуйте datastore як окремий block volume, а не як один великий root disk, оскільки згодом том можна збільшити без перебудови сервера.

Встановлення Proxmox Backup Server на Debian 13

Станом на серпень 2026 року актуальна комбінація — Proxmox Backup Server 4 на Debian 13 з кодовою назвою trixie. У старих інструкціях PBS 2 поєднують із Debian 11, а кодова назва є частиною визначення репозиторію. Тому копіювання старої назви suite призводить до помилки apt про відсутній файл release. Почніть із чистого образу Debian 13. Виконуйте всі наведені нижче команди від імені root або з sudo, як показано.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Контрольна сума має бути 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Якщо це не так, зупиніться. Неправильний keyring означає, що ви збираєтеся встановити пакети, підписані ключем, який ви не перевірили.

Запишіть /etc/apt/sources.list.d/pbs.sources із no-subscription-репозиторієм. Це правильний варіант для сервера без договору на підтримку:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

Вебінтерфейс доступний через HTTPS-порт 8007. Увійдіть як root@pam із системним паролем root, оскільки PBS автентифікує цього користувача через PAM (pluggable authentication modules), тобто ті самі облікові записи, які використовує операційна система. Сертифікат є самопідписаним, і браузер повідомить про це. Відбиток цього сертифіката пізніше фіксує Proxmox VE, тому попередження очікуване і не потребує виправлення.

Порт 8007 доступний через форму входу з публічного інтернету, тому не залишайте його відкритим для всіх. Для цього достатньо одного файла nftables. Запис /etc/nftables.conf очищує поточний набір правил, тому пропустіть цей крок, якщо брандмауером на цьому сервері вже керує інший компонент.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Застосуйте конфігурацію за допомогою sudo systemctl enable --now nftables і залиште відкритим другий SSH-сеанс: policy drop плюс одна помилка в правилі SSH можуть заблокувати вам доступ до власного сервера. Замініть 203.0.113.7 адресою, з якої підключається ваш кластер. Якщо ця адреса динамічна, розширте правило до діапазону вашого провайдера або завершіть підключення через тунель. Також врахуйте, що більшість панелей VPS мають окремий мережевий брандмауер перед сервером, у якому потрібно дозволити той самий порт.

Розмістіть datastore на окремому томі

Datastore не повинен зберігатися в кореневій файловій системі. Якщо datastore заповнює спільну кореневу файлову систему, резервне копіювання завершується помилкою, як і всі інші процеси на сервері, зокрема журналювання, потрібне для з’ясування причини. Під’єднайте block volume, відформатуйте його, змонтуйте і лише після цього створюйте datastore у mount point.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Визначте ім’я пристрою з lsblk. У більшості KVM-образів це /dev/vdb, а в інших — /dev/sdb. Ніколи не вважайте це наперед відомим. Додайте mount до /etc/fstab за label, щоб після перезавантаження перейменування пристрою не вказало datastore на неправильний диск:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt має вивести пристрій, шлях і параметри, зокрема rw,relatime. В одному рядку можуть бути приховані дві проблеми. Якщо mount відсутній, але ви все одно створите datastore, PBS записуватиме дані в кореневу файлову систему під mount point. Наступний успішний mount приховає ці дані, але не видалить їх: datastore виглядатиме порожнім, а коренева файлова система залишатиметься заповненою. Якщо параметри містять noatime, PBS відмовляється працювати, оскільки під час створення datastore і під час кожного garbage collection виконує перевірку безпеки часу доступу.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Це створює каталог .chunks, що містить 65536 підкаталогів із назвами від 0000 до ffff. Datastore складається із сотень тисяч невеликих файлів, а не з кількох великих. З цього випливають два наслідки. Копіювання datastore звичайним інструментом для роботи з файлами достатньо повільне, щоб бути непридатним, а snapshot тому провайдера, створений під час виконання резервного копіювання, не є узгодженою копією datastore. Це та сама причина, через яку snapshots не замінюють резервні копії в інших випадках.

Простори імен не дають двом хостам конфліктувати

За замовчуванням datastore має пласку структуру. Резервні копії мають імена vm/100, ct/101 і host/<name>. Якщо два кластери мають гостьову систему з ID 100 і записують дані в одну групу, їхні snapshot чергуються, а правило зберігання, написане для одного кластера, враховує snapshot іншого. Простори імен створюють для кожного джерела окреме дерево в одному datastore.

Створіть їх на хості PBS. Аргумент --repository має форму [[auth-id@]server[:port]:]datastore, тому локальний простір імен задається як root@pam@localhost:store1, а команда запитує пароль root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

Дедуплікація не залежить від цього поділу. Chunks спільно використовуються в усьому datastore, тому десять гостьових систем Debian, розподілених між трьома просторами імен, усе одно зберігають одну копію базової системи. Саме тому один datastore із просторами імен кращий за окремий datastore для кожного хоста: окремі datastore означають окремі пули chunks, а окремі пули chunks означають повторну оплату тієї самої інсталяції Debian кілька разів.

Створіть для кожного джерела окремий обліковий запис і обмежте його власним простором імен. API (application programming interface) token — це облікові дані, що належать користувачу та мають власні дозволи. Це потрібна схема для машини, яку можуть викрасти.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Команда створення token виводить секрет лише один раз:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Скопіюйте його зараз, оскільки PBS не зберігає його у формі, яку можна повторно переглянути. Уважно перевірте команду керування access control. Вона вказує token, backup@pbs!pve-home, а не користувача, оскільки дозволи token обчислюються лише на основі записів, у яких безпосередньо вказано цей token. Запис лише для backup@pbs не надає token жодного доступу, і перша резервна копія завершується помилкою дозволів, а не проблемою, яку можна побачити в мережі. Шлях також має значення: token із доступом лише до /datastore/store1/pve-home не може читати або видаляти дані в просторі імен office, тому один скомпрометований кластер не зможе знищити історію іншого майданчика.

Додайте VPS як сховище резервних копій у Proxmox VE

Спочатку прочитайте відбиток сертифіката на хості PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Потім виконайте команду на будь-якому вузлі кластера:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Вставте значення cert info замість заповнювача у третьому рядку. Якщо передати --password без значення, pvesm запросить його, тому секрет токена не потрапить до історії оболонки. Він зберігається в /etc/pve/priv/storage/pbs-offsite.pw, а саме визначення сховища — у /etc/pve/storage.cfg. Цей файл реплікується на кожен вузол кластера, тому налаштувати сховище потрібно лише один раз для всього кластера.

--prune-backups keep-all=1 вказує Proxmox VE нічого не видаляти. Політики зберігання налаштовуються на стороні PBS; нижче пояснено чому. Токену не потрібен дозвіл на видалення, тому кластер, зашифрований ransomware, не зможе підключитися до віддаленого сховища та видалити історію, яка має його врятувати.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status виводить active у стовпці стану, а поруч показує загальний і використаний обсяг datastore. inactive означає, що вузол не зміг завершити сеанс TLS (transport layer security) з портом 8007. Це проблема firewall або відбитка сертифіката, а не облікових даних.

Під час першого резервного копіювання передаються всі дані, тому перед запуском виконайте розрахунок. 200 GB — це 1600 gigabit, а uplink зі швидкістю 100 Mbit передає 0.1 gigabit за секунду. Отже, мінімальний час становить приблизно чотири з половиною години, а фактичний буде довшим. Запускайте копіювання тоді, коли пропускна здатність мережі вам не потрібна. Під час кожного наступного запуску передаються лише нові chunks.

Шифрування на клієнті та місце зберігання ключа

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

sudo pvesm set pbs-offsite --encryption-key autogen

Ця команда записує новий ключ у /etc/pve/priv/storage/pbs-offsite.enc. Файл доступний лише користувачу root і реплікується разом з рештою /etc/pve. Починаючи з наступної резервної копії, клієнт шифрує кожен фрагмент перед передаванням. Сервер і далі може показувати список ваших знімків і їхні розміри, але не може прочитати їхній вміст.

Тепер про те, що перетворює це на резервне копіювання, а не на додатковий ризик. Згенерований ключ не має парольної фрази та існує лише в кластері, який він захищає. Якщо цей кластер викрадуть або хтось інший зашифрує його дані, на VPS зберігатимуться дані, які ніхто не зможе відкрити. Скопіюйте ключ із кластера в день його створення.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey виводить ключ у вигляді документа, призначеного для друку на папері та зберігання в іншому місці. Вважайте сам файл секретом, яким він є, оскільки будь-хто, хто володіє ним, може розшифрувати всі резервні копії, створені з його використанням. Для більших інсталяцій PBS також підтримує master key — пару ключів RSA (Rivest Shamir Adleman), створену за допомогою proxmox-backup-client key create-master-key. У цьому разі кожна резервна копія зберігає власний ключ шифрування, зашифрований відкритою частиною пари, а закрита частина залишається в автономному сховищі для відновлення.

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

Обрізання позначає, збір сміття звільняє місце

Цей етап часто пропускають, хоча саме він заповнює том. Обрізання snapshot видаляє його метадані: manifest, indexes, log і notes. Жоден chunk при цьому не видаляється. Chunks спільно використовуються кількома snapshot, тому визначити, що chunk більше не використовується, можна лише після читання всіх індексів, що залишилися. Саме це робить garbage collection. Datastore, для якого налаштовано розклад prune, але не налаштовано розклад garbage collection, лише збільшується.

Налаштуйте обидва розклади. Спочатку retention, по одному завданню на namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Потім налаштуйте розклад collection для datastore — через кілька годин після завдання prune і поза вікном резервного копіювання:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Один раз перевірте цей поділ на PBS host:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Запустіть завдання prune, потім df — показник використаного місця не зміниться. Запустіть garbage collection, а потім знову df — показник зміниться.

Garbage collection виконується у два етапи. На першому етапі процес проходить усі індекси datastore і оновлює час доступу для кожного chunk, на який посилаються ці індекси. На другому етапі видаляються chunks, час доступу до яких старший за граничний. Цей граничний час становить 24 години і 5 хвилин до моменту початку запуску або відповідає початку найстарішого backup, який ще записується, залежно від того, який час є ранішим. Такий запас потрібен тому, що Linux монтує файлові системи з параметром relatime за замовчуванням. Цей параметр оновлює час доступу приблизно раз на добу, а не під час кожного читання. Тому chunk, записаний годину тому, не буде видалено, навіть якщо на нього ще немає посилань. Місце, звільнене після prune, з’явиться лише під час першого collection, який запуститься більш ніж через добу після останнього звернення до chunk. Якщо здається, що datastore нічого не звільнив, часто причина полягає саме в цьому часовому вікні.

На невеликому VPS це найважче завдання для системи, оскільки воно перевіряє metadata кожного файлу chunk на томі. Журнал завдання завершується зведенням: що було видалено і що ще очікує через grace period. Якщо в очікуванні залишилося багато даних, запустіть завдання знову наступного дня. PBS надає gc-atime-safety-check і gc-atime-cutoff як параметри налаштування datastore. Обидва параметри слід залишити без змін. Вони призначені для сховищ, які не можуть записувати час доступу. Вимкнення перевірки безпеки у файловій системі, змонтованій з параметром noatime, може призвести до втрати chunks, на які ще посилаються snapshot, що зберігаються.

Перевірка підтверджує, що чанки все ще доступні для читання

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

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

На невеликому VPS використовуйте невелику кількість потоків. Перевірка обмежена продуктивністю диска та CPU. Інакше вона конкуруватиме за ресурси з іншими процесами на сервері. Щоб налаштувати розклад, відкрийте вкладку Verify Jobs сховища даних у вебінтерфейсі. Щотижневе завдання, яке пропускає вже перевірені знімки та повторно перевіряє все, що не перевірялося понад 30 днів, з часом охоплює все сховище без повторної непотрібної роботи.

Знімок, який не пройшов перевірку, позначається як невдалий у поданні сховища даних. Не ігноруйте такі випадки. Чанки спільно використовуються, тому один пошкоджений чанк із базового образу зазвичай призводить до помилки для кожного знімка, який на нього посилається. Щоб виправити проблему, забудьте невдалі знімки та запустіть нове резервне копіювання. Воно повторно завантажить відсутні чанки. Якщо помилки продовжують з’являтися, перевірте сховище, на якому розміщене сховище даних, і налаштуйте моніторинг стану диска на VPS, щоб накопичувач повідомив про проблему раніше, ніж це зробить завдання перевірки.

Перевірте відновлення, а потім перевірте його без кластера

Ви не дізнаєтеся, чи працює резервна копія, доки не відновите її. Ці два тести перевіряють різні речі.

Увесь guest у кластері:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

Перший стовпець pvesm list — це ідентифікатор тому. Мітка часу є його частиною, тому скопіюйте власне значення, а не вводьте приклад. Відновіть guest із невикористаним ідентифікатором на інше сховище, а потім запустіть його з від’єднаним мережевим інтерфейсом. Не відновлюйте поверх запущеного guest, щоб перевірити резервні копії. Якщо відновлення перерветься, ви також втратите робочу копію.

Другий тест майже ніхто не виконує. Припустімо, що будівлі з кластером більше немає, і відновіть дані з машини, яка ніколи не була його частиною. На будь-якій машині з Debian 13 додайте репозиторій лише для клієнта як /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

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

Що дедуплікація робить і чого не робить із витратами на диск

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

Важливо прямо сказати, чого вона не робить.

• Вона не зменшує обсяг даних, які змінюються. База даних, яка щоночі переписує великі частини своїх файлів, щоночі створює нові фрагменти, а політика зберігання примножує їх.
• Вона не працює через межу криптографічного ключа, як описано вище.
• Вона не працює через межу datastore, що і є основною причиною використовувати namespaces.
• Вона не запобігає заповненню тому. Коли datastore заповнений, резервне копіювання завершується помилкою, і варіантів лише два: збільшити том або скоротити термін зберігання.

Не додавайте ще один рівень дедуплікації під ним. Фрагменти надходять уже дедуплікованими та стисненими клієнтом, тому ZFS deduplication під datastore витрачає RAM на пошук збігів, які було видалено ще до запису. Для тому тут слід використовувати звичайну файлову систему ext4 або xfs.

Вебінтерфейс показує коефіцієнт дедуплікації для datastore. Це число описує ваші гостьові системи, і лише з ним варто планувати, оскільки опубліковані коефіцієнти описують чужі дані. Якщо вам також потрібні резервні копії окремих файлів на машинах, які не є гостьовими системами Proxmox, запускайте їх паралельно на тому самому VPS: PBS — це ціль із підтримкою гіпервізора для резервного копіювання цілих гостьових систем, тоді як restic і BorgBackup працюють із каталогами, а резервні копії restic на VPS підходять для ноутбуків і автономних серверів, для яких PBS ніколи не призначався.

Режими відмов і що ви побачите

Сховище має статус inactive. pvesm status --storage pbs-offsite виводить inactive, коли вузол не може завершити TLS-сеанс із портом 8007. Перевірте firewall на VPS, потім окремий мережевий firewall провайдера, а потім fingerprint. Fingerprint, який більше не відповідає сертифікату, спричиняє таку саму видиму помилку, як і заблокований порт. Він змінюється щоразу, коли цей сертифікат замінюють.

Перша резервна копія завершується помилкою доступу. В елементі керування доступом потрібно вказати token, а не користувача. Він також має охоплювати namespace, на який указує storage. Перш ніж перевіряти щось інше, підтвердьте обидва параметри на вкладці permissions datastore у вебінтерфейсі.

Garbage collection не запускається. Перевірка безпеки часу доступу завершилася помилкою. Майже завжди це означає, що файлову систему datastore змонтовано з параметром noatime. Виконайте findmnt -no OPTIONS /mnt/datastore/store1 для перевірки, виправте параметр у /etc/fstab і змонтуйте файлову систему повторно. Не вимикайте перевірку, щоб обійти цю помилку.

Datastore лише збільшується. Завдання prune запускаються, але дані не звільняються. Або не налаштовано розклад garbage collection, або кожен запуск відбувається протягом 24-годинного періоду зберігання, оскільки garbage collection запускається одразу після резервного копіювання. Перевірте розклад за допомогою proxmox-backup-manager datastore show store1.

Резервне копіювання, яке раніше виконувалося швидко, тепер триває кілька годин. Гостьова система, яку зупинили, перенесли або відновили, втрачає dirty bitmap. Тому під час наступного запуску кластер зчитує весь диск, хоча передає дуже мало даних. У журналі завдання видно велику тривалість і невеликий обсяг переданих даних. Наступний запуск знову виконується швидко. Якщо всі завдання на VPS працюють повільно, причина зазвичай не пов’язана з datastore. Спочатку виміряйте CPU steal time через надмірне навантаження сусіднього клієнта.

FAQ

Чому сховище даних Proxmox Backup Server продовжує зростати під час виконання завдання prune?

Тому що prune видаляє лише метадані snapshot: manifest, indexes, log і notes. Chunks залишаються на диску, доки garbage collection не видалить ті, на які більше не посилається жоден index. Налаштуйте розклад для сховища даних за допомогою proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' і перевірте результат, виконавши df -h для шляху до сховища до та після proxmox-backup-manager garbage-collection start store1. Очікуйте затримку щонайменше на один день, оскільки друга фаза видаляє лише chunks, час доступу до яких старший за 24 години та 5 хвилин.

Скільки дискового простору потрібно VPS із Proxmox Backup Server?

Підсумуйте фактичний обсяг даних, який використовує кожен guest, а потім додайте добовий обсяг змін кожного guest, помножений на кількість днів зберігання. Це верхня оцінка, оскільки compression і deduplication зменшують потрібний обсяг. Додайте приблизно п’яту частину для indexes і робочого простору, а потім округліть значення в більший бік до доступного розміру volume. Через два тижні повторно перевірте розрахунок за фактичним використанням у поданні datastore, оскільки оцінка до створення першої backup завжди буде неточною.

Де слід зберігати encryption key для backup?

У будь-якому місці, крім самого cluster, який він захищає. Proxmox VE зберігає його в /etc/pve/priv/storage/<storage>.enc. Цей файл реплікується на кожен node, тому буде втрачений разом із cluster. Скопіюйте його в інше місце в перший день, виведіть на друк за допомогою proxmox-backup-client key paperkey і зберігайте копію в іншій будівлі. Також врахуйте, що key бере участь у формуванні digest для chunk, тому його подальша заміна призведе до повторного завантаження всіх даних під час наступної backup.

Чи потрібен окремий datastore для кожного Proxmox host, чи достатньо namespaces?

Один datastore і один namespace для кожного source host або cluster. Deduplication працює в межах datastore, але не між datastore, тому розділення за host призводить до повторного зберігання однакових базових images. Namespaces розділяють backup groups, тому два host, які мають guest з ID 100, не конфліктують, а шлях контролю доступу у форматі /datastore/store1/pve-home обмежує API token кожного host його власним namespace.

Чи впорається невеликий VPS із роботою backup server для Proxmox?

Зазвичай так, у homelab, оскільки chunking і hashing виконуються на Proxmox VE node, а не на backup server. VPS записує chunks і запускає два ресурсоємні завдання: garbage collection та verification. Виділіть йому 4 GB RAM і встановіть невелику кількість потоків для verification. Заплануйте обидва завдання поза вікном виконання backup. Якщо вони все одно тривають значно довше, ніж має тривати робота з таким диском, перевірте steal time, перш ніж купувати дорожчий план.