Удалённый Proxmox Backup Server: настройка с Proxmox VE

Локальный Proxmox Backup Server закрывает большую часть сценариев: случайно удалённый файл, неудачное обновление, сломанная ВМ. Но если он стоит в той же стойке, что и гипервизоры, пожар, кража, умерший RAID-контроллер или шифровальщик с доступом к сети заберут и рабочие машины, и их копии. Ниже разбираю, как подключить внешний PBS к Proxmox VE, включить шифрование на стороне клиента, настроить синхронизацию с локальным сервером и раздать права так, чтобы скомпрометированный хост не мог стереть историю бэкапов.

Зачем нужен внешний PBS

Классическое правило 3-2-1: три экземпляра данных, два разных носителя, один экземпляр за пределами площадки. Для кластера Proxmox VE это обычно выглядит так: рабочие диски ВМ, локальный PBS для быстрых восстановлений и удалённый PBS как офсайт-копия. Удалённый сервер может быть вашим собственным во втором офисе или арендованным у провайдера. Технически подключение одинаковое, различаются только права: на чужом сервере вы не администратор, и это скорее плюс.

Какие данные нужны от провайдера

Перед настройкой соберите параметры. Если место вам выдаёт провайдер, он присылает их сам:

адрес сервера — DNS-имя или IP;
порт — по умолчанию 8007/TCP, исходящий доступ на него должен быть открыт с каждого узла PVE;
datastore — имя хранилища на стороне PBS;
namespace — раздел внутри datastore, если провайдер разделяет клиентов или ваши серверы через namespaces;
пользователь или API-токен — вида user@pbs с паролем либо user@pbs!tokenname с секретом;
fingerprint — SHA-256 отпечаток TLS-сертификата PBS.

Отпечаток нужен, когда у PBS самоподписанный сертификат (так по умолчанию). Администратор сервера получает его командой:

proxmox-backup-manager cert info

В выводе есть строка Fingerprint (sha256). Тот же отпечаток показывает веб-интерфейс PBS: Dashboard → Show Fingerprint. Если сервер не ваш, доступа к этой команде у вас не будет — отпечаток сообщает провайдер. Сверяйте его по отдельному каналу, а не только из письма с паролем.

Подключение хранилища в Proxmox VE

Через веб-интерфейс

Датацентр → Хранилище → Добавить → Proxmox Backup Server. На вкладке General заполните ID (локальное имя хранилища в PVE), Server, Username, Password, Datastore, Namespace и Fingerprint. Если поля Datastore и Namespace подтянулись выпадающими списками, значит авторизация и TLS прошли. На вкладке Backup Retention для внешнего хранилища с ограниченными правами лучше оставить Keep all backups — почему, расскажу ниже. Вкладка Encryption — следующий раздел.

Через pvesm

То же из консоли любого узла кластера (конфигурация хранилищ общая, попадёт в /etc/pve/storage.cfg):

pvesm add pbs offsite-pbs \
  --server pbs.example.net \
  --datastore client042 \
  --namespace hv01 \
  --username 'hv01@pbs!pve' \
  --password 'секрет-токена' \
  --fingerprint 'aa:bb:cc:...:ff' \
  --encryption-key autogen

Имя токена берите в одинарные кавычки, иначе bash попытается интерпретировать !. Пароль PVE сохраняет в /etc/pve/priv/storage/offsite-pbs.pw. Проверить, что хранилище живое:

pvesm status --storage offsite-pbs
pvesm list offsite-pbs

Шифрование на стороне клиента

PBS шифрует чанки на клиенте алгоритмом AES-256-GCM до отправки. Сервер хранит уже зашифрованные данные, и владелец сервера прочитать их не может. Обратная сторона: потерянный ключ не восстанавливается никем, а копии без него превращаются в набор бесполезных байтов.

Как получить ключ

Вариантов три:

В GUI на вкладке Encryption выбрать Auto-generate a client encryption key. После сохранения PVE покажет окно с ключом — его сразу скачивают и печатают.
Через pvesm параметром --encryption-key autogen, как в примере выше.
Создать ключ заранее и загрузить его в GUI (Upload an existing client encryption key):

proxmox-backup-client key create /root/offsite.key --kdf none

Параметр --kdf none создаёт ключ без парольной фразы: PVE подставляет ключ в задания без участия человека, поэтому защищённый паролем ключ ему не подходит. В первых двух вариантах ключ ложится в /etc/pve/priv/storage/<ID>.enc.

Бумажная копия и места хранения

Ключ, который лежит только на гипервизоре, погибнет вместе с ним — ровно в том сценарии, ради которого затевался внешний бэкап. Сделайте бумажную копию:

proxmox-backup-client key paperkey /etc/pve/priv/storage/offsite-pbs.enc --output-format text

Вывод содержит ключ текстом и QR-кодом. Минимальный набор: распечатка в сейфе, копия в менеджере паролей компании, копия на носителе вне серверной. Провайдеру ключ не передают — это и есть смысл шифрования на клиенте.

Задание резервного копирования и хранение копий

Датацентр → Резервное копирование → Добавить. Выберите хранилище offsite-pbs, узел, набор ВМ и контейнеров, режим Snapshot (без остановки гостя; для ВМ с qemu-guest-agent PVE выполнит fs-freeze перед снимком) и расписание в формате календарных событий, например 21:30 или mon..fri 01:00. Разовый запуск для проверки:

vzdump 100 --storage offsite-pbs --mode snapshot

Первая копия ВМ уходит целиком, дальше передаются только изменённые чанки. Для работающей ВМ PVE ведёт dirty bitmap, и инкрементальный проход идёт быстро; после перезапуска ВМ bitmap сбрасывается и диски перечитываются, но в сеть всё равно отправляется только новое.

Где задавать политику хранения

Политика вида keep-daily=7, keep-weekly=4, keep-monthly=6 может выполняться в двух местах, и разница принципиальная.

	В задании PVE	На datastore у провайдера (prune job)
Кто удаляет копии	Ваш хост после бэкапа	Сам PBS по расписанию
Какие права нужны вашим учёткам	Datastore.Prune	Только Datastore.Backup
Может ли взломанный хост стереть историю	Да, в пределах своих групп	Нет
Как поменять глубину хранения	Сами, в любой момент	Заявкой администратору PBS

При аренде места разумнее второй вариант: в задании PVE оставить Keep all backups, а глубину хранения согласовать с провайдером, который настроит prune job на ваш namespace. Учтите и квоту: prune только помечает снапшоты удалёнными, место освобождает garbage collection, причём чанки удаляются не раньше чем через сутки после последнего использования.

Синхронизация локального PBS с удалённым

Если локальный PBS уже есть, гипервизоры можно не нагружать вторым заданием: пусть копии в офсайт отправляет сам PBS. Сначала на локальном сервере добавляется remote — Configuration → Remotes → Add или из консоли:

proxmox-backup-manager remote create offsite \
  --host pbs.example.net \
  --auth-id 'hv01@pbs!sync' \
  --password 'секрет-токена' \
  --fingerprint 'aa:bb:cc:...:ff'

Дальше — sync job в одном из двух направлений:

Pull — PBS забирает снапшоты с remote в свой datastore. Классическая схема: офсайт-сервер сам тянет данные с офисного. Для арендованного места pull полезен в обратную сторону — вернуть копии с внешнего сервера на новый локальный после аварии.
Push — локальный PBS сам отправляет снапшоты на remote. Режим появился в PBS 3.3 и удобен, когда офисный сервер за NAT и входящих подключений к нему нет.

Pull-задание из консоли:

proxmox-backup-manager sync-job create restore-from-offsite \
  --store local-ds \
  --remote offsite \
  --remote-store client042 \
  --remote-ns hv01 \
  --schedule daily

Push-задание удобнее создать в GUI: Datastore → нужный datastore → Sync Jobs, тип Push, затем указать remote, целевой datastore и namespace, расписание. Зашифрованные снапшоты синхронизируются как есть, ключ на удалённую сторону не передаётся. Флаг Remove vanished в push-задании требует права на удаление на стороне провайдера — для защиты от шифровальщика его не включайте.

Права: почему токену хватит DatastoreBackup

В PBS у каждой группы бэкапов (например, vm/100) есть владелец — пользователь или токен, создавший первый снапшот. Роль DatastoreBackup разрешает создавать новые снапшоты и читать свои, но не трогает чужие группы. Однако владелец может удалять и прорежать свои снапшоты, если у него есть Datastore.Prune — эта привилегия входит, например, в DatastorePowerUser. Значит, хост с такой ролью при взломе способен вычистить собственную историю.

Поэтому схема для внешнего хранилища такая: токену, под которым работают PVE или sync job, — только DatastoreBackup на свой namespace; prune выполняет провайдер своим заданием или отдельная учётка, которой нет на гипервизорах. На стороне PBS это выглядит примерно так (делает администратор сервера):

proxmox-backup-manager user generate-token hv01@pbs pve
proxmox-backup-manager acl update /datastore/client042/hv01 DatastoreBackup --auth-id 'hv01@pbs!pve'

Права токена — это пересечение прав пользователя и ACL самого токена, поэтому ACL выдаётся именно на токен. Смена владельца группы требует Datastore.Modify, так что новый токен не сможет дописывать в группы, созданные старым, — помните об этом при ротации секретов.

Проверка восстановления

Копия, из которой ни разу не восстанавливали, — гипотеза. Раз в месяц-квартал проверяйте:

Восстановление ВМ целиком. Хранилище → Резервные копии → выбрать снапшот → Restore с новым VMID, без сети или в изолированном bridge. Из консоли: qmrestore offsite-pbs:backup/vm/100/2026-10-10T18:30:00Z 9100 (точное имя тома покажет pvesm list offsite-pbs).
Восстановление файлов. Кнопка File Restore открывает дерево файловой системы внутри копии, нужное скачивается без разворачивания всей ВМ. Для зашифрованных копий ключ должен быть на узле PVE.
Восстановление без исходного хоста. Поставьте чистый Proxmox VE, подключите хранилище, загрузите ключ с бумажной копии или из хранилища паролей. Если этот шаг не проходит, офсайт-копии у вас по сути нет.

Целостность чанков на стороне сервера проверяют verify jobs; если datastore не ваш, уточните у провайдера, как часто они запускаются.

Типичные ошибки

Fingerprint mismatch / not verified. Отпечаток в конфигурации не совпадает с сертификатом сервера — провайдер перевыпустил сертификат или вы скопировали его с ошибкой. Получите новый отпечаток, сверьте и обновите: pvesm set offsite-pbs --fingerprint '...'. Если отпечаток сменился без предупреждения, сначала выясните почему.
Нет прав на namespace. Хранилище добавляется, но список пуст или задание падает с ошибкой проверки прав. Обычно ACL выдан на /datastore/client042 пользователю, а не токену, или на другой namespace. Проверяйте путь ACL и auth-id.
Конфликт владельца группы. После замены токена задание пишет про backup owner — группу создал прежний токен. Смену владельца делает администратор PBS.
Кончилась квота. Когда место исчерпано, задания падают на записи чанков, причём обычно все разом. Удаление старых снапшотов не помогает сразу — нужен garbage collection. Следите за заполнением через pvesm status и закладывайте запас под рост.
Ключ остался только на хосте. Не ошибка в логе, но самая дорогая: обнаруживается в день аварии.

FAQ

Можно ли включить шифрование для хранилища, где уже есть незашифрованные копии?

Да, новые снапшоты будут зашифрованы, старые останутся как были. Первая зашифрованная копия каждой ВМ уйдёт полностью, потому что чанки с другим ключом не совпадают с прежними.

Видит ли провайдер содержимое моих ВМ?

При шифровании на клиенте — нет: на сервере лежат зашифрованные чанки и метаданные снапшотов (имена групп, время, размеры). Без шифрования администратор datastore технически может прочитать данные.

Что выбрать: прямое подключение PVE или sync с локального PBS?

Если локального PBS нет — прямое подключение. Если есть, push-синхронизация разгружает гипервизоры и даёт одну точку управления, а локальные восстановления остаются быстрыми.

Сколько места нужно под внешние копии?

Зависит от объёма изменений и глубины хранения. Дедупликация и сжатие сильно экономят место, но коэффициент индивидуален: сделайте первую копию, понаблюдайте рост за пару недель и только потом считайте квоту.

Нужен ли открытый входящий порт в офисе?

Для прямого подключения и push — нет, нужен только исходящий доступ к 8007/TCP удалённого сервера. Входящий порт нужен, лишь если внешний PBS сам забирает данные pull-заданием.

Если второй площадки нет

Если своей второй площадки нет, место на внешнем PBS можно арендовать, например хранилище Proxmox Backup Server у Service4biz (2,65 ₽ за ГБ в месяц, оплата за квоту), а настройку резервного копирования под ключ делают инженеры IT-Спутника.