Proxmox Backup Server: установка, копирование и восстановление ВМ

Схема: где находятся ВМ, копии и восстановление

PBS добавляется в Proxmox VE как хранилище типа pbs. Он не является дисковым хранилищем для работающих ВМ. Для рабочего размещения и для резервных копий нужны разные роли и план отказов.

Что подготовить: оборудование, сеть и независимость копий

Виртуальный PBS подходит для знакомства, но если его единственный datastore находится на том же хранилище, что исходные ВМ, сохраняется общий риск отказа. Для производства оцените независимый сервер и вторую площадку.

У Proxmox есть отдельные минимальные требования для оценки и рекомендации для рабочего сервера. В частности, рекомендованы от четырёх CPU-ядер, не менее 4 GiB RAM с дополнительной памятью по объёму хранилища, быстрые накопители и многогигабитная сеть. Не переносите минимум лаборатории на рабочую систему. Требования PBS.

Сколько места нужно для копий: формула и пример

Размер виртуальных дисков и размер datastore — разные величины. Не считайте «10 ВМ × диск 1 ТБ × 30 дней»: повторяющиеся блоки PBS использует повторно. Но и обещать экономию «в десять раз» до измерений нельзя. Для предварительного бюджета используйте такую модель:

• B: физический объём уникальных блоков первой полной точки после обработки PBS.
• U: дополнительные уникальные блоки, нужные всем сохраняемым точкам. Каждый блок считается один раз.
• M: бюджет метаданных и служебных расходов, не включённых в B и U.
• G: место для уже ненужных блоков до их освобождения GC и временного перекрытия заданий.
• S: планируемая свободная доля. Например, 0,20 означает 20%; это выбранный запас, а не обязательный норматив PBS.

Условный пример: B = 8 ТБ, сохраняются 31 ежедневная точка, каждая следующая добавляет в среднем 0,15 ТБ новых уникальных блоков. Тогда U ≈ 30 × 0,15 = 4,5 ТБ. Для M отведём 0,5 ТБ, для G — 1 ТБ:

Недельные и месячные точки могут удерживать старые блоки гораздо дольше. Если их добавили, пересчитайте U по всему удержанию. Простое число ежедневных копий уже не описывает такую политику. Скорость изменения файлов в гостевой системе тоже не равна приросту уникальных chunks: измеряйте результат на реальных данных.

1. Сделайте первую согласованную копию и запишите физически занятое место на выделенном datastore.
2. В течение представительного периода, включая обновления и закрытие месяца, фиксируйте прирост, объём удаляемых точек и результат GC.
3. Если измеряете общий USED файловой системы, метаданные уже могут входить в число: не добавляйте их повторно как M.
4. Сравните проектную ёмкость с фактическим трендом и скорректируйте закупку, удержание и пороги уведомлений.

Какой RAID выбрать для PBS и как собрать ZFS-пул

Сначала выберите схему отказоустойчивости и требуемую производительность, затем сравните её ёмкость с расчётом. Для PBS важны не только последовательная запись, но и чтение множества chunks при verify, восстановлении и GC.

Для нашего условного бюджета 17,5 ТБ (≈ 15,92 TiB): два диска по 12 ТБ в mirror дадут грубо 12 ТБ (≈ 10,91 TiB) — мало. Шесть дисков по 8 ТБ в трёх зеркальных парах дают грубо 24 ТБ (≈ 21,83 TiB), а один RAIDZ2 из шести таких дисков — 32 ТБ (≈ 29,10 TiB). Это оценки до расходов файловой системы, особенностей размещения и фактического доступного объёма.

Системные диски PBS планируйте отдельно, например как зеркало двух SSD. Приведённый расчёт касается datastore и не включает место для ОС.

RAID0 не обеспечивает избыточность. Для единственного большого HDD-пула этого примера мы не выбираем RAID5/RAIDZ1: проект предусматривает пережить два отказа в группе. Это инженерный выбор для сценария, а не запрет всех других конфигураций. RAID не защищает от удаления копий, ошибки администратора или потери площадки.

Если используете ZFS, отдайте ей отдельные диски через подходящий HBA/IT/JBOD-режим; не стройте её поверх обычного аппаратного RAID-тома. Если выбран аппаратный RAID, используйте соответствующий ему подход с ext4/XFS. Сравнение mirror и RAIDZ: OpenZFS: vdevs. Требования PBS к дискам и контроллеру — официальное руководство.

Сборка через знакомый интерфейс PBS

1. Откройте Administration → Storage/Disks → Disks. Сверьте размеры, модели, serial и отсутствие нужных данных на выбранных носителях.
2. Перейдите в ZFS → Create. Для нового HDD-примера выберите шесть подготовленных дисков и RAID Level: RAIDZ2. Для двухдискового зеркала выбирается Mirror.
3. Задайте имя backup-data. Compression оставьте включённой; ashift подбирается под сектор дисков. Не меняйте его наугад ради видимой ёмкости.
4. Для сохранения имён из этой статьи снимите Add as Datastore: сначала создаём пул, затем отдельно datastore office. Если автоматически создать datastore, он уже будет отдельным объектом — не дублируйте его на том же каталоге.
5. Перед подтверждением ещё раз сверьте выбранные диски: создание пула меняет их содержимое. На рабочем сервере действие выполняется только после подготовки данных и окна изменений.
6. Проверьте, что пул ONLINE, нужные диски присутствуют и ошибок нет. Сверьте фактическую точку монтирования; для дальнейшего примера используем /mnt/datastore/backup-data.
7. После проверки переходите к созданию datastore в следующем шаге. Не добавляйте новый диск в существующий пул командой add только ради замены неисправного: добавление vdev и замена диска — разные операции.

zpool status -v
zpool list -o name,size,alloc,free,cap,health
zfs list -o name,mountpoint,used,avail

Эти команды только показывают состояние на PBS с ZFS. Не используйте значение zpool SIZE как готовую доступную ёмкость datastore: для RAIDZ оно может вводить в заблуждение при сравнении с полезным пространством. Проверяйте доступный объём файловой системы, её квоты и реальные расходы.

1. Установите PBS и проверьте базовую доступность

1. Загрузите ISO с официального сайта Proxmox и сверьте опубликованную контрольную сумму.
2. Загрузитесь с установочного носителя. Перед подтверждением проверьте модель, серийный номер и назначение системного диска: установка перезаписывает выбранные носители.
3. Задайте пароль администратора, адрес уведомлений, имя сервера, часовой пояс и сетевые параметры. В примере PBS получает 10.50.10.20/24; шлюз и DNS выбираются по вашей сети.
4. После перезагрузки откройте https://10.50.10.20:8007 из административной сети и проверьте идентичность сервера.
5. В Administration проверьте репозитории и обновления. Используйте канал, соответствующий подписке и принятой политике; не смешивайте разные выпуски Debian/PBS.

В консоли PBS от root проверьте версии и службы. Это команды чтения состояния:

proxmox-backup-manager versions
ip -br address
ip route
timedatectl status
systemctl status proxmox-backup proxmox-backup-proxy --no-pager

Ожидаются правильные адреса и маршрут, согласованное время и работающие службы. Если DNS или сеть неверны, исправьте их до создания заданий. Не публикуйте панель PBS напрямую в интернет: организуйте ограниченный административный доступ. Порядок установки — официальное руководство.

2. Подготовьте диски и создайте datastore

В Administration → Storage/Disks сверьте физические диски и их состояние. Для нового стенда можно подготовить Directory на ext4/XFS или ZFS с выбранным уровнем резервирования. Создание файловой системы уничтожает прежнее содержимое выбранных дисков. Рабочие данные сначала переносятся и проверяются отдельно.

Далее предполагается, что отдельная файловая система уже подготовлена, постоянно монтируется в /mnt/datastore/backup-data и имеет место для копий. Это выбранный путь примера, а не обещание автоматического имени каталога в установщике.

proxmox-backup-manager disk list
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt --mountpoint /mnt/datastore/backup-data
df -h /mnt/datastore/backup-data

Продолжайте только если findmnt подтверждает нужное монтирование, а размер и устройство совпадают с планом. Иначе можно начать писать копии на системный диск. Проверьте сохранение монтирования после плановой перезагрузки. Теперь на PBS создайте новый datastore:

proxmox-backup-manager datastore create office /mnt/datastore/backup-data/office
proxmox-backup-manager datastore list

office — логическое имя хранилища, а путь — каталог данных на подготовленной файловой системе. Успешное создание должно появиться и в списке, и в веб-интерфейсе. Не меняйте права на весь каталог на 777 для устранения ошибки. Datastore и диски, синтаксис CLI.

3. Создайте отдельного пользователя и API-токен

В PBS Configuration → Access Control создайте пользователя pve-backup@pbs и токен pve01. Получится идентификатор pve-backup@pbs!pve01. Секрет токена сохраните в защищённом месте; он понадобится при подключении PVE.

Назначьте роль DatastoreBackup на путь /datastore/office отдельно пользователю и токену. Права токена ограничены правами родительского пользователя: одной записи ACL может оказаться недостаточно. Эта роль разрешает копирование и восстановление принадлежащих субъекту копий, но не даёт общего администрирования datastore.

proxmox-backup-manager user permissions 'pve-backup@pbs' --path /datastore/office
proxmox-backup-manager user permissions 'pve-backup@pbs!pve01' --path /datastore/office

Проверьте эффективные права обоих субъектов. Если подключение отклонено, разберите realm, срок действия, ACL и владельца группы копий. Не исправляйте всё выдачей root или DatastoreAdmin. Если политикой хранения управляет PBS, клиенту PVE не требуется право самостоятельного prune; проверьте, что на стороне PVE не настроена конфликтующая очистка. Пользователи, роли и токены.

4. Подключите PBS к Proxmox VE

На консоли PBS получите отпечаток сертификата:

proxmox-backup-manager cert info

Сверьте полный SHA256 fingerprint через доверенный административный канал. На PVE выберите Datacenter → Storage → Add → Proxmox Backup Server: ID pbs-office, Server 10.50.10.20, Datastore office, Username — идентификатор токена, Password — его секрет. При самоподписанном сертификате укажите проверенный fingerprint.

Альтернатива в Bash от root на узле PVE. Сначала вставляется полный отпечаток, затем секрет вводится по запросу программы — без записи в аргументы команды.

read -r -p 'PBS SHA256 fingerprint: ' pbs_fingerprint
pvesm add pbs pbs-office --server 10.50.10.20 \
  --datastore office --username 'pve-backup@pbs!pve01' \
  --fingerprint "$pbs_fingerprint" --password
pvesm status --storage pbs-office

После успешного добавления ожидается статус active. Само подключение не создаёт копий и не подтверждает восстановление. В кластере PVE конфигурация хранилища общая: проверьте доступ со всех узлов, где будет выполняться задание. Интеграция PBS и PVE.

5. Решите вопрос шифрования до первой рабочей копии

TLS защищает соединение, а клиентское шифрование — содержимое копии. В настройках PBS-хранилища на PVE можно включить шифрование и сформировать ключ. Сохраните независимый защищённый экземпляр ключа и порядок его получения после отказа гипервизора. Для ID из примера ключ хранится на PVE в /etc/pve/priv/storage/pbs-office.enc.

Секрет API-токена, пароль root и ключ расшифрования — разные вещи. Наличие доступа к PBS не восстанавливает потерянный ключ. Проверку возврата зашифрованной копии проводите с сохранённым независимым экземпляром, а не только с ключом, который пока лежит на рабочем PVE. Официальное руководство Proxmox: Encryption.

6. Сделайте первую копию одной ВМ

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

На PVE откройте VM 100 → Backup → Backup now, выберите pbs-office и режим Snapshot. Если нужен согласованный останов, выберите Stop в согласованное окно. QEMU Guest Agent с freeze/thaw помогает согласованности файловой системы, но его наличие не заменяет проверку восстановления СУБД.

qm config 100
vzdump 100 --storage pbs-office --mode snapshot
pvesm list pbs-office --vmid 100

Это три последовательных действия: сначала проверка конфигурации, затем копирование, затем просмотр результата после успешного завершения задания. Сохраните журнал и время точки; убедитесь, что копия появилась в PBS и доступна нужному владельцу. Не добавляйте параметры сжатия архивного файла только по аналогии с обычным .vma.zst: backend PBS работает с chunks и индексами. Backup modes, параметры vzdump.

Копия, snapshot и sync: что именно вы видите в интерфейсе

Группа vm/100 объединяет несколько точек одной ВМ. Раскрыв её в Content, выбирайте конкретное время, а не просто название группы. Метка Z в идентификаторе обозначает UTC: сверяйте её с локальным временем интерфейса и журналом задания. Терминология PBS.

В копии ВМ хранятся её конфигурация и включённые диски. Контейнеры используют файловое представление, а клиент proxmox-backup-client умеет сохранять каталоги в pxar. Содержимое внешних ресурсов и исключённых томов не появляется в копии автоматически. Возможности клиента PBS.

Практические приёмы, которые помогают при восстановлении

Контролируйте и процент, и абсолютный остаток свободного места: одинаковые 10% на маленьком и большом datastore дают разное время реакции. Отдельно отслеживайте возраст последнего успешного backup и последнего восстановления. После смены токена проверяйте доступ к старым группам: владелец новой копии и права на прежние точки могут различаться.

Скриншоты ниже и выше взяты из официальной документации Proxmox без подмены значений. В руководстве встречаются снимки разных поколений интерфейса; это ориентиры по элементам управления, а не отчёт о нашем развёртывании. Копия лицензии для этих иллюстраций: GNU Free Documentation License 1.3; оригиналы и сведения об источниках сохранены в проекте.

7. Настройте регулярное задание и уведомления

1. В PVE Datacenter → Backup создайте задание для выбранных узлов и ВМ, укажите PBS-хранилище и режим.
2. Выберите расписание по допустимой потере изменений и нагрузке. Время запуска не равно моменту, когда пригодная копия уже создана.
3. Проверьте список ВМ: новые машины могут не попасть в фиксированную выборку. Назначьте ответственного за её актуальность.
4. На PBS в Configuration → Notifications настройте получателя и правила для verify, sync и GC. На PVE отдельно настройте уведомления заданий backup.
5. Отправьте тестовое уведомление и подтвердите доставку. Успешная настройка адреса в интерфейсе ещё не доказывает доставку сообщения.
6. Дождитесь запуска по расписанию и проверьте журнал, содержимое PBS и доступную точку данных.

Для PBS настраиваются targets и matchers; доступные способы включают SMTP, Sendmail и Gotify. Не рассчитывайте, что уведомления двух продуктов автоматически имеют одинаковую конфигурацию. Уведомления PBS.

8. Разделите verify, prune и garbage collection

Перед включением очистки проверьте правила в prune simulator и сохраните нужные контрольные точки. Например, keep-last=7 и keep-weekly=4 — учебный вариант, не гарантированно одиннадцать независимых копий. Не удаляйте chunks вручную.

Ручная проверка datastore на PBS читает хранилище и создаёт нагрузку. Выполняйте в согласованное окно:

proxmox-backup-manager verify office --ignore-verified false

Ожидается завершение без ошибок, результат проверяется в Tasks и Content. Расписание verify, prune, GC и sync подберите по длительности и доступным IOPS, не запуская их одновременно без оценки нагрузки. Maintenance Tasks.

9. Добавьте независимую копию на другом PBS

Второй PBS позволяет хранить резервную точку вне основной площадки. На целевом сервере настройте Remote и Sync Job, укажите источник, datastore, фильтр групп и учётную запись с нужными правами чтения. Сначала выполните ручную синхронизацию одной тестовой группы, затем назначьте расписание.

Для независимого хранения не включайте remove-vanished автоматически: эта опция может переносить удаление исчезнувших точек на целевую сторону. Цель должна иметь осмысленную собственную политику удержания и отдельные права. Синхронизация сама по себе не является WORM.

Ограничьте канал при необходимости, проверьте задержку доставки и восстановите ВМ именно из второго экземпляра. Одинаковые данные на двух серверах мало помогают, если аварийный PVE не имеет к ним доступа или отсутствует ключ. Remotes и Sync Jobs.

10. Восстановите ВМ под новым ID и без запуска в рабочую сеть

В PVE откройте PBS-хранилище → Backups, выберите точку и Restore. Укажите свободный ID, целевое хранилище и не включайте Start after restore. Для консольного варианта сначала выполните qm list и pvesm list pbs-office --vmid 100.

Ниже Volume ID и время учебные: скопируйте реальный идентификатор из результата pvesm list. Хранилище local-lvm должно существовать и иметь достаточно места.

qmrestore 'pbs-office:backup/vm/100/2026-10-23T01:00:00Z' 9100 \
  --storage local-lvm --unique 1 --start 0
qm status 9100
qm config 9100

Команды статуса выполняйте после успешного восстановления. Ожидается остановленная ВМ с новым ID и отдельными дисками. Не используйте --force для обхода занятого ID. --unique 1 меняет MAC-адреса, но не исправляет гостевые IP-адреса, имя компьютера, доменную идентичность и настройки интеграций. Синтаксис qmrestore.

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

Проверьте загрузку ОС, файловую систему, службы, контрольный документ или отчёт, вложения и работу приложения. Зафиксируйте время получения копии, развёртывания и приёмки. Не считайте длительность одного qmrestore полным временем восстановления бизнеса.

Если нужен один файл, а не вся ВМ

Для подходящей копии можно использовать File Restore в Proxmox VE: выбрать нужный архив диска и доступную файловую систему, найти файл и скачать его в отдельное место. Возможность зависит от содержимого диска, формата и шифрования.

Не заменяйте рабочий файл сразу после скачивания. Сначала проверьте дату, содержимое и согласованность с приложением. Возврат отдельных файлов СУБД не равнозначен корректному восстановлению базы. Для сложной дисковой схемы или проверки сервиса используйте отдельную восстановленную ВМ. Официальное руководство: File Restore.

Типичные ошибки: что проверять по порядку

Для первичного сбора состояния: на PVE — pvesm status --storage pbs-office и журнал backup/restore; на PBS — Tasks, диски, свободное место, службы и системный журнал. Важны также возраст последней успешной точки и дата последнего запуска восстановленной ВМ.

Если настройка не подошла: как вернуться к исходному состоянию

Перед внедрением запишите текущие задания PVE, хранилища, сети и способ копирования. Новую схему вводите рядом с проверенной; прежние копии не удаляются только потому, что PBS стал доступен.

• При ошибках нового задания временно отключите его расписание, сохраните журнал и продолжайте согласованное прежнее копирование.
• Если ошибочно подключён новый storage ID, отключите его использование на PVE и разберите параметры. Не удаляйте datastore и chunks для устранения ошибки подключения.
• После замены токена проверьте новый backup и restore, затем отзовите прежний секрет по порядку доступа.
• Тестовую ВМ сохраняйте изолированной до приёмки; решение о её удалении и сохранении протокола принимайте отдельно.

Для восстановления самого PBS нужен план переустановки, доступа к datastore и защищённо сохранённой конфигурации, включая необходимые секреты. Для возврата на другой PVE заранее сверяют имена хранилищ, bridge/VLAN, версии и ключи. Backup ВМ не заменяет паспорт гипервизора.

Настроим PBS и проверим возврат ваших сервисов

Для начала сообщите количество ВМ, используемые объёмы и прирост, версии Proxmox, текущую схему копирования и требования к возврату. Подробнее: ИТ-аутсорсинг и копирование и восстановление 1С.

Две памятки для внедрения

Вопросы о Proxmox Backup Server