Proxmox backup server windows client — Ваш верный помощник с OS Windows

Are you looking for a robust Windows server backup solution? Try Vinchin Backup & Recovery!↘ Download Free Trial

Proxmox VE is an open source virtualization platform that provides virtualization services based on KVM and LXC. Proxmox Backup Server is a backup solution developed by the Proxmox VE team for backing up and restoring virtual machines and containers.

Is it possible to back up a physical Windows machine to Proxmox Backup Server?

There may currently be some limitations when backing up directly to a Proxmox backup server on a Windows machine. Although it is possible to install a backup client on Linux, many employees still use Windows machines, which introduces some complexity to backups.

However, it is important to note that there currently does not appear to be a Windows client specifically designed for PBS. An alternative is to share a drive on Windows, mount the shared drive on a Linux machine, and then use the Proxmox backup client to back up data from the shared drive. While this method may require some additional setup and configuration, it can serve as a solution for backing up physical Windows machines to PBS.

Another possible solution is to utilize Windows Subsystem for Linux (WSL) in conjunction with the Proxmox backup client for backup. In this way, users can use WSL to run a backup client on a Windows machine to back up specific paths and folders instead of the entire operating system, which can work very well in some cases.

Without a Windows backup client available, some users might consider abandoning PBS as a backup solution and looking for other, more direct and efficient backup methods.

Virtualize a Windows machine on Proxmox and let PBS back up the VM

Using Proxmox Backup Server to back up a virtualized Windows machine running on Proxmox VE is a valid and effective method.

Preparation:

Back up your data: Before you start, be sure to back up all important data on your physical machine in case something unexpected happens.

Get a conversion tool: Download and install a tool suitable for physical-to-virtual (P2V) conversion.

1. Convert physical machine disk

Run the conversion tool on the physical machine and follow the tool’s guidance to convert the physical machine’s disk into a format usable by the virtual machine (such as VMDK, QCOW2, etc.).

2. Upload the converted disk file to Proxmox

Upload the converted disk file to the appropriate location on the Proxmox server.

3. Create a new virtual machine

Create a new virtual machine in Proxmox and select the appropriate operating system type and version.

Associate the uploaded disk file to the newly created virtual machine.

4. Configure the virtual machine

Configure the hardware settings of the virtual machine, such as the number of CPU cores, memory size, etc. Make sure the virtual machine’s network settings are correct, including network adapter and IP address settings.

5. Start the virtual machine and test

Make adjustments and optimizations as needed, such as installing VirtIO drivers to improve performance.

6. Use PBS to back up virtual machines

In the Proxmox VE interface, select Storage and install Proxmox Backup Server.

Log in to the Proxmox Backup Server interface, and in the “Backup” tab, click “Create Backup Task”. Select the virtual machines to back up, set the backup schedule and other related options.

You can monitor the status and logs of backup tasks to ensure that backup tasks are running normally.

If you need to restore a virtual machine, you can select the corresponding backup point in Proxmox Backup Server and perform the restore operation.

Professional solution for Windows backup

Proxmox Backup Server is more suitable for backing up virtual machines and containers in a virtualized environment rather than directly backing up Windows clients. If you want to back up Windows clients, it is usually recommended to use specialized backup software, such as Vinchin Backup & Recovery.

Vinchin Backup & Recovery is a professional enterprise backup and disaster recovery solution, supporting backing up Windows/Linux server (like Windows 2022/2019/2016/2012/2012 R2/2008/2008 R2/2003/ 2003 R2), virtual machine, file server, NAS , database, etc. providing easy protection for complex IT environment.

Vinchin’s physical server backup solution incorporates the VSS (Volume Shadow Copy Service) technique for Windows Server Backup, enabling the creation of application-aware snapshots of NTFS volumes. Furthermore, a custom snapshot mechanism is included for Linux server users to maintain the coherence of backup data.

Except for os-level backup, file-level backup is also supported in Vinchin Backup & Recovery to help protect files and folders regularly.

A user-friendly web console will help easily perform bare metal backup and restore on Windows server. To backup your Windows server, just follow the steps below:

1. Select the Windows server

2. Select the backup destination

3. Select backup strategies

4. Submit the job

The bare metal backup will include the operating system and the other data and then you can use it to perform a bare metal recovery process.

You can start a 60-day full-featured free trial here. Also, contact us, leave your requirements, and then you will receive your tailored solution.

FAQs

1. Q: Does Proxmox Backup Server support cross-platform backup and recovery?

A: Proxmox Backup Server is mainly used to back up and restore virtual machines and containers in the Proxmox VE environment. While it may not directly support backup and restore from other platforms such as VMware or Hyper-V, virtual machines can be imported into a Proxmox VE environment via conversion tools and then backed up and restored using PBS. And Vinchin Backup & Recovery will be a better choice for V2V migration without additional conversion process.

2. Q：What is the relationship between Proxmox Backup Server and Proxmox Backup Client?

A: The Proxmox Backup Server and Proxmox Backup Client work together in a client-server relationship to facilitate data backup and recovery. The client is installed on the systems that need to be backed up and is responsible for preparing and sending the data to the server. The PBS, installed on a dedicated machine, is tasked with managing, storing, and allowing for the restoration of these backups. It provides a web interface for administration, while the client operates on the command line or through scripts, ensuring users can efficiently secure their data across different operating systems.

Conclusion

Backing up a physical Windows machine to a Proxmox backup server may require some extra work and adjustments, but you can try using WSL in combination with a Proxmox backup client or a shared drive to achieve backup. If a Windows backup client is not available, you may want to consider other backup solutions like Vinchin Backup & Recovery to ensure the security and reliability of your data.

Источник

This software implements a proxmox backup client software for windows, backup only as of now
Works on linux too especially for development

The software is still alpha quality and i take no responsability for any kind of damage or data loss even of source files.

Contributions are welcome especially

GUI with tray icon to show backup progress and backup taking place
Encryption support
A GUI way of configuring it and maybe create a json job file similiar freefilesync does
Async upload / compress and multicore upload + compression of chunks
Proxmox side patch to add another kind of entry to pxar format with Windows security descriptors in it
Support for windows symlinks
Anything interesting you can come up with

Usage

A typical command would look like:

proxmoxbackupgo.exe -baseurl "https://yourpbshost:8007" -certfingerprint pbsfingerprint -authid "user@realm!apiid" -secret "apisecret" -backupdir "C:\path\to\backup" -datastore "datastorename"

proxmoxbackupgo.exe
  -authid string
        Authentication ID (PBS Api token)
  -secret string
        Secret for authentication
  -backupdir string
        Backup source directory, must not be symlink
  -baseurl string
        Base URL for the proxmox backup server, example: https://192.168.1.10:8007
  -certfingerprint string
        Certificate fingerprint for SSL connection, example: ea:7d:06:f9...
  -datastore string
        Datastore name
  -namespace string
        Namespace (optional)
  -backup-id string
        Backup ID (optional - if not specified, the hostname is used as the default for host-type backups)
  -pxarout string
        Output PXAR archive for debug purposes (optional)
  -backupstream string  ***NEW***
    	Filename for stream backup
  -mail-host string
        mail notification system: mail server host(optional)
  -mail-port string
        mail notification system: mail server port(optional)
  -mail-username string
        mail notification system: mail server username(optional)
  -mail-password string
        mail notification system: mail server password(optional)
  -mail-insecure bool
        mail notification system: allow insecure communications(optional)
  -mail-from string
        mail notification system: sender mail(optional)
  -mail-to string
        mail notification system: receiver mail(optional)

  -mail-subject-template string
        mail notification system: mail subject template(optional)
  -mail-body-template string
        mail notification system: mail body template(optional)

  -config string
        Path to JSON config file. If this flag is provided all the others will override the loaded config file

For JSON configuration a JSON example is provided, fill in only the needed fields.

Note on mail templating:
Go’s templating engine is used for mail subjects and bodies, please refer to the documentation for the syntax.
The following variables are available for templating:

.NewChunks: number of new chunks created
.ReusedChunks: number of chunks reused
.Datastore: datastore name
.Error: error message if any
.Hostname: hostname of the machine
.StartTime: time the backup started
.EndTime: time the backup ended
.Duration: duration of the backup
.FromattedDuration: formatted duration of the backup
.Success: a boolean telling whether the backup was successful
.Status: string representation of the backup status [SUCCESS, FAILURE]

Stream Backup

This allows backing up a stream instead of a PXAR, allows endless possibilities for example you can invoke

mysqldump yourdatabase | ./proxmoxbackupgo -backupstream yourdatabase.sql [other options]

This allows leveraging buzhash for dedup even when using tar for example, or the sql dump itself, and if someone wants to attempt it should be possible with some hack to pipe DISM command to generate WIM image to this and have full host backup

Known Issues

Windows defender antimalware being active will slow backup down up to 25% of attainable speed

There’s as of now no mechanism to prevent two instances being launched at same time which will screw up VSS and backup
If you using windows planning utility it should theoretically prevent two instances starting at same time when originating from same job

Источник

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

История

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

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

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

Установка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции:

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

Логин:

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

Хранилище

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

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

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

# proxmox-backup-manager disk list

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

# proxmox-backup-manager disk initialize sdX

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

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

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

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

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

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

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

# proxmox-backup-manager disk smart-attributes sdX

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

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

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

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

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

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

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

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

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

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

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

# proxmox-backup-manager datastore list

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

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

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

# proxmox-backup-manager datastore remove store1

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

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

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

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

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

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

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

# proxmox-backup-manager network list

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

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

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

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

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

# proxmox-backup-manager network remove bond0

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

# proxmox-backup-manager network changes

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

# proxmox-backup-manager network revert

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

# proxmox-backup-manager network reload

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

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

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

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

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

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

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

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

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

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

# proxmox-backup-manager user list

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

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

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

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

# proxmox-backup-manager user remove john@pbs

API токены

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

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

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

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

Идентификатор, состоит из имени пользователя, области и имени токена, например user@realm! Tokenname.
Его секрет, например 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

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

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

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

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

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

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

Чтобы вычислить и отобразить набор разрешений пользователя или токена, вы можете использовать подкоманду 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

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

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

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

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

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

Обрезка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уведомления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# export PBS_REPOSITORY=backup-server:store1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# cat folder/subfolder0/.pxarexclude
file3

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

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

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

Шифрование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# proxmox-backup-client snapshot list

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# umount /mnt/mountpoint

Вход и выход

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

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

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

# proxmox-backup-client logout

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

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

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

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

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

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

# proxmox-backup-client snapshot forget <snapshot>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграция с Proxmox VE

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

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

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

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

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

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

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

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

# pvesm status --storage store2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# pxar list archive.pxar

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

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

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

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

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

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

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

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

ZFS

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

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

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

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

Железо

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

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

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

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

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

# man zpool
# man zfs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С grub:

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

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

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

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

# apt-get install zfs-zed

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

ZED_EMAIL_ADDR=»root»

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

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

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

options zfs zfs_arc_max=8589934592

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

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

# update-initramfs -u

SWAP на ZFS

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

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

# sysctl -w vm.swappiness=10

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

vm.swappiness = 10

Сжатие ZFS

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

# zpool set compression=lz4 <pool>

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

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

# zfs set compression=off <dataset>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# zfs set special_small_blocks=4K <pool>

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

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

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

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

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

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

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

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

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

# update-initramfs -u -k all

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

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

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

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

Datastores

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

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

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

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

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

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

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

<datastore-root>/.chunks/

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

a342e8151cbf439ce65f3df696b54c67a114982cc0aa751f2852c2f7acc19a8b

живет в

<datastore-root>/.chunks/a342/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если понравилась статья, подпишись на мой канал в VK или Telegram.

Источник

Вступление, или очередная проблема из неоткуда

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

Синхронизация бэкапов в PBS доступна только между несколькими экземплярами самого сервера бэкапов, то есть для переноса бэкапов на другое устройство там должен быть установлен Debian с пакетом PBS. Альтернативой может являться создание хранилища данных в удаленной папке, созданной по протоколу NFS. В моем случае стояла задача восстановить исходную схему резервирования бэкапов, которая была реализована до перехода на создание бэкапы с помощью PBS, когда резервные копии также переносились на мой основной компьютер, откуда отправлялись на внешний диск.

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

1. Запустить виртуальную машину с PBS

2. Запустить PBS в Docker-контейнере

В дальнейшем я выбрал вариант запуска через Docker-контейнер, так как он для меня оказался более удобным и менее прожорливым по ресурсам (вся система Docker с запущенным PBS потребляет до 700 Мб ОЗУ). Также мне было откровенно лень разбираться с пробросом портов из виртуальной машины и еще пачкой ненужных задач. Для виртуальных машин Proxmox — ван лав. Так же данный способ подойдет для запуска на NAS.

Установка и запуск PBS в докере

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

Для установки PBS на Debian в виртуалке приведен на оффициально сайте: https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-debian

Для запуска докер в Windows необходимо установить docker desktop с официального сайта https://www.docker.com/products/docker-desktop/ для полноценной работы потребуется регистрация на докер хаб.

После установки и первого запуска попадаем в стартовое окно docker desktop которое на самом деле очень бесполезное, в дальнейшем он нам понадобиться только для администрирования контейнера.

1180883330_.png.a180ea26acf1d5b2f7efbb3d5b9a9ce0.png

В принципе этой установки должно быть достаточно, но лучше так же установить WSL если не был установлен ранее. Идем в Microsoft Store (да на удивление он все еще живой, сам в шоке) и находим там Windows Subsystem for Linux.

109690397_.png.b8f0706a6ba918cfc925a3e0aa235df7.png

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

Переходим в настройки докера и включаем запуск при старте Windows и включаем WSL2/

862523056_.png.78344cffb6efbe2c4348ba7ad361773f.png

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

Но дополнительно настроим что бы докер не съедал наши ресурсы до бесконечности, по умолчанию потребление.

Идем в основную папку пользователя: C:\Users\UserName

И создаем там файлик со следующим именем: .wslconfig

Открываем файл через любой текстовый редактор (рекомендую Notepad ++) И вставляем следующий конфиг:

[wsl2]
memory=1GB
processors=1

Данная настройка вступит в силу после перезагрузки компьютера. Таким образом мы ограничиваем работу докера что бы он мог использовать не более 1Гб озу и не более одного виртуального ядра, чего для наших задач достаточно. Отдельно отмечу что минимальный объем может быть 1Гб так как происходит округление до целых значений. Данное ограничение действует на весь WSl в целом.

Подробней о данном конфиг файле можно почитать тут: https://learn.microsoft.com/ru-ru/windows/wsl/wsl-config

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

Сам проект задумывался для того что бы запускать PBS на NAS с поддержкой докера что в принципе является не плохим решением. Подробней с ним можете ознакомиться по ссылке: https://github.com/ayufan/pve-backup-server-dockerfiles

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

Нам потребуется вот такая структура папок:

213618948_.png.be8a7ff97ddca54d8e972fc8d4893281.png

Создаем в корнейвой папке новый файл с именем docker-compose.yml и вставляем следующий конфиг:

version: '2.1'

services:
  pbs:
    image: ayufan/proxmox-backup-server:latest
    container_name: pbs
    hostname: hostName
    mem_limit: 128Mb
    environment:
      - TZ=Europe/Moscow
    volumes:
      - D:\Proxmox Backup Server\etc:/etc/proxmox-backup
      - D:\Proxmox Backup Server\logs:/var/log/proxmox-backup
      - D:\Proxmox Backup Server\lib:/var/lib/proxmox-backup
      - D:\Proxmox Backup Server\backups:/backups
    ports:
      - 8007:8007
    tmpfs:
      - /run
    restart: unless-stopped
    stop_signal: SIGHUP

Изменяем параметры volumes на свои а так же устанавливаем hostname для адекватного отображения имени хоста в интерфейсе PBS.

Сохраняем файл и открываем консоль windows.

Вводим стандартную команду запуска docker compose

docker compose up -d

1582861732_.png.3bfe602ffb192dca625bcb89a5aa8d23.png

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

Возвращаемся в окно docker desktop и видим появившийся новый контейнер и потребление выделенных ресурсов.

1059459557_.png.7bee709accdd506026499780c14d9dff.png

Фактическое потребление (зарезервировано) для системы в моем случае:

783226188_.png.c9a05069e5e5288509cb2b69190c9486.png

На это этап запуска PBS в докере закончен, приступаем к непосредственной настройке синхронизации.

Настройка нового экземпляра PBS

Заходим в веб морду нашего нового экземпляра PBS по адресу: https://<Ip-pc>:8007/

По умолчанию доступен один пользователь: admin с паролем pbspbs

Заходим в систему и приступаем к настройке.

Нам необходимо создать хранилище данных, для этого нажимаем «Добавить хранилище данных».

1412450692_.png.dc412248950a46744213d9777bedde36.png

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

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

1526387704_.png.92c3dbd7b3c1cb57d9ed33e21fc87b74.png

Следующим шагом необходимо настроить права для работы с полученным хранилищем. Идем в радел управление доступом и создаем нового пользователя:

220290977_.png.f016e61013342ae5e14952d6aad3e4db.png

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

Так же выдаем права пользователю:

1300374618_.png.a3ee2f3f8734571c82b3c26c5414d024.png

В моем примере хранилище данных называется deniom-pc.

В хранилище данных должно быть так:

1232426983_.png.4ef9f50a90c48e13394cd2c917507518.png

Настройка синхронизации между экземплярами PBS

Основные настройки будут происходить на вторичном PBS который будет вытягивать бэкапы из PBS на хосте proxmox.

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

Переходим в удаленные хранилища, и добавляем новое подключение

1232254835_.png.18dce72731155fd60c31ab91ff9eb7a2.png

Заполняем данные для авторизации на основном сервере PBS.

1647014973_.png.64f307a96297f212449fe1a817fba68e.png

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

1207597799_.png.e741ac996f7f740038660b641cade92e.png

Переходим в хранилище данных и настроим синхронизацию

1060795000_.png.3754b45056344f010359177b749d0fcc.png

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

Заключение

На этом настройка фактически завершена, на самом деле мы имеем практически полноценный экземпляр PBS.

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

Спасибо за внимание.

Изменено 10 апреля, 2024 пользователем Deniom

Источник

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

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

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

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

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

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

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

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

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

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

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

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

apt update && apt full-upgrade

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

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

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

Для Proxmox Backup Server:

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

Для Proxmox Virtual Environment:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

proxmox-backup-manager cert info | grep Fingerprint

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo nano /etc/apt/sources.list

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

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

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

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

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

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

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

sudo apt update

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

sudo apt install proxmox-backup-client

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

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

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

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

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

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

Заключение

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

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

Источник