Для Proxmox Backup Server із захистом 1 ТБ даних достатньо 4 vCPU, 16 GB RAM і 2 TB NVMe/SSD, а для 20 ТБ і десятків ВМ потрібен виділений сервер із 8–12 vCPU, 64–128 GB ECC RAM, швидким ZFS-пулом і портом від 1 Gbps.
Вимоги Proxmox Backup Server: що насправді навантажує сервер
Диски та IOPS важливіші за номінальну частоту CPU
Основні proxmox backup server requirements визначає не сама кількість віртуальних машин, а обсяг даних, що змінюються, число паралельних завдань і глибина зберігання. PBS приймає чанки, обчислює хеші, звертається до індексів дедуплікації, записує нові блоки та періодично виконує verify. На повільному HDD-масиві процес впирається у випадкові операції читання й запису: вікно резервного копіювання збільшується, а перевірка цілісності створює відчутну затримку.
Для невеликого сховища HDD допустимі лише за наявності SSD/NVMe для metadata, журналу ZFS та індексів. Якщо datastore повністю розташований на HDD, обирайте масив із RAID10 або ZFS mirror/striped mirrors, а не один диск. Один HDD на 7 200 RPM зазвичай забезпечує близько 80–180 випадкових IOPS — цього недостатньо для комфортної паралельної роботи кількох backup і verify-завдань.
Практичний орієнтир: NVMe рівня PCIe 3.0/4.0 із 3 000+ MB/s послідовного читання та десятками тисяч IOPS помітно скорочує backup window. Водночас для PBS важливіші стабільна затримка запису та ресурс TBW, ніж пікова швидкість із рекламної специфікації накопичувача.
Навіщо PBS використовує RAM
Proxmox backup server ram cpu варто розраховувати із запасом для файлового кешу, ZFS ARC, індексів чанків і одночасних операцій відновлення. Дедуплікація в PBS не потребує завантаження всіх захищених даних у пам'ять, але нестача RAM спричиняє часті звернення до диска. На HDD це особливо критично: швидкість verify та garbage collection може знизитися в кілька разів.
Мінімальні 8 GB RAM підходять для тестового PBS із кількома ВМ та обсягом до 500 GB. Для робочого datastore на 1–5 ТБ розумний мінімум — 16–32 GB. За використання ZFS і захисту 10–20 ТБ даних краще планувати 64 GB, а за великої кількості snapshots, namespace і паралельних завдань — 128 GB ECC.
Загальні принципи розрахунку інфраструктури корисно порівняти з матеріалом про вибір обладнання для self-hosted застосунків: пам'ять має покривати не лише процес PBS, а й кеш файлової системи, сервіси моніторингу та запас для пікових операцій.
Який сервер потрібен для Proxmox Backup Server на 1, 5 і 20 ТБ
Специфікація за масштабом навантаження
Для 5 ТБ захищених даних і до 30 ВМ достатньо 6 vCPU, 32 GB RAM, 8 TB NVMe/SSD та мережевого порту 1 Gbps.
| Масштаб навантаження | vCPU | RAM | Диск datastore | Мережевий порт | Ціна |
|---|---|---|---|---|---|
| До 1 TB, 5–10 ВМ | 4 vCPU | 16 GB | 2 TB NVMe або 2 × 2 TB SSD mirror | 1 Gbps | Орієнтовно від $25/міс., березень 2025 |
| До 5 TB, 10–30 ВМ | 6 vCPU | 32 GB | 8 TB usable: 2 × 8 TB SSD/HDD mirror + NVMe metadata | 1 Gbps | Орієнтовно від $70/міс., березень 2025 |
| До 20 TB, 30–100 ВМ | 8–12 vCPU | 64–128 GB ECC | 32–48 TB usable: ZFS mirror/RAID10, 1–2 TB NVMe cache/metadata | 1–10 Gbps | Орієнтовно від $180/міс., березень 2025 |
Ціни наведено як загальноринковий орієнтир для серверів відповідного класу й вони не є публічним прайсом конкретного провайдера. Фактична вартість залежить від країни розміщення, типу дисків, обсягу трафіку, RAID-контролера, IPMI та SLA.
Як підібрати корисний обсяг диска
Не варто виділяти datastore рівно за розміром вихідних ВМ. Базова формула:
Требуемый объём datastore =
защищаемые данные × коэффициент хранения × запас 20–30%Для 5 ТБ фактично зайнятих даних і 14 щоденних точок відновлення коефіцієнт може становити від 1,2 до 3,0. Усе залежить від churn rate — частки даних, що змінюються за добу. Для файлового сервера зі змінами 1–2% дедуплікація та інкрементальні backup працюватимуть добре. Для бази даних, яка щодня перезаписує великі файли, коефіцієнт буде помітно вищим.
Приклад: 5 ТБ даних, середня добова зміна 3%, зберігання 14 точок. Первинний backup займає близько 5 ТБ, а наступні зміни додають приблизно 2,1 ТБ. З урахуванням службових даних і запасу потрібен datastore щонайменше 9–10 ТБ usable, а не 5 ТБ.
Шукаєте надійний сервер для своїх проєктів?
VPS від $10/міс. і виділені сервери від $9/міс. із NVMe, DDoS-захистом і підтримкою 24/7.
Переглянути пропозиції →Скільки RAM потрібно для Proxmox Backup Server і ZFS
Практичні рівні пам'яті
Питання скільки RAM для Proxmox Backup Server не можна вирішити правилом «1 GB на 1 TB»: PBS, ZFS, навантаження verify та кількість одночасно активних клієнтів мають різні профілі. Для не-ZFS datastore на ext4/xfs 16 GB зазвичай достатньо за обсягу до 2–3 ТБ. Але для ZFS доцільніше починати з 32 GB, щоб ARC не витіснявся надто агресивно та не заважав службовим процесам.
- 8 GB RAM — лабораторний стенд, до 500 GB, 1–2 ВМ, без інтенсивного verify.
- 16 GB RAM — до 1–2 ТБ, до 10 ВМ, SSD/NVMe datastore.
- 32 GB RAM — до 5 ТБ, до 30 ВМ, ZFS mirror і щоденні перевірки.
- 64 GB ECC RAM — 10–20 ТБ, кілька завдань backup/restore одночасно.
- 128 GB ECC RAM — великий datastore, 20+ ТБ, багато namespace, ZFS і тривале зберігання.
ECC-пам'ять не прискорює backup безпосередньо, але знижує ризик непоміченої помилки в пам'яті на сервері, який зберігає єдину резервну копію. Для продакшн-сховища це виправдана інвестиція.
Обмеження ARC без шкоди для PBS
Якщо PBS встановлено на сервері з 32 GB RAM і ZFS забирає надто багато кешу, можна встановити обмеження ARC. Не задавайте ліміт без моніторингу: спочатку перевірте фактичне споживання пам'яті, swap і затримку дисків.
cat /proc/spl/kstat/zfs/arcstats | grep -E "size|c_max"
echo "options zfs zfs_arc_max=17179869184" > /etc/modprobe.d/zfs.conf
update-initramfs -u
rebootУ прикладі ARC обмежено до 16 GB. На сервері з 32 GB це залишає місце для PBS, ядра та моніторингу. Для 64 GB RAM зазвичай немає потреби обмежувати ARC, якщо на вузлі не працюють інші важкі сервіси.
Апаратні вимоги Proxmox Backup Server: CPU, диски та ZFS-пул
Який CPU потрібен для backup, verify і restore
Proxmox backup server hardware має забезпечувати стабільну багатопотокову обробку хешів, стиснення та мережевого вводу-виводу. Для 1 ТБ даних достатньо 4 сучасних vCPU із частотою від 2,5 GHz. Для 5 ТБ і 10–30 ВМ підходять 6 ядер. На рівні 20 ТБ варто обирати 8–12 фізичних або високопродуктивних віртуальних ядер.
CPU рідко стає першим обмеженням, якщо datastore розташований на швидкому NVMe. Але за увімкненого стиснення, кількох одночасних backup-завдань і verify 4 vCPU можуть постійно бути завантаженими на 70–100%. Не розміщуйте PBS на тому самому перевантаженому вузлі, де працюють критичні ВМ: у разі аварії хоста резервні копії мають залишатися доступними.
ZFS mirror чи RAIDZ?
Для PBS пріоритетом є передбачувані IOPS і можливість швидко відновити дані. Для 2 дисків обирайте ZFS mirror. За 4–8 дисків для активного backup datastore частіше вигідніші striped mirrors: вони забезпечують більше випадкових IOPS, ніж RAIDZ2. RAIDZ2 підходить для більш місткого архіву, де швидкість restore і verify не критична.
Корисно ознайомитися з особливостями ZFS і контролю цілісності в матеріалі про обладнання та ZFS на виділеному сервері. Для PBS особливо важливі регулярні scrub і моніторинг SMART: дедуплікація заощаджує місце, але не замінює відмовостійкість носіїв.
zpool create -o ashift=12 pbs-pool mirror \
/dev/disk/by-id/disk1 \
/dev/disk/by-id/disk2
zfs create -o compression=zstd -o atime=off pbs-pool/datastore
zpool status
zfs listПараметр ashift=12 відповідає сектору 4K і безпечний для сучасних SSD/HDD. Не використовуйте dedup на рівні ZFS для PBS datastore: PBS уже виконує власну дедуплікацію, а ZFS dedup споживає багато пам'яті та ускладнює sizing.
Підбір обладнання для PBS deduplication: як оцінити дедуплікацію
Що заощаджує місце, а що ні
PBS deduplication hardware sizing залежить від характеру даних сильніше, ніж від сумарного обсягу дисків. PBS розбиває потік backup на чанки та зберігає повторювані блоки один раз. Високий ефект дають клони ВМ, однотипні Linux-сервери, шаблони контейнерів і середовища розробки. Якщо 20 ВМ створені з одного образу ОС, дедуплікація може прибрати десятки або сотні гігабайтів повторів.
Погано дедуплікуються заздалегідь стиснені, зашифровані та файли з постійною зміною внутрішньої структури: ZIP, JPEG, відео, encrypted volumes, деякі образи баз даних. Для таких навантажень не закладайте «магічну» економію 70–90%. Консервативний розрахунок використовує коефіцієнт 1,5–2,5 від обсягу фактично використаних даних, а потім коригується за метриками після першого місяця.
Verify, garbage collection і вільне місце
Verify читає дані datastore і перевіряє їхню цілісність. На HDD-масиві обсягом 20 ТБ повна перевірка може тривати понад добу, особливо якщо паралельно виконуються backup. На NVMe-пулі аналогічна операція зазвичай вкладається у значно коротше вікно, але все одно потребує обмеження паралелізму, щоб не погіршити RPO.
Залишайте щонайменше 20% вільного простору, а за високого темпу змін — 30%. Коли ZFS-пул заповнений більш ніж на 80–85%, зростають фрагментація, latency і ймовірність того, що черговий backup завершиться помилкою через нестачу місця. Плануйте garbage collection після завершення retention, наприклад уночі, окремо від інтенсивних backup-завдань.
Мережа та вікно резервного копіювання: скільки трафіку потрібно PBS
Розрахунок часу первинного backup
Мережа — частина pbs system requirements, особливо якщо PBS розміщено в іншому дата-центрі. Реальна корисна швидкість порту 1 Gbps зазвичай становить близько 90–110 MB/s з урахуванням протоколів, дискової підсистеми та навантаження клієнта. Передавання 1 ТБ за стабільних 100 MB/s триває приблизно 2 години 50 хвилин; 5 ТБ — близько 14–15 годин.
Время, часы = объём данных в GB / (скорость в MB/s × 3,6)
5000 GB / (100 MB/s × 3,6) ≈ 13,9 часаПервинна копія майже завжди потребує окремого вікна. Наступні інкрементальні backup передають лише нові чанки, тому за добової зміни 2% від 5 ТБ мережею передаватиметься орієнтовно 100 GB плюс metadata. На порту 1 Gbps це близько 20–30 хвилин за відсутності вузьких місць на джерелі та datastore.
Практичні рекомендації щодо мережі
- Розміщуйте PBS на окремому вузлі або в окремій локації, щоб відмова одного Proxmox-хоста не знищила і робочі ВМ, і копії.
- Використовуйте 1 Gbps для обсягу до 5 ТБ за нічного вікна від 6–8 годин; для 20 ТБ або короткого RPO обирайте 10 Gbps.
- Налаштуйте ліміти bandwidth на backup job, якщо денна реплікація заважає користувацькому трафіку.
- Перевіряйте фактичну пропускну здатність через
iperf3, а не лише за заявленою швидкістю мережевого порту. - Для віддаленого PBS враховуйте вихідний трафік під час restore: аварійне відновлення 5 ТБ може зайняти багато годин навіть на 1 Gbps.
Цей принцип особливо корисний для ігрових інстансів: наприклад, дані світу та модів для Factorio-сервера зі зростаючою фабрикою змінюються інакше, ніж образи статичних веб-ВМ. Враховуйте фактичний churn файлів, а не тільки розмір папки з грою.
Вимоги до сервера Proxmox Backup: приклад налаштування та моніторингу
Мінімальна безпечна архітектура
Для малого бізнесу робоча схема має такий вигляд: Proxmox VE-кластер зберігає ВМ на локальному RAID/ZFS, окремий PBS-сервер приймає щоденні backup, а найкритичніші дані додатково реплікуються в інший datastore або на другий PBS. Правило 3-2-1 залишається актуальним: щонайменше 3 копії, на 2 типах носіїв, 1 копія поза основним майданчиком.
Не вважайте backup завершеним лише тому, що завдання отримало статус OK. Щонайменше раз на квартал виконуйте тестовий restore однієї ВМ і одного файлу в ізольовану мережу. Для критичних баз даних перевіряйте не лише відновлення диска, а й запуск застосунку.
Які метрики контролювати
Моніторинг має відстежувати вільне місце, SMART, температуру дисків, ZFS pool health, час виконання backup, кількість помилок verify і швидкість мережі. Якщо щоденне завдання, яке тривало 25 хвилин, раптово почало виконуватися 90 хвилин, причина часто полягає в деградації SSD, переповненні пулу або зміні обсягу даних.
# Проверка ZFS и свободного места
zpool status
zpool list
df -h
# SMART NVMe
smartctl -a /dev/nvme0
# Проверка пропускной способности сети
iperf3 -c IP_СЕРВЕРА_PBS -P 4Якщо ви одночасно запускаєте self-hosted сервіси та backup, розділяйте навантаження. Наприклад, self-hosted LLM може зайняти значну частину RAM і CPU, тому її не варто розміщувати на PBS-хості з 32 GB пам'яті без запасу.
Часті запитання
Чи можна встановити Proxmox Backup Server на VPS?
Так, для невеликого datastore до 1 ТБ VPS із 4 vCPU, 16 GB RAM і NVMe-диском підходить для PBS. Але перевірте, що провайдер гарантує достатні IOPS і дозволяє інтенсивне дискове навантаження. Для зберігання єдиної копії критичних ВМ краще використовувати виділений сервер з ECC RAM і фізично окремими дисками.
Чи обов'язково використовувати ZFS для PBS?
ZFS не є обов'язковою: PBS може працювати з ext4 або xfs. Проте ZFS забезпечує checksums, scrub, snapshots і зручну роботу з mirror. Для datastore від 5 ТБ ZFS mirror з 32 GB RAM — надійний варіант. Не вмикайте ZFS dedup: вбудована дедуплікація PBS уже ефективніше виконує це завдання.
Скільки місця виділяти для 5 ТБ віртуальних машин?
Для 5 ТБ фактично зайнятих даних зазвичай планують від 8 до 12 ТБ usable-ємності, якщо зберігається 14–30 точок відновлення, а добовий churn становить 1–3%. Для баз даних, encrypted volumes або змін понад 5% потрібен запас 12–15 ТБ. Після першого повного backup уточніть розрахунок за реальним зростанням datastore.
Чому verify уповільнює PBS?
Verify читає чанки та перевіряє контрольні суми, тому створює інтенсивне навантаження на диск. На одному HDD із 100 IOPS перевірка кількох ТБ може конкурувати з нічними backup-завданнями. Використовуйте NVMe, ZFS mirror або окреме вікно verify; для datastore 20 ТБ плануйте 64 GB RAM і не запускайте всі перевірки одночасно.
Висновки
Для PBS до 1 ТБ обирайте 4 vCPU, 16 GB RAM і NVMe; для 5 ТБ — 6 vCPU, 32 GB RAM і ZFS mirror із запасом ємності щонайменше 30%. Для захисту 20 ТБ і десятків ВМ критичні 64–128 GB ECC RAM, швидкі IOPS, окремий сервер і мережа від 1 Gbps. Не заощаджуйте на дисках: повільний datastore збільшує backup window, verify і час аварійного відновлення.
Bare metal у 70+ локаціях: сучасне обладнання, NVMe, швидка видача, оплата карткою або криптовалютою.
Підібрати сервер
