29 апреля 2026 года вышел Proxmox Backup Server 4.2. Формально это промежуточный релиз: обновили базовую систему до Debian 13.4 Trixie, поставили Linux 7.0 как новый стабильный вариант ядра, добавили ZFS 2.4.1, поправили ошибки и доработали интерфейс. Но по смыслу релиз заметнее, чем кажется: S3-совместимые объектные хранилища стали официально поддерживаемыми, синхронизация между серверами научилась работать параллельно, появились шифрование и расшифровка на стороне сервера для задач синхронизации, а группы резервных копий и пространства имён теперь можно перемещать внутри хранилища.
То есть Proxmox Backup Server постепенно уходит от образа «удобной бэкапницы рядом с Proxmox VE». Он становится отдельным сервером резервного копирования: с дедупликацией, политиками хранения, проверкой целостности, удалённой синхронизацией, S3-хранилищами, лентами и внятной эксплуатационной моделью. Нет, не универсальной заменой всем системам резервного копирования на свете, но очень естественным инструментом для тех, у кого инфраструктура уже построена вокруг Proxmox.
Что такое Proxmox Backup Server
Proxmox Backup Server, или PBS, — это клиент-серверная система резервного копирования для виртуальных машин, контейнеров и физических Linux-хостов. Она особенно хорошо интегрирована с Proxmox VE, но не является просто «галочкой в интерфейсе гипервизора». У PBS есть собственный web-интерфейс, API, пользователи, права, хранилища, задачи синхронизации, проверка целостности, очистка старых данных, поддержка лент и отдельный клиент для файловых резервных копий. В документации Proxmox описывает PBS как систему корпоративного уровня для резервного копирования виртуальных машин, контейнеров и физических хостов, специально оптимизированную под Proxmox VE.
Главная идея PBS — не складывать каждую ночную копию как отдельный огромный архив. Данные режутся на фрагменты, одинаковые фрагменты переиспользуются между разными снимками, а на сервере работает дедупликация. Снаружи администратор видит обычные точки восстановления: вот копия за понедельник, вот за вторник, вот за среду. Внутри же хранится не три полных набора одинаковых данных, а набор фрагментов и индексы, которые описывают, из каких фрагментов состоит каждый снимок.
Для виртуальных машин используются фрагменты фиксированного размера, обычно около 4 МБ. Proxmox VE может использовать QEMU dirty bitmaps, чтобы понимать, какие блоки диска менялись после прошлого резервного копирования, и отправлять только изменившиеся части. Для файловых копий подход другой: PBS использует формат pxar и фрагменты переменного размера, чтобы изменение длины одного файла не ломало дедупликацию всего последующего потока данных.
В результате PBS хорошо попадает в типичный сценарий виртуализации: виртуальных машин много, данные в них частично повторяются, изменения между соседними копиями сравнительно небольшие, а передавать каждую ночь полные образы дисков не хочется.
Почему он так хорошо ложится на Proxmox VE
PBS можно добавить в Proxmox VE как обычное хранилище типа pbs. После этого виртуальные машины и контейнеры резервируются привычным способом из интерфейса Proxmox VE. Начиная с Proxmox VE 6.3, интеграция есть и через API, и через web-интерфейс: сервер резервного копирования добавляется в Datacenter -> Storage, после чего его можно использовать как цель для резервных копий. (pbs.proxmox.com)
Это важная разница по сравнению с внешними системами, которые приходится прикручивать сбоку. Не надо ставить отдельный агент в каждую виртуальную машину только ради базовой копии диска. Не надо писать свои расписания, поддерживать гору скриптов и объяснять каждому администратору, где теперь искать восстановление. Для Proxmox VE PBS выглядит как родной компонент: добавили хранилище, настроили задания, проверили права, включили расписание.
При этом PBS не надо идеализировать. Это не замена Veeam во всех возможных сценариях, не универсальный агент для большого парка Windows-серверов и не система резервного копирования приложений уровня «понимаю все состояния Exchange, SQL Server и Oracle». Его сильная зона — Proxmox VE, Linux-хосты, удалённые копии, дедупликация, проверка целостности и понятное хранение резервных снимков.
Что изменилось в версии 4.2
В 4.2 есть несколько изменений, которые выглядят именно как признаки взросления продукта.
Первое — официальная поддержка S3-совместимых объектных хранилищ. В PBS 4.0 и 4.1 эта возможность уже была, но считалась предварительной. Теперь она вышла из предварительного статуса и считается поддерживаемой. Это значит, что datastore можно размещать не только на локальном диске или файловой системе, но и в S3-совместимом объектном хранилище. (pbs.proxmox.com)
Второе — параллельная синхронизация групп резервных копий. Задачи синхронизации теперь могут обрабатывать несколько групп одновременно через параметр worker-threads. Это особенно полезно при синхронизации между площадками, когда задержка сети мешает одному последовательному потоку нормально загрузить канал. (pbs.proxmox.com)
Третье — шифрование и расшифровка на стороне сервера при синхронизации. Push-задача может зашифровать снимки перед отправкой на удалённый PBS, а pull-задача может расшифровать снимки, которые были зашифрованы на удалённой стороне. Это удобно, когда локальному PBS вы доверяете, а удалённый сервер стоит в менее доверенной площадке. (pbs.proxmox.com)
Четвёртое — перемещение групп и пространств имён внутри одного хранилища. Звучит скромно, но для долгоживущей инфраструктуры это очень полезно. За годы меняются имена машин, кластеры, владельцы, проекты, структура окружений. Раньше старые резервные копии могли оставаться в исторически сложившемся беспорядке. Теперь их можно аккуратно переносить внутри datastore, а PBS следит за согласованностью через блокировки на уровне групп. (Proxmox)
Пятое — эксплуатационные доработки: статистика запросов и трафика для S3-хранилищ, уведомления при превышении порогов, улучшенные журналы задач синхронизации, поддержка HTTP-прокси для удалённых соединений и S3, исправления в обработке повреждённых служебных файлов задач, доработки для ленточных библиотек. Это не выглядит эффектно в пресс-релизе, зато такие вещи хорошо заметны тем, кто потом живёт с системой каждый день. (pbs.proxmox.com)
S3: теперь поддерживается, но думать всё равно надо
Самое заметное изменение 4.2 — официальная поддержка S3-совместимых объектных хранилищ как места хранения резервных копий. Это может быть AWS S3, Cloudflare R2, Ceph RGW или другое совместимое хранилище. В PBS настраивается S3 endpoint, затем создаётся datastore с S3 backend. Сам PBS при этом не создаёт bucket и не управляет правами доступа в облаке: bucket, ключи и разрешения нужно подготовить заранее на стороне провайдера. PBS требует права на получение, запись, перечисление и удаление объектов. (pbs.proxmox.com)
Но S3 — это не просто «диск, только где-то в облаке». У него другая экономика и другие отказы. Провайдер может брать деньги не только за объём хранения, но и за API-запросы, исходящий трафик и пропускную способность. Поэтому в 4.2 появились счётчики запросов, статистика трафика и пороги уведомлений для S3-backed datastore. Это не декоративная метрика, а способ не узнать о проблеме только после счёта от провайдера. (Proxmox)
Есть и техническая деталь: даже если содержимое datastore лежит в объектном хранилище, PBS всё равно нужен локальный постоянный кэш. Документация рекомендует 64–128 ГБ локального кэша и советует выделить под него отдельный диск, раздел или ZFS dataset с quota. Кэш нужен для производительности и для уменьшения числа обращений к объектному хранилищу. (pbs.proxmox.com)
Поэтому использовать S3 в PBS стоит не с мыслью «теперь можно не покупать диски», а с нормальным расчётом: сколько будет копий, сколько будет изменений, как часто потребуется восстановление, сколько стоит исходящий трафик, что будет при массовом restore, как быстро работает объектное хранилище и как поведёт себя локальный кэш.
Для небольшой инфраструктуры хорошая схема может выглядеть так: основной PBS стоит локально на нормальном дисковом массиве, а S3 используется как удалённая копия или дополнительный уровень хранения. Делать S3 единственным местом, где лежат все резервные копии, можно, но это уже требует более аккуратного проектирования.
Синхронизация между серверами стала полезнее
Удалённая синхронизация — одна из сильных сторон PBS. Можно держать быстрый локальный сервер резервного копирования рядом с Proxmox-кластером, а потом синхронизировать данные на другой PBS: в другой стойке, другом офисе, другом дата-центре или у провайдера. Документация описывает remote и sync jobs как штатный способ копировать datastore на другую площадку; при этом передаются только новые данные. (pbs.proxmox.com)
В версии 4.2 синхронизация стала заметно лучше. Раньше задача могла упираться не столько в скорость канала, сколько в задержку сети и последовательную обработку групп. Теперь можно настроить несколько рабочих потоков, и PBS будет обрабатывать несколько групп резервных копий параллельно. Для локальной сети это может быть не так важно, но для связи между площадками — очень заметно.
Вторая важная вещь — шифрование при отправке на удалённый сервер. Допустим, локальный PBS стоит в вашей серверной и считается доверенным. Второй PBS стоит у внешнего провайдера или в филиале, где требования к доверию ниже. Теперь push-задача может шифровать снимки перед отправкой туда. Уже зашифрованные снимки повторно не шифруются, а отправляются как есть. (pbs.proxmox.com)
Это не отменяет клиентского шифрования. Если нужно, чтобы даже основной PBS не видел содержимое резервных копий, шифровать надо на стороне клиента. Но для обычной схемы «локальный доверенный PBS + менее доверенная удалённая площадка» новое серверное шифрование при синхронизации выглядит очень практично.
Перемещение групп и пространств имён: скучно, но нужно
В описаниях релизов обычно все смотрят на S3, шифрование и производительность. Но возможность перемещать группы резервных копий и пространства имён внутри datastore — не менее полезная в жизни админа вещь.
Резервное хранилище живёт долго. Виртуальные машины переименовывают. Кластеры объединяют и разделяют. Тестовые окружения становятся промышленными, а потом снова переезжают. Появляются новые правила именования. Через несколько лет в backup-хранилище легко получить слой археологии: тут старое имя сервера, тут бывший проект, тут тестовый namespace, который давно стал рабочим.
В 4.2 такие вещи можно разбирать без ручного ковыряния в структуре datastore. PBS умеет переносить группы и namespaces внутри одного хранилища и при этом следит за согласованностью операций. В changelog отдельно указаны блокировки на уровне групп и нормальная обработка конфликтов с возможностью повторить частично выполненное перемещение.
Да, это не та функция, ради которой есть смысл обновляться в домашней лаборатории. Но для инфраструктуры, где PBS хранит копии сотен виртуальных машин за несколько лет, это очень правильное изменение.
Как PBS хранит данные и почему ему нужны нормальные диски
PBS технически не похож на простую папку с архивами. Datastore содержит снимки, индексы, служебные файлы и каталог с фрагментами данных. Разные снимки могут ссылаться на одни и те же фрагменты. За счёт этого дедупликация экономит место, но хранилище становится чувствительным к задержкам и количеству операций ввода-вывода.
Документация Proxmox прямо рекомендует для боевой установки быстрые хранилища с высоким числом операций ввода-вывода. В требованиях указаны современный 64-битный процессор минимум с четырьмя ядрами, минимум 4 ГБ памяти для системы и служб PBS, плюс примерно 1 ГБ ОЗУ на каждый ТБ хранилища. Для дисковой подсистемы рекомендуется либо аппаратный RAID с защищённым кэшем записи, либо избыточная схема на ZFS; при этом ZFS поверх аппаратного RAID Proxmox официально не поддерживает.
Это важный момент. PBS можно поставить почти куда угодно, но хорошая система резервного копирования начинается не с красивого интерфейса, а с нормального хранения. «Один старый HDD под бэкапы» — это лабораторный вариант, а не промышленная схема. Особенно если планируются частые проверки целостности, очистка старых данных, синхронизация и быстрое восстановление.
Ставить PBS на сам Proxmox VE — можно, но не надо
Технически PBS можно установить поверх Debian, можно поставить с ISO на отдельный сервер, а можно установить прямо на Proxmox VE. Но последний вариант в документации прямо не рекомендуется: безопаснее использовать отдельный физический сервер для хранения резервных копий, чтобы при отказе гипервизора доступ к копиям сохранялся.
Для домашней лаборатории PBS в виртуальной машине на том же Proxmox — нормальный способ познакомиться с продуктом. Для боевого контура это плохая привычка. Если один узел одновременно держит рабочие виртуальные машины и их резервные копии, то при серьёзной аварии можно потерять и нагрузку, и удобный путь восстановления.
Нормальная схема выглядит иначе: Proxmox VE отдельно, PBS отдельно, хранилище резервных копий отдельно, удалённая копия отдельно. И желательно периодически проверять не только то, что задания резервного копирования «зелёные», но и то, что восстановление действительно работает.
Физические Linux-хосты тоже можно копировать
PBS полезен не только для виртуальных машин и контейнеров из Proxmox VE. Есть утилита proxmox-backup-client, которой можно делать файловые резервные копии Linux-хостов. В версии 4.2 у клиента появились отдельные параметры для компонентов адреса хранилища: сервер, порт, datastore, учётная запись, namespace. Раньше это чаще передавалось одной строкой repository, теперь настройку проще разложить на отдельные параметры и переменные окружения. Также появилась переменная PBS_NAMESPACE.
Кроме того, клиент теперь поддерживает входные данные через FIFO pipe для image backups. Иными словами, образ можно передавать в PBS потоком, не обязательно заранее знать его размер и класть его во временный файл. Это уже не функция для обычного «нажал кнопку в интерфейсе», а полезная возможность для скриптов и нестандартных процедур резервного копирования.
Но здесь тоже не надо путать возможности. PBS-клиент — это прежде всего история про Linux. Если в инфраструктуре много Windows-серверов и нужен прикладной, application-aware backup, то PBS не закрывает такую задачу сам по себе.
Ленты всё ещё живы
В PBS есть поддержка ленточных накопителей и библиотек. Для малого бизнеса и домашних лабораторий это может звучать как привет из прошлого, но в крупных инфраструктурах ленты до сих пор имеют смысл: долгосрочное хранение, вынос носителя за пределы площадки, защита от части сценариев шифровальщиков и аварий, где online-хранилище может быть уничтожено или повреждено.
В 4.2 ленты не получили громкой новой функции, но получили эксплуатационные доработки: в web-интерфейсе теперь допускается до 256 приводов на changer, исправлена работа с устройствами, которым нужны выровненные размеры буфера при настройке шифрования, улучшен разбор SCSI-строк у ленточного оборудования.
Это как раз ещё один случай, когда изменение выглядит скучно, но для людей с реальными ленточными библиотеками оно важнее очередной красивой кнопки в интерфейсе.
Безопасность: шифрование, права, проверки
PBS поддерживает TLS для обмена между клиентом и сервером, клиентское шифрование резервных данных и проверку целостности через SHA-256. В документации отдельно подчёркивается, что данные можно шифровать на стороне клиента перед отправкой на сервер, что полезно при резервном копировании в не полностью доверенные места.
В 4.2 к этому добавились новые сценарии шифрования при синхронизации между PBS-серверами. Это не революция в криптографии, а практичная доработка модели доверия. Теперь можно точнее решить, кому вы доверяете: исходному серверу, удалённому серверу, клиенту, конкретной площадке.
Также в 4.2 исправлены отдельные проблемы безопасности и надёжности: например, ошибка, позволявшая при наличии сильной привилегии Sys.Modify внедрять произвольные опции в вызов apt-get, утечка информации о существовании пользователя при некоторых условиях, а также интеграция исправлений AppArmor.
Для администратора вывод простой: PBS даёт нормальные инструменты, но безопасность всё равно проектируется руками. Нужны отдельные пользователи и токены, минимальные права, двухфакторная аутентификация для администраторов, защищённые ключи шифрования, удалённая копия, регулярная проверка восстановления и аккуратная политика удаления старых снимков.
Обновление до 4.2
PBS 4.2 доступен как ISO-образ для установки на отдельный сервер. Также его можно поставить поверх существующего Debian или обновить через обычный APT. Продукт остаётся свободным ПО под GNU AGPLv3, а платная подписка даёт доступ к Enterprise Repository и коммерческой поддержке. В пресс-релизе Proxmox указывает цену подписки от 560 евро за сервер в год, без искусственных ограничений на объём backup storage и число клиентов.
При обновлении с PBS 3.x до 4.x надо идти по инструкции, а не просто «поменял репозиторий и нажал Enter». Это сервер резервного копирования, и перед крупным обновлением у него самого должна быть резервная стратегия. Минимально разумно иметь удалённую копию важных данных, проверить доступ к консоли, понимать, что будет с сетевыми интерфейсами после нового ядра, и не делать такое обновление в момент, когда резервные копии нужны прямо сейчас.
В release notes для 4.2 указано, что известных проблем и ломающих изменений на момент выхода нет. Хотя это и занудно, но еще раз подчеркну: обновление должно пройти спокойно, но эта надежда не повод обновлять единственный backup server без плана отката.
Где PBS хорош
PBS хорош там, где Proxmox VE уже является основной платформой виртуализации. В таком окружении он закрывает большую часть базовых и средних задач резервного копирования без лишней обвязки: копии VM и LXC, дедупликация, сжатие, проверка целостности, восстановление отдельных объектов, удалённая синхронизация, шифрование, ленты, S3, права доступа и web-интерфейс.
Он также хорош для небольших и средних инфраструктур, где не хочется покупать тяжёлый коммерческий backup suite, но хочется не просто «rsync куда-нибудь», а нормальную систему с понятной моделью хранения.
Отдельный плюс — отсутствие искусственных ограничений на число клиентов и объём хранилища. Это не отменяет стоимости железа, дисков, удалённой площадки и времени администратора, но снижает зависимость от лицензирования по сокетам, машинам или терабайтам.
Где надо быть осторожным
PBS не делает резервное копирование правильным сам по себе.
Если PBS стоит на том же сервере, что и Proxmox VE, — это всё ещё одна зона отказа. Если нет удалённой копии — пожар, шифровальщик или грубая ошибка администратора могут уничтожить и рабочие данные, и резервные копии. Если не проверяется восстановление — зелёные задания в интерфейсе могут создать ложное чувство безопасности. Если ключ шифрования потерян — зашифрованные копии превращаются в мусор.
S3 тоже не надо воспринимать как бесплатную магию. Объектное хранилище удобно для удалённого слоя, но требует расчёта стоимости, понимания задержек, локального кэша и сценария восстановления больших объёмов. Особенно если речь не о нескольких домашних виртуалках, а о десятках терабайт данных.
И ещё один момент: PBS не стоит рассматривать как универсальный ответ на всё. Для Proxmox VE — да, очень хороший вариант. Для Linux-файловых копий — тоже применим. Для сложного парка Windows и прикладных систем с особыми требованиями к согласованности данных — надо смотреть отдельно.
Итог
Proxmox Backup Server 4.2 — не релиз с одной красивой функцией. Это обновление, в котором продукт стал взрослее в нескольких местах сразу.
S3-хранилища вышли из предварительного статуса. Синхронизация между серверами стала параллельной. Появилось шифрование при отправке копий на менее доверенную площадку. Группы и пространства имён теперь можно переносить внутри хранилища. Улучшились журналы, статистика, работа за прокси, поведение при ошибках и поддержка ленточного оборудования.
Для администратора Proxmox это означает простую вещь: PBS всё меньше похож на «дополнение для бэкапов» и всё больше похож на нормальный сервер резервного копирования, вокруг которого можно строить серьёзную схему хранения. Не без расчётов, не без нормального железа и не без проверки восстановления. Но уже без ощущения, что для каждого взрослого сценария придётся городить обходной путь.