Proxmox backup server windows agent

Posted by jpluimers on 2018/01/26

This entry was posted on 2018/01/26 at 06:00 and is filed under Power User, Proxmox, Virtualization, Windows.
You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, or trackback from your own site.

• #1

Hi,

how realistic is it to have a proxmox-backup-client for windows in the next months ? Is someone working on that ? Would that be an easy or complicated task ? I would like to have file Backups of windows vms in addition to image Backups.

• #2

Having backup clients for other operating systems is on our roadmap, but there is no fixed timeframe. This holds especially for Windows, unfortunately.

• #3

Hello

Can we create pbs clients for Windows Server?

Thank

• #4

Hello

Can we create pbs clients for Windows Server?

Thank

Yes I’d be very interested in Server and Win10 support, even it’s a broad indicative timescale

• #5

Plus one for me too, Even if it is a crude client that stops the whole server.

• #6

I’m although interestet in an PBS-Client for Windows Systems

• #7

If it goes somewhere near what VEEAM does it can be a real game-changer….

• #8

I’m also running PBS + Veeam and would prefer to just run PBS. Running Veeam Backup & Replication with deduplication got way too much hardware requirements for a small Homelab setup with very few Windows hosts/guests.

• #9

Is it a matter of money? If so I think we could find enough people to financially support the development of such a thing.

• #10

Is it a matter of money? If so I think we could find enough people to financially support the development of such a thing.

I believe it is more than just money. Consider you start supporting just Windows Client Backup, next people will call for Windows Server backup, next SQL, Exchange, SharePoint…. this is a very huge project. So resources needed are quite huge….

• #11

D’accord, but consider this: the majority of admins using PBS are well versed in supporting multiple OSes and have to support them on a daily basis.
Having an agent for Windows Server, without any drapings like M$SQL, EXCH etc., just an agent to backup the server from within, would be a huge advantage, especially in situations, where a migration to proxmox and PBS is a possibility or pending. To move Server VM Backups from [insert name of product] to PBS gives IT people an edge in arguing for the move. (and less headaches)
With the speed and reliability PBS works, it is, in my opinion, not strictly necessary to have extra agents for the mentioned applications, because a completely safed machine can be restored and the data extracted (although it would be nice to have )
And I could definitely live with a perpetual beta, if it works

• #12

For me just a proxmox-backup-client Win binary that could use VSS to backup some NTFS folders would be totally fine.

• #13

For me just a proxmox-backup-client Win binary that could use VSS to backup some NTFS folders would be totally fine.

Sure, that would be a good start. But even then… Windows 8? 8.1? 10 with its endless sub-builds? What about Windows 11?
Sure, all of them have VSS in Basic, but even the great global VEEAM-Company has often Problems keeping it stable for all OS-Versions when it comes to Version-Specific-Problems in VSS…. I guess it might hard to support all of this. But maybe some day…. if we keep going spreading around PVE and PBS….

• #14

…. if we keep going spreading around PVE and PBS….

That’s the plan, Pinky…

• #15

Same for MacOS … it would be even fine to have the source code to be able to build it ourselves … can’t have too many dependencies since it is a console application only, right?

• #18

Same for MacOS … it would be even fine to have the source code to be able to build it ourselves … can’t have too many dependencies since it is a console application only, right?

For OS X exists Time Machine and Works fine, in WIndows the Windows Server Backup sucks. =(

• #19

For OS X exists Time Machine and Works fine, in WIndows the Windows Server Backup sucks. =(

Hi, the concept of Time Machine is a little different, cannot say anything about the Windows Server Backup.

• #20

Is there any update with this?

В этой статье представлен перевод документации по Proxmox Backup Server. Оригинал документации доступен по этой ссылке!

Введение

Proxmox Backup Server – это сервер корпоративного класса для создания резервных копий. Он может сохранять виртуальные машины, контейнеры и данные с физических серверов.

Прежде всего пробежимся по основным особенностям для этого сервера:

• оптимизирован для ProxmoxVE;
• позволяет синхронизировать резервные копии с другими серверами Proxmox BS;
• простое управление с помощью веб-интерфейса;
• поддерживает дедупликацию, сжатие и шифрование.

В качестве языка программирования использовался RUST. Это гарантирует высокую производительность, низкое потребление ресурсов и качественную кодовую базу.

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

Архитектура и основные функции

Proxmox BS использует клиент-серверную модель. Сервер не только хранит резервные копии, а также обеспечивает безопасность хранения, предоставляет API для создания хранилищ и управления ими. Дополнительно можно управлять дисками, сетью и другими серверными ресурсами.

Клиент резервного копирования использует API для доступа к резервным копиям. С помощью инструмента командной строки proxmox-backup-client вы можете создавать резервные копии и восстанавливать данные. Более того, в Proxmox VE клиент уже встроен.

Одна резервная копия может содержать несколько архивов. Например, при резервном копировании виртуальной машины (VM) каждый диск сохраняется как отдельный архив внутри резервной копии. А конфигурация VM хранится в виде дополнительного файла. В результате можно восстановить только важные части резервной копии без необходимости сканировать её всю.

Proxmox BS состоит из нескольких компонентов:

• Служба сервера, предоставляющая, помимо прочего, RESTful API, сверхбыстрые асинхронные задачи, облегченный сбор статистики, планирование событий, строгое разделение привилегированных и непривилегированных сред выполнения.
• Веб-интерфейс управления написанный на JavaScript.
• Инструмент командной строки для управления сервером (proxmox-backup-manager).
• Инструмент командной строки для создания резервных копий (proxmox-backup-client) доступный для любого 64-разрядного Linux.

Все, кроме веб-интерфейса, написано на языке Rust.

Основные функции:

• Поддержка Proxmox VE – вы можете легко создавать резервные копии виртуальных машин и контейнеров.
• Производительность – программный стек написан на Rust, что обеспечивает высокую скорость и эффективную работы с памятью.
• Дедупликация – позволяет избежать избыточности и уменьшить используемое пространство для хранения.
• Инкрементные резервные копии – изменения между резервными копиями обычно невелики, чтение и отправка только дельты уменьшает влияние на хранилище и сеть.
• Целостность данных – встроенный алгоритм контрольной суммы SHA256 обеспечивает согласованность резервных копий.
• Удаленная синхронизация – можно синхронизировать данные с удаленными серверами PBS, при этом данные передаются инкрементально.
• Сжатие – сверхбыстрое сжатие Zstandard способно сжимать несколько гигабайт данных в секунду.
• Шифрование – резервные копии могут быть зашифрованы на стороне клиента с использованием AES-256 в режиме Galois / Counter Mode (GCM). Кроме того все данные передаются через безопасное соединение TLS.
• Веб-интерфейс – управляйте сервером с помощью встроенного веб-интерфейса.
• Открытый исходный код – это бесплатное программное обеспечение с открытым исходным кодом под лицензией AGPL, v3.
• Поддержка Enterprise – подписка на Proxmox Backup – это дополнительная сервисная программа, предназначенная для того, чтобы помочь поддерживать свои сервера в актуальном состоянии и получать помощь от технических экспертов.

Причины резервного копирования данных

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

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

Еще одна причина для резервного копирования – требования законодательства. Некоторые данные по закону должны храниться в надежном месте в течение нескольких лет, чтобы к ним можно было получить доступ в случае необходимости.

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

Получение помощи и Лицензирование

• Форум поддержки сообщества. Мы всегда поощряем наших пользователей обсуждать и делиться своими знаниями на форуме. Форум модерирует служба поддержки Proxmox. Большая база пользователей разбросана по всему миру. Это отличное место для получения информации.
• Списки рассылки. Proxmox BS является полностью открытым исходным кодом, и мы приветствуем участие! Это основной канал связи для разработчиков.
• Отслеживание ошибок. Proxmox запускает общедоступный трекер ошибок на Bugzilla. Если возникнет проблема, отправьте туда свой отчет. Проблема может быть как ошибкой, так и запросом новой функции.

Авторские права принадлежат: Proxmox Server Solutions GmbH. Proxmox BS – это бесплатное программное обеспечение с открытым исходным кодом: вы можете использовать его, распространять или изменять в соответствии с условиями лицензии GNU, опубликованной Free Software Foundation.

Вы должны были получить копию лицензии вместе с этой программой. Если нет, см. AGPL3.

История

Резервное копирование было и всегда будет центральным аспектом IT-администрирования. Более того, с использованием виртуализации важность резервных копий увеличивается. Поэтому мы с самого начала поставляем инструмент резервного копирования с Proxmox VE. Этот инструмент называется vzdump и может делать резервные копии контейнеров LXC и виртуальных машин KVM.

Однако vzdump позволяет делать только полные резервные копии. Это становится проблемой для пользователей с большими виртуальными машинами. Чтобы решить эту проблему, мы предложили дедупликацию и инкрементное резервное копирование.

Еще в октябре 2018 года началась разработка, а уже в июле 2020 года мы выпустили первую бета-версию Proxmox BS, а в ноябре 2020 года – первую стабильную версию.

Установка

Системные требования

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

Минимальные системные требования:

• ЦП: 64-разрядный, 2 ядра
• Память: 2 ГБ
• Жесткий диск: более 8 ГБ свободного места
• Сетевая карта

Рекомендованные системные требования:

• ЦП: современный 64-разрядный, 4+ ядра
• Память: минимум 4 ГБ для ОС. Добавьте 1 ГБ на 1 ТБ хранилища.
• Хранилище ОС:
  • 32 ГБ или более свободного места;
  • аппаратный RAID с защищенным от батареи кешем записи (BBU) или ZFS с резервированием.
• Хранилище резервных копий:
  • для достижения наилучших результатов используйте только SSD;
  • если используются жесткие диски то настоятельно рекомендуется использовать кеш метаданных.
• Сетевые карты с высокой пропускной способностью.

Для доступа к веб-интерфейсу подойдет любой современный браузер.

Debian репозитории

Все системы на основе Debian используют APT в качестве пакетного менеджера. Списки репозиториев определены в /etc/apt/sources.list, а дополнительные файлы .list находятся в каталоге /etc/apt/sources.d/. Обновления можно установить с помощью командной строки apt или через web-интерфейс.

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

Например файл /etc/apt/sources.list:

deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib
# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Кроме того, вам понадобится репозиторий от Proxmox для получения обновлений ProxmoxBS.

Безопасность APT

Файлы в репозиториях подписаны. APT использует эти подписи для проверки того, что все пакеты получены из надежного источника. Если вы устанавливаете Proxmox BS из официального ISO-образа, ключ проверки уже установлен. Если вы устанавливаете Proxmox BS поверх Debian, загрузите и установите ключ с помощью следующей команды:

# wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

Затем проверьте контрольные суммы с помощью:

# sha512sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
acca6f416917e8e11490a08a1e2842d500b3a5d9f322c6319db0927b2901c3eae23cfb5cd5df6facf2b57399d3cfa52ad7769ebdd75d9 /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

# md5sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
f3f6c5a3a67baf38ad178e5ff1ee270c /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

PBS репозиторий с подпиской

Это стандартный, стабильный и рекомендуемый репозиторий. Он доступен для всех пользователей подписки Proxmox Backup. Он содержит самые стабильные пакеты и подходит для производственного использования. Репозиторий pbs-enterprise по умолчанию включен.

Файл: /etc/apt/sources.list.d/pbs-enterprise.list:

deb https://enterprise.proxmox.com/debian/pbs buster pbs-enterprise

Чтобы никогда не пропустить важные исправления безопасности, суперпользователь (root@pam) получает уведомление по электронной почте о новых пакетах, как только они становятся доступны. Журнал изменений и подробную информацию о каждом пакете можно просмотреть в графическом интерфейсе (при наличии).

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

Вы можете отключить этот репозиторий, закомментировав приведенную выше строку, если у вас нет ключа подписки. В этом случае настройте репозиторий pbs-no-subscription.

PBS репозиторий без подписки

Как следует из названия, вам не нужен ключ подписки для доступа к этому репозиторию. Его можно использовать для тестирования и непроизводственного использования. Не рекомендуется использовать его на производственных серверах, потому что эти пакеты не всегда тщательно тестируются и проверяются.

Мы рекомендуем настроить этот репозиторий в /etc/apt/sources.list:

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

PBS тестовый репозиторий

Этот репозиторий содержит последние пакеты и активно используется разработчиками для тестирования новых функций, поэтому он не рекомендуется для использования в рабочей среде. Вы можете получить доступ к этому репозиторию, добавив следующую строку в /etc/apt/sources.list:

deb http://download.proxmox.com/debian/pbs buster pbstest

Установка используя установщик

Образ диска (файл ISO), предоставленный Proxmox, включает полную систему Debian («buster» для версии 1.x), а также все необходимые пакеты для сервера Proxmox Backup.

Установщик проведет вас через процесс установки и позволит вам:

• разбить локальный диск или диски;
• применить базовые конфигурации системы: часовой пояс, язык, сеть;
• установить все необходимые пакеты.

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

Загрузите ISO с https://www.proxmox.com/downloads. Он включает программу установки, которая разбивает локальные диски с помощью ext4, xfs или ZFS и устанавливает операционную систему с полным набором инструментов для резервного копирования и ядром с поддержкой ZFS. В процессе установки по умолчанию все существующие данные удаляются.

Установка на Debian

В качестве альтернативы Proxmox BS можно установить поверх существующей системы Debian. После настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-server

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

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

# apt-get update
# apt-get install proxmox-backup

Это установит все необходимые пакеты и ядро Proxmox с поддержкой ZFS.

Осторожно! Установка Proxmox BS поверх существующей установки Debian выглядит просто, но предполагает, что базовая система и локальное хранилище были настроены правильно. В общем, это нетривиально, особенно при использовании LVM или ZFS. Конфигурация сети также полностью зависит от ваших предыдущих настроек.

Вы можете получить доступ к веб-интерфейсу Proxmox BS с помощью веб-браузера, используя HTTPS на порту 8007 (https: // <ip>:8007).

Установка на Proxmox VE

После настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-server

Внимание! Не рекомендуется устанавливать сервер резервного копирования непосредственно на гипервизор. Для хранения резервных копий безопаснее использовать отдельный физический сервер. Если сервер гипервизора выйдет из строя, вы все равно сможете получить доступ к резервным копиям.

Установка клиента

Для установки клиента на Debian, после настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-client

Терминология

Содержимое резервной копии

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

Разделение на фрагменты фиксированного размера требует минимальной мощности процессора и используется для резервного копирования образов виртуальных машин.

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

Сервер резервного копирования Proxmox поддерживает обе стратегии.

Архивы образов: <имя> .img

Это используется для образов виртуальных машин и других больших двоичных данных. Контент разбивается на фрагменты фиксированного размера (chunks).

Файловые архивы: <имя> .pxar

В файловом архиве хранится полное дерево каталогов. Контент хранится с использованием формата архива файлов Proxmox (.pxar), разбитого на блоки переменного размера. Формат оптимизирован для достижения хороших показателей дедупликации.

Бинарные данные (BLOB)

Этот тип используется для хранения двоичных данных меньшего размера (<16 МБ), например файлов конфигурации. Файлы большего размера следует хранить как архив образа.

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

Каталог файлов: catalog.pcat1

Файл каталога – это индекс для файловых архивов. Он содержит список файлов и используется для ускорения операций поиска.

Манифест: index.json

Манифест содержит список всех файлов резервных копий, их размеры и контрольные суммы. Он используется для проверки целостности резервной копии.

Тип резервной копии

Сервер резервного копирования группирует резервные копии по типу, где тип может быть одним из:

• vm – используется для виртуальных машин, обычно состоит из файла конфигурации виртуальной машины и архива образов для каждого диска;
• ct – используется для контейнеров, состоит из конфигурации контейнера и одного файлового архива для содержимого файловой системы;
• host – используется для резервных копий данных с физического сервера, обычно это может быть физический хост, но также может быть виртуальная машина или контейнер. Такие резервные копии могут содержать файловые архивы и архивы образов, ограничений на это нет.

ID резервной копии

Уникальный идентификатор. Обычно это идентификатор виртуальной машины или контейнера. Резервные копии типа хоста обычно используют имя хоста.

Время создания резервной копии

Время, когда была сделана резервная копия.

Группа резервной копии

Кортеж <type> / <ID> называется группой резервной копии. Такая группа может содержать один или несколько снимков резервных копий.

Снимок резервной копии

Тройка <тип> / <ID> / <время> называется снимком резервной копии. Он однозначно определяет конкретную резервную копию в хранилище данных.

Примеры снимков резервной копии:

vm / 104 / 2019-10-09T08: 01: 06Z
host / elsa / 2019-11-08T09: 48: 14Z

Как видите, формат времени – RFC 3399 с универсальным временем (UTC, обозначается буквой Z в конце).

Графический пользовательский интерфейс

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

Доступ к веб-интерфейсу можно получить по https: // <ip>: 8007. Логин по умолчанию – root, а пароль – который вы указали при установки.

Функции:

• простой интерфейс управления сервером;
• мониторинг задач, журналов и использования ресурсов;
• управление пользователями, разрешениями, хранилищами данных и т. д;
• безопасная консоль HTML5;
• поддержка нескольких источников аутентификации;
• поддержка нескольких языков;
• на основе JavaScript-фреймворка ExtJS 6.x.

Логин:

Когда подключаетесь к веб-интерфейсу, сначала увидите окно входа в систему. Proxmox BS поддерживает различные языки и серверы аутентификации (Realms).

Для удобства вы можете сохранить имя пользователя на стороне клиента, установив флажок «Save User name:» в нижней части окна.

Обзор

Веб-интерфейс состоит из 3 основных разделов:

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

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

На панели мониторинга (dashboard) отображается сводка активности и использования ресурсов на сервере. В частности, здесь отображается использование оборудования, сводка предыдущих и текущих задач, а также информация о подписке.

Configuration содержит некоторые параметры конфигурации системы, такие как время и конфигурация сети. Он также содержит следующие подразделы:

• Access Control: добавление и управление пользователями, токенами API и разрешениями, связанными с этими элементами.
• Remotes: добавление, редактирование и удаление других серверов для синхронизации.
• Subscription: загрузите ключ подписки, просмотрите статус подписки и получите доступ к текстовому системному отчету.

Administration содержит панель с задачами администрирования и информацией:

• Server Status: обеспечивает доступ к консоли, параметрам питания и различной статистике использования ресурсов.
• Services: управление и мониторинг службами.
• Updates: интерфейс для обновления пакетов.
• Syslog: просмотр сообщений журнала с сервера.
• Tasks: история задач с несколькими вариантами фильтрации.

Пункт меню Administration также содержит подраздел управления дисками:

• Storage / Disks: просмотр информации о доступных дисках:
  • Disks – просмотр и управление дисками;
  • Directory – создание и просмотр информации на дисках ext4 и xfs;
  • ZFS – создание и просмотр информации на дисках ZFS.

Раздел Datastore содержит интерфейсы для создания и управления хранилищами данных. Он содержит кнопку для создания нового хранилища данных на сервере, а также подраздел для каждого хранилища данных в системе, в котором вы можете использовать верхнюю панель для просмотра:

• Summary: доступ к статистике использования хранилища данных;
• Content: информация о группах резервных копий и их соответствующем содержимом;
• Prune & GC: планирование операций очистки и сборки мусора, а также запуск сборки мусора вручную;
• Sync Jobs: создание, управление и запуск заданий синхронизации с удаленными серверами;
• Verify Jobs: создание, управление и выполнение заданий проверки в хранилище данных;
• Options: управление оповещениями, и проверять ли новые снимки;
• Permissions: управление правами доступа к данному хранилищу.

Хранилище

Управление дисками

Proxmox BS поставляется с набором дисковых утилит, доступ к которым осуществляется с помощью подкоманды disk. Эта подкоманда позволяет вам инициализировать диски, создавать различные файловые системы и получать информацию о дисках.

Чтобы просмотреть диски, подключенные к системе, перейдите в Administration -> Disks в веб-интерфейсе или используйте команду:

# proxmox-backup-manager disk list

Чтобы инициализировать диск с новым GPT, используйте подкоманду initialize:

# proxmox-backup-manager disk initialize sdX

Вы можете создать файловую систему ext4 или xfs, используя команду fs create, или перейдя в Administration -> Disks -> Directory в веб-интерфейсе и создав ее оттуда. Следующая команда создает файловую систему ext4 и передает параметр –add-datastore, чтобы автоматически создать хранилище данных на диске. Это создаст хранилище данных в местоположении /mnt/datastore/store1:

# proxmox-backup-manager disk fs create store1 --disk sdd --filesystem ext4 --add-datastore

Вы также можете создать zpool с различными уровнями рейда, выбрав Administration -> Disks -> Zpool в веб-интерфейсе или с помощью zpool create. Приведенная ниже команда создает зеркальный zpool с использованием двух дисков (sdb и sdc) и монтирует его в /mnt/datastore/zpool1:

# proxmox-backup-manager disk zpool create zpool1 --devices sdb,sdc --raidlevel mirror

Вы также можете передать здесь параметр –add-datastore, чтобы автоматически создать хранилище данных с диска.

Вы можете использовать disk fs list и disk zpool list для отслеживания файловых систем и zpool соответственно.

Proxmox BS использует пакет smartmontools. Это набор инструментов, используемых для мониторинга и управления S.M.A.R.T. для локальных жестких дисков. Если диск поддерживает S.M.A.R.T. и у вас она включена, вы можете отображать S.M.A.R.T. атрибуты из веб-интерфейса или с помощью команды:

# proxmox-backup-manager disk smart-attributes sdX

Доступ к этой функции также можно получить напрямую с помощью команды smartctl, которая входит в состав пакета smartmontools.

Хранилище данных

Хранилище данных – это место, в котором хранятся резервные копии. Текущая реализация использует каталог внутри стандартной файловой системы Unix (ext4, xfs или zfs) для хранения данных резервного копирования.

Хранилища данных идентифицируются простым именем. Вы можете настроить его при создании хранилища данных. Информация о конфигурации хранилищ данных хранится в файле /etc/proxmox-backup/datastore.cfg.

Требуется чтобы файловая система поддерживала не менее 65538 подкаталогов на каталог. Эта цифра получается из 2¹⁶ предварительно созданных каталогов (chunk) пространств имен блоков. Это требование исключает поддержку определенных файловых систем. Например, ext3 в целом или ext4 с отключенной функцией dir_nlink.

Вы можете настроить несколько хранилищ данных (datastore). Но необходимо настроить минимум одно хранилище. Datastore идентифицируется простым именем и указывает на каталог в файловой системе. С каждым datastore также связаны настройки хранения, указывающие, сколько снимков резервных копий для каждого интервала времени хранить в этом хранилище. Сокращение и удаление резервных копий и сборку мусора также можно настроить для периодического запуска в соответствии с настроенным расписанием для каждого хранилища данных.

Вы можете создать новое хранилище данных из веб-интерфейса, щелкнув Add Datastore в боковом меню в разделе Datastore. В окне настройки:

• Name – имя хранилища.
• Backing Path – путь к каталогу, в котором вы хотите создать хранилище.
• GC Schedule – время и интервалы, с которыми выполняется сборка мусора.
• Prune Schedule – относится к частоте, с которой происходит обрезка.
• Prune Options – количество резервных копий, которое вы хотите сохранить.
• Comment – можно использовать для добавления некоторой информации о хранилище.

В качестве альтернативы вы можете создать новое хранилище данных из командной строки. Следующая команда создает новое хранилище данных с именем store1 на /backup/disk1/store1:

# proxmox-backup-manager datastore create store1 /backup/disk1/store1

Чтобы вывести список существующих хранилищ выполните:

# proxmox-backup-manager datastore list

Вы можете изменить параметры сборки мусора и сокращения хранилища данных, отредактировав хранилище данных из графического интерфейса пользователя или используя подкоманду update. Например, приведенные ниже команды изменят расписание сборки мусора и выведут его свойства:

# proxmox-backup-manager datastore update store1 --gc-schedule 'Tue 04:27'
# proxmox-backup-manager datastore show store1

А также, можно удалить конфигурацию хранилища данных:

# proxmox-backup-manager datastore remove store1

Приведенная выше команда удаляет только конфигурацию хранилища, не удаляя данные из основного каталога.

После создания хранилища в каталоге появится:

• файл .lock – пустой файл, используемый для блокировки процесса;
• каталог .chunks – содержащий подкаталоги, в которых будут храниться фрагментированные данные после выполнения операции резервного копирования.

Управление сетью

Proxmox BS предоставляет как веб-интерфейс, так и инструмент командной строки для настройки сети. В веб-интерфейсе существует раздел Network Interfaces в меню Configuration, в добавок к этому существует подкоманда network. Эти интерфейсы позволяют выполнять некоторые основные задачи управления сетью, такие как добавление, настройка и удаление сетевых интерфейсов.

Любые изменения, внесенные в конфигурацию сети, не применяются, пока вы не нажмете кнопку Apply Configuration или не введете команду перезагрузки сети. Это позволяет вносить сразу много изменений. Это также позволяет вам убедиться, что ваши изменения верны, прежде чем применять их, так как допущенная здесь ошибка может сделать сервер недоступным по сети.

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

# proxmox-backup-manager network list

Чтобы добавить новый сетевой интерфейс, используйте подкоманду create с соответствующими параметрами. Например, вы можете захотеть создать интерфейс резервирования сети (bond):

# proxmox-backup-manager network create bond0 --type bond --bond_mode active-backup --slaves ens18,ens19 --autostart true --cidr x.x.x.x/x --gateway x.x.x.x

Вы можете внести изменения в конфигурацию сетевого интерфейса с помощью подкоманды update:

# proxmox-backup-manager network update bond0 --cidr y.y.y.y/y

Вы также можете удалить сетевой интерфейс:

# proxmox-backup-manager network remove bond0

Незавершенные изменения файла конфигурации сети появятся в нижней части веб-интерфейса. Вы также можете просмотреть эти изменения, используя команду:

# proxmox-backup-manager network changes

Если вы хотите отменить все изменения на этом этапе, вы можете либо щелкнуть кнопку Revert, либо использовать следующую команду:

# proxmox-backup-manager network revert

Если вас устраивают изменения и вы хотите записать их в файл конфигурации, выберите Apply Configuration. Соответствующая команда:

# proxmox-backup-manager network reload

Эта команда и соответствующая кнопка графического интерфейса зависят от команды ifreload из пакета ifupdown2. Этот пакет включен в установку Proxmox BS, однако вам, возможно, придется установить его самостоятельно.

Вы также можете настроить параметры DNS в разделе Configuration или с помощью подкоманды dns программы proxmox-backup-manager.

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

Настройка пользователей

Proxmox BS поддерживает несколько областей аутентификации, и вам необходимо выбрать область при добавлении нового пользователя. Возможные области:

• pam – стандартная аутентификация Linux PAM. Используйте если вы хотите аутентифицироваться как пользователь системы Linux (пользователи должны существовать в системе).
• pbs – область сервера Proxmox BS. Этот тип хранит хешированные пароли в /etc/proxmox-backup/shadow.json.

После установки появляется единственный пользователь root@pam. Информация о конфигурации пользователя хранится в файле /etc/proxmox-backup/user.cfg. Также вы можете использовать инструмент командной строки для получения списка пользователей или управления ими.

Суперпользователь имеет полные права администрирования во всем. Вы можете добавить других пользователей с меньшими правами. Вы можете добавить нового пользователя с помощью подкоманды user create или через веб-интерфейс на вкладке User Management в Configuration -> Access Control. Подкоманда create позволяет указать множество параметров, например –email или –password. Вы можете обновить или изменить любые свойства пользователя с помощью подкоманды update позже:

# proxmox-backup-manager user create john@pbs --email john@example.com
# proxmox-backup-manager user update john@pbs --firstname John --lastname Smith
# proxmox-backup-manager user update john@pbs --comment "An example user."

Получить список пользователей можно так:

# proxmox-backup-manager user list

У вновь созданных пользователей нет разрешений.

Если вы хотите отключить учетную запись пользователя, вы можете сделать это, установив –enable в 0:

# proxmox-backup-manager user update john@pbs --enable 0

Или полностью удалите пользователя:

# proxmox-backup-manager user remove john@pbs

API токены

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

Токены API служат двум целям:

1. Простой отзыв в случае компрометации клиента.
2. Ограничение разрешения для каждого клиента / токена в пределах полномочий пользователей.

Токен API состоит из двух частей:

1. Идентификатор, состоит из имени пользователя, области и имени токена, например user@realm! Tokenname.
2. Его секрет, например 58a77e1c-77ea-4e7d-bf2c-e265b43d93c0.

Обе части должны быть предоставлены клиенту вместо идентификатора пользователя и его пароля.

Токен API передается от клиента к серверу путем установки HTTP-заголовка авторизации с методом PBSAPIToken на значение TOKENID: TOKENSECRET.

Создание новых токенов можно выполнить с помощью proxmox-backup-manager или графического интерфейса пользователя:

# proxmox-backup-manager user generate-token john@pbs client1

Отображаемое секретное значение необходимо сохранить, поскольку оно не может быть отображено снова после генерации токена API.

Подкоманда user list-tokens может использоваться для отображения токенов и их метаданных:

# proxmox-backup-manager user list-tokens john@pbs

Точно так же пользовательская подкоманда delete-token может использоваться для удаления токена.

У вновь созданных токенов нет никаких разрешений. 

Управление доступом

По умолчанию новые пользователи и токены не имеют разрешений. Вам нужно указать, что разрешено, а что нет. Вы можете сделать это, назначив роли пользователям / токенам для определенных объектов, таких как хранилища данных или remotes. Существуют следующие роли:

• NoAccess – ничего не разрешено.
• Admin – может все.
• Audit – может просматривать, но не может изменять настройки.
• DatastoreAdmin – может делать что угодно в хранилищах данных.
• DatastoreAudit – может просматривать настройки хранилища данных и содержимое. Но не разрешено читать фактические данные (восстанавливать данные).
• DatastoreReader  – может проверять содержимое хранилища и выполнять восстановление.
• DatastoreBackup – Может создавать резервные копии и восстанавливать собственные резервные копии.
• DatastorePowerUser – Может создавать резервные копии, восстанавливать и удалять собственные резервные копии.
• RemoteAdmin – может делать что угодно на remote.
• RemoteAudit – может просматривать настройки remote.
• RemoteSyncOperator – разрешено читать данные с remote.

Информация о правах доступа хранится в /etc/proxmoxbackup/acl.cfg. Файл содержит 5 полей, разделенных двоеточием. Типичная запись имеет вид:

acl:1:/datastore:john@pbs:DatastoreBackup

В каждом поле представлены следующие данные:

1. идентификатор acl;
2. 1 или 0, включено или отключено;
3. объект, на который установлено разрешение;
4. пользователи / токены, для которых установлено разрешение;
5. устанавливаемая роль.

Вы можете управлять разрешениями через Configuration -> Access Control -> Permissions в веб-интерфейсе. Кроме этого вы можете использовать подкоманду acl. Например, добавить пользователя john@pbs в качестве DatastoreAdmin для хранилища данных store1, расположенного в /backup/disk1/store1:

# proxmox-backup-manager acl update /datastore/store1 DatastoreAdmin --auth-id john@pbs

Вы можете получить список ACL каждого пользователя / токена, используя следующую команду:

# proxmox-backup-manager acl list

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

Здесь важно соглашение об именах. Для хранилищ данных на хосте необходимо использовать соглашение /datastore/{storename}. Например, чтобы установить разрешения для хранилища данных, смонтированного в /mnt/backup/disk4/store2, вы должны использовать /datastore/store2 в качестве пути. Для удаленных хранилищ используйте соглашение /remote/{remote}/{storename}, где {remote} означает имя remote, а {storename} – имя хранилища данных на удаленном компьютере.

Права API токенов

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

На практике это означает:

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

Действующие разрешения

Чтобы вычислить и отобразить набор разрешений пользователя или токена, вы можете использовать подкоманду user permission:

# proxmox-backup-manager user permissions john@pbs --path /datastore/store1

Двухфакторная аутентификация

Введение

Для простой аутентификации требуется только логин и пароль (один фактор). Если пароль украден любой может использовать его для входа в систему.

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

Это означает, что удаленный пользователь никогда не сможет заполучить такой физический объект. Таким образом, даже если этот пользователь знает ваш пароль, он не сможет успешно пройти аутентификацию как вы, поскольку отсутствует ваш второй фактор.

Доступные вторые факторы

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

• TOTP (одноразовый пароль на основе времени). Сокращенный код, полученный из общего секрета и текущего времени он переключается каждые 30 секунд.
• WebAuthn (веб-аутентификация). Общий стандарт аутентификации. Реализовано различными устройствами безопасности, такими как аппаратные ключи или доверенные платформенные модули (TPM) из компьютера или смартфона.
• Одноразовые ключи восстановления. Список ключей, которые следует распечатать и сохранить, или сохранить в цифровом виде. Каждый ключ можно использовать только один раз, они идеально подходят для того, чтобы гарантировано получить доступ, даже если все ваши другие вторые факторы потеряны.

Настройка

TOTP

Настройка сервера не требуется, просто установите приложение TOTP на свой смартфон (например, FreeOTP) и используйте веб-интерфейс Proxmox Backup Server, чтобы добавить TOTP.

WebAuthn

Для работы WebAuthn необходимы две вещи:

• доверенный сертификат HTTPS (например, с помощью Let’s Encrypt)
• настроить конфигурацию WebAuthn (Configuration -> Authentication). Его можно автоматически заполнить в большинстве настроек.

Выполнив оба этих требования, вы можете добавить конфигурацию WebAuthn в панель Access Control.

Recovery Keys

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

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

Автоматический доступ

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

Управление удаленными PBS

Remote (сервер PBS для синхронизации)

Под Remote подразумевается отдельная установка Proxmox BS. Вы можете синхронизировать хранилища данных удаленного сервера с локальным хранилищем данных с помощью задания синхронизации. Вы можете настроить Remote в веб-интерфейсе в разделе Configuration -> Remote. Информация о конфигурации Remote хранится в файле /etc/proxmox-backup/remote.cfg.

Чтобы добавить Remote, вам потребуется его имя или IP, идентификатор пользователя и пароль, а также его отпечаток сертификата. Чтобы получить отпечаток, используйте подкоманду cert info на Remote или перейдите в Dashboard в его веб-интерфейсе и выберите Show Fingerprint.

# proxmox-backup-manager cert info | grep Fingerprint

Используя информацию, указанную выше, вы можете добавить Remote из панели конфигурации Remote или с помощью команды:

# proxmox-backup-manager remote create pbs2 --host pbs2.mydomain.example --userid sync@pam --password 'SECRET' --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

Используйте подкоманды list, show, update для управления Remote:

# proxmox-backup-manager remote update pbs2 --host pbs2.example
# proxmox-backup-manager remote list
# proxmox-backup-manager remote remove pbs2

Задания синхронизации

Задания синхронизации используются для извлечения содержимого хранилища данных на удаленном сервере в локальное хранилище. Вы можете управлять заданиями синхронизации в веб-интерфейсе, на вкладке Sync Jobs хранилища данных, для которого вы хотите их настроить, или с помощью подкоманды sync-job. Информация о конфигурации для заданий синхронизации хранится в /etc/proxmox-backup/sync.cfg. Чтобы создать новое задание синхронизации, нажмите кнопку добавления в графическом интерфейсе или воспользуйтесь командой create. После создания задания синхронизации вы можете либо запустить его вручную из графического интерфейса, либо предоставить ему расписание для регулярного выполнения.

# proxmox-backup-manager sync-job create pbs2-local --remote pbs2 --remote-store local --store local --schedule 'Wed 02:30'
# proxmox-backup-manager sync-job update pbs2-local --comment 'offsite'
# proxmox-backup-manager sync-job list
# proxmox-backup-manager sync-job remove pbs2-local

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

1. Remote.Read для хранилища на удаленном сервере
2. Datastore.Backup для хранилища на локальном сервере

Если установлен параметр remove-vanished, Datastore.Prune также требуется на локальном хранилище. Если параметр владельца не задан (по умолчанию root@pam) или задан другой параметр, также требуется Datastore.Modify.

Задание синхронизации может синхронизировать только те группы резервных копий, которые может считывать пользователь или токен API. Если удаленный сервер настроен с помощью пользователя, который имеет только права Datastore.Backup, можно синхронизировать только ограниченный набор доступных снимков, принадлежащих этому пользователю.

Управление задачами

Обрезка

Prune позволяет указать, какие снимки резервных копий вы хотите сохранить. Доступны следующие варианты хранения:

• keep-last <N> Хранить последние <N> снимки резервных копий.
• keep-hourly <N> Хранить резервные копии за последние <N> часов. Если за один час создается более одной резервной копии, сохраняется только последняя.
• keep-daily <N> Хранить резервные копии за последние <N> дней. Если за один день создается более одной резервной копии, сохраняется только последняя.
• keep-weekly <N> Хранить резервные копии за последние <N> недель. Если за одну неделю создается более одной резервной копии, сохраняется только последняя. Недели начинаются в понедельник и заканчиваются в воскресенье.
• keep-month <N> Хранить резервные копии за последние <N> месяцев. Если за один месяц создается более одной резервной копии, сохраняется только последняя.
• keep-Annual <N> Хранить резервные копии за последние <N> лет. Если за один год создается более одной резервной копии, сохраняется только последняя.

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

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

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

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

Обрезка по расписанию

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

В следующем примере мы предполагаем, что вы делаете ежедневные резервные копии, имеете период хранения 10 лет, а период между хранением резервных копий постепенно увеличивается:

• keep-last: 3 – даже если резервное копирование выполняется только ежедневно, администратор может захотеть сохранить ещё 3 резервные копии на случай резервных копий сделанных вручную.
• keep-hourly: не задано – для ежедневных резервных копий это не актуально.
• keep-daily: 13 – вместе с keep-last, у вас будет как минимум две недели резервного копирования.
• keep-weekly: 8 – гарантирует, что у вас будет как минимум два полных месяца еженедельного резервного копирования.
• keep-monthly: 11 – вместе с предыдущими настройками это гарантирует, что у вас будет как минимум годовое ежемесячное резервное копирование.
• keep-yearly: 9 – для долгосрочного архива. Что даст вам в общей сложности как минимум 10 лет покрытия.

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

Сборка мусора

Вы можете отслеживать и запускать сборку мусора на сервере Proxmox BS, используя подкоманду garbage-collection. Вы можете использовать подкоманду start, чтобы вручную запустить сборку мусора для всего хранилища, и подкоманду status, чтобы просмотреть атрибуты, относящиеся к сборке мусора.

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

Проверка резервной копии

Proxmox Backup предлагает различные варианты проверки, чтобы убедиться, что данные резервной копии не повреждены. Верификация обычно осуществляется путем создания заданий верификации. Это запланированные задачи, которые запускают проверку с заданным интервалом. С их помощью вы можете установить, будут ли игнорироваться уже проверенные снимки, а также установить период времени, по истечении которого проверенные задания будут проверяться снова. Интерфейс для создания заданий проверки находится на вкладке Verify Jobs хранилища данных.

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

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

Уведомления

Proxmox BS может отправлять вам электронные письма с уведомлениями об автоматически запланированных результатах проверки, сборки мусора и синхронизации.

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

Вы также можете изменить уровень получаемого уведомления для каждого типа задачи, доступны следующие параметры:

• Always: отправлять уведомление независимо от результата.
• Errors: отправлять уведомление, после ошибки.
• Never: не отправлять уведомления.

Использование клиента

Утилита командной строки клиента называется proxmox-backup-client.

Клиент использует следующую запись для указания репозитория хранилища данных на сервере резервного копирования:

[[username@]server[:port]:]datastore

Значение по умолчанию для имени пользователя – root@pam. Если сервер не указан, по умолчанию используется localhost.

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

Обратите внимание, что если сервер является адресом IPv6, вы должны записать его в квадратных скобках (например, [fe80 :: 01]).

Вы можете передать репозиторий с помощью параметра командной строки –repository или установив переменную среды PBS_REPOSITORY.

Вот несколько примеров действующих репозиториев и реальных значений.

Example	User	Host:Port	Datastore
mydatastore	root@pam	localhost:8007	mydatastore
myhostname:mydatastore	root@pam	myhostname:8007	mydatastore
user@pbs@myhostname:mydatastore	user@pbs	myhostname:8007	mydatastore
user@pbs!token@host:store	user@pbs!token	myhostname:8007	mydatastore
192.168.55.55:1234:mydatastore	root@pam	192.168.55.55:1234	mydatastore
[ff80::51]:mydatastore	root@pam	[ff80::51]:8007	mydatastore
[ff80::51]:1234:mydatastore	root@pam	[ff80::51]:1234	mydatastore

Переменные окружения

PBS_REPOSITORY – Репозиторий резервных копий по умолчанию.

PBS_PASSWORD – Если установлено, используется для пароля от backup server. Вы также можете установить это значение для токена.

PBS_ENCRYPTION_PASSWORD – Если установлено, используется для доступа к секретному ключу шифрования (если защищен паролем).

PBS_FINGERPRINT – Если установлено, используется для проверки сертификата сервера (используется только если сертификаты CA системы не могут подтвердить сертификат).

Формат вывода команд

Большинство команд поддерживают параметр –output-format. Принимает следующие значения:

• text – Текстовый формат (по умолчанию). Структурированные данные отображаются в виде таблицы.
• json –  JSON (однострочный).
• json-pretty – JSON (несколько строк, красиво отформатированы).

Для изменения поведения вывода используйте следующие переменные среды:

• PROXMOX_OUTPUT_FORMAT – определяет выходной формат по умолчанию.
• PROXMOX_OUTPUT_NO_BORDER – если установлено (любое значение), не отображать границы таблицы.
• PROXMOX_OUTPUT_NO_HEADER – если установлено (любое значение), не отображать заголовки таблиц.

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

Создание резервной копии

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

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

# proxmox-backup-client backup root.pxar:/ --repository backup-server:store1
Starting backup: host/elsa/2019-12-03T09:35:01Z
Client name: elsa
skip mount point: "/boot/efi"
skip mount point: "/dev"
skip mount point: "/run"
skip mount point: "/sys"
Uploaded 12129 chunks in 87 seconds (564 MB/s).
End Time: 2019-12-03T10:36:29+01:00

Вам будет предложено ввести пароль, а затем будет загружен файловый архив с именем root.pxar, содержащий все файлы в каталоге /.

Обратите внимание, что proxmox-backup-client не включает автоматически точки монтирования. Вместо этого вы увидите короткое уведомление о пропуске точки монтирования для каждого из них. Идея состоит в том, чтобы создать отдельный файловый архив для каждого подключенного диска. Вы можете явно включить их, используя параметр –include-dev (например, –include-dev /boot/efi). Вы можете использовать эту опцию несколько раз для каждой точки монтирования, которую необходимо включить.

Параметр –repository может быть довольно длинным. Вместо этого вы можете установить переменную среды PBS_REPOSITORY. Если вы хотите, чтобы это значение оставалось после перезагрузки, вам следует добавить следующую строку в ваш файл .bashrc:

# export PBS_REPOSITORY=backup-server:store1

После этого вы можете выполнять все команды без указания опции –repository.

Одна резервная копия может содержать более одного архива. Например, если вы хотите сделать резервную копию двух дисков, установленных в /mnt/disk1 и /mnt/disk2:

# proxmox-backup-client backup disk1.pxar:/mnt/disk1 disk2.pxar:/mnt/disk2

Это создаст резервную копию обоих дисков.

Команда резервного копирования принимает список спецификаций резервного копирования, который включает имя архива на сервере, тип архива и источник архива на клиенте. Формат:

<archive-name>.<type>:<source-path>

Распространенными типами являются .pxar для файловых архивов и .img для образов блочных устройств. Чтобы создать резервную копию блочного устройства, выполните следующую команду:

# proxmox-backup-client backup mydata.img:/dev/mylvm/mydata

Исключение файлов и папок из резервной копии

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

Файл должен содержать по одному шаблону на строку. Пустые строки и закомментированные игнорируются. А “!” в начале строки изменяет шаблон совпадения с исключения на явное включение. Строки, оканчивающиеся на /, соответствуют только каталогам. Каталог, содержащий файл .pxarexclude, считается корнем данных шаблонов. Сопоставлять файлы можно только в этом каталоге и его подкаталогах.

используется для экранирования специальных символов.

? соответствует любому одиночному символу.

* соответствует любому символу, включая пустую строку.

** используется для сопоставления подкаталогов. Его можно использовать, например, для исключения всех файлов, оканчивающихся на .tmp, в каталоге или подкаталогах с помощью следующего шаблона **/*.tmp.

[…] соответствует одному символу из представленных в квадратных скобках. [! …] дополняет и соответствует любому одному символу, не заключенному в скобки. Также можно указать диапазоны двумя символами, разделенными знаком -. Например, [a-z] соответствует любому буквенному символу в нижнем регистре, а [0-9] соответствует любой цифре.

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

Например, рассмотрим следующую структуру каталогов:

# ls -aR folder
folder/:
. .. .pxarexclude subfolder0 subfolder1 
folder/subfolder0:
. .. file0 file1 file2 file3 .pxarexclude
folder/subfolder1:
. .. file0 file1 file2 file3

Различные файлы .pxarexclude содержат следующее:

# cat folder/.pxarexclude
/subfolder0/file1
/subfolder1/*
!/subfolder1/file2

# cat folder/subfolder0/.pxarexclude
file3

При этом будут исключены файлы file1 и file3 в subfolder0 и всё в subfolder1, кроме file2.

Восстановление этой резервной копии приведет к:

# ls -aR restored
restored/:
. .. .pxarexclude subfolder0 subfolder1
restored/subfolder0:
. .. file0 file2 .pxarexclude
restored/subfolder1:
. .. file2

Шифрование

Proxmox Backup поддерживает шифрование на стороне клиента с помощью AES-256 в режиме GCM. Чтобы настроить это, вам сначала нужно создать ключ шифрования:

# proxmox-backup-client key create my-backup.key
Encryption Key Password: **************

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

# proxmox-backup-client key create /path/to/my-backup.key --kdf none

Создав этот ключ, теперь можно создать зашифрованную резервную копию, передав параметр –keyfile с путем к файлу ключа.

# proxmox-backup-client backup etc.pxar:/etc --keyfile /path/to/my-backup.key
Password: *********
Encryption Key Password: **************
...

Если вы не укажете имя резервного ключа, ключ будет создан в расположении по умолчанию ~/.config/proxmox-backup/encryption-key.json. proxmox-backup-client также будет искать в этом месте по умолчанию, если параметр –keyfile не указан.

Вы можете избежать ввода паролей, установив переменные среды PBS_PASSWORD и PBS_ENCRYPTION_PASSWORD.

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

Вы также можете использовать proxmox-backup-client для создания пары открытый / закрытый ключ RSA, которую можно использовать для хранения зашифрованной версии симметричного ключа шифрования резервной копии вместе с каждой резервной копией и восстановления ее позже.

Чтобы настроить мастер-ключ:

1. Создайте ключ шифрования для резервной копии:

# proxmox-backup-client key create
creating default key at: "~/.config/proxmox-backup/encryption-key.json"
Encryption Key Password: **********

2. Создайте пару открытого / закрытого ключей RSA:

# proxmox-backup-client key create-master-key
Master Key Password: *********
...

Это создаст два файла в вашем текущем каталоге, master-public.pem и master-private.pem.

3. Импортируйте только что созданный публичный сертификат master-public.pem, чтобы proxmox-backup-client мог найти и использовать его при резервном копировании.

# proxmox-backup-client key import-master-pubkey /path/to/master-public.pem
Imported public master key to "~/.config/proxmox-backup/master-public.pem"

4. Со всеми этими файлами запустите задание резервного копирования:

# proxmox-backup-client backup etc.pxar:/etc

Ключ будет храниться в вашей резервной копии под именем rsa-encrypted.key.

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

5. Чтобы убедиться, что все работает, вы можете восстановить ключ из резервной копии:

# proxmox-backup-client restore /path/to/backup/ rsa-encrypted.key /path/to/target

Для извлечения этого файла ключ шифрования не требуется. Однако, если ключ существует в местоположении по умолчанию (~/.config/proxmox-backup/encryption-key.json), программа запросит у вас пароль для ключа шифрования. Простое перемещение encryption-key.json из этого каталога решит эту проблему.

6. Затем используйте сгенерированный ранее мастер-ключ для расшифровки файла:

# proxmox-backup-client key import-with-master-key /path/to/target --master-keyfile /path/to/master-private.pem --encrypted-keyfile /path/to/rsa-encrypted.key
Master Key Password: ******
New Password: ******
Verify Password: ******

7. Теперь целевой файл будет содержать информацию о ключе шифрования в виде обычного текста. Успех этого может быть подтвержден передачей результирующего файла json с параметром –keyfile при расшифровке файлов из резервной копии.

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

Рекомендуется хранить мастер-ключ в безопасности, но в легко доступном месте для быстрого восстановления после сбоев. Поэтому лучше всего хранить его в диспетчере паролей, где его можно немедленно восстановить. В качестве резервной копии вы также должны сохранить ключ на USB-накопитель и хранить его в надежном месте. Таким образом, он отключается от любой системы, но по-прежнему легко восстанавливается в случае возникновения чрезвычайной ситуации. Наконец, готовясь к наихудшему сценарию, вам также следует подумать о хранении бумажной копии вашего главного ключа в надежном месте. Подкоманду paperkey можно использовать для создания QR-версии вашего главного ключа.

Следующая команда отправляет вывод команды paperkey в текстовый файл для упрощения печати.

# proxmox-backup-client key paperkey --output-format text > qrkey.txt

Восстановление данных

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

Во-первых, вам нужно найти снимок, который вы хотите восстановить. Команда snapshot list предоставляет список всех снимков на сервере:

# proxmox-backup-client snapshot list

Вы можете просмотреть каталог, чтобы найти определенные файлы.

# proxmox-backup-client catalog dump host/elsa/2019-12-03T09:35:01Z
...
d "./root.pxar.didx/etc/cifs-utils"
l "./root.pxar.didx/etc/cifs-utils/idmap-plugin"
d "./root.pxar.didx/etc/console-setup"
...

Команда восстановления позволяет восстановить отдельный архив из резервной копии.

# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z root.pxar /target/path/

Чтобы получить содержимое любого архива, вы можете восстановить файл index.json в репозитории по целевому пути «-». Это выведет содержимое на стандартный вывод.

# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z index.json -

Интерактивное восстановление

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

# proxmox-backup-client catalog shell host/elsa/2019-12-03T09:35:01Z root.pxar
Starting interactive shell
pxar:/ > ls
bin boot dev etc home lib lib32
…

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

Использование каталога для навигации значительно снижает накладные расходы, поскольку необходимо загрузить и при необходимости, расшифровать только каталог. Фактические фрагменты потребуются только в том случае, если метаданных в каталоге недостаточно для фактического восстановления.

Подобно обычным оболочкам UNIX cd и ls – это команды, используемые для изменения рабочего каталога и вывода содержимого каталога в архиве. pwd показывает полный путь к текущему рабочему каталогу относительно корня архива.

Возможность быстрого поиска в содержимом архива – это необходимая функция. Например:

pxar:/ > find etc/**/*.txt --select
"/etc/X11/rgb.txt"
pxar:/ > list-selected
etc/**/*.txt
pxar:/ > restore-selected /target/path
...

Это найдет и распечатает все файлы с расширением .txt, расположенные в etc или подкаталоге, и добавит соответствующий шаблон в список для последующего восстановления. list-selected показывает эти шаблоны, а restore-selected восстанавливает все файлы в архиве в /target/path на локальном хосте.

С помощью команды restore /target/path вы можете восстановить часть архива, указанный в текущем рабочем каталоге, по локальному целевому пути /target/path на вашем хосте. Если дополнительно передать шаблон с –pattern <glob>, восстановление будет дополнительно ограничено файлами, соответствующими шаблону. Например:

pxar:/ > cd /etc/
pxar:/etc/ > restore /target/ --pattern **/*.conf
...

Это просканирует все подкаталоги в /etc и восстановит все файлы, заканчивающиеся на .conf.

Монтирование архивов используя FUSE

Реализация FUSE для архива pxar позволяет вам монтировать файловый архив как файловую систему только для чтения к точке монтирования на вашем хосте.

# proxmox-backup-client mount host/backup-client/2020-01-29T11:29:22Z root.pxar /mnt/mountpoint
# ls /mnt/mountpoint
bin dev home lib32 libx32 media opt root sbin sys usr boot etc lib lib64 lost+found mnt proc run srv tmp var

Это позволяет беспрепятственно получить доступ ко всему содержимому архива.

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

Чтобы размонтировать файловую систему, используйте команду umount с точкой монтирования:

# umount /mnt/mountpoint

Вход и выход

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

Вы также можете вручную запустить вход / выход из системы с помощью команд:

# proxmox-backup-client login
Password: **********

# proxmox-backup-client logout

Изменение владельца группы резервных копий

По умолчанию владельцем группы резервных копий является пользователь, который использовался для первоначального создания этой группы (или, в случае заданий синхронизации, root@pam). Это означает, что если пользователь mike@pbs создал резервную копию, другой пользователь john@pbs не может быть использован для создания резервных копий в той же группе. Если вы хотите изменить владельца резервной копии, вы можете сделать это с помощью приведенной ниже команды, используя пользователя с правами Datastore.Modify в хранилище данных.

# proxmox-backup-client change-owner vm/103 john@pbs

Это также можно сделать из веб-интерфейса, перейдя в раздел Content хранилища данных, содержащего группу резервного копирования, и выбрав значок пользователя в столбце Действия. Обычными случаями для этого может быть изменение владельца задания синхронизации с root@pam или изменение назначения группы резервного копирования.

Обрезка и удаление резервных копий

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

# proxmox-backup-client snapshot forget <snapshot>

Внимание! Эта команда удаляет все архивы в этом снимке резервной копии. Они будут недоступны и не подлежат восстановлению.

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

–keep-last <N> Сохранить последние <N> резервные снимки.

–keep-hourly <N> Сохранить резервные копии за последние <N> часов. Если за один час создается более одной резервной копии, сохраняется только последняя.

–keep-daily <N> Сохранить резервные копии за последние <N> дней. Если за один день создается более одной резервной копии, сохраняется только последняя.

–keep-weekly <N> Сохранить резервные копии за последние <N> недель. Если за одну неделю создается более одной резервной копии, сохраняется только последняя. Неделя начинается с понедельника.

–keep-monthly <N> Сохранить резервные копии за последние <N> месяцев. Если за один месяц создается более одной резервной копии, сохраняется только последняя.

–keep-yearly <N> Сохранить резервные копии за последние <N> лет. Если за один год создается более одной резервной копии, сохраняется только последняя.

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

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

# proxmox-backup-client prune <group> --keep-daily 7 --keep-weekly 4 --keep-monthly 3

Вы можете использовать параметр –dry-run, чтобы проверить свои настройки. Здесь отображается только список существующих снимков и действия, которые необходимо выполнить при сокращении.

# proxmox-backup-client prune host/elsa --dry-run --keep-daily 1 --keep-weekly 3

Примечание. Ни команда prune, ни команда forget не освобождают место в хранилище фрагментов. Хранилище фрагментов все еще содержит блоки данных. Чтобы освободить место, нужно выполнить сборку мусора.

Сборка мусора

Команда prune удаляет только индексные файлы резервных копий, но не данные из хранилища данных. Эта задача возложена на команду сборки мусора. Рекомендуется регулярно производить сборку мусора.

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

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

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

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

# proxmox-backup-client garbage-collect
starting garbage collection on store store2
Start GC phase1 (mark used chunks)
Start GC phase2 (sweep unused chunks)
percentage done: 1, chunk count: 219
percentage done: 2, chunk count: 453
...
percentage done: 99, chunk count: 21188
Removed bytes: 411368505
Removed chunks: 203
Original data bytes: 327160886391
Disk bytes: 52767414743 (16 %)
Disk chunks: 21221
Average chunk size: 2486565
TASK OK

Тестирование производительности

Клиент резервного копирования поставляется с инструментом для тестирования производительности. Этот инструмент измеряет различные показатели, относящиеся к скорости сжатия и шифрования. Вы можете запустить тест, используя подкоманду benchmark:

# proxmox-backup-client benchmark
Uploaded 656 chunks in 5 seconds.
Time per request: 7659 microseconds.
TLS speed: 547.60 MB/s
SHA256 speed: 585.76 MB/s
Compression speed: 1923.96 MB/s
Decompress speed: 7885.24 MB/s
AES256/GCM speed: 3974.03 MB/s

Примечание: проценты, указанные в выходной таблице, соответствуют сравнению с Ryzen 7 2700X. Тест TLS подключается к локальному хосту, поэтому сеть не задействована.

Вы также можете передать параметр –output-format для вывода статистики в json, а не в формате таблицы по умолчанию.

Вам необходимо определить новое хранилище с типом «pbs» на вашем узле Proxmox VE. В следующем примере в качестве имени хранилища используется store2, предполагается, что адрес сервера – localhost, и вы хотите подключиться как user1@pbs.

# pvesm add pbs store2 --server localhost --datastore store2
# pvesm set store2 --username user1@pbs --password <secret>

Примечание. Если вы не хотите передавать свой пароль в виде обычного текста, вы можете передать параметр –password без каких-либо аргументов. Это заставит программу запрашивать пароль при вводе команды.

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

# proxmox-backup-manager cert info | grep Fingerprint
Fingerprint (sha256): 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

Добавьте этот отпечаток в свою конфигурацию, чтобы установить доверительные отношения:

# pvesm set store2 --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

После этого вы сможете увидеть статус хранилища с помощью:

# pvesm status --storage store2

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

Инструмент командной строки pxar

pxar – это утилита командной строки для создания и управления архивами в формате файлового архива Proxmox (.pxar). Он вдохновлен форматом файлового архива casync, который обслуживает аналогичный вариант использования. Формат .pxar адаптирован для удовлетворения конкретных потребностей Proxmox Backup Server, например, для эффективного хранения жестких ссылок. Формат предназначен для уменьшения объема памяти, необходимого на сервере, за счет достижения высокого уровня дедупликации.

Создание архива

Выполните следующую команду, чтобы создать архив папки с именем source:

# pxar create archive.pxar /path/to/source

Это создаст новый архив с именем archive.pxar с содержимым исходной папки.

Примечание: pxar не перезапишет существующие архивы. Если в целевой папке уже есть архив с таким именем, создание не удастся.

По умолчанию pxar пропускает определенные точки монтирования и не соответствует границам устройства. Это проектное решение основано на основном варианте использования – создании архивов для резервных копий. Имеет смысл не резервировать содержимого определенных временных или системных файлов. Чтобы изменить это поведение и следовать границам устройства, используйте флаг –all-file-systems.

Можно исключить определенные файлы или папки из архива, передав параметр –exclude с шаблонами.

Например, вы можете исключить из архива все файлы с расширением .txt, запустив:

# pxar create archive.pxar /path/to/source --exclude '**/*.txt'

Имейте в виду, что оболочка сама попытается развернуть все шаблоны перед вызовом pxar. Чтобы этого избежать, все шаблоны должны быть указаны правильно.

Можно передавать параметр –exclude несколько раз, чтобы соответствовать более чем одному шаблону. Это позволяет использовать более сложное поведение. Однако в таких случаях рекомендуется использовать файлы .pxarexclude.

Например, вы можете исключить из архива все файлы .txt, кроме одного. Это достигается с помощью шаблона отрицательного совпадения с префиксом “!”. Все шаблоны относятся к исходному каталогу.

# pxar create archive.pxar /path/to/source --exclude '**/*.txt' --exclude '!/folder/file.txt'

Примечание: порядок шаблонов имеет значение, поскольку более поздние имеют приоритет над предыдущими.

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

Более удобный и надежный способ исключить файлы из архива – это поместить шаблоны в файлы .pxarexclude. Эти файлы можно создавать и размещать в любом каталоге дерева файловой системы. Эти файлы должны содержать по одному шаблону в строке, и снова более поздние шаблоны имеют преимущество перед предыдущими. Шаблоны управляют исключением файлов, находящихся в данном каталоге или ниже в дереве. Поведение такое же, как описано в разделе «Создание резервных копий».

Извлечение архива

Существующий архив archive.pxar извлекается в целевой каталог с помощью следующей команды:

# pxar extract archive.pxar /path/to/target

Если цель не указана, содержимое архива извлекается в текущий каталог.

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

# pxar extract etc.pxar /restore/target/etc --pattern '**/*.conf'

В приведенном выше примере восстанавливаются все файлы .conf, обнаруженные в любой из подпапок в архиве в  /etc, в /restore/target/etc. Путь к файлу, содержащему шаблоны совпадений, можно указать с помощью параметра –files-from.

Чтобы отобразить файлы и каталоги, содержащиеся в архиве archive.pxar, выполните следующую команду:

# pxar list archive.pxar

Здесь отображается полный путь к каждому файлу или каталогу относительно корня архива.

Монтирование архива

pxar позволяет монтировать и проверять содержимое архива через FUSE. Чтобы смонтировать архив с именем archive.pxar в точку монтирования /mnt, выполните команду:

# pxar mount archive.pxar /mnt
# cd /mnt
# ls
bin  dev  home lib32 libx32 media opt  root sbin sys usr boot etc lib lib64 lost+found mnt proc run srv tmp var

Администрирование сервера

Proxmox Backup основан на дистрибутиве Debian. Это означает, что у вас есть доступ ко всем пакетам Debian, а базовая система хорошо документирована. Справочник администратора Debian доступен в Интернете и содержит всестороннее введение в эту операционную систему.

Стандартная установка Proxmox Backup использует репозитории Debian по умолчанию, поэтому вы получаете исправления ошибок и обновления безопасности через этот канал. Кроме того, мы предоставляем собственный репозиторий пакетов для развертывания всех пакетов, связанных с Proxmox. При необходимости сюда входят обновления некоторых пакетов Debian.

Мы также поставляем специально оптимизированное ядро ​​Linux, в котором мы включаем все необходимые функции виртуализации и контейнеров. Это ядро ​​включает драйверы для ZFS и несколько драйверов оборудования. Например, мы поставляем драйверы сетевых карт Intel для поддержки новейшего оборудования.

ZFS

ZFS – это комбинированный менеджер файловой системы и логических томов, разработанный Sun Microsystems. Нет необходимости вручную компилировать модули ZFS – все пакеты включены.

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

Общие преимущества ZFS:

• Простая настройка и управление с помощью графического интерфейса и командной строки
• Надежность
• Защита от повреждения данных
• Сжатие данных на уровне файловой системы
• Снимки
• Копирование при записи (клоны)
• Различные уровни рейдов: RAID0, RAID1, RAID10, RAIDZ1, RAIDZ2 и RAIDZ3.
• Можно использовать SSD для кеширования
• Самовосстановление
• Непрерывная проверка целостности
• Разработан для хранения большой емкости
• Асинхронная репликация по сети
• Открытый исходный код
• Шифрование

Железо

ZFS сильно зависит от памяти, поэтому для запуска вам потребуется не менее 8 ГБ. На практике используйте столько, сколько можете получить в соответствии с вашим оборудованием / бюджетом. Чтобы предотвратить повреждение данных, мы рекомендуем использовать ОЗУ с ECC высокого качества.

Если вы используете выделенный кэш и / или диск для журнала, вам следует использовать SSD корпоративного класса (например, Intel SSD DC S3700 Series). Это может значительно повысить общую производительность.

Важно! Не используйте ZFS поверх аппаратного контроллера, который имеет собственное управление кешем. ZFS необходимо напрямую взаимодействовать с дисками. Адаптер HBA – это то, что нужно, или что-то вроде контроллера LSI, прошитого в IT Mode.

Администрирование

В этом разделе приведены некоторые примеры использования для общих задач. Сама по себе ZFS действительно мощная и предоставляет множество возможностей. Основные команды для управления ZFS – это zfs и zpool. Обе команды имеют отличные справочные страницы, которые можно прочитать с помощью:

# man zpool
# man zfs

Для создания нового пула необходим как минимум один диск. ashift зависит от размера сектора на диске (2 в степени ashift = размер сектора) или больше. 2¹² = 4096.

# zpool create -f -o ashift=12 <pool> <device>

В следующем листинге показаны примеры создания пулов:

• RAID-0 (минимум 1 диск)

# zpool create -f -o ashift=12 <pool> <device1> <device2>

• RAID-1 (минимум 2 диска)

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2>

• RAID-10 (минимум 4 диска)

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> mirror <device3> <device4>

• RAIDZ-1 (минимум 3 диска)

# zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>

• RAIDZ-2 (минимум 4 диска)

# zpool create -f -o ashift=12 <pool> raidz2 <device1> <device2> <device3> <device4>

Создание пула с кешем (L2ARC)

Для увеличения производительности можно использовать выделенный раздел кеш-диска (используйте SSD). В качестве <устройства> можно использовать части команд из создания пула.

# zpool create -f -o ashift=12 <pool> <device> cache <cache_device>

Создание пула с логом (ZIL)

Для увеличения производительности можно использовать выделенный раздел кеш-диска (SSD).

# zpool create -f -o ashift=12 <pool> <device> log <log_device>

Добавление кеша и журнала в существующий пул

Если у вас пул без кеша и журнала. Сначала разделите SSD на 2 раздела с помощью parted или gdisk (используйте только GPT таблицу разделов). Максимальный размер устройства журнала должен составлять примерно половину размера физической памяти, поэтому обычно он довольно мал. Остальной SSD можно использовать как кеш.

# zpool add -f <pool> log <device-part1> cache <device-part2>

Замена вышедшего из строя устройства

# zpool replace -f <pool> <old device> <new device>

Замена отказавшего загрузочного устройства

В зависимости от того, как был установлен Proxmox Backup, в качестве загрузчика используется либо grub, либо systemd-boot.

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

# sgdisk <исправный загрузочный диск> -R <новый диск>
# sgdisk -G <новый диск>
# zpool replace -f <pool> <старый zfs раздел> <новый zfs раздел>

Примечание. Используйте команду zpool status -v, чтобы отслеживать, насколько продвинулся процесс resilvering нового диска.

С помощью systemd-boot:

# pve-efiboot-tool format <new disk's ESP>
# pve-efiboot-tool init <new disk's ESP>

Примечание. ESP означает системный раздел EFI, который устанавливается как раздел №2 на загрузочных дисках, устанавливаемый установщиком pve, начиная с версии 5.4.

С grub:

Обычно grub.cfg находится в /boot/grub/grub.cfg

# grub-install <new disk>
# grub-mkconfig -o /path/to/grub.cfg

Активация e-mail уведомлений

ZFS поставляется с демоном событий, который отслеживает события, генерируемые модулем ядра ZFS. Демон также может отправлять электронные письма о событиях ZFS, например об ошибках пула. Новые пакеты ZFS поставляют демон в отдельном пакете, и вы можете установить его с помощью apt-get:

# apt-get install zfs-zed

Для активации демона необходимо отредактировать /etc/zfs/zed.d/zed.rc вашим любимым редактором и раскомментировать параметр ZED_EMAIL_ADDR:

ZED_EMAIL_ADDR=”root”

Обратите внимание, что Proxmox Backup пересылает почту root на адрес электронной почты, настроенный для пользователя root. Единственная необходимая настройка – ZED_EMAIL_ADDR. Все остальные настройки не обязательны.

Лимит использование памяти ZFS

Для ZFS ARC рекомендуется использовать не более 50 % (по умолчанию) системной памяти, чтобы предотвратить снижение производительности хоста. Используйте предпочтительный редактор, чтобы изменить конфигурацию в /etc/modprobe.d/zfs.conf и вставить:

options zfs zfs_arc_max=8589934592

В этом примере 8GB.

Важно: если ваша корневая файловая система – ZFS, вы должны обновлять initramfs каждый раз, после этих изменений:

# update-initramfs -u

SWAP на ZFS

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

Мы настоятельно рекомендуем использовать достаточно памяти, чтобы обычно не возникали ситуации нехватки памяти. Если вам нужно или вы хотите добавить подкачку, рекомендуется создать раздел на физическом диске и использовать его как устройство подкачки. Вы можете оставить для этой цели свободное место в расширенных параметрах установщика. Кроме того, вы можете снизить значение подкачки. Хорошее значение для серверов – 10:

# sysctl -w vm.swappiness=10

Чтобы сделать подкачку постоянной, откройте /etc/sysctl.conf в любом редакторе и добавьте следующую строку:

vm.swappiness = 10

Сжатие ZFS

Чтобы активировать сжатие:

# zpool set compression=lz4 <pool>

Мы рекомендуем использовать алгоритм lz4, поскольку он очень мало увеличивает нагрузку на процессор. Также доступны другие алгоритмы, такие как lzjb и gzip-N (где N – целое число от 1 до 9, представляющее степень сжатия, 1 – самое быстрое, а 9 – лучшее сжатие). В зависимости от алгоритма и степени сжатия данных включение сжатия может даже повысить производительность ввода-вывода.

Вы можете отключить сжатие в любое время с помощью:

# zfs set compression=off <dataset>

Это изменение затронет только новые блоки.

Специальное устройство ZFS

Начиная с версии 0.8.0 ZFS поддерживает специальные устройства. Специальное устройство в пуле используется для хранения метаданных, таблиц дедупликации и, возможно, небольших файловых блоков.

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

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

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

Создание пула со специальным устройством и RAID-1:

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> special mirror <device3> <device4>

Добавление специального устройства в существующий пул с RAID-1:

# zpool add <pool> special mirror <device1> <device2>

Датасеты ZFS предоставляют свойство special_small_blocks = <size>. size может быть 0, чтобы отключить хранение небольших файловых блоков на специальном устройстве, или степенью двойки в диапазоне от 512 И до 128K. После установки свойства новые блоки файлов меньше размера будут размещены на специальном устройстве.

Важно! если значение special_small_blocks больше или равно размеру записи (по умолчанию 128 КБ) набора данных, все данные будут записаны на специальное устройство, поэтому будьте осторожны!

Установка свойства special_small_blocks в пуле изменит значение этого свойства по умолчанию для всех дочерних наборов данных ZFS (например, все контейнеры в пуле будут выбирать небольшие блоки файлов).

Например включим все файлы размером меньше 4K-блоков для всего пула:

# zfs set special_small_blocks=4K <pool>

Или для одного датасета:

# zfs set special_small_blocks=4K <pool>/<filesystem>

Отказаться от небольших файловых блоков можно так:

# zfs set special_small_blocks=0 <pool>/<filesystem>

Поиск проблемы

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

Для каждого пула запустите:

# zpool set cachefile=/etc/zfs/zpool.cache POOLNAME

а затем обновите initramfs, запустив:

# update-initramfs -u -k all

и, наконец, перезагрузите ваш сервер.

Иногда файл кэша ZFS может быть поврежден, и служба zfs-import-cache.service не импортирует пулы, которых нет в файле кеша.

Еще один способ решения этой проблемы – включить службу zfs-import-scan.service, которая выполняет поиск и импорт пулов с помощью сканирования устройства (обычно медленнее).

Технический обзор

Datastores

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

<datastore-root>/<type>/<id>/<time>/

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

Chunks (фрагменты данных)

Это некоторые (возможно, зашифрованные) данные с контрольной суммой CRC-32 в конце и маркером типа в начале. Он идентифицируется контрольной суммой SHA-256 его содержимого.

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

Фрагменты хранилища данных находятся в

<datastore-root>/.chunks/

Этот каталог фрагментов дополнительно подразделяется на первые четыре байта контрольной суммы фрагментов, поэтому фрагмент с контрольной суммой

a342e8151cbf439ce65f3df696b54c67a114982cc0aa751f2852c2f7acc19a8b

живет в

<datastore-root>/.chunks/a342/

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

Эти каталоги фрагментов («0000» – «ffff») будут предварительно выделены при создании хранилища данных.

Фрагменты с фиксированным размером

Для блочного резервного копирования (например, виртуальных машин) используются фрагменты фиксированного размера. Контент (образ диска) разбивается на фрагменты одинаковой длины (обычно 4 МБ).

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

В качестве оптимизации виртуальные машины в Proxmox VE могут использовать «грязные растровые изображения» (dirty bitmaps), которые могут отслеживать измененные блоки. Поскольку эти изображения также являются изображениями, разделенными на фрагменты, существует прямая связь между грязными блоками изображения и фрагментами, которые необходимо загрузить, поэтому для резервного копирования необходимо загружать только измененные фрагменты диска.

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

Для согласованности Proxmox VE использует внутренний механизм моментальных снимков QEMU, который также не полагается на моментальные снимки хранилища.

Фрагменты с динамическим размером

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

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

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

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

Зашифрованные фрагменты

Зашифрованные фрагменты – это особый случай. Куски фиксированного и динамического размера могут быть зашифрованы, и они обрабатываются немного иначе, чем обычные фрагменты.

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

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

Предостережения и ограничения

Примечания к хеш-коллизиям

У каждого алгоритма хеширования есть шанс вызвать коллизии, то есть два (или более) входа генерируют одинаковую контрольную сумму. Для SHA-256 этот шанс ничтожен. 

Для примера, в лотерее с угадыванием 6 из 45 шансов нужно угадать все 6 чисел, а вероятность столкновения примерно такая же, как при выигрыше 13 таких лотерей подряд. Крайне маловероятно, что такое столкновение произойдет случайно в обычном хранилище данных.

Кроме того, SHA-256 подвержен атакам на расширение длины, но, поскольку существует верхний предел размера блока, это не проблема.

Файловое резервное копирование

Поскольку блоки динамического размера (для файловых резервных копий) создаются в пользовательском формате архива (pxar), между файлами и блоками нет никакой связи. Это означает, что клиент Proxmox Backup должен заново читать все файлы для каждой резервной копии. Обратите внимание, что будут загружаться только новые или измененные фрагменты.

Проверка зашифрованных блоков

Для зашифрованных фрагментов доступна только контрольная сумма исходных (незашифрованных) данных, что делает невозможным для сервера (без ключа шифрования) проверить свое содержимое по нему. Вместо этого проверяется только контрольная сумма CRC-32.

Вопросы и ответы

На каком дистрибутиве основан Proxmox Backup Server (PBS)?

Сервер резервного копирования Proxmox основан на Debian GNU / Linux.

Какие платформы поддерживаются в качестве резервного источника (клиенты)?

Клиент работает в большинстве современных систем Linux, что означает, что вы не ограничены одним Debian.

Будет ли Proxmox Backup Server работать на 32-битном процессоре?

Сервер резервного копирования поддерживает только 64-битные процессоры (AMD или Intel). В будущем нет планов по поддержке 32-битных процессоров.

Как долго будет поддерживаться моя версия Proxmox Backup Server?

Proxmox Backup 1.x /  Debian 10 (Buster) / срок поддержки будет объявлен позже.

Могу ли я скопировать или синхронизировать свое хранилище данных с другим местом?

Proxmox Backup Server позволяет копировать или синхронизировать хранилища данных в другие места с помощью удалённых серверов pbs и заданий синхронизации. Remote – это термин, присвоенный отдельному серверу, на котором есть хранилище данных, которое может быть синхронизировано с локальным хранилищем. Задание синхронизации – это процесс, который используется для извлечения содержимого хранилища данных с удаленного устройства в локальное хранилище.

Может ли Proxmox Backup Server проверить целостность данных резервной копии?

Proxmox Backup Server использует встроенный алгоритм контрольной суммы SHA256 для обеспечения целостности данных. В каждой резервной копии создается файл манифеста (index.json), который содержит список всех файлов резервных копий, а также их размеры и контрольные суммы. Этот файл манифеста используется для проверки целостности каждой резервной копии.

Должен ли я доверять удаленному серверу при резервном копировании на удаленные серверы?

Proxmox BS передает данные через TLS и дополнительно поддерживает шифрование на стороне клиента. Это означает, что данные передаются надежно и могут быть зашифрованы до того, как достигнут сервера. Таким образом, в случае, если злоумышленник получит доступ к серверу или любой точке сети, он не сможет прочитать данные.

Примечание. По умолчанию шифрование отключено.

Резервная копия инкрементная / дедуплицированная?

С Proxmox BS резервные копии отправляются инкрементно, а данные дедуплицируются на сервере. Это сводит к минимуму как потребляемую память, так и влияние на сеть.

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

Введение

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

Прежде всего пробежимся по основным особенностям для этого сервера:

• оптимизирован для ProxmoxVE;
• позволяет синхронизировать резервные копии с другими серверами Proxmox BS;
• простое управление с помощью веб-интерфейса;
• поддерживает дедупликацию, сжатие и шифрование.

В качестве языка программирования использовался RUST. Это гарантирует высокую производительность, низкое потребление ресурсов и качественную кодовую базу.

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

Архитектура и основные функции

Proxmox BS использует клиент-серверную модель. Сервер не только хранит резервные копии, а также обеспечивает безопасность хранения, предоставляет API для создания хранилищ и управления ими. Дополнительно можно управлять дисками, сетью и другими серверными ресурсами.

Клиент резервного копирования использует API для доступа к резервным копиям. С помощью инструмента командной строки proxmox-backup-client вы можете создавать резервные копии и восстанавливать данные. Более того, в Proxmox VE клиент уже встроен.

Одна резервная копия может содержать несколько архивов. Например, при резервном копировании виртуальной машины (VM) каждый диск сохраняется как отдельный архив внутри резервной копии. А конфигурация VM хранится в виде дополнительного файла. В результате можно восстановить только важные части резервной копии без необходимости сканировать её всю.

Proxmox BS состоит из нескольких компонентов:

• Служба сервера, предоставляющая, помимо прочего, RESTful API, сверхбыстрые асинхронные задачи, облегченный сбор статистики, планирование событий, строгое разделение привилегированных и непривилегированных сред выполнения.
• Веб-интерфейс управления написанный на JavaScript.
• Инструмент командной строки для управления сервером (proxmox-backup-manager).
• Инструмент командной строки для создания резервных копий (proxmox-backup-client) доступный для любого 64-разрядного Linux.

Все, кроме веб-интерфейса, написано на языке Rust.

Основные функции:

• Поддержка Proxmox VE — вы можете легко создавать резервные копии виртуальных машин и контейнеров.
• Производительность — программный стек написан на Rust, что обеспечивает высокую скорость и эффективную работы с памятью.
• Дедупликация — позволяет избежать избыточности и уменьшить используемое пространство для хранения.
• Инкрементные резервные копии — изменения между резервными копиями обычно невелики, чтение и отправка только дельты уменьшает влияние на хранилище и сеть.
• Целостность данных — встроенный алгоритм контрольной суммы SHA256 обеспечивает согласованность резервных копий.
• Удаленная синхронизация — можно синхронизировать данные с удаленными серверами PBS, при этом данные передаются инкрементально.
• Сжатие — сверхбыстрое сжатие Zstandard способно сжимать несколько гигабайт данных в секунду.
• Шифрование — резервные копии могут быть зашифрованы на стороне клиента с использованием AES-256 в режиме Galois / Counter Mode (GCM). Кроме того все данные передаются через безопасное соединение TLS.
• Веб-интерфейс — управляйте сервером с помощью встроенного веб-интерфейса.
• Открытый исходный код — это бесплатное программное обеспечение с открытым исходным кодом под лицензией AGPL, v3.
• Поддержка Enterprise — подписка на Proxmox Backup — это дополнительная сервисная программа, предназначенная для того, чтобы помочь поддерживать свои сервера в актуальном состоянии и получать помощь от технических экспертов.

Причины резервного копирования данных

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

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

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

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

Получение помощи и Лицензирование

• Форум поддержки сообщества. Мы всегда поощряем наших пользователей обсуждать и делиться своими знаниями на форуме. Форум модерирует служба поддержки Proxmox. Большая база пользователей разбросана по всему миру. Это отличное место для получения информации.
• Списки рассылки. Proxmox BS является полностью открытым исходным кодом, и мы приветствуем участие! Это основной канал связи для разработчиков.
• Отслеживание ошибок. Proxmox запускает общедоступный трекер ошибок на Bugzilla. Если возникнет проблема, отправьте туда свой отчет. Проблема может быть как ошибкой, так и запросом новой функции.

Авторские права принадлежат: Proxmox Server Solutions GmbH. Proxmox BS — это бесплатное программное обеспечение с открытым исходным кодом: вы можете использовать его, распространять или изменять в соответствии с условиями лицензии GNU, опубликованной Free Software Foundation.

Вы должны были получить копию лицензии вместе с этой программой. Если нет, см. AGPL3.

История

Резервное копирование было и всегда будет центральным аспектом IT-администрирования. Более того, с использованием виртуализации важность резервных копий увеличивается. Поэтому мы с самого начала поставляем инструмент резервного копирования с Proxmox VE. Этот инструмент называется vzdump и может делать резервные копии контейнеров LXC и виртуальных машин KVM.

Однако vzdump позволяет делать только полные резервные копии. Это становится проблемой для пользователей с большими виртуальными машинами. Чтобы решить эту проблему, мы предложили дедупликацию и инкрементное резервное копирование.

Еще в октябре 2018 года началась разработка, а уже в июле 2020 года мы выпустили первую бета-версию Proxmox BS, а в ноябре 2020 года — первую стабильную версию.

Установка

Системные требования

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

Минимальные системные требования:

• ЦП: 64-разрядный, 2 ядра
• Память: 2 ГБ
• Жесткий диск: более 8 ГБ свободного места
• Сетевая карта

Рекомендованные системные требования:

• ЦП: современный 64-разрядный, 4+ ядра
• Память: минимум 4 ГБ для ОС. Добавьте 1 ГБ на 1 ТБ хранилища.
• Хранилище ОС:
  • 32 ГБ или более свободного места;
  • аппаратный RAID с защищенным от батареи кешем записи (BBU) или ZFS с резервированием.
• Хранилище резервных копий:
  • для достижения наилучших результатов используйте только SSD;
  • если используются жесткие диски то настоятельно рекомендуется использовать кеш метаданных.
• Сетевые карты с высокой пропускной способностью.

Для доступа к веб-интерфейсу подойдет любой современный браузер.

Debian репозитории

Все системы на основе Debian используют APT в качестве пакетного менеджера. Списки репозиториев определены в /etc/apt/sources.list, а дополнительные файлы .list находятся в каталоге /etc/apt/sources.d/. Обновления можно установить с помощью командной строки apt или через web-интерфейс.

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

Например файл /etc/apt/sources.list:

deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib
# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Кроме того, вам понадобится репозиторий от Proxmox для получения обновлений ProxmoxBS.

Безопасность APT

Файлы в репозиториях подписаны. APT использует эти подписи для проверки того, что все пакеты получены из надежного источника. Если вы устанавливаете Proxmox BS из официального ISO-образа, ключ проверки уже установлен. Если вы устанавливаете Proxmox BS поверх Debian, загрузите и установите ключ с помощью следующей команды:

# wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

Затем проверьте контрольные суммы с помощью:

# sha512sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
acca6f416917e8e11490a08a1e2842d500b3a5d9f322c6319db0927b2901c3eae23cfb5cd5df6facf2b57399d3cfa52ad7769ebdd75d9 /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

# md5sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
f3f6c5a3a67baf38ad178e5ff1ee270c /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

PBS репозиторий с подпиской

Это стандартный, стабильный и рекомендуемый репозиторий. Он доступен для всех пользователей подписки Proxmox Backup. Он содержит самые стабильные пакеты и подходит для производственного использования. Репозиторий pbs-enterprise по умолчанию включен.

Файл: /etc/apt/sources.list.d/pbs-enterprise.list:

deb https://enterprise.proxmox.com/debian/pbs buster pbs-enterprise

Чтобы никогда не пропустить важные исправления безопасности, суперпользователь (root@pam) получает уведомление по электронной почте о новых пакетах, как только они становятся доступны. Журнал изменений и подробную информацию о каждом пакете можно просмотреть в графическом интерфейсе (при наличии).

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

Вы можете отключить этот репозиторий, закомментировав приведенную выше строку, если у вас нет ключа подписки. В этом случае настройте репозиторий pbs-no-subscription.

PBS репозиторий без подписки

Как следует из названия, вам не нужен ключ подписки для доступа к этому репозиторию. Его можно использовать для тестирования и непроизводственного использования. Не рекомендуется использовать его на производственных серверах, потому что эти пакеты не всегда тщательно тестируются и проверяются.

Мы рекомендуем настроить этот репозиторий в /etc/apt/sources.list:

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

PBS тестовый репозиторий

Этот репозиторий содержит последние пакеты и активно используется разработчиками для тестирования новых функций, поэтому он не рекомендуется для использования в рабочей среде. Вы можете получить доступ к этому репозиторию, добавив следующую строку в /etc/apt/sources.list:

deb http://download.proxmox.com/debian/pbs buster pbstest

Установка используя установщик

Образ диска (файл ISO), предоставленный Proxmox, включает полную систему Debian («buster» для версии 1.x), а также все необходимые пакеты для сервера Proxmox Backup.

Установщик проведет вас через процесс установки и позволит вам:

• разбить локальный диск или диски;
• применить базовые конфигурации системы: часовой пояс, язык, сеть;
• установить все необходимые пакеты.

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

Загрузите ISO с https://www.proxmox.com/downloads. Он включает программу установки, которая разбивает локальные диски с помощью ext4, xfs или ZFS и устанавливает операционную систему с полным набором инструментов для резервного копирования и ядром с поддержкой ZFS. В процессе установки по умолчанию все существующие данные удаляются.

Установка на Debian

В качестве альтернативы Proxmox BS можно установить поверх существующей системы Debian. После настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-server

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

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

# apt-get update
# apt-get install proxmox-backup

Это установит все необходимые пакеты и ядро Proxmox с поддержкой ZFS.

Осторожно! Установка Proxmox BS поверх существующей установки Debian выглядит просто, но предполагает, что базовая система и локальное хранилище были настроены правильно. В общем, это нетривиально, особенно при использовании LVM или ZFS. Конфигурация сети также полностью зависит от ваших предыдущих настроек.

Вы можете получить доступ к веб-интерфейсу Proxmox BS с помощью веб-браузера, используя HTTPS на порту 8007 (https: // <ip>:8007).

Установка на Proxmox VE

После настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-server

Внимание! Не рекомендуется устанавливать сервер резервного копирования непосредственно на гипервизор. Для хранения резервных копий безопаснее использовать отдельный физический сервер. Если сервер гипервизора выйдет из строя, вы все равно сможете получить доступ к резервным копиям.

Установка клиента

Для установки клиента на Debian, после настройки репозиториев необходимо запустить:

# apt-get update
# apt-get install proxmox-backup-client

Терминология

Содержимое резервной копии

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

Разделение на фрагменты фиксированного размера требует минимальной мощности процессора и используется для резервного копирования образов виртуальных машин.

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

Сервер резервного копирования Proxmox поддерживает обе стратегии.

Архивы образов: <имя> .img

Это используется для образов виртуальных машин и других больших двоичных данных. Контент разбивается на фрагменты фиксированного размера (chunks).

Файловые архивы: <имя> .pxar

В файловом архиве хранится полное дерево каталогов. Контент хранится с использованием формата архива файлов Proxmox (.pxar), разбитого на блоки переменного размера. Формат оптимизирован для достижения хороших показателей дедупликации.

Бинарные данные (BLOB)

Этот тип используется для хранения двоичных данных меньшего размера (<16 МБ), например файлов конфигурации. Файлы большего размера следует хранить как архив образа.

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

Каталог файлов: catalog.pcat1

Файл каталога — это индекс для файловых архивов. Он содержит список файлов и используется для ускорения операций поиска.

Манифест: index.json

Манифест содержит список всех файлов резервных копий, их размеры и контрольные суммы. Он используется для проверки целостности резервной копии.

Тип резервной копии

Сервер резервного копирования группирует резервные копии по типу, где тип может быть одним из:

• vm — используется для виртуальных машин, обычно состоит из файла конфигурации виртуальной машины и архива образов для каждого диска;
• ct — используется для контейнеров, состоит из конфигурации контейнера и одного файлового архива для содержимого файловой системы;
• host — используется для резервных копий данных с физического сервера, обычно это может быть физический хост, но также может быть виртуальная машина или контейнер. Такие резервные копии могут содержать файловые архивы и архивы образов, ограничений на это нет.

ID резервной копии

Уникальный идентификатор. Обычно это идентификатор виртуальной машины или контейнера. Резервные копии типа хоста обычно используют имя хоста.

Время создания резервной копии

Время, когда была сделана резервная копия.

Группа резервной копии

Кортеж <type> / <ID> называется группой резервной копии. Такая группа может содержать один или несколько снимков резервных копий.

Снимок резервной копии

Тройка <тип> / <ID> / <время> называется снимком резервной копии. Он однозначно определяет конкретную резервную копию в хранилище данных.

Примеры снимков резервной копии:

vm / 104 / 2019-10-09T08: 01: 06Z
host / elsa / 2019-11-08T09: 48: 14Z

Как видите, формат времени — RFC 3399 с универсальным временем (UTC, обозначается буквой Z в конце).

Графический пользовательский интерфейс

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

Доступ к веб-интерфейсу можно получить по https: // <ip>: 8007. Логин по умолчанию — root, а пароль — который вы указали при установки.

Функции:

• простой интерфейс управления сервером;
• мониторинг задач, журналов и использования ресурсов;
• управление пользователями, разрешениями, хранилищами данных и т. д;
• безопасная консоль HTML5;
• поддержка нескольких источников аутентификации;
• поддержка нескольких языков;
• на основе JavaScript-фреймворка ExtJS 6.x.

Логин:

Когда подключаетесь к веб-интерфейсу, сначала увидите окно входа в систему. Proxmox BS поддерживает различные языки и серверы аутентификации (Realms).

Для удобства вы можете сохранить имя пользователя на стороне клиента, установив флажок «Save User name:» в нижней части окна.

Обзор

Веб-интерфейс состоит из 3 основных разделов:

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

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

На панели мониторинга (dashboard) отображается сводка активности и использования ресурсов на сервере. В частности, здесь отображается использование оборудования, сводка предыдущих и текущих задач, а также информация о подписке.

Configuration содержит некоторые параметры конфигурации системы, такие как время и конфигурация сети. Он также содержит следующие подразделы:

• Access Control: добавление и управление пользователями, токенами API и разрешениями, связанными с этими элементами.
• Remotes: добавление, редактирование и удаление других серверов для синхронизации.
• Subscription: загрузите ключ подписки, просмотрите статус подписки и получите доступ к текстовому системному отчету.

Administration содержит панель с задачами администрирования и информацией:

• Server Status: обеспечивает доступ к консоли, параметрам питания и различной статистике использования ресурсов.
• Services: управление и мониторинг службами.
• Updates: интерфейс для обновления пакетов.
• Syslog: просмотр сообщений журнала с сервера.
• Tasks: история задач с несколькими вариантами фильтрации.

Пункт меню Administration также содержит подраздел управления дисками:

• Storage / Disks: просмотр информации о доступных дисках:
  • Disks — просмотр и управление дисками;
  • Directory — создание и просмотр информации на дисках ext4 и xfs;
  • ZFS — создание и просмотр информации на дисках ZFS.

Раздел Datastore содержит интерфейсы для создания и управления хранилищами данных. Он содержит кнопку для создания нового хранилища данных на сервере, а также подраздел для каждого хранилища данных в системе, в котором вы можете использовать верхнюю панель для просмотра:

• Summary: доступ к статистике использования хранилища данных;
• Content: информация о группах резервных копий и их соответствующем содержимом;
• Prune & GC: планирование операций очистки и сборки мусора, а также запуск сборки мусора вручную;
• Sync Jobs: создание, управление и запуск заданий синхронизации с удаленными серверами;
• Verify Jobs: создание, управление и выполнение заданий проверки в хранилище данных;
• Options: управление оповещениями, и проверять ли новые снимки;
• Permissions: управление правами доступа к данному хранилищу.

Хранилище

Управление дисками

Proxmox BS поставляется с набором дисковых утилит, доступ к которым осуществляется с помощью подкоманды disk. Эта подкоманда позволяет вам инициализировать диски, создавать различные файловые системы и получать информацию о дисках.

Чтобы просмотреть диски, подключенные к системе, перейдите в Administration -> Disks в веб-интерфейсе или используйте команду:

# proxmox-backup-manager disk list

Чтобы инициализировать диск с новым GPT, используйте подкоманду initialize:

# proxmox-backup-manager disk initialize sdX

Вы можете создать файловую систему ext4 или xfs, используя команду fs create, или перейдя в Administration -> Disks -> Directory в веб-интерфейсе и создав ее оттуда. Следующая команда создает файловую систему ext4 и передает параметр —add-datastore, чтобы автоматически создать хранилище данных на диске. Это создаст хранилище данных в местоположении /mnt/datastore/store1:

# proxmox-backup-manager disk fs create store1 --disk sdd --filesystem ext4 --add-datastore

Вы также можете создать zpool с различными уровнями рейда, выбрав Administration -> Disks -> Zpool в веб-интерфейсе или с помощью zpool create. Приведенная ниже команда создает зеркальный zpool с использованием двух дисков (sdb и sdc) и монтирует его в /mnt/datastore/zpool1:

# proxmox-backup-manager disk zpool create zpool1 --devices sdb,sdc --raidlevel mirror

Вы также можете передать здесь параметр —add-datastore, чтобы автоматически создать хранилище данных с диска.

Вы можете использовать disk fs list и disk zpool list для отслеживания файловых систем и zpool соответственно.

Proxmox BS использует пакет smartmontools. Это набор инструментов, используемых для мониторинга и управления S.M.A.R.T. для локальных жестких дисков. Если диск поддерживает S.M.A.R.T. и у вас она включена, вы можете отображать S.M.A.R.T. атрибуты из веб-интерфейса или с помощью команды:

# proxmox-backup-manager disk smart-attributes sdX

Доступ к этой функции также можно получить напрямую с помощью команды smartctl, которая входит в состав пакета smartmontools.

Хранилище данных

Хранилище данных — это место, в котором хранятся резервные копии. Текущая реализация использует каталог внутри стандартной файловой системы Unix (ext4, xfs или zfs) для хранения данных резервного копирования.

Хранилища данных идентифицируются простым именем. Вы можете настроить его при создании хранилища данных. Информация о конфигурации хранилищ данных хранится в файле /etc/proxmox-backup/datastore.cfg.

Требуется чтобы файловая система поддерживала не менее 65538 подкаталогов на каталог. Эта цифра получается из 2¹⁶ предварительно созданных каталогов (chunk) пространств имен блоков. Это требование исключает поддержку определенных файловых систем. Например, ext3 в целом или ext4 с отключенной функцией dir_nlink.

Вы можете настроить несколько хранилищ данных (datastore). Но необходимо настроить минимум одно хранилище. Datastore идентифицируется простым именем и указывает на каталог в файловой системе. С каждым datastore также связаны настройки хранения, указывающие, сколько снимков резервных копий для каждого интервала времени хранить в этом хранилище. Сокращение и удаление резервных копий и сборку мусора также можно настроить для периодического запуска в соответствии с настроенным расписанием для каждого хранилища данных.

Вы можете создать новое хранилище данных из веб-интерфейса, щелкнув Add Datastore в боковом меню в разделе Datastore. В окне настройки:

• Name — имя хранилища.
• Backing Path — путь к каталогу, в котором вы хотите создать хранилище.
• GC Schedule — время и интервалы, с которыми выполняется сборка мусора.
• Prune Schedule — относится к частоте, с которой происходит обрезка.
• Prune Options — количество резервных копий, которое вы хотите сохранить.
• Comment — можно использовать для добавления некоторой информации о хранилище.

В качестве альтернативы вы можете создать новое хранилище данных из командной строки. Следующая команда создает новое хранилище данных с именем store1 на /backup/disk1/store1:

# proxmox-backup-manager datastore create store1 /backup/disk1/store1

Чтобы вывести список существующих хранилищ выполните:

# proxmox-backup-manager datastore list

Вы можете изменить параметры сборки мусора и сокращения хранилища данных, отредактировав хранилище данных из графического интерфейса пользователя или используя подкоманду update. Например, приведенные ниже команды изменят расписание сборки мусора и выведут его свойства:

# proxmox-backup-manager datastore update store1 --gc-schedule 'Tue 04:27'
# proxmox-backup-manager datastore show store1

А также, можно удалить конфигурацию хранилища данных:

# proxmox-backup-manager datastore remove store1

Приведенная выше команда удаляет только конфигурацию хранилища, не удаляя данные из основного каталога.

После создания хранилища в каталоге появится:

• файл .lock — пустой файл, используемый для блокировки процесса;
• каталог .chunks — содержащий подкаталоги, в которых будут храниться фрагментированные данные после выполнения операции резервного копирования.

Управление сетью

Proxmox BS предоставляет как веб-интерфейс, так и инструмент командной строки для настройки сети. В веб-интерфейсе существует раздел Network Interfaces в меню Configuration, в добавок к этому существует подкоманда network. Эти интерфейсы позволяют выполнять некоторые основные задачи управления сетью, такие как добавление, настройка и удаление сетевых интерфейсов.

Любые изменения, внесенные в конфигурацию сети, не применяются, пока вы не нажмете кнопку Apply Configuration или не введете команду перезагрузки сети. Это позволяет вносить сразу много изменений. Это также позволяет вам убедиться, что ваши изменения верны, прежде чем применять их, так как допущенная здесь ошибка может сделать сервер недоступным по сети.

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

# proxmox-backup-manager network list

Чтобы добавить новый сетевой интерфейс, используйте подкоманду create с соответствующими параметрами. Например, вы можете захотеть создать интерфейс резервирования сети (bond):

# proxmox-backup-manager network create bond0 --type bond --bond_mode active-backup --slaves ens18,ens19 --autostart true --cidr x.x.x.x/x --gateway x.x.x.x

Вы можете внести изменения в конфигурацию сетевого интерфейса с помощью подкоманды update:

# proxmox-backup-manager network update bond0 --cidr y.y.y.y/y

Вы также можете удалить сетевой интерфейс:

# proxmox-backup-manager network remove bond0

Незавершенные изменения файла конфигурации сети появятся в нижней части веб-интерфейса. Вы также можете просмотреть эти изменения, используя команду:

# proxmox-backup-manager network changes

Если вы хотите отменить все изменения на этом этапе, вы можете либо щелкнуть кнопку Revert, либо использовать следующую команду:

# proxmox-backup-manager network revert

Если вас устраивают изменения и вы хотите записать их в файл конфигурации, выберите Apply Configuration. Соответствующая команда:

# proxmox-backup-manager network reload

Эта команда и соответствующая кнопка графического интерфейса зависят от команды ifreload из пакета ifupdown2. Этот пакет включен в установку Proxmox BS, однако вам, возможно, придется установить его самостоятельно.

Вы также можете настроить параметры DNS в разделе Configuration или с помощью подкоманды dns программы proxmox-backup-manager.

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

Настройка пользователей

Proxmox BS поддерживает несколько областей аутентификации, и вам необходимо выбрать область при добавлении нового пользователя. Возможные области:

• pam — стандартная аутентификация Linux PAM. Используйте если вы хотите аутентифицироваться как пользователь системы Linux (пользователи должны существовать в системе).
• pbs — область сервера Proxmox BS. Этот тип хранит хешированные пароли в /etc/proxmox-backup/shadow.json.

После установки появляется единственный пользователь root@pam. Информация о конфигурации пользователя хранится в файле /etc/proxmox-backup/user.cfg. Также вы можете использовать инструмент командной строки для получения списка пользователей или управления ими.

Суперпользователь имеет полные права администрирования во всем. Вы можете добавить других пользователей с меньшими правами. Вы можете добавить нового пользователя с помощью подкоманды user create или через веб-интерфейс на вкладке User Management в Configuration -> Access Control. Подкоманда create позволяет указать множество параметров, например —email или —password. Вы можете обновить или изменить любые свойства пользователя с помощью подкоманды update позже:

# proxmox-backup-manager user create john@pbs --email john@example.com
# proxmox-backup-manager user update john@pbs --firstname John --lastname Smith
# proxmox-backup-manager user update john@pbs --comment "An example user."

Получить список пользователей можно так:

# proxmox-backup-manager user list

У вновь созданных пользователей нет разрешений.

Если вы хотите отключить учетную запись пользователя, вы можете сделать это, установив —enable в 0:

# proxmox-backup-manager user update john@pbs --enable 0

Или полностью удалите пользователя:

# proxmox-backup-manager user remove john@pbs

API токены

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

Токены API служат двум целям:

1. Простой отзыв в случае компрометации клиента.
2. Ограничение разрешения для каждого клиента / токена в пределах полномочий пользователей.

Токен API состоит из двух частей:

1. Идентификатор, состоит из имени пользователя, области и имени токена, например user@realm! Tokenname.
2. Его секрет, например 58a77e1c-77ea-4e7d-bf2c-e265b43d93c0.

Обе части должны быть предоставлены клиенту вместо идентификатора пользователя и его пароля.

Токен API передается от клиента к серверу путем установки HTTP-заголовка авторизации с методом PBSAPIToken на значение TOKENID: TOKENSECRET.

Создание новых токенов можно выполнить с помощью proxmox-backup-manager или графического интерфейса пользователя:

# proxmox-backup-manager user generate-token john@pbs client1

Отображаемое секретное значение необходимо сохранить, поскольку оно не может быть отображено снова после генерации токена API.

Подкоманда user list-tokens может использоваться для отображения токенов и их метаданных:

# proxmox-backup-manager user list-tokens john@pbs

Точно так же пользовательская подкоманда delete-token может использоваться для удаления токена.

У вновь созданных токенов нет никаких разрешений. 

Управление доступом

По умолчанию новые пользователи и токены не имеют разрешений. Вам нужно указать, что разрешено, а что нет. Вы можете сделать это, назначив роли пользователям / токенам для определенных объектов, таких как хранилища данных или remotes. Существуют следующие роли:

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

Информация о правах доступа хранится в /etc/proxmoxbackup/acl.cfg. Файл содержит 5 полей, разделенных двоеточием. Типичная запись имеет вид:

acl:1:/datastore:john@pbs:DatastoreBackup

В каждом поле представлены следующие данные:

1. идентификатор acl;
2. 1 или 0, включено или отключено;
3. объект, на который установлено разрешение;
4. пользователи / токены, для которых установлено разрешение;
5. устанавливаемая роль.

Вы можете управлять разрешениями через Configuration -> Access Control -> Permissions в веб-интерфейсе. Кроме этого вы можете использовать подкоманду acl. Например, добавить пользователя john@pbs в качестве DatastoreAdmin для хранилища данных store1, расположенного в /backup/disk1/store1:

# proxmox-backup-manager acl update /datastore/store1 DatastoreAdmin --auth-id john@pbs

Вы можете получить список ACL каждого пользователя / токена, используя следующую команду:

# proxmox-backup-manager acl list

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

Здесь важно соглашение об именах. Для хранилищ данных на хосте необходимо использовать соглашение /datastore/{storename}. Например, чтобы установить разрешения для хранилища данных, смонтированного в /mnt/backup/disk4/store2, вы должны использовать /datastore/store2 в качестве пути. Для удаленных хранилищ используйте соглашение /remote/{remote}/{storename}, где {remote} означает имя remote, а {storename} — имя хранилища данных на удаленном компьютере.

Права API токенов

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

На практике это означает:

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

Действующие разрешения

Чтобы вычислить и отобразить набор разрешений пользователя или токена, вы можете использовать подкоманду user permission:

# proxmox-backup-manager user permissions john@pbs --path /datastore/store1

Двухфакторная аутентификация

Введение

Для простой аутентификации требуется только логин и пароль (один фактор). Если пароль украден любой может использовать его для входа в систему.

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

Это означает, что удаленный пользователь никогда не сможет заполучить такой физический объект. Таким образом, даже если этот пользователь знает ваш пароль, он не сможет успешно пройти аутентификацию как вы, поскольку отсутствует ваш второй фактор.

Доступные вторые факторы

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

• TOTP (одноразовый пароль на основе времени). Сокращенный код, полученный из общего секрета и текущего времени он переключается каждые 30 секунд.
• WebAuthn (веб-аутентификация). Общий стандарт аутентификации. Реализовано различными устройствами безопасности, такими как аппаратные ключи или доверенные платформенные модули (TPM) из компьютера или смартфона.
• Одноразовые ключи восстановления. Список ключей, которые следует распечатать и сохранить, или сохранить в цифровом виде. Каждый ключ можно использовать только один раз, они идеально подходят для того, чтобы гарантировано получить доступ, даже если все ваши другие вторые факторы потеряны.

Настройка

TOTP

Настройка сервера не требуется, просто установите приложение TOTP на свой смартфон (например, FreeOTP) и используйте веб-интерфейс Proxmox Backup Server, чтобы добавить TOTP.

WebAuthn

Для работы WebAuthn необходимы две вещи:

• доверенный сертификат HTTPS (например, с помощью Let’s Encrypt)
• настроить конфигурацию WebAuthn (Configuration -> Authentication). Его можно автоматически заполнить в большинстве настроек.

Выполнив оба этих требования, вы можете добавить конфигурацию WebAuthn в панель Access Control.

Recovery Keys

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

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

Автоматический доступ

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

Управление удаленными PBS

Remote (сервер PBS для синхронизации)

Под Remote подразумевается отдельная установка Proxmox BS. Вы можете синхронизировать хранилища данных удаленного сервера с локальным хранилищем данных с помощью задания синхронизации. Вы можете настроить Remote в веб-интерфейсе в разделе Configuration -> Remote. Информация о конфигурации Remote хранится в файле /etc/proxmox-backup/remote.cfg.

Чтобы добавить Remote, вам потребуется его имя или IP, идентификатор пользователя и пароль, а также его отпечаток сертификата. Чтобы получить отпечаток, используйте подкоманду cert info на Remote или перейдите в Dashboard в его веб-интерфейсе и выберите Show Fingerprint.

# proxmox-backup-manager cert info | grep Fingerprint

Используя информацию, указанную выше, вы можете добавить Remote из панели конфигурации Remote или с помощью команды:

# proxmox-backup-manager remote create pbs2 --host pbs2.mydomain.example --userid sync@pam --password 'SECRET' --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

Используйте подкоманды list, show, update для управления Remote:

# proxmox-backup-manager remote update pbs2 --host pbs2.example
# proxmox-backup-manager remote list
# proxmox-backup-manager remote remove pbs2

Задания синхронизации

Задания синхронизации используются для извлечения содержимого хранилища данных на удаленном сервере в локальное хранилище. Вы можете управлять заданиями синхронизации в веб-интерфейсе, на вкладке Sync Jobs хранилища данных, для которого вы хотите их настроить, или с помощью подкоманды sync-job. Информация о конфигурации для заданий синхронизации хранится в /etc/proxmox-backup/sync.cfg. Чтобы создать новое задание синхронизации, нажмите кнопку добавления в графическом интерфейсе или воспользуйтесь командой create. После создания задания синхронизации вы можете либо запустить его вручную из графического интерфейса, либо предоставить ему расписание для регулярного выполнения.

# proxmox-backup-manager sync-job create pbs2-local --remote pbs2 --remote-store local --store local --schedule 'Wed 02:30'
# proxmox-backup-manager sync-job update pbs2-local --comment 'offsite'
# proxmox-backup-manager sync-job list
# proxmox-backup-manager sync-job remove pbs2-local

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

1. Remote.Read для хранилища на удаленном сервере
2. Datastore.Backup для хранилища на локальном сервере

Если установлен параметр remove-vanished, Datastore.Prune также требуется на локальном хранилище. Если параметр владельца не задан (по умолчанию root@pam) или задан другой параметр, также требуется Datastore.Modify.

Задание синхронизации может синхронизировать только те группы резервных копий, которые может считывать пользователь или токен API. Если удаленный сервер настроен с помощью пользователя, который имеет только права Datastore.Backup, можно синхронизировать только ограниченный набор доступных снимков, принадлежащих этому пользователю.

Управление задачами

Обрезка

Prune позволяет указать, какие снимки резервных копий вы хотите сохранить. Доступны следующие варианты хранения:

• keep-last <N> Хранить последние <N> снимки резервных копий.
• keep-hourly <N> Хранить резервные копии за последние <N> часов. Если за один час создается более одной резервной копии, сохраняется только последняя.
• keep-daily <N> Хранить резервные копии за последние <N> дней. Если за один день создается более одной резервной копии, сохраняется только последняя.
• keep-weekly <N> Хранить резервные копии за последние <N> недель. Если за одну неделю создается более одной резервной копии, сохраняется только последняя. Недели начинаются в понедельник и заканчиваются в воскресенье.
• keep-month <N> Хранить резервные копии за последние <N> месяцев. Если за один месяц создается более одной резервной копии, сохраняется только последняя.
• keep-Annual <N> Хранить резервные копии за последние <N> лет. Если за один год создается более одной резервной копии, сохраняется только последняя.

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

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

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

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

Обрезка по расписанию

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

В следующем примере мы предполагаем, что вы делаете ежедневные резервные копии, имеете период хранения 10 лет, а период между хранением резервных копий постепенно увеличивается:

• keep-last: 3 — даже если резервное копирование выполняется только ежедневно, администратор может захотеть сохранить ещё 3 резервные копии на случай резервных копий сделанных вручную.
• keep-hourly: не задано — для ежедневных резервных копий это не актуально.
• keep-daily: 13 — вместе с keep-last, у вас будет как минимум две недели резервного копирования.
• keep-weekly: 8 — гарантирует, что у вас будет как минимум два полных месяца еженедельного резервного копирования.
• keep-monthly: 11 — вместе с предыдущими настройками это гарантирует, что у вас будет как минимум годовое ежемесячное резервное копирование.
• keep-yearly: 9 — для долгосрочного архива. Что даст вам в общей сложности как минимум 10 лет покрытия.

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

Сборка мусора

Вы можете отслеживать и запускать сборку мусора на сервере Proxmox BS, используя подкоманду garbage-collection. Вы можете использовать подкоманду start, чтобы вручную запустить сборку мусора для всего хранилища, и подкоманду status, чтобы просмотреть атрибуты, относящиеся к сборке мусора.

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

Проверка резервной копии

Proxmox Backup предлагает различные варианты проверки, чтобы убедиться, что данные резервной копии не повреждены. Верификация обычно осуществляется путем создания заданий верификации. Это запланированные задачи, которые запускают проверку с заданным интервалом. С их помощью вы можете установить, будут ли игнорироваться уже проверенные снимки, а также установить период времени, по истечении которого проверенные задания будут проверяться снова. Интерфейс для создания заданий проверки находится на вкладке Verify Jobs хранилища данных.

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

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

Уведомления

Proxmox BS может отправлять вам электронные письма с уведомлениями об автоматически запланированных результатах проверки, сборки мусора и синхронизации.

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

Вы также можете изменить уровень получаемого уведомления для каждого типа задачи, доступны следующие параметры:

• Always: отправлять уведомление независимо от результата.
• Errors: отправлять уведомление, после ошибки.
• Never: не отправлять уведомления.

Использование клиента

Утилита командной строки клиента называется proxmox-backup-client.

Клиент использует следующую запись для указания репозитория хранилища данных на сервере резервного копирования:

[[username@]server[:port]:]datastore

Значение по умолчанию для имени пользователя — root@pam. Если сервер не указан, по умолчанию используется localhost.

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

Обратите внимание, что если сервер является адресом IPv6, вы должны записать его в квадратных скобках (например, [fe80 :: 01]).

Вы можете передать репозиторий с помощью параметра командной строки —repository или установив переменную среды PBS_REPOSITORY.

Вот несколько примеров действующих репозиториев и реальных значений.

Example	User	Host:Port	Datastore
mydatastore	root@pam	localhost:8007	mydatastore
myhostname:mydatastore	root@pam	myhostname:8007	mydatastore
user@pbs@myhostname:mydatastore	user@pbs	myhostname:8007	mydatastore
user@pbs!token@host:store	user@pbs!token	myhostname:8007	mydatastore
192.168.55.55:1234:mydatastore	root@pam	192.168.55.55:1234	mydatastore
[ff80::51]:mydatastore	root@pam	[ff80::51]:8007	mydatastore
[ff80::51]:1234:mydatastore	root@pam	[ff80::51]:1234	mydatastore

Переменные окружения

PBS_REPOSITORY — Репозиторий резервных копий по умолчанию.

PBS_PASSWORD — Если установлено, используется для пароля от backup server. Вы также можете установить это значение для токена.

PBS_ENCRYPTION_PASSWORD — Если установлено, используется для доступа к секретному ключу шифрования (если защищен паролем).

PBS_FINGERPRINT — Если установлено, используется для проверки сертификата сервера (используется только если сертификаты CA системы не могут подтвердить сертификат).

Формат вывода команд

Большинство команд поддерживают параметр —output-format. Принимает следующие значения:

• text — Текстовый формат (по умолчанию). Структурированные данные отображаются в виде таблицы.
• json —  JSON (однострочный).
• json-pretty — JSON (несколько строк, красиво отформатированы).

Для изменения поведения вывода используйте следующие переменные среды:

• PROXMOX_OUTPUT_FORMAT — определяет выходной формат по умолчанию.
• PROXMOX_OUTPUT_NO_BORDER — если установлено (любое значение), не отображать границы таблицы.
• PROXMOX_OUTPUT_NO_HEADER — если установлено (любое значение), не отображать заголовки таблиц.

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

Создание резервной копии

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

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

# proxmox-backup-client backup root.pxar:/ --repository backup-server:store1
Starting backup: host/elsa/2019-12-03T09:35:01Z
Client name: elsa
skip mount point: "/boot/efi"
skip mount point: "/dev"
skip mount point: "/run"
skip mount point: "/sys"
Uploaded 12129 chunks in 87 seconds (564 MB/s).
End Time: 2019-12-03T10:36:29+01:00

Вам будет предложено ввести пароль, а затем будет загружен файловый архив с именем root.pxar, содержащий все файлы в каталоге /.

Обратите внимание, что proxmox-backup-client не включает автоматически точки монтирования. Вместо этого вы увидите короткое уведомление о пропуске точки монтирования для каждого из них. Идея состоит в том, чтобы создать отдельный файловый архив для каждого подключенного диска. Вы можете явно включить их, используя параметр —include-dev (например, —include-dev /boot/efi). Вы можете использовать эту опцию несколько раз для каждой точки монтирования, которую необходимо включить.

Параметр —repository может быть довольно длинным. Вместо этого вы можете установить переменную среды PBS_REPOSITORY. Если вы хотите, чтобы это значение оставалось после перезагрузки, вам следует добавить следующую строку в ваш файл .bashrc:

# export PBS_REPOSITORY=backup-server:store1

После этого вы можете выполнять все команды без указания опции —repository.

Одна резервная копия может содержать более одного архива. Например, если вы хотите сделать резервную копию двух дисков, установленных в /mnt/disk1 и /mnt/disk2:

# proxmox-backup-client backup disk1.pxar:/mnt/disk1 disk2.pxar:/mnt/disk2

Это создаст резервную копию обоих дисков.

Команда резервного копирования принимает список спецификаций резервного копирования, который включает имя архива на сервере, тип архива и источник архива на клиенте. Формат:

<archive-name>.<type>:<source-path>

Распространенными типами являются .pxar для файловых архивов и .img для образов блочных устройств. Чтобы создать резервную копию блочного устройства, выполните следующую команду:

# proxmox-backup-client backup mydata.img:/dev/mylvm/mydata

Исключение файлов и папок из резервной копии

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

Файл должен содержать по одному шаблону на строку. Пустые строки и закомментированные игнорируются. А “!” в начале строки изменяет шаблон совпадения с исключения на явное включение. Строки, оканчивающиеся на /, соответствуют только каталогам. Каталог, содержащий файл .pxarexclude, считается корнем данных шаблонов. Сопоставлять файлы можно только в этом каталоге и его подкаталогах.

\ используется для экранирования специальных символов.

? соответствует любому одиночному символу.

* соответствует любому символу, включая пустую строку.

** используется для сопоставления подкаталогов. Его можно использовать, например, для исключения всех файлов, оканчивающихся на .tmp, в каталоге или подкаталогах с помощью следующего шаблона **/*.tmp.

[…] соответствует одному символу из представленных в квадратных скобках. [! …] дополняет и соответствует любому одному символу, не заключенному в скобки. Также можно указать диапазоны двумя символами, разделенными знаком -. Например, [a-z] соответствует любому буквенному символу в нижнем регистре, а [0-9] соответствует любой цифре.

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

Например, рассмотрим следующую структуру каталогов:

# ls -aR folder
folder/:
. .. .pxarexclude subfolder0 subfolder1 
folder/subfolder0:
. .. file0 file1 file2 file3 .pxarexclude
folder/subfolder1:
. .. file0 file1 file2 file3

Различные файлы .pxarexclude содержат следующее:

# cat folder/.pxarexclude
/subfolder0/file1
/subfolder1/*
!/subfolder1/file2

# cat folder/subfolder0/.pxarexclude
file3

При этом будут исключены файлы file1 и file3 в subfolder0 и всё в subfolder1, кроме file2.

Восстановление этой резервной копии приведет к:

# ls -aR restored
restored/:
. .. .pxarexclude subfolder0 subfolder1
restored/subfolder0:
. .. file0 file2 .pxarexclude
restored/subfolder1:
. .. file2

Шифрование

Proxmox Backup поддерживает шифрование на стороне клиента с помощью AES-256 в режиме GCM. Чтобы настроить это, вам сначала нужно создать ключ шифрования:

# proxmox-backup-client key create my-backup.key
Encryption Key Password: **************

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

# proxmox-backup-client key create /path/to/my-backup.key --kdf none

Создав этот ключ, теперь можно создать зашифрованную резервную копию, передав параметр —keyfile с путем к файлу ключа.

# proxmox-backup-client backup etc.pxar:/etc --keyfile /path/to/my-backup.key
Password: *********
Encryption Key Password: **************
...

Если вы не укажете имя резервного ключа, ключ будет создан в расположении по умолчанию ~/.config/proxmox-backup/encryption-key.json. proxmox-backup-client также будет искать в этом месте по умолчанию, если параметр —keyfile не указан.

Вы можете избежать ввода паролей, установив переменные среды PBS_PASSWORD и PBS_ENCRYPTION_PASSWORD.

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

Вы также можете использовать proxmox-backup-client для создания пары открытый / закрытый ключ RSA, которую можно использовать для хранения зашифрованной версии симметричного ключа шифрования резервной копии вместе с каждой резервной копией и восстановления ее позже.

Чтобы настроить мастер-ключ:

1. Создайте ключ шифрования для резервной копии:

# proxmox-backup-client key create
creating default key at: "~/.config/proxmox-backup/encryption-key.json"
Encryption Key Password: **********

2. Создайте пару открытого / закрытого ключей RSA:

# proxmox-backup-client key create-master-key
Master Key Password: *********
...

Это создаст два файла в вашем текущем каталоге, master-public.pem и master-private.pem.

3. Импортируйте только что созданный публичный сертификат master-public.pem, чтобы proxmox-backup-client мог найти и использовать его при резервном копировании.

# proxmox-backup-client key import-master-pubkey /path/to/master-public.pem
Imported public master key to "~/.config/proxmox-backup/master-public.pem"

4. Со всеми этими файлами запустите задание резервного копирования:

# proxmox-backup-client backup etc.pxar:/etc

Ключ будет храниться в вашей резервной копии под именем rsa-encrypted.key.

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

5. Чтобы убедиться, что все работает, вы можете восстановить ключ из резервной копии:

# proxmox-backup-client restore /path/to/backup/ rsa-encrypted.key /path/to/target

Для извлечения этого файла ключ шифрования не требуется. Однако, если ключ существует в местоположении по умолчанию (~/.config/proxmox-backup/encryption-key.json), программа запросит у вас пароль для ключа шифрования. Простое перемещение encryption-key.json из этого каталога решит эту проблему.

6. Затем используйте сгенерированный ранее мастер-ключ для расшифровки файла:

# proxmox-backup-client key import-with-master-key /path/to/target --master-keyfile /path/to/master-private.pem --encrypted-keyfile /path/to/rsa-encrypted.key
Master Key Password: ******
New Password: ******
Verify Password: ******

7. Теперь целевой файл будет содержать информацию о ключе шифрования в виде обычного текста. Успех этого может быть подтвержден передачей результирующего файла json с параметром —keyfile при расшифровке файлов из резервной копии.

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

Рекомендуется хранить мастер-ключ в безопасности, но в легко доступном месте для быстрого восстановления после сбоев. Поэтому лучше всего хранить его в диспетчере паролей, где его можно немедленно восстановить. В качестве резервной копии вы также должны сохранить ключ на USB-накопитель и хранить его в надежном месте. Таким образом, он отключается от любой системы, но по-прежнему легко восстанавливается в случае возникновения чрезвычайной ситуации. Наконец, готовясь к наихудшему сценарию, вам также следует подумать о хранении бумажной копии вашего главного ключа в надежном месте. Подкоманду paperkey можно использовать для создания QR-версии вашего главного ключа.

Следующая команда отправляет вывод команды paperkey в текстовый файл для упрощения печати.

# proxmox-backup-client key paperkey --output-format text > qrkey.txt

Восстановление данных

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

Во-первых, вам нужно найти снимок, который вы хотите восстановить. Команда snapshot list предоставляет список всех снимков на сервере:

# proxmox-backup-client snapshot list

Вы можете просмотреть каталог, чтобы найти определенные файлы.

# proxmox-backup-client catalog dump host/elsa/2019-12-03T09:35:01Z
...
d "./root.pxar.didx/etc/cifs-utils"
l "./root.pxar.didx/etc/cifs-utils/idmap-plugin"
d "./root.pxar.didx/etc/console-setup"
...

Команда восстановления позволяет восстановить отдельный архив из резервной копии.

# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z root.pxar /target/path/

Чтобы получить содержимое любого архива, вы можете восстановить файл index.json в репозитории по целевому пути «-». Это выведет содержимое на стандартный вывод.

# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z index.json -

Интерактивное восстановление

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

# proxmox-backup-client catalog shell host/elsa/2019-12-03T09:35:01Z root.pxar
Starting interactive shell
pxar:/ > ls
bin boot dev etc home lib lib32
…

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

Использование каталога для навигации значительно снижает накладные расходы, поскольку необходимо загрузить и при необходимости, расшифровать только каталог. Фактические фрагменты потребуются только в том случае, если метаданных в каталоге недостаточно для фактического восстановления.

Подобно обычным оболочкам UNIX cd и ls — это команды, используемые для изменения рабочего каталога и вывода содержимого каталога в архиве. pwd показывает полный путь к текущему рабочему каталогу относительно корня архива.

Возможность быстрого поиска в содержимом архива — это необходимая функция. Например:

pxar:/ > find etc/**/*.txt --select
"/etc/X11/rgb.txt"
pxar:/ > list-selected
etc/**/*.txt
pxar:/ > restore-selected /target/path
...

Это найдет и распечатает все файлы с расширением .txt, расположенные в etc или подкаталоге, и добавит соответствующий шаблон в список для последующего восстановления. list-selected показывает эти шаблоны, а restore-selected восстанавливает все файлы в архиве в /target/path на локальном хосте.

С помощью команды restore /target/path вы можете восстановить часть архива, указанный в текущем рабочем каталоге, по локальному целевому пути /target/path на вашем хосте. Если дополнительно передать шаблон с —pattern <glob>, восстановление будет дополнительно ограничено файлами, соответствующими шаблону. Например:

pxar:/ > cd /etc/
pxar:/etc/ > restore /target/ --pattern **/*.conf
...

Это просканирует все подкаталоги в /etc и восстановит все файлы, заканчивающиеся на .conf.

Монтирование архивов используя FUSE

Реализация FUSE для архива pxar позволяет вам монтировать файловый архив как файловую систему только для чтения к точке монтирования на вашем хосте.

# proxmox-backup-client mount host/backup-client/2020-01-29T11:29:22Z root.pxar /mnt/mountpoint
# ls /mnt/mountpoint
bin dev home lib32 libx32 media opt root sbin sys usr boot etc lib lib64 lost+found mnt proc run srv tmp var

Это позволяет беспрепятственно получить доступ ко всему содержимому архива.

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

Чтобы размонтировать файловую систему, используйте команду umount с точкой монтирования:

# umount /mnt/mountpoint

Вход и выход

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

Вы также можете вручную запустить вход / выход из системы с помощью команд:

# proxmox-backup-client login
Password: **********

# proxmox-backup-client logout

Изменение владельца группы резервных копий

По умолчанию владельцем группы резервных копий является пользователь, который использовался для первоначального создания этой группы (или, в случае заданий синхронизации, root@pam). Это означает, что если пользователь mike@pbs создал резервную копию, другой пользователь john@pbs не может быть использован для создания резервных копий в той же группе. Если вы хотите изменить владельца резервной копии, вы можете сделать это с помощью приведенной ниже команды, используя пользователя с правами Datastore.Modify в хранилище данных.

# proxmox-backup-client change-owner vm/103 john@pbs

Это также можно сделать из веб-интерфейса, перейдя в раздел Content хранилища данных, содержащего группу резервного копирования, и выбрав значок пользователя в столбце Действия. Обычными случаями для этого может быть изменение владельца задания синхронизации с root@pam или изменение назначения группы резервного копирования.

Обрезка и удаление резервных копий

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

# proxmox-backup-client snapshot forget <snapshot>

Внимание! Эта команда удаляет все архивы в этом снимке резервной копии. Они будут недоступны и не подлежат восстановлению.

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

—keep-last <N> Сохранить последние <N> резервные снимки.

—keep-hourly <N> Сохранить резервные копии за последние <N> часов. Если за один час создается более одной резервной копии, сохраняется только последняя.

—keep-daily <N> Сохранить резервные копии за последние <N> дней. Если за один день создается более одной резервной копии, сохраняется только последняя.

—keep-weekly <N> Сохранить резервные копии за последние <N> недель. Если за одну неделю создается более одной резервной копии, сохраняется только последняя. Неделя начинается с понедельника.

—keep-monthly <N> Сохранить резервные копии за последние <N> месяцев. Если за один месяц создается более одной резервной копии, сохраняется только последняя.

—keep-yearly <N> Сохранить резервные копии за последние <N> лет. Если за один год создается более одной резервной копии, сохраняется только последняя.

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

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

# proxmox-backup-client prune <group> --keep-daily 7 --keep-weekly 4 --keep-monthly 3

Вы можете использовать параметр —dry-run, чтобы проверить свои настройки. Здесь отображается только список существующих снимков и действия, которые необходимо выполнить при сокращении.

# proxmox-backup-client prune host/elsa --dry-run --keep-daily 1 --keep-weekly 3

Примечание. Ни команда prune, ни команда forget не освобождают место в хранилище фрагментов. Хранилище фрагментов все еще содержит блоки данных. Чтобы освободить место, нужно выполнить сборку мусора.

Сборка мусора

Команда prune удаляет только индексные файлы резервных копий, но не данные из хранилища данных. Эта задача возложена на команду сборки мусора. Рекомендуется регулярно производить сборку мусора.

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

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

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

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

# proxmox-backup-client garbage-collect
starting garbage collection on store store2
Start GC phase1 (mark used chunks)
Start GC phase2 (sweep unused chunks)
percentage done: 1, chunk count: 219
percentage done: 2, chunk count: 453
...
percentage done: 99, chunk count: 21188
Removed bytes: 411368505
Removed chunks: 203
Original data bytes: 327160886391
Disk bytes: 52767414743 (16 %)
Disk chunks: 21221
Average chunk size: 2486565
TASK OK

Тестирование производительности

Клиент резервного копирования поставляется с инструментом для тестирования производительности. Этот инструмент измеряет различные показатели, относящиеся к скорости сжатия и шифрования. Вы можете запустить тест, используя подкоманду benchmark:

# proxmox-backup-client benchmark
Uploaded 656 chunks in 5 seconds.
Time per request: 7659 microseconds.
TLS speed: 547.60 MB/s
SHA256 speed: 585.76 MB/s
Compression speed: 1923.96 MB/s
Decompress speed: 7885.24 MB/s
AES256/GCM speed: 3974.03 MB/s

Примечание: проценты, указанные в выходной таблице, соответствуют сравнению с Ryzen 7 2700X. Тест TLS подключается к локальному хосту, поэтому сеть не задействована.

Вы также можете передать параметр —output-format для вывода статистики в json, а не в формате таблицы по умолчанию.

Интеграция с Proxmox VE

Вам необходимо определить новое хранилище с типом «pbs» на вашем узле Proxmox VE. В следующем примере в качестве имени хранилища используется store2, предполагается, что адрес сервера — localhost, и вы хотите подключиться как user1@pbs.

# pvesm add pbs store2 --server localhost --datastore store2
# pvesm set store2 --username user1@pbs --password <secret>

Примечание. Если вы не хотите передавать свой пароль в виде обычного текста, вы можете передать параметр —password без каких-либо аргументов. Это заставит программу запрашивать пароль при вводе команды.

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

# proxmox-backup-manager cert info | grep Fingerprint
Fingerprint (sha256): 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

Добавьте этот отпечаток в свою конфигурацию, чтобы установить доверительные отношения:

# pvesm set store2 --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

После этого вы сможете увидеть статус хранилища с помощью:

# pvesm status --storage store2

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

Инструмент командной строки pxar

pxar — это утилита командной строки для создания и управления архивами в формате файлового архива Proxmox (.pxar). Он вдохновлен форматом файлового архива casync, который обслуживает аналогичный вариант использования. Формат .pxar адаптирован для удовлетворения конкретных потребностей Proxmox Backup Server, например, для эффективного хранения жестких ссылок. Формат предназначен для уменьшения объема памяти, необходимого на сервере, за счет достижения высокого уровня дедупликации.

Создание архива

Выполните следующую команду, чтобы создать архив папки с именем source:

# pxar create archive.pxar /path/to/source

Это создаст новый архив с именем archive.pxar с содержимым исходной папки.

Примечание: pxar не перезапишет существующие архивы. Если в целевой папке уже есть архив с таким именем, создание не удастся.

По умолчанию pxar пропускает определенные точки монтирования и не соответствует границам устройства. Это проектное решение основано на основном варианте использования — создании архивов для резервных копий. Имеет смысл не резервировать содержимого определенных временных или системных файлов. Чтобы изменить это поведение и следовать границам устройства, используйте флаг —all-file-systems.

Можно исключить определенные файлы или папки из архива, передав параметр —exclude с шаблонами.

Например, вы можете исключить из архива все файлы с расширением .txt, запустив:

# pxar create archive.pxar /path/to/source --exclude '**/*.txt'

Имейте в виду, что оболочка сама попытается развернуть все шаблоны перед вызовом pxar. Чтобы этого избежать, все шаблоны должны быть указаны правильно.

Можно передавать параметр —exclude несколько раз, чтобы соответствовать более чем одному шаблону. Это позволяет использовать более сложное поведение. Однако в таких случаях рекомендуется использовать файлы .pxarexclude.

Например, вы можете исключить из архива все файлы .txt, кроме одного. Это достигается с помощью шаблона отрицательного совпадения с префиксом “!”. Все шаблоны относятся к исходному каталогу.

# pxar create archive.pxar /path/to/source --exclude '**/*.txt' --exclude '!/folder/file.txt'

Примечание: порядок шаблонов имеет значение, поскольку более поздние имеют приоритет над предыдущими.

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

Более удобный и надежный способ исключить файлы из архива — это поместить шаблоны в файлы .pxarexclude. Эти файлы можно создавать и размещать в любом каталоге дерева файловой системы. Эти файлы должны содержать по одному шаблону в строке, и снова более поздние шаблоны имеют преимущество перед предыдущими. Шаблоны управляют исключением файлов, находящихся в данном каталоге или ниже в дереве. Поведение такое же, как описано в разделе «Создание резервных копий».

Извлечение архива

Существующий архив archive.pxar извлекается в целевой каталог с помощью следующей команды:

# pxar extract archive.pxar /path/to/target

Если цель не указана, содержимое архива извлекается в текущий каталог.

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

# pxar extract etc.pxar /restore/target/etc --pattern '**/*.conf'

В приведенном выше примере восстанавливаются все файлы .conf, обнаруженные в любой из подпапок в архиве в  /etc, в /restore/target/etc. Путь к файлу, содержащему шаблоны совпадений, можно указать с помощью параметра —files-from.

Чтобы отобразить файлы и каталоги, содержащиеся в архиве archive.pxar, выполните следующую команду:

# pxar list archive.pxar

Здесь отображается полный путь к каждому файлу или каталогу относительно корня архива.

Монтирование архива

pxar позволяет монтировать и проверять содержимое архива через FUSE. Чтобы смонтировать архив с именем archive.pxar в точку монтирования /mnt, выполните команду:

# pxar mount archive.pxar /mnt
# cd /mnt
# ls
bin  dev  home lib32 libx32 media opt  root sbin sys usr boot etc lib lib64 lost+found mnt proc run srv tmp var

Администрирование сервера

Proxmox Backup основан на дистрибутиве Debian. Это означает, что у вас есть доступ ко всем пакетам Debian, а базовая система хорошо документирована. Справочник администратора Debian доступен в Интернете и содержит всестороннее введение в эту операционную систему.

Стандартная установка Proxmox Backup использует репозитории Debian по умолчанию, поэтому вы получаете исправления ошибок и обновления безопасности через этот канал. Кроме того, мы предоставляем собственный репозиторий пакетов для развертывания всех пакетов, связанных с Proxmox. При необходимости сюда входят обновления некоторых пакетов Debian.

Мы также поставляем специально оптимизированное ядро ​​Linux, в котором мы включаем все необходимые функции виртуализации и контейнеров. Это ядро ​​включает драйверы для ZFS и несколько драйверов оборудования. Например, мы поставляем драйверы сетевых карт Intel для поддержки новейшего оборудования.

ZFS

ZFS — это комбинированный менеджер файловой системы и логических томов, разработанный Sun Microsystems. Нет необходимости вручную компилировать модули ZFS — все пакеты включены.

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

Общие преимущества ZFS:

• Простая настройка и управление с помощью графического интерфейса и командной строки
• Надежность
• Защита от повреждения данных
• Сжатие данных на уровне файловой системы
• Снимки
• Копирование при записи (клоны)
• Различные уровни рейдов: RAID0, RAID1, RAID10, RAIDZ1, RAIDZ2 и RAIDZ3.
• Можно использовать SSD для кеширования
• Самовосстановление
• Непрерывная проверка целостности
• Разработан для хранения большой емкости
• Асинхронная репликация по сети
• Открытый исходный код
• Шифрование

Железо

ZFS сильно зависит от памяти, поэтому для запуска вам потребуется не менее 8 ГБ. На практике используйте столько, сколько можете получить в соответствии с вашим оборудованием / бюджетом. Чтобы предотвратить повреждение данных, мы рекомендуем использовать ОЗУ с ECC высокого качества.

Если вы используете выделенный кэш и / или диск для журнала, вам следует использовать SSD корпоративного класса (например, Intel SSD DC S3700 Series). Это может значительно повысить общую производительность.

Важно! Не используйте ZFS поверх аппаратного контроллера, который имеет собственное управление кешем. ZFS необходимо напрямую взаимодействовать с дисками. Адаптер HBA — это то, что нужно, или что-то вроде контроллера LSI, прошитого в IT Mode.

Администрирование

В этом разделе приведены некоторые примеры использования для общих задач. Сама по себе ZFS действительно мощная и предоставляет множество возможностей. Основные команды для управления ZFS — это zfs и zpool. Обе команды имеют отличные справочные страницы, которые можно прочитать с помощью:

# man zpool
# man zfs

Для создания нового пула необходим как минимум один диск. ashift зависит от размера сектора на диске (2 в степени ashift = размер сектора) или больше. 2¹² = 4096.

# zpool create -f -o ashift=12 <pool> <device>

В следующем листинге показаны примеры создания пулов:

• RAID-0 (минимум 1 диск)

# zpool create -f -o ashift=12 <pool> <device1> <device2>

• RAID-1 (минимум 2 диска)

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2>

• RAID-10 (минимум 4 диска)

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> mirror <device3> <device4>

• RAIDZ-1 (минимум 3 диска)

# zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>

• RAIDZ-2 (минимум 4 диска)

# zpool create -f -o ashift=12 <pool> raidz2 <device1> <device2> <device3> <device4>

Создание пула с кешем (L2ARC)

Для увеличения производительности можно использовать выделенный раздел кеш-диска (используйте SSD). В качестве <устройства> можно использовать части команд из создания пула.

# zpool create -f -o ashift=12 <pool> <device> cache <cache_device>

Создание пула с логом (ZIL)

Для увеличения производительности можно использовать выделенный раздел кеш-диска (SSD).

# zpool create -f -o ashift=12 <pool> <device> log <log_device>

Добавление кеша и журнала в существующий пул

Если у вас пул без кеша и журнала. Сначала разделите SSD на 2 раздела с помощью parted или gdisk (используйте только GPT таблицу разделов). Максимальный размер устройства журнала должен составлять примерно половину размера физической памяти, поэтому обычно он довольно мал. Остальной SSD можно использовать как кеш.

# zpool add -f <pool> log <device-part1> cache <device-part2>

Замена вышедшего из строя устройства

# zpool replace -f <pool> <old device> <new device>

Замена отказавшего загрузочного устройства

В зависимости от того, как был установлен Proxmox Backup, в качестве загрузчика используется либо grub, либо systemd-boot.

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

# sgdisk <исправный загрузочный диск> -R <новый диск>
# sgdisk -G <новый диск>
# zpool replace -f <pool> <старый zfs раздел> <новый zfs раздел>

Примечание. Используйте команду zpool status -v, чтобы отслеживать, насколько продвинулся процесс resilvering нового диска.

С помощью systemd-boot:

# pve-efiboot-tool format <new disk's ESP>
# pve-efiboot-tool init <new disk's ESP>

Примечание. ESP означает системный раздел EFI, который устанавливается как раздел №2 на загрузочных дисках, устанавливаемый установщиком pve, начиная с версии 5.4.

С grub:

Обычно grub.cfg находится в /boot/grub/grub.cfg

# grub-install <new disk>
# grub-mkconfig -o /path/to/grub.cfg

Активация e-mail уведомлений

ZFS поставляется с демоном событий, который отслеживает события, генерируемые модулем ядра ZFS. Демон также может отправлять электронные письма о событиях ZFS, например об ошибках пула. Новые пакеты ZFS поставляют демон в отдельном пакете, и вы можете установить его с помощью apt-get:

# apt-get install zfs-zed

Для активации демона необходимо отредактировать /etc/zfs/zed.d/zed.rc вашим любимым редактором и раскомментировать параметр ZED_EMAIL_ADDR:

ZED_EMAIL_ADDR=»root»

Обратите внимание, что Proxmox Backup пересылает почту root на адрес электронной почты, настроенный для пользователя root. Единственная необходимая настройка — ZED_EMAIL_ADDR. Все остальные настройки не обязательны.

Лимит использование памяти ZFS

Для ZFS ARC рекомендуется использовать не более 50 % (по умолчанию) системной памяти, чтобы предотвратить снижение производительности хоста. Используйте предпочтительный редактор, чтобы изменить конфигурацию в /etc/modprobe.d/zfs.conf и вставить:

options zfs zfs_arc_max=8589934592

В этом примере 8GB.

Важно: если ваша корневая файловая система — ZFS, вы должны обновлять initramfs каждый раз, после этих изменений:

# update-initramfs -u

SWAP на ZFS

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

Мы настоятельно рекомендуем использовать достаточно памяти, чтобы обычно не возникали ситуации нехватки памяти. Если вам нужно или вы хотите добавить подкачку, рекомендуется создать раздел на физическом диске и использовать его как устройство подкачки. Вы можете оставить для этой цели свободное место в расширенных параметрах установщика. Кроме того, вы можете снизить значение подкачки. Хорошее значение для серверов — 10:

# sysctl -w vm.swappiness=10

Чтобы сделать подкачку постоянной, откройте /etc/sysctl.conf в любом редакторе и добавьте следующую строку:

vm.swappiness = 10

Сжатие ZFS

Чтобы активировать сжатие:

# zpool set compression=lz4 <pool>

Мы рекомендуем использовать алгоритм lz4, поскольку он очень мало увеличивает нагрузку на процессор. Также доступны другие алгоритмы, такие как lzjb и gzip-N (где N — целое число от 1 до 9, представляющее степень сжатия, 1 — самое быстрое, а 9 — лучшее сжатие). В зависимости от алгоритма и степени сжатия данных включение сжатия может даже повысить производительность ввода-вывода.

Вы можете отключить сжатие в любое время с помощью:

# zfs set compression=off <dataset>

Это изменение затронет только новые блоки.

Специальное устройство ZFS

Начиная с версии 0.8.0 ZFS поддерживает специальные устройства. Специальное устройство в пуле используется для хранения метаданных, таблиц дедупликации и, возможно, небольших файловых блоков.

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

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

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

Создание пула со специальным устройством и RAID-1:

# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> special mirror <device3> <device4>

Добавление специального устройства в существующий пул с RAID-1:

# zpool add <pool> special mirror <device1> <device2>

Датасеты ZFS предоставляют свойство special_small_blocks = <size>. size может быть 0, чтобы отключить хранение небольших файловых блоков на специальном устройстве, или степенью двойки в диапазоне от 512 И до 128K. После установки свойства новые блоки файлов меньше размера будут размещены на специальном устройстве.

Важно! если значение special_small_blocks больше или равно размеру записи (по умолчанию 128 КБ) набора данных, все данные будут записаны на специальное устройство, поэтому будьте осторожны!

Установка свойства special_small_blocks в пуле изменит значение этого свойства по умолчанию для всех дочерних наборов данных ZFS (например, все контейнеры в пуле будут выбирать небольшие блоки файлов).

Например включим все файлы размером меньше 4K-блоков для всего пула:

# zfs set special_small_blocks=4K <pool>

Или для одного датасета:

# zfs set special_small_blocks=4K <pool>/<filesystem>

Отказаться от небольших файловых блоков можно так:

# zfs set special_small_blocks=0 <pool>/<filesystem>

Поиск проблемы

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

Для каждого пула запустите:

# zpool set cachefile=/etc/zfs/zpool.cache POOLNAME

а затем обновите initramfs, запустив:

# update-initramfs -u -k all

и, наконец, перезагрузите ваш сервер.

Иногда файл кэша ZFS может быть поврежден, и служба zfs-import-cache.service не импортирует пулы, которых нет в файле кеша.

Еще один способ решения этой проблемы — включить службу zfs-import-scan.service, которая выполняет поиск и импорт пулов с помощью сканирования устройства (обычно медленнее).

Технический обзор

Datastores

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

<datastore-root>/<type>/<id>/<time>/

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

Chunks (фрагменты данных)

Это некоторые (возможно, зашифрованные) данные с контрольной суммой CRC-32 в конце и маркером типа в начале. Он идентифицируется контрольной суммой SHA-256 его содержимого.

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

Фрагменты хранилища данных находятся в

<datastore-root>/.chunks/

Этот каталог фрагментов дополнительно подразделяется на первые четыре байта контрольной суммы фрагментов, поэтому фрагмент с контрольной суммой

a342e8151cbf439ce65f3df696b54c67a114982cc0aa751f2852c2f7acc19a8b

живет в

<datastore-root>/.chunks/a342/

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

Эти каталоги фрагментов («0000» — «ffff») будут предварительно выделены при создании хранилища данных.

Фрагменты с фиксированным размером

Для блочного резервного копирования (например, виртуальных машин) используются фрагменты фиксированного размера. Контент (образ диска) разбивается на фрагменты одинаковой длины (обычно 4 МБ).

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

В качестве оптимизации виртуальные машины в Proxmox VE могут использовать «грязные растровые изображения» (dirty bitmaps), которые могут отслеживать измененные блоки. Поскольку эти изображения также являются изображениями, разделенными на фрагменты, существует прямая связь между грязными блоками изображения и фрагментами, которые необходимо загрузить, поэтому для резервного копирования необходимо загружать только измененные фрагменты диска.

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

Для согласованности Proxmox VE использует внутренний механизм моментальных снимков QEMU, который также не полагается на моментальные снимки хранилища.

Фрагменты с динамическим размером

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

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

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

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

Зашифрованные фрагменты

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

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

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

Предостережения и ограничения

Примечания к хеш-коллизиям

У каждого алгоритма хеширования есть шанс вызвать коллизии, то есть два (или более) входа генерируют одинаковую контрольную сумму. Для SHA-256 этот шанс ничтожен. 

Для примера, в лотерее с угадыванием 6 из 45 шансов нужно угадать все 6 чисел, а вероятность столкновения примерно такая же, как при выигрыше 13 таких лотерей подряд. Крайне маловероятно, что такое столкновение произойдет случайно в обычном хранилище данных.

Кроме того, SHA-256 подвержен атакам на расширение длины, но, поскольку существует верхний предел размера блока, это не проблема.

Файловое резервное копирование

Поскольку блоки динамического размера (для файловых резервных копий) создаются в пользовательском формате архива (pxar), между файлами и блоками нет никакой связи. Это означает, что клиент Proxmox Backup должен заново читать все файлы для каждой резервной копии. Обратите внимание, что будут загружаться только новые или измененные фрагменты.

Проверка зашифрованных блоков

Для зашифрованных фрагментов доступна только контрольная сумма исходных (незашифрованных) данных, что делает невозможным для сервера (без ключа шифрования) проверить свое содержимое по нему. Вместо этого проверяется только контрольная сумма CRC-32.

Вопросы и ответы

На каком дистрибутиве основан Proxmox Backup Server (PBS)?

Сервер резервного копирования Proxmox основан на Debian GNU / Linux.

Какие платформы поддерживаются в качестве резервного источника (клиенты)?

Клиент работает в большинстве современных систем Linux, что означает, что вы не ограничены одним Debian.

Будет ли Proxmox Backup Server работать на 32-битном процессоре?

Сервер резервного копирования поддерживает только 64-битные процессоры (AMD или Intel). В будущем нет планов по поддержке 32-битных процессоров.

Как долго будет поддерживаться моя версия Proxmox Backup Server?

Proxmox Backup 1.x /  Debian 10 (Buster) / срок поддержки будет объявлен позже.

Могу ли я скопировать или синхронизировать свое хранилище данных с другим местом?

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

Может ли Proxmox Backup Server проверить целостность данных резервной копии?

Proxmox Backup Server использует встроенный алгоритм контрольной суммы SHA256 для обеспечения целостности данных. В каждой резервной копии создается файл манифеста (index.json), который содержит список всех файлов резервных копий, а также их размеры и контрольные суммы. Этот файл манифеста используется для проверки целостности каждой резервной копии.

Должен ли я доверять удаленному серверу при резервном копировании на удаленные серверы?

Proxmox BS передает данные через TLS и дополнительно поддерживает шифрование на стороне клиента. Это означает, что данные передаются надежно и могут быть зашифрованы до того, как достигнут сервера. Таким образом, в случае, если злоумышленник получит доступ к серверу или любой точке сети, он не сможет прочитать данные.

Примечание. По умолчанию шифрование отключено.

Резервная копия инкрементная / дедуплицированная?

С Proxmox BS резервные копии отправляются инкрементно, а данные дедуплицируются на сервере. Это сводит к минимуму как потребляемую память, так и влияние на сеть.

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

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