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

Содержание скрыть

Введение

Что такое 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 подкаталогов на каталог. Эта цифра получается из 216 предварительно созданных каталогов (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.

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

ExampleUserHost:PortDatastore
mydatastoreroot@pamlocalhost:8007mydatastore
myhostname:mydatastoreroot@pammyhostname:8007mydatastore
user@pbs@myhostname:mydatastoreuser@pbsmyhostname:8007mydatastore
user@pbs!token@host:storeuser@pbs!tokenmyhostname:8007mydatastore
192.168.55.55:1234:mydatastoreroot@pam192.168.55.55:1234mydatastore
[ff80::51]:mydatastoreroot@pam[ff80::51]:8007mydatastore
[ff80::51]:1234:mydatastoreroot@pam[ff80::51]:1234mydatastore

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

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 = размер сектора) или больше. 212 = 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 - Перевод документации
Имя статьи
Proxmox Backup Server - Перевод документации
Описание
В этой статье представлен перевод документации по Proxmox Backup Server.

2 Replies to “Proxmox Backup Server — Перевод документации”

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *