Proxmox копирование файлов на виртуальную машину

Обновлено: 03.07.2024

ИТ компании постоянно требуются различного рода решения для резервного копирования, гарантирующие низкую стоимость владения соответствующим ПО. В данном документе приведены стратегии резервного копирования виртуальных машин на гипервизоре Proxmox с помощью Bacula Enterprise Edition 8 и плагина для Proxmox. Плагин Bacula Enterprise Edition для Proxmox позволяет восстанавливать виртуальные машины на «голое железо», включая гостевые ВМ QEMU и LXC.

Данный документ знакомит пользователя с возможностями и процедурами, которым необходимо следовать для выполнения резервного копирования ВМ на базе Proxmox и их восстановления с помощью Bacula Enterprise Edition.

Характеристики

Резервное копирование любой гостевой ВМ, включая QEMU и LXC, в режиме реального времени с использованием снапшотов.
Полное резервное копирование на уровне образа.
Возможность полного восстановления образа ВМ.
Возможность восстановления архивов ВМ QEMU (.vma) в альтернативный каталог.
Возможность восстановления архивов ВМ LXC (.tar) и конфигурирование машины в альтернативном каталоге.

Термины и выражения

1. Стратегии резервного копирования гостевых ВМ

1.1 Установка клиента Bacula на каждую гостевую машину

Первая стратегия предполагает резервное копирования ВМ без использования плагина Bacula Enterprise Edition Proxmox. Вместо него на каждую ВМ устанавливается Bacula Enterprise File Daemon как на обычный физический клиент. Чтобы оптимизировать ввод-вывод данных в системе Proxmox, необходимо использовать планировщик Bacula Schedule, приоритеты Priorities, и задать последовательность выполнения задач Job. Это позволит распределить все задачи резервного копирования в окне резервного копирования. Поскольку все гостевые ВМ используют одно и то же хранилище в гипервизоре Proxmox, запуск всех задач одновременно может привести к возникновению эффекта «бутылочного горлышка» в сети/на диске.

Установка Bacula Enterprise File Daemon на каждую ВМ позволяет управлять виртуальными серверами как физическими, а также использовать все следующие функции Bacula Enterprise:

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

2 Операции резервного копирования и восстановления

2.1 Резервное копирование

Резервное копирование одной гостевой ВМ построено на выполнении следующих шагов:

Сохранение конфигурации гостевой ВМ (для гостевых ВМ LXC).
Создание снапшота нового бэкапа (по умолчанию), приостановка или остановка гостевой ВМ.
Выполнение команды vzdump и сохранение данных.

Бэкапы можно создавать с гостевых ВМ в любом состоянии (на запущенных или остановленных ВМ). Гипервизор Proxmox автоматически создаст требуемый снапшот бэкапа и удалит его после создания самого бэкапа. Все прочие снапшоты не будут затронуты. Плагин Proxmox проинформирует вас о начале и завершении создания резервной копии гостевой:

В ходе создания бэкапа будет создан один (.vma) файл для любой гостевой ВМ QEMU и два файла (.conf and .tar) для любой гостевой ВМ LXC. Внутри Bacula это будет выглядеть следующим образом.

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

2.2 Восстановление

Плагин для Proxmox позволяет выполнять две задачи при восстановлении:

Восстанавливать ВМ на гипервизоре Proxmox в качестве новой или исходной гостевой ВМ
Восстанавливать в локальной директории архивные файлы Proxmox (.vma или два файла .tar и .conf).

2.2.1 Восстановление в Proxmox

Чтобы воспользоваться данным методом восстановления, используется команда Bacula where= параметр. Архив гостевой ВМ будет отправлен на гипервизор Proxmox и восстановлен в качестве новой гостевой ВМ, если будет назначен vmid восстанавливаемой ВМ. В противном случае, гостевая ВМ будет восстановлена с использованием исходного vmid.

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

Новые гостевые ВМ получат новые vmid. Идентификаторы можно назначать с помощью плагина Bacula Proxmox в качестве произвольных значений в диапазоне vmid+1 и +11. Эта процедура позволяет избегать возможных проблем с назначением ресурсов, которые могут возникнуть, если две или более гостевых ВМ восстанавливаются или создаются в одно и то же время, поскольку сами по себе решения Proxmox не содержат механизмов решения таких проблем.

Используя опцию восстановления плагина sequentialvmid, можно изменить процедуру назначения идентификатора так, чтобы при восстановлении новая гостевая ВМ получала бы следующий доступный vmid. Эта процедура позволит ограничить диапазон vmid’ов назначенных за определенное время. Однако, при этом, процедура одновременного восстановления станет ненадежной.

Целевое хранилище Storage, которое будет использоваться для диска(ов) восстанавливаемой гостевой ВМ, можно задать с помощью опции плагина. Если опция не задана, все диски гостевой ВМ будут восстановлены в исходное хранилище Storage.

Чтобы перечислить все доступные хранилища, можно воспользоваться режимом перечисления (смотрите раздел 6.1 на странице 12).

При выборе неправильного (несуществующего) хранилища для восстановления в процессе восстановления будет создана гостевая ВМ в хранилище гипервизора Proxmox, используемом по умолчанию.

2.2.2 Восстановление в локальный каталог

В данном режиме используется параметр Bacula where=/some/path, то есть задается полный путь к серверу, на котором установлен плагин для Proxmox. В случае отсутствия пути, он будет создан плагином Bacula Proxmox.

3 Установка

Bacula File Daemon и плагин для Proxmox необходимо устанавливать на хосте гипервизора Proxmox, который запускает гостевые ВМ, резервную копию которых необходимо создать. Proxmox использует кастомизированные дистрибутивы Debian, поэтому для данной платформы необходимо использовать Bacula Enterprise File Daemon.

3.1 Конфигурирование

Директива Plugin Directory ресурса File Daemon в /opt/bacula/etc/bacula-fd.conf должна указывать, где установлен файл proxmox-fd.so. Стандартно используется каталог /opt/bacula/plugins

3.2 Установка плагина

Установку плагина Bacula Enterprise Proxmox проще всего выполнять путем добавления файла хранилища, соответствующего существующей подписке и версии Debian, на которой разработана Proxmox. Например, /etc/apt/sources.list.d/bacula.list со следующим содержимым:

После этого необходимо выполнить обновление apt-get. Затем можно будет установить плагин с помощью:

apt-get install bacula-enterprise-proxmox-plugin

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

4 Конфигурирование плагина

Плагин конфигурируется с помощью параметров, описанных в разделе FileSets Include в файле конфигурирования службы Bacula Enterprise Edition Director.

4.1 Универсальные параметры плагина

Следующие параметры плагина для Proxmox оказывают влияние на любой тип задачи Job (резервное копирование, анализ, или восстановление).

abort_on_error[=<0 or 1>] параметр определяет, должен или не должен плагин прекращать выполнение задачи в случае возникновения критических ошибок во время резервного копирования, анализа, или восстановления. Это опциональный параметр. По умолчанию используется значение 0.

4.2 Параметры анализа и резервного копирования

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

vm=<name-label> параметр задает имя гостевой ВМ для резервного копирования. Для резервного копирования будут выбраны все гостевые ВМ с указанным параметром <name-label>. Можно задавать несколько параметров vm=. Если гостевая ВМ с параметром <name-label> не будет найдена, будет сгенерирована единичная ошибка задачи, а процесс резервного копирования переключится на следующую ВМ, если не задана команда abort_on_error, которая приводит к завершению задачи при возникновении ошибки. Это опциональный параметр.

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

mode=<snapshot|suspend|stop> параметр задает режим резервного копирования по умолчанию. В режиме снапшота будет сгенерирован «живой» бэкап с помощью снапшотов, что позволит сократить время простоя ВМ во время процедуры резервного копирования. Отложенный режим предполагает простой в работе гостевой ВМ на время резервного копирования. Гостевая ВМ будет находиться в режиме простоя во время создания бэкапа. По завершении создания бэкапа гостевой ВМ, она вновь будет запущена. В режиме остановки, до начала резервного копирования работа ВМ будет остановлена, а после завершения резервного копирования необходимо будет перезапустить ВМ.

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

vzdump_storage=<proxmox_storage> параметр указывает на хранилище Proxmox <proxmox_storage>, используемое командой vzdump во время резервного копирования, если «локальное» хранилище Proxmox не содержит доступного бэкапа. Параметр <proxmox_storage> должен указывать на хранилище Proxmox, которое содержит резервную копию с подходящим типом контента (смотрите раздел 6.2.1 на странице 13). Это опциональный параметр. Если он не задан, используется «локальное» хранилище Proxmox по умолчанию.

bwlimit=<N> параметр указывает на то, должен ли бэкап создаваться с ограничением пропускной способности ввода-вывода (в Кб/с) со стороны гипервизора. Это ограничение не зависит от ограничения пропускной способности Bacula и выполняется на другом уровне.

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

4.3 Параметры восстановления

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

storage: <storage> параметр задает хранилище Proxmox, куда будет восстановлена гостевая ВМ. Если не будет задано хранилище, тогда гостевая ВМ будет восстановлена в хранилище Proxmox Storage, из которого создавалась ее резервная копия. Если параметр указывает на несуществующее хранилище, будет использовано исходное хранилище гостевой ВМ. Это опциональный параметр.

pool: <resourcepool> параметр задает ресурс Proxmox Resource Pool, к которому будет прикреплена восстанавливаемая ВМ. Если параметр не задан, восстанавливаемая гостевая ВМ не будет содержать прикрепленного Resource Pool. Если параметр указывает на несуществующий пул, пул не будет прикреплен. Это опциональный параметр.

sequentialvmid: <yes or no> параметр задает процедуру присвоения нового VMID. Если параметру присвоено значение «yes», новая гостевая ВМ получит первый доступный VMID, исходя из максимального VMID, найденного на гипервизоре Proxmox. В противном случае, восстанавливаемая гостевая ВМ получит случайный VMID, сгенерированный в диапазоне + 10 от максимального используемого VMID, найденного на гипервизоре Proxmox. Это значение по умолчанию.

Если sequentialvmid присвоить значение «yes», то можно избежать конфликтов, которые могут возникнуть во время одновременного восстановления нескольких ВМ.

4.4 Примеры использования директивы FileSet

В примере ниже будут созданы бэкапы всех гостевых ВМ:

В примере ниже будет создан бэкап одной ВМ с именем-меткой «VM1»:

Идентичный пример с использованием vmid:

В примере ниже будут созданы бэкапы ВМ, имена которых содержат выражение «Prod».

В примере ниже будет созданы бэкапы всех гостевых ВМ за исключением тех, которые начинаются с выражения «Test».

5 Восстановление

5.1 Восстановление в гипервизор Proxmox

Чтобы восстановить ВМ или несколько ВМ в гипервизор Proxmox, администратор должен выполнить команду восстановления и задать параметр where, как указано в примере:

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

В следующем примере показано использование параметра sequentialvmid, которому присвоено значение «yes»:

Лог задачи восстановления будет указывать на то, какая гостевая ВМ восстанавливается, и какая новая ВМ создается.

Новая гостевая ВМ, создаваемая во время восстановления, получит новый VMID (если исходный VMID более недоступен) однако будут сохранены исходные имя/имя хоста.

5.2 Восстановление в локальный каталог

Можно восстановить данные гостевой ВМ в файл без передачи их в гипервизор. Чтобы выполнить такое восстановление, необходимо с помощью параметра where задать каталог:

Обратите внимание на пример ниже, приведенный для проверки восстановления ВМ в локальный каталог.

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

6 Дополнительная информация

6.1 Перечисление ресурсов

Плагин Bacula Enterprise Proxmox поддерживает новую функцию Plugin Listing Bacula Enterprise Edition 8.x и более поздних версий. Данный режим позволяет плагину отображать некоторую важную информацию о ресурсах Proxmox:

Список имен-меток гостевых ВМ,
Список VMID гостевых ВМ,
Список хранилищ Proxmox,
Список пулов ресурсов Proxmox

Новая функция использует специальную команду .ls совместно с новым параметром plugin=<plugin>. Команда требует задать следующие параметры:

client=<client> Имя клиента Bacula, на котором установлен плагин Proxmox.

plugin=<plugin> Имя плагина, в данном случае proxmox: опциональные параметры указаны в разделе 4.1 на странице 6.

path=<path> путь к объекту для отображения.

Параметр path=<path> поддерживает следующие значения:

/ для отображения типов объектов доступных для вывода списком.
vm для отображения списка имен-меток гостевых ВМ.
vmid для отображения списка VMID гостевых ВМ и указателей имен-меток.
storage для отображения списка доступных хранилищ.
pool для отображения списка пулов ресурсов.
Для отображения доступных типов объектов следуйте примеру:

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

Чтобы отобразить список VMID гостевых ВМ, используйте следующий пример:

Списки ВМ и VMID отобразят примерный размер гостевой ВМ.

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

И наконец, чтобы отобразить доступные пулы Proxmox, используйте следующий пример:

6.2 Рекомендации

6.2.1 Резервное ЗУ для Proxmox

Если вы обнаружили следующую ошибку во время выполнения задачи резервного копирования:

Необходимо проверить лог задач Proxmox на наличие следующей ошибки:

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

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

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

Исследование параметров резервного копирования Proxmox

Настройка резервного копирования

Резервное копирование файла настройки

Параметры резервного копирования Proxmox

В версии Proxmox VE 4.1 существует две опции резервного копирования в стандартной поставке:

Полное резервное копирование : Выполняет резервное копирование виртуальной машины целиком

Снимки : Осуществляется замораживание состояния ВМ на определённый момент времени

Proxmox 4.1 может выполнять только полное резервное копирование и не может выполнять никакого гранулированного резервного копирования файлов изнутри виртуальной машины. Proxmox также не применяет никаких агентов резервного копирования.

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

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

Режимы полного резервного копирования Live backup ). Так как резервное копирование происходит при работающей ВМ, нет никакого простоя для данного режима, однако это также и самое продолжительное резервное копирование. В редких случаях используемые файлы могут вызывать ошибки резервного копирования из- за блокировок файлов.

Снимки (snapshot) замораживают или захватывают текущее состояние виртуальной машины на некий момент времени. Это не полная резервная копия ВМ, так как снимки полностью зависят от оригинальной ВМ. Мы не можем перемещать снимки куда- либо ещё для сохранности. Снимки применяются для откатов к предыдущему состоянию. Так как снимки не делают резервную копию всей виртуальной машины с образами диска, это наиболее быстрый вариант резервного копирования для быстрого сохранения состояния определённой ВМ. В Proxmox мы можем делать снимки работающих ВМ; в этом случае также сохраняется и содержимое работающей оперативной памяти. Таким образом, мы можем вернуться к более ранней ВМ в точности как если бы она работала в момент выполнения снимка.

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

Полное резервное копирование никогда не следует полностью заменять на снимки. Всегда включайте полную резервную копию в стратегию первичного восстановления при катастрофе.

В Proxmox VE 4.1 нет вариантов снимков по расписанию. Все снимки должны выполняться вручную. Для сред с несколькими десятками виртуальных машин выполнение снимков вручную может стать временезатратной задачей. Можно установить расписание снимков при помощи bash , cron и qm , однако эти методы могут иметь дефекты и они известны как нестабильные; более того, они не рекомендуются для промышленных сред.

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

Настройка хранилища резервного копирования

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

Одним из наиболее популярных вариантов для хранения резервных копий является NFS. В корпоративных или критически важных средах рекомендуемой практикой является выделение для резервных копий кластера со встроенной избыточностью. В средах меньшего размера хорошая избыточность может быть достигнута при применении таких вариантов хранилищ как Gluster или DRBD. После добавления ZFS и Gluster в Proxmox VE, теперь это жизнеспособный вариант превращения узла Proxmox в узел резервного копирования с применением Gluster поверх ZFS, при том что узел всё ещё будет управляться через GUI Proxmox. < Прим. пер.: отметим, что Gluster здесь применяется исключительно для кластеризации ZFS. Это распространённый трюк о котором следует помнить. > К сожалению мы не можем сохранять файлы в хранилище Ceph RBD. < Прим. пер.: Однако, можем настроить NFS поверх CephFS. >

Для отдельного узла хранения резервных копий великолепным решением является FreeNAS без кластерной избыточности. В зависимости от того какая система хранения применяется, первичная цель состоит в хранении резервной копии на отдельном узле вместо использования вычислительного узла. Отсылаем вас к Главе 4, Системы хранения для получения информации о том, как подключать различные системы хранения к Proxmox. Когда хранилище настроено и подключено к Proxmox, нам необходимо убедиться, что тип сохраняемого содержимого настроен надлежащим образом для хранения файлов резервного копирования и количества ротаций резервных копий. Существует два варианта в блоке диалога вашего хранилища для выбора типа содержимого и определения количества ротаций резервных копий. Следующий снимок отображает блок диалога хранилища для хранилища NFS в нашем примере кластера:

Рисунок 1

В предыдущем снимке экрана мы выбрали VZDump backup file в ниспадающем списке и ввели 3 в закладке Max backups или закладке количества ротаций резервных копий. Это означает, что хранилище позволит вам сохранять файлы резервной копии и всегда будут оставаться три последние резервные копии. Более старые копии будут автоматически удаляться. Это будет происходить исключительно автоматически в процессе обработки расписания резервного копирования.

Рисунок 2

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

В зависимости от избранной стратегии резервного копирования и деловых потребностей может существовать необходимость хранить определённые периоды истории резервных копий. Proxmox допускает как автоматическое, так и ручное удаление любых выходящих за пределы требуемого исторического диапазона копий. Автоматическое удаление выполняется через определённое значение Max backups в блоке диалога резервных копий. Мы можем ввести любое численное значение в пределах от 0 до 365 в качестве Max backups . Например, наше хранилище NFS имеет значение Max backups равное 3 . Это означает, что в процессе полного резервного копирования Proxmox будет сохранять три самые новые копии каждой виртуальной машины и удалять все более старые.

Если нам нужно фиксировать резервные копии ежедневно, мы потенциально можем хранить 365 дней или значение резервных копий 1 года на любой определённый момент. Если мы делаем резервную копию каждый второй день, то это будет значение резервных копий 2 лет.

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

Все полные резервные копии находятся в формате tar

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

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

Рисунок 3

В Proxmox мы можем составлять расписание автоматизации задач резервного копирования или фиксировать резервные копии вручную для каждой виртуальной машины. Будь то резервное копирование по расписанию или вручную, и для виртуальных машин KVM, и для LXC процесс один и тот же.

Создание расписания для резервного копирования

расписания можно создавать в параметрах Backup в меню с закладками Центра данных. В последующих разделах мы подробнее рассмотрим каждый блок параметров. Параметры резервного копирования отображают перечень уже созданных расписаний Backup с параметрами для задач Add , Remove и Edit . Блок диалога расписания один и тот же для задач добавления, удаления и изменения. Мы можем кликнуть на добавление для открытия такого блока диалога, как это отображено на следующем экранном снимке:

Рисунок 4

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

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

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

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

Данный ниспадающий перечень помогает выбрать какой (какие) день или дни недели применяются для задач резервного копирования. Мы можем выбрать множество дней в этом списке. для того, чтобы создать ежедневную задачу резервного копирования, должны быть выбраны все дни в этом списке. В Proxmox VE 4.1 мы можем создавать задачи ежемесячного или годового резервного копирования.

В отличие от Day of week может быть выбран только один пункт. Невозможно выбрать множество времён для резервного копирования в различное время данного дня.

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

Этот ниспадающий перечень используется для определения того, как ВМ выбираются для резервных копирований. Существует три варианта доступные для выбора. Режим All выберет все виртуальные машины в пределах целого кластера Proxmox или узла, в зависимости от сделанного в ниспадающем списке Node . Режим Exclude selected VMs возьмёт за основу все ВМ за исключением отобранных. Include selected VMs возмёт за основу только выбранные ВМ. Допустим, мы выбрали Include selected VMs .

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

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

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

Ниже показан вариант Backup с нашей вновь созданной задачей резервного копирования в списке.

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

пятница, 14 августа 2020 г.

Proxmox Backup Server - что за зверь? (установка)

С подачи подписчика рассмотрим новый продукт от Proxmox.

На сайте Proxmox выложена 1-я бетта бэкап сервера

Анотация Мы рады объявить о выпуске первой бета-версии нашего нового сервера Proxmox Backup Server.
Это программное обеспечение для резервного копирования клиент-сервер корпоративного класса, которое выполняет резервное копирование виртуальных машин, контейнеров и физических хостов. Он специально оптимизирован для платформы Proxmox Virtual Environment и позволяет безопасно выполнять резервное копирование и репликацию ваших данных. Он обеспечивает простое управление с помощью командной строки и веб-интерфейса пользователя и находится под лицензией GNU Affero General Public License v3 (GNU AGPL, v3).
Proxmox Backup Server поддерживает инкрементное резервное копирование, дедупликацию, сжатие и шифрование с проверкой подлинности. Использование Rust поскольку язык реализации гарантирует высокую производительность, низкое использование ресурсов и безопасную высококачественную кодовую базу. Он имеет надежное шифрование на стороне клиента. Таким образом, возможно резервное копирование данных на не полностью доверенные цели.

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

Качаем образ, болваним и запускаем установку
Наблюдаем стандартное для продуктов Proxmox меню

принимаем соглашение

меню выбора диска и задания опций

выбрал ZFS

Выбрав "Advanced options" можно задать подкачку и прочие параметры

задаем региональные параметры

задаем пароль root и его email

задаем сетевые параметры

страничка подтверждения настроек

процес установки

жмем reboot

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

где ip это адрес сервера, example имя севера , domin это домин если нету домина то произвольно, local расширения к примеру ru? com, или локальные после этого перезагружаема.

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

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

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

Установим по верх Debian Proxmox Backup Server. После настройки репозиториев необходимо запустить обновления репозитория и установку самого сервера:

В команде присутствую && это означает выполнить следующе действие а -y выполнить без подтверждения

Дальше надо настроить postfix

Postfix

потребуется выбрать если у вас не настроен почтовый сервер то тогда выбираете Только локальное использование

Postfix Только локальное использование

Логин и пароль которые изначально при установки debian создавали.

Надо закомментировать в mcedit /etc/apt/sources.list.d/pbs-enterprise.list строчку так как она не даст вам обновиться в будущем

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

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

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

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

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

Читайте также: