Proxmox где лежат бэкапы

Трактат о сущности механизма бэкапов в Proxmox VE

В статье «Магия виртуализации: вводный курс в Proxmox VE» мы успешно установили на сервер гипервизор, подключили к нему хранилище, позаботились об элементарной безопасности и даже создали первую виртуальную машину. Теперь разберем как реализовать самые базовые задачи, которые приходится выполнять, чтобы всегда иметь возможность восстановить работу сервисов в случае сбоя. Штатные инструменты Proxmox позволяют не только […]

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

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

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

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

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

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

Разберем вначале механизмы сжатия:

1. Сжатие LZO. Алгоритм сжатия данных без потерь, придуманный еще в середине 90-х годов. Код был написан Маркусом Оберхеймером (реализуется в Proxmox утилитой lzop). Основной особенностью этого алгоритма является очень скоростная распаковка. Следовательно, любая резервная копия, созданная с помощью этого алгоритма, может при необходимости быть развернута за минимальное время.

2. Сжатие GZIP. При использовании этого алгоритма резервная копия будет «на лету» сжиматься утилитой GNU Zip, использующей мощный алгоритм Deflate, созданный Филом Кацем . Основной упор делается на максимальное сжатие данных, что позволяет сократить место на диске, занимаемое резервными копиями. Главным отличием от LZO является то, что процедуры компрессии/декомпреcсии занимают достаточно большое количество времени.

Режимы архивирования

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

1. Режим Snapshot (Снимок). Этот режим можно еще назвать как Live backup, поскольку для его использования не требуется останавливать работу виртуальной машины. Использование этого механизма не прерывает работу VM, но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде. В противном случае есть риск, что при необходимости экстренного восстановления, они могут дать сбой.

2. Режим Suspend (Приостановка). Виртуальная машина временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Разумеется, это вызывает простой сервера на время копирования информации, зато нет необходимости выключения/включения виртуальной машины, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Тем не менее такие резервные копии также следует разворачивать в тестовой среде для проверки.

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

Выполнение процедуры резервирования

Для создания резервной копии:

1. Переходим на нужную виртуальную машину.
2. Выбираем пункт Резервирование.
3. Нажимаем кнопку Резервировать сейчас. Откроется окно, в котором можно будет выбрать параметры будущей резервной копии.

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

Теперь созданные архивы с резервными копиями виртуальных машин станут доступны для скачивания с сервера. Самым простым и банальным способом копирования является SFTP. Для этого воспользуйтесь популярным кроссплатформенным FTP-клиентом FileZilla, который умеет работать по SFTP-протоколу.

1. В поле Хост вводим IP-адрес нашего сервера виртуализации, в поле Имя пользователя вводим root, в поле Пароль — тот, который был выбран при установке, а в поле Порт указываем «22» (либо любой другой порт, который был задан для SSH-подключений).

2. Нажимаем кнопку Быстрое соединение и, если все данные были введены правильно, то в активной панели Вы увидите все файлы, расположенные на сервере.

3. Переходим в директорию /mnt/storage. Все создаваемые резервные копии будут лежать в поддиректории «dump». Они будут иметь вид:

• vzdump-qemu-номер_машины-дата-время.vma.gz в случае выбора метода сжатия GZIP;
• vzdump-qemu-номер_машины-дата-время.vma.lzo для использования метода LZO.

Резервные копии рекомендуется сразу скачивать с сервера и сохранять в надежном месте, например, в нашем облачном хранилище. Если распаковать файл с разрешением vma, одноименной утилитой, идущей в комплекте с Proxmox, то внутри будут файлы с расширениями raw, conf и fw. В этих файлах содержится следующее:

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

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

1. Открываем хранилище, на котором лежит резервная копия.
2. Переходим на вкладку Содержимое.
3. Выбираем нужную копию и нажимаем кнопку Восстановление.

4. Указываем целевое хранилище и ID, который будет присвоен машине, после завершения процесса.
5. Нажимаем кнопку Восстановление.

Как только восстановление завершится, VM появится в списке доступных.

Клонирование виртуальной машины

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

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

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

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

Кстати, Selectel предоставляет всем своим клиентам услугу размещения любого количества доменов на NS-серверах бесплатно. Управление записями осуществляется как с помощью нашей панели управления, так и с помощью специального API. Подробнее об этом читайте в нашей базе знаний.

Клонирование VM в Proxmox является очень простой задачей. Для ее выполнения необходимо выполнить следующие действия:

1. Перейти на нужную нам машину.
2. Выбрать из меню More пункт Clone.
3. В открывшемся окне заполнить параметр Имя.

4. Выполнить клонирование нажатием кнопки Clone.

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

Форматы виртуальных накопителей

Расскажем подробнее об используемых в Proxmox форматах накопителей:

1. RAW. Самый понятный и простой формат. Это файл с данными жесткого диска «байт в байт» без сжатия или оптимизации. Это очень удобный формат, поскольку его легко смонтировать стандартной командой mount в любой linux-системе. Более того это самый быстрый «тип» накопителя, так как гипервизору не нужно его никак обрабатывать.

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

2. QEMU image format (qcow2). Пожалуй, самый универсальный формат для выполнения любых задач. Его преимущество в том, что файл с данными будет содержать только реально занятое место внутри виртуальной машины. Например, если было выделено 40 Гб места, а реально было занято только 2 Гб, то все остальное место будет доступно для других VM. Это очень актуально в условиях экономии дискового пространства.

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

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

3. VMware image format (vmdk). Этот формат является «родным» для гипервизора VMware vSphere и был включен в Proxmox для совместимости. Он позволяет выполнить миграцию виртуальной машины VMware в инфраструктуру Proxmox.

Использование vmdk на постоянной основе не рекомендуется, данный формат самый медленный в Proxmox, поэтому он годится лишь для выполнения миграции, не более. Вероятно в обозримом будущем этот недостаток будет устранен.

Работа с образами дисков

В комплекте c Proxmox есть очень удобная утилита, под названием qemu-img. Одной из ее функций является конвертирование образов виртуальных дисков. Чтобы воспользоваться им, достаточно открыть консоль гипервизора и выполнить команду в формате:

qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2

В приведенном примере, vmdk-образ виртуального накопителя VMware под названием test будет преобразован в формат qcow2. Это очень полезная команда, когда требуется исправить ошибку при изначальном выборе формата.

Благодаря этой же команде можно принудительно создать нужный образ, используя аргумент create:

qemu-img create -f raw test.raw 40G

Такая команда создаст образ test в формате RAW, размером 40 Гб. Теперь он годится для подключения к любой из виртуальных машин.

Изменение размера виртуального диска

И в заключение покажем как увеличить размер образа диска, если по каким-то причинам места на нем перестало хватать. Для этого воспользуемся аргументом resize:

qemu-img resize -f raw test.raw 80G

Теперь наш образ стал размером 80 Гб. Посмотреть подробную информацию об образе можно с помощью аргумента info:

qemu-img info test.raw

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

resize2fs /dev/sda1

где /dev/sda1 — нужный раздел.

Автоматизация создания резервных копий

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

1. Используя веб-интерфейс гипервизора, открываем пункт Датацентр.
2. Выбираем пункт Резервирование.
3. Нажимаем кнопку Добавить.
4. Задаем параметры для планировщика.

5. Отмечаем галочкой пункт Включить.
6. Сохраняем изменения, используя кнопку Создать.

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

Заключение

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

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

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

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

Где лежат образы виртуальных машин на Proxmox?

Добрый день. Достались мне по гос контракте сервера от поставщика с виртуальными машинами на proxmox.
В админке вижу созданы 2 storage:
local, тип Directory, содержимое backup
iso и pve тип LVM, содержимое images.
Стоит 2 параллельные задачи:
1- Хочу перенести виртуальные машины с proxmox на vmware, не могу найти где на сервере лежат образы машин в raw формате, что бы с конвертировать его в формат vmware.
2 — Хочу перенести виртуальные машины на другой сервер, поднял на нем proxmox, скопировал в папку /var/lib/vz/dump образы бэкапов, в админке их не вижу. Как можно их восстановить на новом сервере?

• Вопрос задан более трёх лет назад
• 41875 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 3

Ушел на http://ru.stackoverflow.com/

1) /var/lib/vz/images/ ,если не указано другое, вообще можно посмотреть через веб морду Датацентр-Хранилище. RAW формата может и не быть, все машины могут лежать в более современном qcow2, тогда сначала конввертим в raw, затем в vmware.
2) Вы не указали, что бэкапы должны лежать там, заходим в Датацентр-Хранилище, открываем на изменение local, там выделяем поле . backup.

P.S. Я так понимаю, что цену на vmware вы уже видели, согласовали с руководством и оно готово заплатить кучу денег за ваше неумение пользоваться открытыми инструментами, Proxmox в ровных руках ничем не хуже, а в ситуации, когда много контейнеров даже лучше продуктов vmware, в чем смысл перехода, если и так все работает?

Ответ написан более трёх лет назад
Комментировать
Нравится 5 Комментировать
Netker @Netker Автор вопроса

1)Смотрел /var/lib/vz/ через mc, папки images нет.
В веб-морде такая настройка:

2) Спасибо, именно эту отметку пропустил. Восстановил виртуальную машину на новом сервере Proxmox VE 3.4, до этого виртуальная машина крутилась на более старом Proxmox-е 2.6.32.-16.
При запуске востановленной виртуальной машины выходит ошибка:

kvm: -drive file=/var/lib/vz/images/102/vm-102-disk-1.raw,if=none,id=drive-virtio0,format=raw,aio=native,cache=none,detect-zeroes=on: file system may not support O_DIRECT kvm: -drive file=/var/lib/vz/images/102/vm-102-disk-1.raw,if=none,id=drive-virtio0,format=raw,aio=native,cache=none,detect-zeroes=on: could not open disk image /var/lib/vz/images/102/vm-102-disk-1.raw: Could not open '/var/lib/vz/images/102/vm-102-disk-1.raw': Invalid argument TASK ERROR: start failed: command '/usr/bin/kvm -id 102 -chardev 'socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -vnc unix:/var/run/qemu-server/102.vnc,x509,password -pidfile /var/run/qemu-server/102.pid -daemonize -name IPA-CentOS-6.3-x64 -smp '2,sockets=1,cores=2,maxcpus=2' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000' -vga cirrus -cpu kvm64,+lahf_lm,+x2apic,+sep -m 4096 -k en-us -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:2abbc53a20a0' -drive 'file=/var/lib/vz/images/102/vm-102-disk-1.raw,if=none,id=drive-virtio0,format=raw,aio=native,cache=none,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'rtl8139,mac=6E:0D:E8:9B:99:16,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300'' failed: exit code 1

Не могу понять на что ругается.

P.S. На vmware цены смотрел. Я только начал заниматься визуализацией, и еще не знаю что выбрать.

И еще вопрос, когда в proxmox добавляю раздел LVM поле «Группа разделов» пустая, где её нужно заполнить?

PVE/Backup Server

Proxmox Backup Server (PBS) — клиент-серверное решение для резервного копирования и восстановления виртуальных машин, контейнеров и физических узлов. Решение оптимизировано для проекта PVE и позволяет безопасно создавать резервные копии. Поддерживается инкрементное резервное копирование с полной дедупликацией, что значительно снижает нагрузку на сеть и экономит пространство для хранения.

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

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

• 1 Установка
  • 1.1 Установка сервера
  • 1.2 Установка клиента
  • 3.1 Управление дисками
  • 3.2 Хранилище данных
    • 3.2.1 Создание хранилища данных
    • 3.2.2 Управление хранилищами данных
    • 4.1 Управление пользователями
    • 4.2 API-токены
    • 4.3 Контроль доступа
    • 4.4 Двухфакторная аутентификация
    • 6.1 Создание резервной копии
      • 6.1.1 Шифрование

      Установка

      Установка сервера

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

      • CPU: 64bit (x86-64 или AMD64), 2+ Ядра
      • ОЗУ: 2 ГБ
      • Диск: от 8 ГБ
      • Сеть: 1 интерфейс

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

      • CPU: 64bit, 4 Ядра
      • ОЗУ: 4 ГБ (+1 ГБ на каждый ТБ дискового пространства)
      • Диск: от 32 ГБ + резервное хранилище
      • Сеть: 1 интерфейс + резервирование

      Примечание: Не рекомендуется устанавливать сервер резервного копирования непосредственно на гипервизор. Безопаснее использовать отдельный физический сервер для хранения резервных копий.

      Установить сервер PBS можно следующей командой:

      # apt-get install proxmox-backup-server 

      Запустить и добавить в автозагрузку Proxmox Backup API Proxy Server:

      # systemctl enable --now proxmox-backup-proxy.service 

      Служба proxmox-backup-proxy предоставляет API Proxmox Backup Server через TCP-порт 8007 с использованием HTTPS. Она имеет весьма ограниченные разрешения. Операции, требующие дополнительных разрешений, перенаправляются в локальную службу proxmox-backup.

      Служба proxmox-backup предоставляет API управления Proxmox Backup Server по адресу 127.0.0.1:82. Она имеет разрешение на выполнение всех привилегированных операций.

      Примечание: Для работы с локальным ZFS хранилищем должен быть установлен модуль ядра с поддержкой ZFS (например, kernel-modules-zfs-std-def).

      Включить модуль можно следующей командой:

      # modprobe zfs 

      Чтобы не вводить эту команду после перезагрузки, следует раскомментировать строку:

      в файле /etc/modules-load.d/zfs.conf .

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

      Установить клиент PBS:

      # apt-get install proxmox-backup-client 

      Веб-интерфейс

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

      Веб-интерфейс PBS доступен по адресу https://:8007. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки).

      

      

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

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

      Увидеть диски, подключенные к системе, можно в веб-интерфейсе «Управление» → «Storage/Disks» («Хранилище/Диски»):

      

      Также можно воспользоваться командой:

      # proxmox-backup-manager disk list ┌─────────┬────────────┬─────┬───────────┬─────────────┬──────────────────────┬─────────┬─────────┐ │ name │ used │ gpt │ disk-type │ size │ model │ wearout │ status │ ╞═════════╪════════════╪═════╪═══════════╪═════════════╪══════════════════════╪═════════╪═════════╡ │ nvme0n1 │ zfs │ 1 │ ssd │ 21474836480 │ ORCL-VBOX-NVME-VER12 │ 0.00 % │ passed │ ├─────────┼────────────┼─────┼───────────┼─────────────┼──────────────────────┼─────────┼─────────┤ │ nvme0n2 │ zfs │ 1 │ ssd │ 21474836480 │ ORCL-VBOX-NVME-VER12 │ 0.00 % │ passed │ ├─────────┼────────────┼─────┼───────────┼─────────────┼──────────────────────┼─────────┼─────────┤ │ sda │ mounted │ 0 │ ssd │120034123776 │ GOODRAM │ 0.00 % │ passed │ ├─────────┼────────────┼─────┼───────────┼─────────────┼──────────────────────┼─────────┼─────────┤ │ sdb │ partitions │ 0 │ hdd │ 62914560000 │ USB_DISK_2.0 │ - │ unknown │ └─────────┴────────────┴─────┴───────────┴─────────────┴──────────────────────┴─────────┴─────────┘

      Создание файловой системы ext4 или xfs на диске в веб-интерфейсе:

      

      Пример создания файловой системы в командной строке (будет создана файловая система ext4 и хранилище данных на диске nvme0n3, хранилище данных будет создано по адресу /mnt/datastore/store2 ):

      # proxmox-backup-manager disk fs create store2 --disk nvme0n3 --filesystem ext4 --add-datastore true create datastore 'store2' on disk nvme0n3 Chunkstore create: 1% Chunkstore create: 2% … Chunkstore create: 99% TASK OK

      Для создания zpool в веб-интерфейсе, следует в разделе «Storage/Disks» перейти на вкладку «ZFS» и нажать кнопку «Создать: ZFS». В открывшемся окне следует задать параметры zpool: имя хранилища, выбрать диски, уровень RAID и нажать кнопку «OK»:

      

      Команда для создания зеркального zpool с использованием двух дисков и монтированием в /mnt/datastore/zfs_st :

      # proxmox-backup-manager disk zpool create zfs_st --devices nvme0n1,nvme0n2 --raidlevel mirror 

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

      # proxmox-backup-manager disk smart-attributes sdX 

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

      Хранилище данных — это место, где хранятся резервные копии. Текущая реализация PBS использует каталог внутри стандартной файловой системы (ext4, xfs или zfs) для хранения данных резервного копирования. Информация о конфигурации для хранилищ данных хранится в файле /etc/proxmox-backup/datastore.cfg .

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

      Создание хранилища данных

      Для создания хранилища в веб-интерфейсе, необходимо нажать кнопку «Add Datastore» («Добавить хранилище данных») в боковом меню в разделе «Datastore». В открывшемся окне необходимо указать:

      • «Имя» — название хранилища данных;
      • «Backing Path» — путь к каталогу, в котором будет создано хранилище данных;
      • «GC Schedule» — частота, с которой запускается сборка мусора;
      • «Prune Schedule» — частота, с которой происходит обрезка;
      • «Prune Options» — количество резервных копий, которые необходимо хранить.

      

      Создание хранилища данных в консоли:

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

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

      # ls -arilh /mnt/backup/disk1/ итого 1,1M 665243 -rw-r--r-- 1 backup backup 0 мар 31 14:05 .lock 665242 drwxr-x--- 1 backup backup 1,1M мар 31 14:05 .chunks 665240 drwxr-xr-x 3 root root 4,0K мар 31 13:56 .. 665241 drwxr-xr-x 3 backup backup 4,0K мар 31 14:05

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

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

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

      # proxmox-backup-manager datastore list 

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

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

      # proxmox-backup-manager datastore show store1 

      Удалить хранилище данных:

      # proxmox-backup-manager datastore remove store1 

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

      Пользователи

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

      PBS поддерживает следующие области (методы) аутентификации:

      • pam — cтандартная аутентификация Linux PAM (Linux PAM standart authentication). При использовании этой аутентификации системный пользователь должен существовать (должен быть создан, например, с помощью команды adduser). Пользователь аутентифицируется с помощью своего обычного системного пароля;
      • pbs — аутентификация Proxmox Backup Server. Хэшированные пароли хранятся в файле /etc/proxmox-backup/shadow.json .

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

      Для добавления пользователя в веб-интерфейсе, следует в веб-интерфейсе перейти в раздел «Конфигурация» → «Access Control» («Контроль доступа») и на вкладке «Управление пользователями» нажать кнопку «Добавить»:

      

      

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

      просмотреть список пользователей:

      # proxmox-backup-manager user list ┌──────────────┬────────┬────────┬───────────┬──────────┬───────┬───────────┐ │ userid │ enable │ expire │ firstname │ lastname │ email │ comment │ ╞══════════════╪════════╪════════╪═══════════╪══════════╪═══════╪═══════════╡ │ backup_u@pbs │ 1 │ never │ │ │ │ │ ├──────────────┼────────┼────────┼───────────┼──────────┼───────┼───────────┤ │ root@pam │ 1 │ never │ │ │ │ Superuser │ └──────────────┴────────┴────────┴───────────┴──────────┴───────┴───────────┘

      # proxmox-backup-manager user create backup_u@pbs --email backup_u@test.alt 

      # proxmox-backup-manager user update backup_u@pbs --firstname Дмитрий --lastname Иванов 

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

      # proxmox-backup-manager user remove backup_u@pbs 

      API-токены

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

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

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

      API-токен состоит из двух частей: идентификатора, состоящего из имени пользователя, области и имени токена (user@realm!имя токена), и секретного значения.

      Генерация API-токена в веб-интерфейсе:

      

      

      Генерация API-токена в консоли:

      # proxmox-backup-manager user generate-token backup_u@pbs client1 Result:

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

      Контроль доступа

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

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

      Информация о правах доступа хранится в файле /etc/proxmox-backup/acl.cfg . Файл содержит 5 полей, разделенных двоеточием (‘:’):

      acl:1:/datastore:backup_u@pbs!client1:DatastoreAdmin

      Добавление разрешения в веб-интерфейсе:

      

      Добавление разрешения в консоли (добавить пользователя backup_u@pbs в качестве администратора хранилища данных для хранилища данных store1, расположенного в /mnt/backup/disk1/store1 ):

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

      Вывести список разрешений:

      # proxmox-backup-manager acl list 

      Отобразить действующий набор разрешений пользователя или API-токена:

      # proxmox-backup-manager user permissions backup_u@pbs --path /datastore/store1 Privileges with (*) have the propagate flag set Path: /datastore/store1 - Datastore.Audit (*) - Datastore.Backup (*) - Datastore.Modify (*) - Datastore.Prune (*) - Datastore.Read (*) - Datastore.Verify (*)

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

      Двухфакторная аутентификация реализована только для веб-интерфейса.

      

      Proxmox Backup Server поддерживает три метода двухфакторной аутентификации:

      • TOTP (Time-based One-Time Password) — для создания этого кода используется алгоритм одноразового пароля с учетом времени входа в систему (код меняется каждые 30 секунд). Настройка аутентификации TOTP: Использование TOTP при аутентификации пользователя:
      • WebAuthn (веб-аутентификация) — реализуется с помощью различных устройств безопасности, таких как аппаратные ключи или доверенные платформенные модули (TPM). Для работы веб-аутентификации необходим сертификат HTTPS;
      • Одноразовые ключи восстановления — список ключей, каждый из которых можно использовать только один раз. В каждый момент времени у пользователя может быть только один набор одноразовых ключей. Создание набора ключей: Использование Recovery Key при аутентификации пользователя:

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

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

      Информация о конфигурации удалённых PBS хранится в файле /etc/proxmox-backup/remote.cfg .

      Для добавления удалённого PBS в веб-интерфейсе следует перейти в раздел «Конфигурация» → «Remotes» и нажать кнопку «Добавить»:

      

      Примечание: Отпечаток TLS-сертификата можно получить в веб-интерфейсе удалённого PBS:

      

      Или в командной строке:

      # proxmox-backup-manager cert info | grep Fingerprint 

      Управление удалёнными PBS в консоли:

      добавить удалённый PBS:

      # proxmox-backup-manager remote create pbs2 --host pbs2.test.alt --userid root@pam --password 'SECRET' --fingerprint 42:5d:ff:3a:50:38:53:5a:9b:f7:50. ab:1b 

      # proxmox-backup-manager remote list 

      # proxmox-backup-manager remote remove pbs2 

      Для настройки задачи синхронизации необходимо перейти в разделе «Datastore» на вкладку «Sync Jobs» и нажать кнопку «Добавить»:

      

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

      добавить удалённый PBS:

      # proxmox-backup-manager sync-job create test_job --remote pbs2 --remote-store remotestore --store zfs_st --schedule 'Sat 18:15' 

      # proxmox-backup-manager sync-job list 

      # proxmox-backup-manager sync-job update test_job --comment 'offsite' 

      # proxmox-backup-manager sync-job remove test_job 

      После создания задания синхронизации оно будет запускаться по заданному расписанию, также его можно запустить вручную из веб-интерфейса (кнопка «Run now»).

      Клиент резервного копирования

      Клиент резервного копирования использует следующий формат для указания репозитория хранилища данных на сервере резервного копирования (где имя пользователя указывается в виде user@realm):

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

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

      Указать репозиторий можно, передав его в параметре —repository, или установив переменную среды PBS_REPOSITORY, например:

      # export PBS_REPOSITORY=pbs.test.alt:store1 

      Примеры репозиториев

      Пример	Пользователь	Хост:Порт	Хранилище
      store1	root@pam	localhost:8007	store1
      pbs.test.alt:store1	root@pam	pbs.test.alt:8007	store1
      backup_u@pbs@pbs.test.alt:store1	backup_u@pbs	pbs.test.alt:8007	store1
      backup_u@pbs!client1@pbs.test.alt:store1	backup_u@pbs!client1	pbs.test.alt:8007	store1
      192.168.0.123:1234:store1	root@pam	192.168.0.123:1234	store1

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

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

      Создать резевную копию домашнего каталога пользователя user (будет создан архив user.pxar):

      $ proxmox-backup-client backup user.pxar:/home/user/ --repository store1 Password for "root@pam": ****** Starting backup: host/pbs/2022-04-01T14:11:27Z Client name: pbs Starting backup protocol: Fri Apr 1 16:11:29 2022 fingerprint: 42:5d:29:20:72:56:18:66:bb:ba:85:fb:7f:0b:11:99:91:a0:ea:5f:a2:55:d1:be:bc:c0:c0:a9:9b:b1:a8:1b Are you sure you want to continue connecting? (y/n): y No previous manifest available. Upload directory '/home/user/' to 'store1' as user.pxar.didx user.pxar: had to backup 98.346 MiB of 98.346 MiB (compressed 21.303 MiB) in 3.65s user.pxar: average backup speed: 26.951 MiB/s Uploaded backup catalog (151.103 KiB) Duration: 6.95s End Time: Fri Apr 1 16:11:36 2022

      Распространенными типами архивов являются .pxar для файловых архивов и .img для образов блочных устройств.

      Команда создания резервной копии блочного устройства:

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

      Шифрование

      PBS поддерживает шифрование на стороне клиента с помощью AES-256 в режиме GCM.

      Создать ключ шифрования:

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

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

      $ proxmox-backup-client backup user_s.pxar:/home/user/ --repository store1 --keyfile ./my-backup.key Password for "root@pam": *** Starting backup: host/pbs/2022-04-01T14:25:29Z Client name: pbs Starting backup protocol: Fri Apr 1 16:25:31 2022 Using encryption key from './my-backup.key'.. Encryption Key Password: ****** Encryption key fingerprint: b9:7d:0d:6d:51:e6:12:d6 Downloading previous manifest (Fri Apr 1 16:11:27 2022) Upload directory '/home/user/' to 'store1' as user_s.pxar.didx user_s.pxar: had to backup 98.346 MiB of 98.346 MiB (compressed 21.292 MiB) in 1.66s user_s.pxar: average backup speed: 59.289 MiB/s Uploaded backup catalog (151.104 KiB) Duration: 7.44s End Time: Fri Apr 1 16:25:38 2022

      Содержимое хранилища store1:

      

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

      Список всех снимков на сервере:

      $ proxmox-backup-client snapshot list --repository pbs.test.alt:store1 Password for "root@pam": *** ┌───────────────────────────────────┬─────────────┬──────────────────────────────────────┐ │ snapshot │ size │ files │ ╞═══════════════════════════════════╪═════════════╪══════════════════════════════════════╡ │ host/host-01/2022-04-28T12:27:01Z │ 667.147 MiB │ catalog.pcat1 index.json user.pxar │ ├───────────────────────────────────┼─────────────┼──────────────────────────────────────┤ │ host/host-01/2022-04-28T12:33:04Z │ 667.148 MiB │ catalog.pcat1 index.json user_s.pxar │ ├───────────────────────────────────┼─────────────┼──────────────────────────────────────┤ │ host/pbs/2022-04-01T14:11:27Z │ 98.494 MiB │ catalog.pcat1 index.json user.pxar │ ├───────────────────────────────────┼─────────────┼──────────────────────────────────────┤ │ host/pbs/2022-04-01T14:25:29Z │ 98.494 MiB │ catalog.pcat1 index.json user_s.pxar │ └───────────────────────────────────┴─────────────┴──────────────────────────────────────┘

      Просмотреть содержимое снимка:

      $ proxmox-backup-client catalog dump host/pbs/2022-04-01T14:11:27Z --repository pbs.test.alt:store1 

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

      $ proxmox-backup-client restore host/pbs/2022-04-01T14:11:27Z user.pxar /target/path/ --repository pbs.test.alt:store1 

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

      $ proxmox-backup-client restore host/pbs/2022-04-01T14:11:27Z index.json - --repository pbs.test.alt:store1 

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

      $ proxmox-backup-client catalog shell host/host-01/2022-04-28T12:27:01Z user.pxar --repository pbs.test.alt:store1 Starting interactive shell pxar:/ > ls …

      Пример поиска в содержимом архива и восстановление данных:

      pxar:/ > find *.txt --select /test/connection_trace.txt /Рабочий стол/1.txt pxar:/ > list-selected /test/connection_trace.txt /Рабочий стол/1.txt pxar:/ > restore-selected /home/user/restore/ pxar:/ > restore /home/user/conf/ --pattern *.conf pxar:/ > exit

      • find *.txt —select — найти все файлы с расширением .txt и добавить соответствующие шаблоны в список для последующего восстановления;
      • list-selected — вывести шаблоны на экран;
      • restore-selected /home/user/restore/ — восстановить все файлы в архиве, соответствующие шаблонам в /home/user/restore/ на локальном хосте;
      • restore /home/user/conf/ —pattern *.conf — восстановить все файлы с расширением .conf в /home/user/conf/ на локальном хосте.

      Вход и выход

      При первой попытке получить доступ к серверу с использованием команды proxmox-backup-client , потребуется ввести пароль пользователя. Сервер проверяет учётные данные и отправляет билет, действительный в течение двух часов. Клиент использует этот билет для последующих запросов к этому серверу.

      Можно вручную инициировать вход/выход. Команда входа:

      $ proxmox-backup-client login --repository pbs.test.alt:store1 Password for "root@pam": ******

      $ proxmox-backup-client logout --repository pbs.test.alt:store1 

      Интеграция с PVE

      Proxmox Backup Server можно интегрировать в автономную или кластерную установку PVE, добавив его в качестве хранилища в PVE.

      Для создания нового хранилища типа «Proxmox Backup Server» необходимо выбрать «Датацентр» → «Хранилище», нажать кнопку «Добавить» и в выпадающем меню выбрать пункт «Proxmox Backup Server»:

      

      Диалог создания хранилища pbs_backup типа «Proxmox Backup Server» для хранения резервных копий:

      

      Примечание: Отпечаток TLS-сертификата можно получить в веб-интерфейсе сервера резервного копирования:

      

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

      # proxmox-backup-manager cert info | grep Fingerprint Fingerprint (sha256): c8:26:af:4a:c3:dc:60:72:4a:0b:4d:c1:e6:58:02:62:90:39:cb:fc:75:5d:00:9a:57:ca:3d:28:a0:2c:99:a5

      Добавление хранилища в командной строке:

      # pvesm add pbs pbs_backup --server pbs.test.alt --datastore store2 --fingerprint c8:26:af:4a:c3:dc:60:72. 99:a5 --username root@pam --password 

      Просмотреть состояние хранилища:

      # pvesm status --storage pbs_backup Name Type Status Total Used Available % pbs_backup pbs active 30786448 3097752 26099504 10.06%

      Добавив хранилище данных типа «Proxmox Backup Server» в PVE, можно создавать резервные копии ВМ и контейнеров в это хранилище так же, как и в любые другие хранилища (см. Резервное копирование и восстановление).

      Резервная копия ВМ:

      

      Бэкап и восстановление гипервизора

      

      Здравствуйте. Заниматься proxmox только начал. Поставили задачу снятия бэкапа с именно системы (не с ВМ или контейнеров). Чтобы потом, «если что», можно было снова развернуть гипервизор со всеми настройками (при условии, что с ВМ и контейнерами всё в порядке). Всё работает на lvm. ВМ, контейнеры и их образа установочные, лежат на сториджах в виде отдельных дисков (подключались как директории). Тушить систему — нельзя. Иначе бы тупо снял имидж с диска тем же dd.

      Принцип работ себе представляю. Но — образно. =(( Снять снапшот с рабочей системы. Примонтировать внешний диск. Упаковать и перекинуть на внешний диск. Отмонтировать диск. Удалить снапшот. Это — только как сделать бэкап. А, вот, как потом его развернуть, увы.

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

      За рабочую методику с разъяснениями готов поощрить финансово. По договорённости. Возможно, здесь это не принято. Но, своими силами этот вопрос я не решу. А всё, что находил в сети, мало понятно. Спасибо.

      Метки темы

      

      Присоединился: 3 года назад
      New Member
      10.01.2021 20:51

      Получилось у вас задуманное сделать?

      У меня ситуация немного хуже. Умер 1сник который на proxmox в виртуалку поставил win2008 server. Я к этому отношения до этого не имел, но теперь пытаюсь все ниточки собрать воедино.

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

      

      (@spoonlight)
      Присоединился: 4 года назад
      New Member
      11.01.2021 08:08

      Как Вам уже ответил хозяин форума, по факту имеем дебиан, который тупо можно копировать файлами. Или вообще сделать dd диска. Но, у меня была задача от руководителя. =) А задачи — не обсуждаются. =))) Кто девушку заказывает — тот ее и танцует. =)))

      Всё решение состоит из 2 частей. Общий бэкап системы (делается 1 раз). И, ежедневный бэкап папок с настройками гипервизора (его здесь не указываю, делается архивированием папок /etc и /root через скрипт, и задание потом в cron).

      1.
      1.1 Тушим proxmox, грузимся с образа clonezilla (в принципе, можно любой никс-загрузочный образ. Но, этот выбран был из-за скорости работы и его уже изначальной наполненности программами. Пытались сделать бэкап по пошаговому мастеру — вышло очень коряво. А предлагаемый хозяином форума Veeam у нас не завёлся сразу, разбираться не стали). В процессе загрузки последовательно по меню уходим в терминал.

      # sudo su (Все действия под рутом.)

      1.2 Смотрим, какое имя у диска, который будем монтировать под бэкап

      # lsblk -l (список дисков в системе. Proxmox, скорее всего, будет на sda)

      1.3 Монтируем диск в удобную папку.

      1.4 Копируем всё sda, упаковываем архиватором и кладём по нужному пути примонтированного диска для бэкапов (здесь в папку /mnt. Имена сами придумаете для файлов. В настройках 7zip, здесь это 7za, ключ -р это пароль. В данном случае пароль 1234):
      # partclone.dd -s /dev/sda1 | 7za -si -p1234 a /mnt/pack-sda1.7z
      # partclone.dd -s /dev/sda2 | 7za -si -p1234 a /mnt/pack-sda2.7z
      # partclone.dd -s /dev/pve/root | 7za -si -p1234 a /mnt/pack-root.7z

      Т.к., всё это собиралось уже пол года назад, немного не уверен в последней команде. Кажется, /dev/pve/root находится на sda3. В принципе, можно целиком его заархивировать. Требует проверки, давно делал.

      1.5 Снимаем информацию по структуре диска sda и его разделов и кладём в файл, который потом можно легко просмотреть:
      # sfdisk -d /dev/sda > /mnt/bckp-pve.struct

      2. При выходе из строя диска с гипервизором — подсовываем новый и разворачиваем наши архивы в обратной последовательности на пустой диск, так же загрузившись с clonezilla или с любого live-DVD от дебиан-подобного дистра. Все действия под root.

      # 7za -so -p12341 x /mnt/pck-sda1.7z | partclone.dd -o /dev/sda1
      # 7za -so -p1234 x /mnt/pck-sda2.7z | partclone.dd -o /dev/sda2
      # 7za -so -p1234 x /mnt/pck-root.7z | partclone.dd -o /dev/pve/root

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

      Тогда грузимся либо с деб-лив-двд, либо с установочного дистра proxmox (здесь в Rescue boot). И выполняем две команды:

      # update-grub
      # grub-install /dev/sda

      Перегружаемся. (Взято отсюда: pve.proxmox.com/wiki/Recover_From_Grub_Failure)

      Вопрос целесообразности подобного действа — риторический. Спрашивал у импортных пользователей, кто уже давно на proxmox-е «съел собаку» — так же ставили квадратные глаза «а зачем?» Как было объяснено мне (повторюсь: обсуждать подобное было, не то что бы, нельзя. Но — бессмысленно), подобный процесс защищает от выхода из строя гипервизора, который «лежит» в забугорье. Мол, кто их там знает, как быстро они там среагируют на проблему, и, вообще, не известно, как у них реализована поддержка пользователей (бэкапирование, зеркалирование). А у нас уже есть готовый набор для разворачивания. В целом же, да. Можно просто сохранить настройки гипера и сами виртуалки с контейнерами. А потом накатить новый гипер и восстановить настройки с ВМ.

      Похожие публикации:

      1. Stackoverflow что с сайтом
      2. Как отключить турбо буст на процессоре
      3. Как скопировать только один столбец в пдф
      4. Как удалить линию в колонтитуле в ворде