Для 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 requirements: что действительно нагружает сервер
Диск и 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: требования по объёму 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 и latency дисков.
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 hardware: 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 hardware sizing: как оценить дедупликацию
Что экономит место, а что не экономит
PBS deduplication hardware sizing зависит от характера данных сильнее, чем от суммарного размера дисков. PBS разбивает поток backup на чанки и хранит повторяющиеся блоки один раз. Высокий эффект получают клоны ВМ, однотипные Linux-серверы, шаблоны контейнеров и среды разработки. Если 20 ВМ созданы из одного образа ОС, дедупликация может убрать десятки или сотни гигабайт повторов.
Плохо дедуплицируются заранее сжатые, зашифрованные и постоянно меняющие внутреннюю структуру файлы: ZIP, JPEG, видео, encrypted volumes, некоторые образы баз данных. Для таких нагрузок не закладывайте «магическую» экономию 70–90%. Консервативный расчёт использует коэффициент 1,5–2,5 от объёма фактически используемых данных и потом корректируется по метрикам после первого месяца.
Verify, garbage collection и свободное место
Verify читает данные datastore и проверяет их целостность. На 20 ТБ HDD-массиве полная проверка может занять более суток, особенно если параллельно идут 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 плюс метаданные. На порте 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, быстрая выдача, оплата картой или криптой.
Подобрать сервер
