Настройка Proxmox Backup Server на удаленном VPS

Что на самом деле дает Proxmox Backup Server на VPS

Proxmox Backup Server (PBS) на VPS — это удаленная площадка для резервных копий, которая использует тот же протокол, что и ваш кластер Proxmox VE. Благодаря этому каждая резервная копия после первой является инкрементальной, дедуплицируется между гостевыми системами, шифруется до отправки с вашего узла и проверяется после завершения. Вы арендуете VPS с блочным хранилищем, устанавливаете PBS на Debian 13, создаете один datastore на этом томе и добавляете его в Proxmox VE как хранилище типа pbs. Установка занимает десять минут. Все последующие действия — работа с namespaces, сбор мусора (garbage collection), хранение ключей и восстановление, которое вы действительно протестировали, — определяют, будет ли ваша резервная копия полезна через год.

Причина использовать PBS вместо копирования файлов vzdump на арендованный диск заключается в хранилище чанков (chunk store). Клиент разбивает каждый диск гостевой системы на фрагменты размером около 4 MiB, вычисляет их хеши и загружает только те фрагменты, которых еще нет в datastore. Для работающей виртуальной машины QEMU отслеживает измененные блоки в dirty bitmap после первой резервной копии, поэтому при следующем запуске считываются только эти блоки с локального диска. Гостевая система объемом 200 GB, в которой ежедневно меняется 3 GB данных, будет передавать около 3 GB в день. Именно это позволяет эффективно использовать домашний канал связи и арендованный объем хранилища, и именно поэтому 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 ГБ и меняется примерно на 3.0 ГБ в день. Таким образом, для тридцати ежедневных снимков потребуется примерно 210 ГБ: одна полная копия плюс тридцать дней изменений. Сложите значения последнего столбца для всех 3 гостей, и общая сумма составит около 619 ГБ. Добавьте сверху 20% на индексы, метаданные и свободное место, необходимое для работы сборщика мусора, что указывает на необходимость тома объемом 1 ТБ.

Остальные требования к плану минимальны. PBS достаточно 2 ГБ оперативной памяти, а 4 ГБ обеспечивают комфортную работу, так как основная нагрузка ложится на сторону кластера: узел Proxmox VE считывает диски гостей, выполняет разбиение на чанки и хеширование. Задача VPS — записывать чанки и выполнять две ресурсоемкие операции: сборку мусора и проверку целостности. Арендуйте хранилище как отдельный блочный том, а не как один большой корневой диск, так как том можно увеличить позже без переустановки сервера.

Установка Proxmox Backup Server на Debian 13

По состоянию на август 2026 года актуальной связкой является Proxmox Backup Server 4 и Debian 13 с кодовым именем trixie. В старых руководствах PBS 2 сочетается с Debian 11, а поскольку кодовое имя является частью определения репозитория, копирование старого имени дистрибутива приведет к ошибке 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. Если это не так, остановитесь. Неверная связка ключей означает, что вы собираетесь установить пакеты, подписанные неизвестным источником, который вы не проверяли.

Создайте файл /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 имеют отдельный сетевой брандмауэр перед машиной, который также должен разрешать этот порт.

Размещение хранилища данных на отдельном томе

Хранилище данных не должно находиться в корневой файловой системе. Если хранилище переполняет общую корневую файловую систему, резервное копирование завершается с ошибкой, как и всё остальное на сервере, включая логи, необходимые для выяснения причин сбоя. Подключите блочный том, отформатируйте его, смонтируйте, и только после этого создавайте хранилище данных внутри точки монтирования.

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

Имя устройства возьмите из lsblk. В большинстве KVM-образов это /dev/vdb, в других — /dev/sdb, поэтому полагаться на догадки небезопасно. Добавьте монтирование в /etc/fstab по метке (label), чтобы переименование устройства после перезагрузки не привело к тому, что хранилище данных окажется на другом диске:

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. В этой строке скрыты две ошибки. Если монтирование отсутствует, а вы всё равно создаёте хранилище, PBS запишет данные в корневую файловую систему под точкой монтирования. Последующее успешное монтирование скроет эти данные, не удаляя их: хранилище будет выглядеть пустым, а корневая файловая система останется переполненной. Если в параметрах указано noatime, PBS откажется работать, так как он выполняет проверку времени доступа при создании хранилища и при каждой сборке мусора.

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

Это создаёт каталог .chunks, содержащий 65536 подкаталогов с именами от 0000 до ffff. Хранилище данных состоит из сотен тысяч мелких файлов, а не из нескольких крупных. Из этого следуют два вывода. Копирование хранилища обычными инструментами на уровне файлов происходит слишком медленно и бесполезно, а снапшот тома от провайдера, сделанный во время выполнения резервного копирования, не является консистентной копией, что является той же причиной, по которой снапшоты не заменяют резервные копии в любых других случаях.

Пространства имен предотвращают конфликты между хостами

По умолчанию хранилище данных является плоским. Резервные копии называются vm/100, ct/101 и host/<name>. Если два кластера имеют гостевые системы с ID 100, они записывают данные в одну группу, их снимки перемешиваются, а правило хранения, созданное для одного из них, учитывает снимки другого. Пространства имен предоставляют каждому источнику собственное дерево внутри одного хранилища данных.

Создайте их на хосте 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) являются общими для всего хранилища, поэтому десять гостевых систем Debian, распределенных по трем пространствам имен, по-прежнему хранят лишь одну копию базовой системы. Это основной аргумент в пользу использования одного хранилища с пространствами имен вместо отдельного хранилища для каждого хоста: отдельные хранилища означают отдельные пулы фрагментов, а отдельные пулы фрагментов означают многократную оплату за хранение одной и той же установки Debian.

Назначьте каждому источнику собственную учетную запись, ограниченную его пространством имен. Токен API (интерфейса прикладного программирования) — это учетные данные, которые принадлежат пользователю и имеют собственные права доступа; это именно то, что нужно для машины, которую могут украсть.

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'

Команда создания токена выводит секретный ключ только один раз:

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

Скопируйте его сразу, так как PBS не хранит его в виде, который можно отобразить повторно. Внимательно изучите команду управления доступом. Она указывает токен, backup@pbs!pve-home, а не пользователя, поскольку права токена вычисляются только на основе записей, в которых указан сам токен. Запись только для backup@pbs оставит токен без доступа, и первая же попытка резервного копирования завершится ошибкой прав доступа, а не сетевой проблемой. Путь также имеет критическое значение: токен, ограниченный /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 ничего не удалять. Политика хранения (retention) настраивается на стороне PBS, что подробно описано далее. Причина проста: в этом случае токену не требуются права на удаление, поэтому, если кластер будет зашифрован программой-вымогателем, злоумышленники не смогут получить доступ к удаленным резервным копиям, предназначенным для восстановления.

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

pvesm status выводит active в столбце состояния, а также общий и занятый объем хранилища. Статус inactive означает, что узел не смог установить TLS-сессию (transport layer security) с портом 8007. Обычно это указывает на проблему с брандмауэром или неверный отпечаток, а не на ошибку учетных данных.

Первое резервное копирование загружает все данные целиком, поэтому выполните расчеты перед запуском. 200 GB — это 1600 гигабит. При исходящем канале 100 Mbit скорость передачи составляет 0.1 гигабит в секунду, поэтому минимальное время составит около четырех с половиной часов, а в реальности — дольше. Запускайте процесс в то время, когда вам не требуется вся пропускная способность сети. Все последующие запуски будут передавать только новые фрагменты данных.

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

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 также поддерживает мастер-ключ — пару RSA (Rivest Shamir Adleman), созданную с помощью proxmox-backup-client key create-master-key. В этом случае каждая резервная копия хранит собственный ключ шифрования, зашифрованный открытой частью мастер-ключа, а закрытая часть хранится в офлайне для восстановления.

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

Очистка меток и сборка мусора

Этот раздел часто пропускают, именно он приводит к заполнению дискового пространства. Удаление снимка (pruning) убирает только его метаданные: манифест, индексы, журнал и заметки. Сами чанки (chunks) при этом не удаляются. Чанки используются совместно разными снимками, поэтому система не может определить, что чанк не используется, пока не будут прочитаны все оставшиеся индексы. Эту задачу выполняет сборка мусора (garbage collection). Хранилище данных, в котором настроено расписание очистки, но не настроена сборка мусора, будет только расти.

Настройте оба процесса. Сначала — удержание (retention), по одному заданию на пространство имен:

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

Затем настройте расписание сборки мусора для хранилища данных, через несколько часов после задания очистки и вне окна резервного копирования:

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

Проверьте разделение этих процессов на хосте PBS:

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

Запустите задание очистки, затем выполните df — показатель используемого места не изменится. Запустите сборку мусора, затем снова выполните df — объем используемого места уменьшится.

Сборка мусора выполняется в две фазы. Первая фаза обходит все индексы в хранилище данных и обновляет время доступа для каждого чанка, на который ссылаются эти индексы. Вторая фаза удаляет чанки, время доступа к которым старше порогового значения. Пороговое значение составляет 24 часа и 5 минут до момента запуска или время начала самого старого резервного копирования, которое еще записывается (выбирается более раннее). Этот запас необходим, так как Linux по умолчанию монтирует файловые системы с флагом relatime, что обновляет время доступа примерно раз в сутки, а не при каждом чтении. Поэтому чанк, записанный час назад, не будет удален, даже если на него пока нет ссылок, а место, освобожденное после очистки, появится только после сборки мусора, запущенной более чем через сутки после последнего обращения к чанку. Если кажется, что хранилище не освободило место, скорее всего, оно просто находится внутри этого временного окна.

На небольших VPS это самая ресурсоемкая задача, так как она выполняет stat для каждого файла чанка на томе. Журнал задачи завершается сводкой о том, что было удалено, а что осталось в очереди из-за льготного периода. Если в очереди осталось много данных, запустите процесс на следующий день. PBS предоставляет параметры gc-atime-safety-check и gc-atime-cutoff для настройки хранилища данных, их лучше не изменять. Они существуют для хранилищ, которые не могут записывать время доступа, а отключение проверки безопасности на файловой системе, смонтированной с noatime, приведет к потере чанков, на которые все еще ссылаются существующие снимки.

Проверка подтверждает, что чанки остаются читаемыми

Резервная копия, которая была успешно загружена, через год может оказаться нечитаемой. Проверка повторно считывает чанки и сравнивает их с контрольными суммами, хранящимися в индексе, поэтому повреждения обнаруживаются по расписанию, а не в момент восстановления.

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

На небольших VPS используйте низкое количество потоков. Проверка ограничена производительностью диска и процессора, поэтому она будет конкурировать за ресурсы с другими задачами на сервере. Для настройки расписания используйте вкладку Verify Jobs в веб-интерфейсе хранилища: еженедельное задание, которое пропускает уже проверенные снимки и повторно проверяет данные старше 30 дней, со временем охватит всё хранилище без выполнения лишней работы.

Снимок, не прошедший проверку, помечается в интерфейсе хранилища как неисправный. Не игнорируйте такие уведомления. Чанки являются общими, поэтому один поврежденный чанк из базового образа обычно приводит к ошибке всех снимков, которые на него ссылаются. Для исправления ситуации удалите поврежденные снимки и выполните новое резервное копирование, которое повторно загрузит недостающие чанки. Если ошибки продолжают появляться, проверьте накопитель, на котором размещено хранилище, и настройте мониторинг состояния диска на VPS, чтобы получать уведомления о проблемах с оборудованием до того, как их обнаружит задание проверки.

Протестируйте восстановление, а затем протестируйте его вне кластера

Вы не можете быть уверены в работоспособности резервной копии, пока не восстановите её. Существует два теста, и каждый из них проверяет разные аспекты.

Целиком гостевая система в кластере:

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

Первый столбец в pvesm list — это ID тома, который содержит временную метку, поэтому скопируйте свой ID, а не вводите пример вручную. Выполните восстановление в неиспользуемый ID гостевой системы и на другое хранилище, затем запустите её с отключенным сетевым интерфейсом. Никогда не восстанавливайте данные поверх работающей гостевой системы для проверки резервных копий, так как сбой в процессе восстановления приведет к потере и рабочей копии.

Второй тест — это то, что никто не выполняет. Представьте, что здание, в котором находился кластер, уничтожено, и выполните восстановление с машины, которая никогда не входила в его состав. На любом узле с 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. Это докажет то, что не может подтвердить первый тест: что ваш файл ключа расшифровывает реальные данные и что вы можете управлять клиентом с машины, на которой никогда не было конфигурации вашего кластера. Запишите четыре необходимых значения: строку репозитория, секретный токен, отпечаток и файл ключа, и храните их вместе в месте, указанном в вашем плане аварийного восстановления.

Как дедупликация влияет на расходы на дисковое пространство

Дедупликация — это реальный механизм, работающий во всем хранилище данных. Десять гостевых систем Debian используют одну общую копию базовой системы, поэтому хранение второго идентичного гостя практически не требует места. Это также экономит пропускную способность при передаче данных, так как клиент отправляет контрольную сумму вместо самих данных для любого блока, который уже есть на сервере.

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

• Она не уменьшает объем данных, которые постоянно изменяются. База данных, которая каждую ночь перезаписывает значительную часть своих файлов, создает новые блоки каждую ночь, а политики хранения данных только множат их.
• Она не работает через границы ключей шифрования, как было описано выше.
• Она не работает через границы хранилищ данных, что является основным аргументом в пользу использования пространств имен (namespaces).
• Она не предотвращает переполнение тома. Когда хранилище заполнено, резервное копирование завершается с ошибкой, и единственным решением остается увеличение объема тома или сокращение срока хранения данных.

Не стоит накладывать еще один уровень дедупликации под существующий. Блоки поступают уже дедуплицированными и сжатыми на стороне клиента, поэтому дедупликация ZFS под хранилищем данных будет расходовать оперативную память на поиск совпадений, которые были удалены еще до записи. Обычные файловые системы ext4 или xfs на томе — правильный выбор в данном случае.

Веб-интерфейс отображает коэффициент дедупликации для хранилища данных. Это число описывает именно ваши гостевые системы, и только на него стоит опираться при планировании, так как опубликованные коэффициенты описывают чужие данные. Если вам также требуется резервное копирование на уровне файлов для машин, которые не являются гостями Proxmox, запускайте их параллельно на том же VPS: PBS является целевым хранилищем с поддержкой гипервизора для целых гостевых систем, в то время как restic и BorgBackup работают с директориями, а резервное копирование restic на VPS подходит для ноутбуков и автономных серверов, для которых PBS изначально не предназначался.

Режимы сбоев и их признаки

Хранилище отображается как неактивное. pvesm status --storage pbs-offsite выводит inactive, если узел не может завершить TLS-сессию на порт 8007. Проверьте межсетевой экран на VPS, затем внешний сетевой экран провайдера, а после этого — отпечаток сертификата. Несоответствие отпечатка сертификату приводит к таким же видимым ошибкам, как и блокировка порта; отпечаток меняется при каждой замене сертификата.

Первое резервное копирование завершается ошибкой прав доступа. Список контроля доступа должен содержать токен, а не имя пользователя, и охватывать пространство имен, на которое указывает хранилище. Подтвердите оба параметра на вкладке прав доступа к хранилищу данных в веб-интерфейсе, прежде чем искать проблему в других местах.

Сборка мусора не запускается. Проверка безопасности времени доступа завершилась неудачей, что почти всегда означает, что файловая система хранилища смонтирована с параметром noatime. Выполните findmnt -no OPTIONS /mnt/datastore/store1 для подтверждения, исправьте параметр в /etc/fstab и выполните перемонтирование. Не отключайте проверку, чтобы обойти эту ошибку.

Хранилище данных только увеличивается. Задания очистки выполняются, но место не освобождается. Либо отсутствует расписание сборки мусора, либо каждый сеанс сборки попадает в 24-часовое окно ожидания, так как запускается сразу после резервного копирования. Проверьте расписание с помощью proxmox-backup-manager datastore show store1.

Резервное копирование, которое раньше выполнялось быстро, теперь занимает часы. Гостевая система, которая была остановлена, мигрировала или была восстановлена, теряет «грязную» битовую карту (dirty bitmap). В результате при следующем запуске кластер считывает весь диск целиком, даже если объем передаваемых данных невелик. Журнал задач показывает большую длительность при малом объеме загрузки, а последующий запуск снова проходит быстро. Если же медленно работают все задания на VPS, причина обычно находится вне хранилища данных, и первым делом следует измерить время ожидания CPU из-за влияния соседних виртуальных машин.

FAQ

Почему размер хранилища Proxmox Backup Server продолжает расти после выполнения задачи очистки (prune)?

Потому что очистка удаляет только метаданные снимка: манифест, индексы, журнал и заметки. Фрагменты данных (chunks) остаются на диске до тех пор, пока сборщик мусора (garbage collection) не удалит те из них, на которые больше не ссылается ни один индекс. Настройте расписание для хранилища с помощью proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' и убедитесь в результате, выполнив df -h для пути к хранилищу до и после proxmox-backup-manager garbage-collection start store1. Учитывайте задержку минимум в один день, так как вторая фаза удаляет только те фрагменты, время последнего доступа к которым превышает 24 часа и 5 минут.

Какой объем диска нужен для VPS с Proxmox Backup Server?

Сложите объем данных, фактически используемый каждой гостевой системой, затем прибавьте ежедневный прирост данных для каждой системы, умноженный на количество дней хранения. Полученная сумма является верхним пределом, так как сжатие и дедупликация работают в вашу пользу. Добавьте около 20% на индексы и рабочее пространство, после чего округлите значение до доступного объема диска. Проверьте показатели через две недели, сравнив их с реальным использованием в представлении хранилища, так как предварительная оценка до первого резервного копирования всегда будет неточной.

Где следует хранить ключ шифрования резервных копий?

Где угодно, но не только на том кластере, который он защищает. Proxmox VE хранит его в /etc/pve/priv/storage/<storage>.enc, который реплицируется на все узлы и, следовательно, теряется вместе с кластером. Скопируйте ключ в первый же день, распечатайте его с помощью proxmox-backup-client key paperkey и храните эту копию в другом здании. Учтите также, что ключ участвует в создании дайджеста фрагментов, поэтому его замена в будущем приведет к тому, что при следующем резервном копировании все данные будут загружены заново.

Нужно ли создавать отдельное хранилище для каждого узла Proxmox или использовать пространства имен (namespaces)?

Используйте одно хранилище и по одному пространству имен для каждого исходного узла или кластера. Дедупликация работает в пределах одного хранилища, а не между разными, поэтому разделение по узлам приведет к многократному хранению одинаковых базовых образов. Пространства имен позволяют изолировать группы резервных копий, чтобы два узла, имеющие гостевые системы с одинаковым ID 100, не конфликтовали, а путь контроля доступа вида /datastore/store1/pve-home ограничивает API-токен каждого узла его собственным пространством имен.

Справится ли небольшой VPS с ролью сервера резервного копирования Proxmox?

Обычно да, если речь идет о домашней лаборатории, так как разбиение на фрагменты и хеширование происходят на узле Proxmox VE, а не на сервере резервного копирования. VPS записывает фрагменты и выполняет две ресурсоемкие задачи: сборку мусора и проверку целостности. Выделите ему 4 GB оперативной памяти и ограничьте количество потоков проверки. Запланируйте обе задачи вне окна резервного копирования, и если они все равно занимают гораздо больше времени, чем позволяет скорость диска, проверьте показатель steal time перед покупкой более мощного тарифа.