Proxmox backup server windows server

Виртуализация плотно вошла в нашу жизнь, предоставляя широкие возможности даже небольшим организациям, вместе с тем появляются и новые сложности, одна из них — эффективное резервное копирование виртуальной инфраструктуры. А так как количество копируемых данных только растет также остро встает вопрос эффективного использования пространства хранения и нагрузки на каналы связи. Многие из этих вопросов позволяет решить новый продукт от компании Proxmox — Backup Server, который прекрасно дополняет собственные решения по виртуализации.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Почему именно Backup Server, что такого, чего нет в существующих решениях предоставляет данная разработка? Proxmox Virtual Environment имеет собственные средства резервного копирования, построенные на базе vzdump. Они просты и надежны, но все их достоинства на этом заканчиваются. По сути, штатные средства умеют только создавать дамп в выбранное хранилище, в том числе и сетевое, но остальное — это уже отдельная забота системного администратора. Если нод или кластеров несколько, то каждый из них имеет собственные настройки резервного копирования, собственные хранилища и т.д. и т.п. Нет никакой общей точки управления бекапами.

Proxmox Backup Server такую общую точку предоставляет, теперь вы можете видеть все свои резервные копии в одном месте и централизованно управлять ими. Но централизация — важное, но не единственное преимущество нового продукта. Так vzdump не умеет создавать инкрементные копии, каждый раз создавая полный образ виртуальной машины или контейнера. Даже если у вас достаточно места на устройствах хранения, то все равно остается вопрос нагрузки на каналы связи, особенно если резервные копии нужно делать в рабочее время или технологическое окно невелико.

Proxmox Backup Server использует собственный формат резервных копий и полностью поддерживает инкрементное копирование, теперь по сети будут передаваться только измененные данные виртуальной машины, что позволяет не только снизить трафик, но и ускорить сам процесс копирования. Теперь копии можно делать чаще и быстрее, что только положительно скажется на надежности инфраструктуры.

Вторая существенная проблема современных информационных систем — постоянно растущий объем данных и виртуализация только подливает масла в огонь. Вместо одной системы с множеством сервисов мы получаем множество систем с индивидуальным сервисом в каждой, каждая из которых нуждается в резервном копировании и содержит пересекающиеся с другими системами данные — системные файлы и библиотеки, которые одинаковы в однотипных машинах. Решение этой проблемы придумано достаточно давно — дедупликация и Proxmox Backup Server ее поддерживает.

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

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

Установка Proxmox Backup Server не представляет особой сложности, продукт имеет фирменный инсталлятор, прекрасно знакомый любому, кто работал с Proxmox.

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

Общие рекомендаций по организации системы хранения дать сложно, но чаще всего имеет смысл разделять систему, вынося ее на отдельные высокоскоростные диски (NVMe, SSD), и собственно хранилище, собранное из дисков подходящей емкости. Для системы мы предпочитаем использовать ext4, как наиболее простую и понятную файловую систему, а для хранилища ZFS.

Первоначальная настройка Proxmox Backup Server

После установки вам будет доступен веб-интерфейс сервера резервного копирования по адресу https://<адрес_сервера>:8007, в качестве адреса можно использовать как IP-адрес, так и FQDN имя. Обратите внимание, что в отличие от Proxmox VE, который использует порт 8006, Backup Server использует порт 8007. Русский язык присутствует, но перевод выполнен частично. Сам интерфейс реализован в привычном ключе и не должен вызвать затруднений в работе.

Но перед тем, как начинать настройку сервера нужно выполнить некоторые подготовительные действия, прежде всего нужно отключить коммерческий репозиторий Proxmox и подключить репозиторий без подписки. Для отключения удалим файл репозитория из источников адресов apt:

rm -f /etc/apt/sources.list.d/pbs-enterprise.list

И создадим новый файл с адресом некоммерческого репозитория:

echo "deb http://download.proxmox.com/debian/pbs bullseye pbs-no-subscription" > /etc/apt/sources.list.d/pbs-no-subscription.list

Теперь получим список пакетов и обновим систему, это можно сделать как в консоли, так и в графической оболочке. В этом случае, если вы используете русский язык, у вас будет две кнопки Обновить, которые выполняют различные действия: первая обновляет список пакетов (Update), вторая обновляет систему (Upgrade), эти действия нужно выполнить последовательно.

Либо откройте консоль и выполните:

apt update
apt full-upgrade

После обновления систему следует перезагрузить.

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

Конкретные рекомендации по организации системы хранения дать сложно, все зависит от типа, объема и количества используемых дисков, а также предполагаемой нагрузки и объема хранимых данных. Но в любом случае мы бы советовали присмотреться к RAIDZ, это оригинальная реализация RAID-массива от ZFS, продолжающая заложенные в RAID-5 идеи, но избавленная от многих его недостатков. В данном случае RAIDZ массивы являются наиболее оптимальными по сочетанию производительности и надежности хранения, цифра в наименовании массива показывает отказ какого количества дисков одновременно он способен выдержать. Так RAIDZ-1 допускает выход одного жесткого диска, а RAIDZ-3 — сразу трех.

Управление хранилищами данных

Для размещения резервных копий Proxmox Backup Server использует хранилища данных (Datastore) — это дополнительный уровень абстракции, представляющий собой особым образом организованную директорию в пределах существующей файловой системы. Каждое хранилище имеет собственные настройки глубины хранения, очистки, дедупликации, наборы прав доступа и т.д. Количество хранилищ не ограничено, но вы должны создать как минимум одно.

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

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

В нашем случае мы создадим два хранилища: одно для контейнеров с Linux, второе для виртуальных машин с Mikrotik CHR. Для того чтобы добавить хранилище выберем Add Datastore и заполним ряд необходимых полей: Name — имя хранилища, может быть произвольным, но желательно чтобы оно отражало содержимое хранилища, в дальнейшем имя будет использоваться как идентификатор хранилища, Backing Path — абсолютный путь к каталогу, в котором вы хотите создать хранилище, если путь не существует, то он будет создан. GC Schedule — периодичность выполнения сборки мусора, фактически выполняет задачу дедупликации, Prune Schedule — периодичность очистки хранилища от устаревших резервных копий.

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

Все просто, задание очистки обрабатывает их последовательно, в порядке перечисления, уже обработанные копии из дальнейшей обработки исключаются:

• Keep Last <N> — Хранить последние <N> снимки резервных копий.
• Keep Hourly <N> — Хранить резервные копии за последние <N> часов
• Keep Daily <N> — Хранить резервные копии за последние <N> дней.
• Keep Weekly <N> — Хранить резервные копии за последние <N> недель. Недели начинаются в понедельник и заканчиваются в воскресенье.
• Keep Monthly <N> — Хранить резервные копии за последние <N> месяцев.
• Keep Yearly <N> — Хранить резервные копии за последние <N> лет.

Если за один период создается более одной резервной копии, сохраняется только последняя.

Для того, чтобы лучше понять принцип действия алгоритма рекомендуем воспользоваться Симулятором очистки, давайте зададим следующие параметры: хранить 4 последних копии, копии за последние 4 часа, последние 2 дня и последнюю неделю. Периодичность копирования — один раз в шесть часов. Теперь внимательно изучим результат:

С первой опцией все понятно — храним 4 последних копии, а вот с последними 4 часами есть тонкость — наши копии делаются раз в шесть часов, т.е. не попадают под условие очистки, точнее наоборот, попадают, возможно все, так как 4-х часовой интервал будет рассчитываться от последней сохраненной по предыдущему правилу копии. Но в этом случае разработчики решили расширить действие правила, и оно также захватит 4 последних копии, хотя фактически это будет 24-х часовой интервал. Далее мы видим две дневные и одну недельную копию. Все ровно так, как мы и задали: 4 — 4 -2 — 1, т.е. в любом случае сервер будет хранить резервные копии в количестве не менее указанного, даже если они выходят за интервал хранения. На наш взгляд — это правильно, лучше иметь резервную копию, нежели не иметь ее.

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

Управление пользователями

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

Поэтому кроме разделения данных по разным хранилищам также следует настроить различные права доступа к ним. Proxmox Backup Server поддерживает две области аутентификации (Realms): стандартную Linux PAM, которая включает системных пользователей и pbs — область аутентификации Backup Server, этот тип пользователей не регистрируется в системе и не может войти в нее, а существует только в пределах сервера резервного копирования, что обеспечивает более высокую степень безопасности.

Для создания пользователей следует перейти в Configuration — Access Control — User Management, а сам процесс не представляет какой-либо сложности, существует ограничение на длину имени — не менее 5 символов.

Обратите внимание, что все создаваемые при помощи веб-интерфейса пользователи будут включены в область аутентификации pbs, если вам нужен пользователь с областью аутентификации pam — его следует создать средствами операционной системы. По умолчанию пользователям не назначаются никакие права, это нужно сделать самостоятельно, для этого можно воспользоваться вкладкой Permissions, но если мы хотим задать права доступа к хранилищам, то удобнее пойти другим путем.

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

Существует достаточно сбалансированная система ролей, начиная от роли Admin, которому можно все и заканчивая ролью Audit, которая ограничена только чтением настроек и не имеет доступа к реальным данным. Если мы говорим о хранилище, то следует выбрать одну из следующих ролей:

• DatastoreAdmin — полный доступ к хранилищу данных.
• DatastoreAudit — может просматривать настройки хранилища данных и содержимое. Не разрешено читать фактические данные (восстанавливать данные).
• DatastoreReader — может проверять содержимое хранилища и выполнять восстановление.
• DatastoreBackup — может создавать резервные копии и восстанавливать собственные резервные копии.
• DatastorePowerUser — может создавать резервные копии, восстанавливать и удалять собственные резервные копии.

Для примера выполним вход пользователем, для которого мы указали роль DatastoreAdmin, он будет иметь доступ только к собственному хранилищу и будет иметь возможность создать новое хранилище, также для него существует возможность создавать новых пользователей и выдавать им права на те объекты, которые ему доступны. Доступа к настройкам других пользователей или системы он не имеет, а при попытке получить доступ ему будет выведено сообщение об ошибке 403 Forbidden.

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

Подключение Proxmox Backup Server к Virtual Environment

Теперь, когда хранилища настроены и пользователи созданы самое время подключить наш сервер резервного копирования к гипервизору и настроить их совместную работу. Все современные версии Proxmox Virtual Environment поддерживают работу с Backup Server «из коробки», но в любом случае мы советуем обновить пакеты гипервизора до самой последней версии.

Для подключения перейдем на уровень Датацентр — Хранилища — Добавить и в выпадающем списке выберем Proxmox Backup Server.

Диалог добавления в целом понятен: указываем идентификатор хранилища, его можем выбрать произвольно, но желательно задавать осмысленные имена, адрес сервера можно указать как по IP, так и по FQDN, имя пользователя с обязательным указанием области аутентификации, т.е. root@pam или user_1@pbs, в поле Datastore указываем идентификатор хранилища, к которому подключаемся. Отдельного разговора заслуживает поле Отпечаток, о нем ниже.

При подключении хранилища мы должны убедиться в подлинности сервера резервного копирования, это можно сделать различными способами, один из них — проверка отпечатка сертификата, который остается неизменным на весь период действия последнего и позволяет однозначно подтвердить его подлинность. Получить отпечаток можно перейдя в Панель мониторинга (Dashboard) Proxmox Backup Server и нажав в верхнем правом углу кнопку Show Fingerprint.

Если все сделано правильно, то хранилище будет добавлено в список доступных для этого датацентра (или отдельной ноды, если при подключении вы указали ограничения в поле Узлы) и его можно использовать для настройки резервного копирования штатными средствами. Если у вас есть уже настроенные задания то их можно легко перенаправить на Proxmox Backup Server просто изменив хранилище в настройках.

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

Управление резервными копиями

Теперь, когда мы все настроили и проверили самое время посмотреть какие возможности предоставляет Proxmox Backup Server и ради чего все это затевалось. Начнем со статистики, она ведется для каждого хранилища и показывает не только объем занятого пространства, но и скорости обмена с дисками, количество и задержки операций ввода-вывода, что очень важно, так как позволяет непосредственно контролировать производительность хранилища, понимать и избегать узких мест.

Единственный момент, который следует учитывать — это параметр Storage usage, который показывает занятое и доступное свободное место не в хранилище, а в файловой системе, где расположено хранилище и если у вас в пределах одной файловой системы расположено несколько хранилищ, то этот показатель будет везде одинаков.

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

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

Все мы знаем, что резервные копии мало создавать и хранить, нужно еще обеспечивать их целостность и регулярно выполнять такие проверки. Файлы резервной копии могут быть повреждены при передаче, либо может возникнуть ошибка в системе хранения, для «холодных» данных это особенно актуально, так как о возникновении такой ошибки мы узнаем только тогда, когда попробуем прочитать файл.

Proxmox Backup Server позволяет эффективно избегать подобных ситуаций, для этого вместе с каждой резервной копией создается файл-манифест index.json который содержит контрольные суммы для каждого файла резервной копии, а процесс верификации заново вычисляет контрольные суммы хранящихся файлов и сравнивает их с манифестом, если они совпали — то копия является целостной. Такие проверки следует выполнять регулярно и настроить их можно на вкладке Verify Jobs, настройки по умолчанию подразумевают ежедневную верификацию и повторную проверку верифицированных копий раз в месяц, что позволить вовремя выявить проблемы с отказом устройств хранения или возникновения ошибок на них.

Также вы можете выполнить верификацию вручную, не дожидаясь срабатывания задания, выбрав один из вариантов на вкладке Content, можно проверить все хранилище, отдельную виртуальную машину / контейнер, либо отдельную копию.

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

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

В заключение рассмотрим возможности взаимодействия с сервером резервного копирования в интерфейсе Proxmox Virtual Environment, их немного, но это минимум достаточного. Мы можем восстановить резервную копию в новое расположение, просмотреть конфигурацию виртуальной машины или контейнера, выполнить очистку для группы (под группой подразумевается виртуальная машина / контейнер) или удалить копию, также отсюда мы можем контролировать статус верификации.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В середине июля этого года мы рассказывали о том, что была представлена бета-версия Proxmox Backup Server (PBS). В день холостяков, 11.11.2020 в 11:11, Proxmox Server Solutions GmbH опубликовали релиз версии 1.0.1, что не прошло незамеченным. Взглянем детально, как использовать PBS и для чего он подходит.

Основной упор при создании PBS был сделан на совместимость и удобство работы с Proxmox VE (PVE). Разработчики постарались максимально упростить процесс интеграции и сделать так, чтобы все элементы интерфейса и подход к управлению резервным копированием были интуитивно понятны пользователям PVE.

Короткое, но емкое вводное видео о возможностях Proxmox Backup Server:

Прежде всего установим Proxmox Backup Server. С момента выхода beta-версии инсталлятор остался точно таким же.

^{Доступные варианты файловых систем в инсталляторе}

Примечательно то, что система может сама собрать ZFS-массив и установиться сразу на него. Также для выбора доступна традиционная для Linux файловая система EXT4.

Вариант с XFS не рекомендуем, поскольку у нее имеется ряд существенных недостатков, таких как невозможность уменьшить размер существующей файловой системы, а также сложность восстановления данных при возникновении сбоев.

После установки и перезагрузки появляется возможность зайти в веб-интерфейс управления PBS. Отметим, что не все действия можно выполнить непосредственно из него, часть придется выполнять через CLI. Вероятно, с развитием продукта ситуация в корне поменяется.

^{Внешний вид веб-интерфейса управления}

Главная страница достаточно информативна. Удобные индикаторы, показывающие в реальном времени нагрузку на сервер, данные по занятому дисковому пространству, наиболее длительные операции за последний месяц, а также запущенные задания резервного копирования.

Главное не забыть обновления

Чтобы потом не было мучительно больно получать ошибки вида HTTP Error 404 Not Found: Path ‘/fixed_index’ not found при создании заданий бэкапа, следует озаботиться обновлением серверов PVE и PBS до актуальных версий. Если у вас есть платная подписка на Enterprise-репозиторий, то просто обновляете дистрибутивы командой:

apt update && apt full-upgrade

Если подписки нет — ничего страшного. Пропишем в систему no-subscription репозиторий и обновимся с него.

nano /etc/apt/sources.list.d/pve-enterprise.list

Закомментируем строку платного репозитория символом # и добавим следующую строку.

Для Proxmox Backup Server:

deb http://download.proxmox.com/debian/pbs buster pbs-no-subscription

Для Proxmox Virtual Environment:

deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Выходим Ctrl + X и отвечаем y. Теперь можно обновить пакеты вышеуказанной командой и приступить к интеграции PBS.

Добавляем PBS-сервер в Proxmox VE

Перед тем как добавлять сервер резервного копирования в среду виртуализации Proxmox VE, потребуется выполнить ряд предварительных действий непосредственно на сервере Proxmox Backup Server.

Создание пользователей

^{Управление пользователями в Proxmox Backup Server}

Перед тем как переходить к бэкапам, нужно первым делом сконфигурировать доступы. Советуем сразу зайти в Configuration — Access Control и создать пользователей для хранилища. Для демонстрации мы изначально создали пользователя test@pbs, которого станем использовать для подключения. Обратите внимание, что при вводе имени пользователя часть ‘@pbs’ обязательна, в противном случае будет выдаваться ошибка о неверно введенных данных.

Теперь переходим к созданию нужных репозиториев (Datastore в терминологии PBS). Это дает возможность четко распределить бэкапы по необходимым системному администратору критериям, а также распределить права доступа. Для создания нам потребуется директория, расположенная на одном из примонтированных дисков.

Создание Datastore и указание прав доступа

^{Управление дисками в Proxmox Backup Server}

Заходим в раздел Administration — Storage / Disks. Выбираем нужный диск и инициализируем его нажатием кнопки Initialize Disk with GPT. Теперь переходим в раздел Directory — Create:Directory и создаем директорию для хранения данных. Здесь указываем имя репозитория и абсолютный путь к созданной директории. Если поставить галочку Add as Datastore, то новый репозиторий сразу будет подключен как сущность для хранения данных.

Осталось лишь указать пользователей, которые имеют право использовать этот репозиторий, и их уровень доступа. Для этого кликаем на имя созданного репозитория, переходим в раздел Permissions и нажимаем кнопку Add — User Permission. Выбираем нужного пользователя и его роль, затем подтверждаем нажатием Add. На этом предварительная подготовка закончена.

Сохранение «‎отпечатка пальца»‎ сервера

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

Заходим в Administration — Shell и ‎снимаем «отпечаток пальца»‎ сервера:

proxmox-backup-manager cert info | grep Fingerprint

Ответом на команду будет строка вида:

Fingerprint (sha256):
bb:fb:13:0f:f7:59:df:32:f0:bf:70:38:22:f8:22:93:05:2f:22:80:bc:71:07:cc:8d:1f:6e:f8:0f:da:bf:73

В дальнейшем мы будем использовать этот отпечаток для установки соединения.

Добавление сервера в роли хранилища

Добавление хранилища можно выполнить или непосредственно из веб-интерфейса Proxmox VE (Datacenter — Storage — Add) или вручную. Мы воспользуемся консолью и проделаем следующие шаги. Добавляем наш Datastore командой:

pvesm add pbs PVE_STORAGE_NAME --server PBS_SERVER_ADDRESS --datastore STORAGE_NAME

Немного разберем, что делает эта команда:

• pvesm add pbs — добавление хранилища (Storage в терминологии PVE);
• PVE_STORAGE_NAME — это имя будет отображаться в веб-интерфейсе PVE и может отличаться от имени хранилища;
• —server PBS_SERVER_ADDRESS — указываем хостнейм или IP-адрес сервера PBS (при необходимости можно указать и другой порт подключения через —port);
• —datastore STORAGE_NAME — тут указываем имя существующего datastore на сервере PBS.

pvesm set PVE_STORAGE_NAME --username test@pbs --password PASSWORD

Тут все также логично. Нам нужно указать реквизиты для подключения к хранилищу. Именно для этого мы предварительно создавали пользователя и распределяли права доступа. Осталось лишь прописать «‎отпечаток пальца»‎ сервера для установки доверенного соединения.

pvesm set PVE_STORAGE_NAME --fingerprint 
bb:fb:13:0f:f7:59:df:32:f0:bf:70:38:22:f8:22:93:05:2f:22:80:bc:71:07:cc:8d:1f:6e:f8:0f:da:bf:73

^{Так выглядит правильно подключенное хранилище сервера PBS}

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

Бэкап LXC-контейнера

^{Тестовый контейнер с Ubuntu}

Для теста мы из стандартного шаблона создали и запустили контейнер СТ100 с запущенной внутри операционной системой Ubuntu 16.04. Теперь переходим в раздел Backup, выбираем нужный Storage и нажимаем кнопку Backup Now. Выбираем тип резервного копирования (об этом можно детально прочитать в одной из предыдущих статей) и выполняем резервное копирование.

^{Успешно выполненный бэкап из web-интерфейса PVE}

Зайдя на сервер PBS, мы также увидим, что у нас теперь есть информация о выполненном задании резервного копирования.

^{Успешно выполненный бэкап из web-интерфейса PBS}

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

Сделать бэкап — это лишь половина успеха. Гораздо важнее из него восстановиться. Удаляем наш LXC-контейнер с Ubuntu и попробуем выполнить процедуру восстановления. Для этого в веб-интерфейсе PVE переходим на наш Storage в раздел Content и выбираем файл бэкапа.

^{Выбор опций восстановления}

Для восстанавливаемого контейнера выбираем место размещения, новый ID (по умолчанию будет стоять тот, который был на момент резервного копирования), а также скоростной лимит чтения данных. Это позволит не перегрузить входящий канал сервера виртуализации. Нажимаем Restore и запускаем наш контейнер.

^{Контейнер восстановлен и запущен}

Контейнер успешно восстановлен. На нашем тестовом стенде процедура бэкапа заняла чуть более 9 секунд и восстановилась за 14. Скорость будет зависеть как от выбранных опций, так и от характеристик обоих серверов.

Бэкап виртуальной машины

Процедура бэкапа полноценной виртуальной машины ничем не отличается от процедуры бэкапа контейнера, разве что времени занимает больше. Мы для теста создали машину с ID 100 и развернули на ней Ubuntu 16.04, после чего выполнили резервное копирование.

^{Успешно выполненный бэкап виртуальной машины из веб-интерфейса PVE}

Со стороны Proxmox Backup Server это выглядело следующим образом:

^{Успешно выполненный бэкап виртуальной машины из веб-интерфейса PBS}

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

Бэкап данных с любого Linux-хоста

Помимо виртуальных машин и контейнеров, заявлено, что Proxmox Backup Server позволяет бэкапить любые Linux-хосты целиком. Проверим это на практике. Будет использован тот же PBS-сервер. Для корректного выполнения нам потребуется на бэкапируемом хосте выполнить ряд дополнительных действий по установке агента под названием proxmox-backup-client. В роли тестовой машины у нас будет компьютер с той же самой Ubuntu 16.04.

Утилиты proxmox-backup-client в репозиториях Ubuntu нет, поэтому для начала добавим 3 репозитория. Два из них нужны для разрешения зависимостей утилиты, а еще один содержит нужный нам клиент:

sudo nano /etc/apt/sources.list

В конец добавляем строки:

deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib
deb http://download.proxmox.com/debian/pbs buster pbs-no-subscription

Выходим из редактора Ctrl + X и отвечаем y на вопрос о сохранении данных. Вытягиваем и устанавливаем ключики репозиториев:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 7BF2812E8A6E88E0

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 04EE7237B7D453EC

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com DCC9EFBF77E11517

Обновляем список источников приложений:

sudo apt update

Устанавливаем бэкап-клиент:

sudo apt install proxmox-backup-client

Осталось лишь выполнить бэкап. Для примера мы забэкапим корневую директорию нашей тестовой машины:

sudo proxmox-backup-client backup root.pxar:/ --repository PBS_IP_ADDRESS:DATASTORE_NAME

^{Успешно выполненный бэкап хоста}

Восстановление отдельных файлов из бэкапа

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

^{Пример скачивания отдельного файла из бэкапа}

Заключение

Proxmox Backup Server стал тем кусочком паззла, которого не хватало для полноценной среды виртуализации Enterprise-уровня. Один раз настроив выполнение бэкапов по расписанию, можно будет не переживать, что виртуальные машины или контейнеры пропадут, например, при сбое носителей информации. Восстановить их теперь — тривиальная задача, практически не требующая никаких лишних телодвижений. Подняли новый хост, добавили репозиторий и запустили восстановление.

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

Previously, I discussed built-in snapshots and backup features in Proxmox VE. Today, I will have a look at Proxmox Backup Server. Proxmox Backup Server is an enterprise-ready backup and recovery solution for VMs, containers, and physical servers. It supports deduplicated and incremental backups to reduce network load and increase storage efficiency.

Download Proxmox Backup Server

You can download the ISO file of Proxmox Backup Server from the official website and then extract it to a USB flash drive using Rufus or balenaEtcher.

The process of creating a bootable USB flash drive is similar to that of Proxmox VE.

Install Proxmox Backup Server

Once you have the bootable USB ready, plug it in, and boot your server from the USB drive. Then follow these steps:

1. On the welcome screen, select the Install Proxmox Backup Server option, and press Enter.

   

   Welcome to Proxmox Backup Server installation

2. Read the end user license agreement and click the I agree button to proceed.

   

   Accepting the end user license agreement for Proxmox Backup Server

   The installer will automatically detect all the hard drives connected to the server.

3. Select your preferred installation target (hard disk) for Proxmox Backup Server, and click Next.

   

   Selecting the installation target for Proxmox Backup Server

4. Now, select your country, time zone, and keyboard layout, and click Next.

   

   Selecting the location and time zone for Proxmox Backup Server

5. Set a strong password for the root account, enter your email address, and click Next.

   

   Setting the administrator password and email address for Proxmox Backup Server

   Proxmox Backup Server will send important alert notifications to this email address, so make sure you enter a valid email address here.

6. Now select a management network interface and configure a hostname, IP address, gateway, and DNS for Proxmox Backup Server.

   

   Management network configuration for Proxmox Backup Server

7. Finally, review all the settings, and click Install.

   

   Review the configuration summary for Proxmox Backup Server

   The server restarts automatically after installation.

   The management URL for Proxmox Backup Server is displayed on the login screen.

8. Open this URL in the web browser to start managing your Proxmox Backup Server.

   

   Viewing the management URL on the Proxmox Backup Server login screen

   

   Proxmox Backup Server management GUI login

   If you have a private DNS server configured, you can also use the server’s hostname, such as https://pbs1.testlab.local:8007/.

Proxmox Backup Server GUI

Let’s discuss various options available in the Proxmox Backup Server management interface. The Administration menu option allows you to perform various administrative tasks. Here, you can manage services, updates, repositories, and syslog. You can also restart or shut down Proxmox Backup Server.

Manage your subscription and repository

When you log in to the Proxmox Backup Server GUI, you will see a notification about no valid subscription.

You can purchase a subscription if you’re planning to use this server in a production environment. After purchasing a subscription, click Subscription in the navigation menu and then click the Upload Subscription Key button, as shown in the screenshot below.

You can upload the subscription key here, which gives you access to the enterprise repository to receive production-grade updates that are heavily tested.

If you do not want to pay, you can enable a no-subscription repository to receive updates that are not as heavily tested as those of the enterprise repository. To enable the no-subscription repository, you first need to disable the enterprise repository, which is enabled by default. To do so, select Administration > Repositories. Now select the pbs-enterprise.list repository, and click the Disable button. See the following screenshot for reference:

After disabling the enterprise repository, click the Add button, choose the No-Subscription repository from the dropdown list, and click Add as shown in the screenshot:

Install updates

Once you have enabled a suitable repository as per your requirements (enterprise or no-subscription), click the Administration menu, select the Updates tab, and then click the Refresh button to check for updates.

If updates are available, click the Upgrade button. The process starts in a new popup window, as you can see in the image.

Manage users

There is only a root user that is created by default during the installation of Proxmox Backup Server. You can create a new user by clicking the Access Control submenu under Configuration and then going to the Under Management tab.

As you can see in the screenshot, I just created a Backup Operator user. Note that the realm for this new user is pbs, whereas the default root user is created under the pam realm. Realms are authentication methods supported by Proxmox VE and Proxmox Backup Server. We don’t need to give this user any permissions right now; we will do that later.

Create a datastore

Storage is the heart of any backup system. Proxmox Backup Server supports both block-level and file-level backups. Before you can start using Proxmox Backup Server, you first need to configure a datastore—a location where backups are stored. To do so, click the Storage / Disks menu option. You will see a list of all the hard drives connected to your Proxmox Backup Server. Now select an unused disk and click Initialize Disk with GPT.

Once the disk is initialized, click the Directory tab, and then click the Create: Directory button, as shown in the screenshot.

Now, create a backup directory, as shown in the screenshot below:

Make sure the Add as Datastore checkbox is selected and click the Create button. This adds the newly created directory as a datastore. If you have multiple unused hard disks, you can click the ZFS option and create a ZFS pool. ZFS makes your backups more resilient to single-disk failures.

As soon as the backup directory is created, a new datastore appears in the Proxmox Backup Server interface. See the screenshot below for reference:

At this point, our new Proxmox Backup Server is ready for use with Proxmox VE.

Datastore permissions

By default, the root user on Proxmox Backup Server gets full access to the datastore. However, we will use the Backup Operator user that we created earlier and give it the required permissions. To do so, click the Permissions tab, then click Add, and select the User Permission option.

Now, select the Backup Operator user and assign a role to it. For our use case, the DatastoreAdmin role is sufficient, as it will allow our Backup Operator user to create and manage backups in the datastore.

Integrate with Proxmox VE

We can now integrate our new Proxmox Backup Server with Proxmox VE. To do so, log in to your Proxmox VE GUI and make sure the Datacenter node is selected at the top. Now, click the Storage option, click the Add button, and then choose Proxmox Backup Server from the dropdown list, as shown in the screenshot below:

Now, fill in all the fields, as shown in the screenshot below:

Notice how the username is specified here. Just entering the username (e.g., root or backup) is not sufficient; you also need to specify the realm. To specify the root user, you need to type root@pam in the username field. The fingerprint can be obtained from the Proxmox Backup Server Dashboard, as shown in the screenshot below:

Backup encryption can be enabled under the Encryption tab.

If you enable encryption, don’t forget to download your encryption key, and keep it safe. Without this key, you will not be able to restore your encrypted backups.

Once Proxmox Backup Server is added under the Proxmox VE datacenter, it is immediately attached to every server (node) in your Proxmox cluster, as shown in the screenshot below:

Configure backups in Proxmox VE

We are now ready to create a backup job in the Proxmox VE datacenter to save the backups in Proxmox Backup Server. To do so, make sure Datacenter is selected in Proxmox VE. Now click the Backup option, and then click the Add button.

Now specify the following settings:

• Under Node, select All to back up all Proxmox VE servers. If you want, you can exclude specific servers here.
• Under Storage, select Proxmox Backup Server ID (pbs, in our case).
• Under Schedule, select a backup schedule as required. I set the backup to happen at 11:59 p.m. every day.
• Under Selection mode, choose All to back up all VMs and containers in the selected Proxmox servers. You may choose a different option to include or exclude any VM or container, as required.
• Under the Send email to and Email fields, enter your email address and configure it to receive alerts as required. I set it to receive alerts about backup failures only.
• Under the Mode field, choose a backup mode. Snapshot mode is the fastest and requires no downtime, but it can cause backup inconsistencies. For highly reliable and consistent backups, you may want to change the backup mode to Stop; keep in mind that this could cause VM downtime.
• Finally, the Enable checkbox ensures that the backup job is enabled.

The backup pruning settings can be configured on the Retention tab.

Our new backup job is now visible under the Backup option.

I will now click the Run now button to manually run the backup job. You will see detailed information about backups under the datastore in the Proxmox Backup Server interface.

Restore from backup

To restore a VM or container from backup, all you need to do is select the Proxmox Backup Server ID, locate the appropriate backup, select it, and then click the Restore button, as shown in the screenshot below:

Subscribe to 4sysops newsletter!

If you want to restore a particular file or folder, you can do so by clicking the File Restore button. You can also perform an on-demand backup and restore an individual VM or container to Proxmox Backup Server. You just need to select pbs as the storage target for your on-demand backup. For more details on Proxmox VE backup and restore, check out my previous post.

Build & Release Notes

rustup Toolchain

We normally want to build with the rustc Debian package. To do that
you can set the following rustup configuration:

# rustup toolchain link system /usr
# rustup default system

Versioning of proxmox helper crates

To use current git master code of the proxmox* helper crates, add:

git = "git://git.proxmox.com/git/proxmox"

or:

path = "../proxmox/proxmox"

to the proxmox dependency, and update the version to reflect the current,
pre-release version number (e.g., «0.1.1-dev.1» instead of «0.1.0»).

Local cargo config

This repository ships with a .cargo/config that replaces the crates.io
registry with packaged crates located in /usr/share/cargo/registry.

A similar config is also applied building with dh_cargo. Cargo.lock needs to be
deleted when switching between packaged crates and crates.io, since the
checksums are not compatible.

To reference new dependencies (or updated versions) that are not yet packaged,
the dependency needs to point directly to a path or git source (e.g., see
example for proxmox crate above).

Build

on Debian 12 Bookworm

Setup:

1. # echo ‘deb http://download.proxmox.com/debian/devel/ bookworm main’ | sudo tee /etc/apt/sources.list.d/proxmox-devel.list
2. # sudo wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
3. # sudo apt update
4. # sudo apt install devscripts debcargo clang
5. # git clone git://git.proxmox.com/git/proxmox-backup.git
6. # cd proxmox-backup; sudo mk-build-deps -ir

Note: 2. may be skipped if you already added the PVE or PBS package repository

You are now able to build using the Makefile or cargo itself, e.g.:

# make deb
# # or for a non-package build
# cargo build --all --release

Design Notes

Here are some random thought about the software design (unless I find a better place).

Large chunk sizes

It is important to notice that large chunk sizes are crucial for performance.
We have a multi-user system, where different people can do different operations
on a datastore at the same time, and most operation involves reading a series
of chunks.

So what is the maximal theoretical speed we can get when reading a series of
chunks? Reading a chunk sequence need the following steps:

• seek to the first chunk’s start location
• read the chunk data
• seek to the next chunk’s start location
• read the chunk data
• …

Lets use the following disk performance metrics:

AST:	Average Seek Time (second)
MRS:	Maximum sequential Read Speed (bytes/second)
ACS:	Average Chunk Size (bytes)

The maximum performance you can get is:

MAX(ACS) = ACS /(AST + ACS/MRS)

Please note that chunk data is likely to be sequential arranged on disk, but
this it is sort of a best case assumption.

For a typical rotational disk, we assume the following values:

AST: 10ms
MRS: 170MB/s

MAX(4MB)  = 115.37 MB/s
MAX(1MB)  =  61.85 MB/s;
MAX(64KB) =   6.02 MB/s;
MAX(4KB)  =   0.39 MB/s;
MAX(1KB)  =   0.10 MB/s;

Modern SSD are much faster, lets assume the following:

max IOPS: 20000 => AST = 0.00005
MRS: 500Mb/s

MAX(4MB)  = 474 MB/s
MAX(1MB)  = 465 MB/s;
MAX(64KB) = 354 MB/s;
MAX(4KB)  =  67 MB/s;
MAX(1KB)  =  18 MB/s;

Also, the average chunk directly relates to the number of chunks produced by
a backup:

CHUNK_COUNT = BACKUP_SIZE / ACS

Here are some staticics from my developer worstation:

Disk Usage:       65 GB
Directories:   58971
Files:        726314
Files < 64KB: 617541

As you see, there are really many small files. If we would do file
level deduplication, i.e. generate one chunk per file, we end up with
more than 700000 chunks.

Instead, our current algorithm only produce large chunks with an
average chunks size of 4MB. With above data, this produce about 15000
chunks (factor 50 less chunks).