Как настроить Proxmox Backup Server и проверить восстановление

Proxmox Backup Server (PBS) можно установить из ISO, создать datastore, подключить к Proxmox VE и запустить первую задачу. Но считать систему готовой через 15 минут нельзя: нужны расчёт хранилища, ограниченные права, расписание, защита ключа шифрования и проверенное восстановление.

Что PBS делает с резервной копией

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

PBS передаёт изменившиеся данные инкрементально и повторно использует одинаковые блоки. При этом каждый снимок ссылается на полный набор нужных блоков и считается полной копией для восстановления. Поэтому фразы «инкрементальный бэкап» и «полная точка восстановления» не противоречат друг другу. Сколько места удастся сэкономить, заранее обещать нельзя: это зависит от характера данных, изменений, сжатия и срока хранения. «До 90 процентов» без измерений — рекламная цифра, не план ёмкости.

rsync сам по себе не является системой резервного копирования с каталогом снимков, управлением retention и проверкой восстановления. Но и объявлять его бесполезным инструментом неверно: он решает задачи синхронизации файлов. Для виртуальных машин на Proxmox VE разумно использовать штатную связку с PBS, а для остального подбирать механизм по данным и сценарию восстановления. Инструмент не спасает от плохого плана: если копии лежат рядом с оригиналами и удаляются тем же доступом, авария может задеть оба места. Если нужно сравнить схему с отдельной репликацией, полезно разобрать репликацию Proxmox: это другая задача и другой механизм.

Установка: сначала диски и роль сервера

Для обычного развёртывания скачайте официальный ISO Proxmox Backup Server, запишите его на носитель и загрузите сервер с него. Установщик предложит выбрать целевой диск и сетевые параметры. Внимание: при стандартной установке данные на выбранном диске будут удалены. Перед нажатием Install перепроверьте устройство и схему хранения. Устанавливать «наугад, а потом разберёмся» — способ получить не готовый PBS, а внеплановую задачу по восстановлению старого содержимого.

После перезагрузки откройте адрес сервера по HTTPS на порту 8007; точный адрес покажет установщик. Войдите учётной записью root с паролем, который задали при установке, затем проверьте имя узла, сетевую конфигурацию, время и доступ к обновлениям. Установка PBS поверх Debian тоже возможна, но для неё заранее настраивают официальный репозиторий и ключи пакетов. Это отдельный путь с большей ответственностью за базовую систему и диски; для первого внедрения ISO обычно проще.

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

Datastore и диск: не путайте файловую систему с пулом

В PBS основная единица хранения называется datastore. Создайте его в интерфейсе PBS и укажите подготовленную файловую систему и каталог, предназначенный для резервных копий. Datastore — логическое место для снимков и блоков, а не «пул» из меню Datacenter в Proxmox VE. Путь /mnt/pbs-data из случайного примера не становится правильным только потому, что выглядит убедительно: сначала нужно смонтировать нужный том, проверить его устойчивое подключение после перезагрузки и затем выбрать реальный путь.

Не форматируйте хранилище в Btrfs или ZFS только ради «поддержки снапшотов». PBS сам управляет содержимым datastore; выбор файловой системы и схемы дисков — решение на уровне сервера хранения. Для ZFS учитывайте рекомендации документации: ZFS не следует размещать поверх аппаратного RAID-контроллера, который скрывает физические диски. Отдельно оцените отказоустойчивость, скорость случайного чтения, ёмкость и запас свободного места. Ни дедупликация, ни снапшоты не создают дополнительное место из воздуха.

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

Подключите PBS к Proxmox VE с отдельными правами

В интерфейсе Proxmox VE добавьте хранилище типа Proxmox Backup Server и укажите адрес PBS, datastore, пользователя и отпечаток TLS-сертификата, если он нужен для проверки доверия. Это настройка в PVE; разделы Users и Datastore находятся в интерфейсе PBS. Не ищите там несуществующий мастер Datacenter → Storage → Add → Directory: такой маршрут смешивает интерфейсы и ведёт к неверной инструкции.

Создайте отдельную учётную запись или токен для подключения, назначьте доступ только к нужному datastore и проверьте роль по руководству PBS. Роль DatastoreAdmin из черновика не является универсальным готовым рецептом для отправки бэкапов: требуемые права зависят от выбранной схемы аутентификации, пользователя и операций. Не подключайте повседневную задачу с неограниченной учётной записью root «для простоты». Ограниченные права уменьшают ущерб при утечке пароля и делают аудит понятнее. Для сценария с токеном полезно отдельно разобрать права API-токена PBS; применяйте их с учётом своей версии и схемы доступа.

При настройке подключения внимательно проверьте адрес, datastore, идентификатор пользователя и TLS fingerprint. Не принимайте незнакомый отпечаток вслепую: сверьте его с PBS по защищённому каналу или получите из доверенного интерфейса. Затем создайте задание резервного копирования для тестовой VM, выберите режим, расписание и политику хранения. Успешное завершение задания подтверждает, что данные отправлены; оно ещё не подтверждает, что приложение запустится после восстановления. Эти проверки отвечают на разные вопросы.

Шифрование, хранение и проверка целостности

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

Настройте расписание, срок хранения и очистку снимков осознанно. Политика хранения отвечает на вопрос, какие точки восстановления останутся через неделю или месяц; выбирайте её по требованиям бизнеса и доступной ёмкости. Перед удалением старых копий проверьте, что новая схема действительно сохраняет требуемые точки. Для второй площадки рассмотрите отдельный PBS и задачу синхронизации: документация описывает remotes и sync jobs, при которых удалённое хранилище копируется в локальное. Синхронизация полезна, но сама по себе не защищает от ошибочного удаления, если оно затем распространяется.

Планируйте штатную проверку целостности datastore и смотрите её результат, а не только статус расписания резервного копирования. PBS использует SHA-256 для проверки данных и манифест с перечнем объектов снимка. Это техническая проверка содержимого, а не гарантия, что бизнес-приложение корректно стартует или что сотрудник найдёт нужную версию файла. Для полного контроля нужны и проверки целостности, и периодическое восстановление в изолированную среду. Миф «зелёная задача означает проверенный бэкап» пора оставить в прошлом.

Восстановление — критерий готовности

Сначала определите, что именно понадобится вернуть: виртуальную машину целиком, контейнер или отдельные файлы. Для VM выполните тестовое восстановление в отдельную сеть или на стенд, чтобы не столкнуть копию с рабочей системой. Убедитесь, что гостевая ОС загружается, приложение видит данные, а ответственное лицо может подтвердить результат. Запишите, сколько заняли поиск точки, восстановление и проверка. Так появляется оценка времени возврата, основанная на вашей инфраструктуре, а не обещание «за четыре часа» из неподтверждённого кейса.

Восстановление отдельных файлов доступно через инструменты PBS для поддерживаемых типов бэкапов, но порядок зависит от источника и версии компонентов. Не обещайте «любой файл за минуты» без проверки конкретной VM, гостевой системы, прав и объёма. Отдельно проверьте, доступны ли нужные ключи шифрования, учётные записи, DNS и сеть на стенде. У резервной копии есть техническая сторона и организационная: кто принимает решение о возврате, кто имеет право его запускать, откуда берётся пароль и как фиксируется результат.

Составьте короткий регламент: частота резервных копий, срок хранения, кто проверяет задания, где хранится вторая копия и как часто выполняется восстановление. Документация не устанавливает единую для всех компаний частоту тестов «раз в месяц»: интервал выбирают по критичности систем и допустимому риску. Но ни одну важную систему нельзя считать защищённой, пока восстановление не проверено на практике. Бэкап без репетиции — это сценарий, который никто не читал до премьеры.

Частые вопросы