company_banner

Инкрементальный бэкап в Proxmox VE с помощью VBR


    В одной из предыдущих статей цикла про гипервизор Proxmox VE мы уже рассказывали, как выполнять бэкап штатными средствами. Сегодня покажем, как для этих же целей использовать отличный инструмент Veeam® Backup&Replication™ 10.

    «Бэкапы имеют явную квантовую сущность. До тех пор, пока ты не попытался восстановиться из бэкапа, он находится в суперпозиции. Он одновременно успешный и нет». (найдено на просторах интернета)

    Дисклеймер:
    Эта статья — вольный и расширенный перевод на тему гайда, опубликованного на форуме Veeam. Если действовать строго по оригинальному гайду, то даже на первом этапе установки pve-заголовков вы получите ошибку, т.к. система просто не будет знать где их брать. Неочевидных моментов там предостаточно.

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

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

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

    Часто бывает, что о необходимости бэкапа и выборе инструмента задумываются только после уже случившегося ЧП, связанного с потерей критичных данных. По мере развития технологий виртуализации приложения для резервного копирования стали ориентироваться на тесное взаимодействие с гипервизорами. Не стал исключением и продукт Veeam® Backup&Replication™, имеющий широкие возможности по резервному копированию в виртуализованных средах. Сегодня мы расскажем, как настроить его для работы с Proxmox VE.

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


    Мы будем использовать актуальную версию Proxmox на момент написания статьи — 6.2-1. Эта версия вышла 12 мая 2020 года и содержит в себе массу полезных изменений, о которых расскажем в одной из следующих статей. Пока что начнем готовить гипервизор. Основная задача — установить Veeam® Agent for Linux на резервируемый хост с Proxmox. Но перед этим совершим несколько действий.

    Подготовка системы


    Поставим утилиту sudo, которая отсутствует в системе, если Proxmox устанавливался не в существующую Linux-систему, а как самостоятельная ОС из официального образа. Также нам понадобятся pve-заголовки ядра. Заходим на сервер через SSH и добавляем репозиторий, работающий без подписки на поддержку (официально он не рекомендуется для production, однако содержит необходимые нам пакеты):

    echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" >> /etc/apt/sources.list

    apt update

    apt install sudo pve-headers

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

    Установка Veeam® Agent


    Скачиваем deb-пакет Veeam® Agent for Linux с официального сайта (требуется наличие учетной записи), вооружаемся SFTP-клиентом и заливаем полученный deb-пакет на сервер. Устанавливаем пакет и обновляем список программ в репозиториях, которые этот пакет добавляет:

    dpkg -i veeam-release-deb_1.x.x_amd64.deb

    Обновляем репозитории еще раз:

    apt update

    Устанавливаем сам агент:

    apt install veeam

    Проверяем, что все установилось корректно:

    dkms status

    Ответ будет приблизительно таким:

    veeamsnap, 4.0.0.1961, 5.4.41-1-pve, x86_64: installed

    Настройка Veeam® Backup&Replication™


    Добавление репозитория


    Разумеется, хранить резервные копии можно и непосредственно на сервере с развернутым Veeam® Backup&Replication™, однако удобнее все-таки пользоваться внешним хранилищем.

    Переходим в раздел BACKUP INFRASTRUCTURE:


    Выбираем пункт Backup Repositories, нажимаем кнопку Add Repository и в появившемся окне выбираем Network attached storage:


    Для примера возьмем тестовое SMB-хранилище, у меня это обычный QNAP:


    Заполняем имя и описание, затем нажимаем кнопку Next:


    Вводим адрес SMB-хранилища и, если оно требует авторизации, нажимаем Add для добавления реквизитов доступа:


    Заполняем имя пользователя и пароль для доступа к SMB-хранилищу, а затем нажимаем кнопку ОК и, вернувшись в предыдущее окно, — Next:


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


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


    Проверяем, что необходимые компоненты установлены и находятся в статусе already exists, и нажимаем кнопку Apply:


    На этом этапе Veeam® Backup&Replication™ еще раз подключится к хранилищу, определит нужные параметры и создаст репозиторий. Нажимаем Next:


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


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


    Репозиторий успешно добавлен:


    Создание задания бэкапа


    В главном окне Veeam® Backup&Replication™ нажимаем Backup JobLinux computer. Выбираем тип Server и режим Managed by backup server:


    Даем имя заданию и по желанию добавляем описание. Затем нажимаем Next:


    Далее нам нужно внести все серверы с Proxmox, которые будем бэкапить. Для этого нажимаем AddIndividual computer. Вводим хостнейм или IP-адрес сервера и реквизиты доступа. Таким образом формируем список Protected computers и нажимаем Next:


    Теперь очень важный момент, а именно выбор данных, которые будут добавлены в резервную копию. Тут все будет зависеть от того, где именно у вас располагаются виртуальные машины. Если хотите добавить только какой-либо логический том, то нужен режим Volume level backup и выбираете путь к логическому тому или устройству, например /dev/pve. Все остальные действия идентичны.

    Для этой статьи мы покажем как работает режим File level backup:


    В следующем окне формируем список директорий для бэкапа. Нажимаем Add и прописываем директории, где хранятся конфигурационные файлы виртуальных машин. По умолчанию это каталог /etc/pve/nodes/pve/qemu-server/. Если вы используете не только виртуальные машины, но и LXC-контейнеры, то добавьте директорию /etc/pve/nodes/pve/lxc/. В моем случае это еще и каталог /data.

    Сформировав таким образом список директорий, нажимаем Next:


    Из выпадающего списка репозиториев выбираем Storage, созданный ранее. Определяем длину цепочки для инкрементального бэкапа. Чем больше точек будет в Retention policy, тем больше места вы сэкономите. Но вместе с этим снизится надежность резервной копии. Мне важнее надежность, чем объем места в хранилище, поэтому я поставил 4 точки. Вы можете взять стандартное значение 7. Продолжаем настройку задания, нажав Next:


    Тут параметры оставляем без изменений, просто идем в следующее окно:


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


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


    Остается только проверить суммарную информацию о задании и нажать кнопку Finish:


    На этом создание задания резервного копирования закончено.

    Выполнение бэкапа


    Тут все элементарно. В главном окне программы выбираем созданное задание и нажимаем Start. Система автоматически подключится к нашему серверу (или нескольким серверам), проверит доступность хранилища и зарезервирует необходимое количество дискового пространства. Затем, собственно, начнется процесс резервного копирования, и по завершении мы получим исчерпывающую информацию о процессе.
    Если в процессе запуска бэкапа возникла проблема вида Failed to load module [veeamsnap] with parameters [zerosnapdata=1 debuglogging=0], то нужно пересобрать модуль veeamsnap в соответствии с инструкцией.

    Что особенно интересно — на самом сервере мы можем посмотреть не только список всех выполненных заданий резервного копирования, но и в реальном времени наблюдать за процессом командой veeam:


    Предрекая вопрос, почему консоль так странно выглядит, скажу сразу: мне очень нравится, как выглядит консоль на экране теплого лампового СRT-монитора. Делается это при помощи эмулятора терминала cool-retro-term.

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


    Теперь самый важный вопрос. А как же восстановить данные, если случилось непоправимое? К примеру, случайно удалили не ту виртуальную машину. В GUI Proxmox она вообще пропала, в хранилище на месте машины ничего не осталось.

    Процесс восстановления несложный. Заходим на консоль Proxmox и вводим команду:

    veeam

    Мы увидим список выполненных бэкапов. Выбираем стрелками нужный и нажимаем клавишу R. Далее выберем точку восстановления и нажмем Enter:


    Спустя пару секунд точка восстановления будет смонтирована в директорию /mnt/backup.

    Останется только скопировать по своим местам виртуальные накопители и конфигурационные файлы виртуальных машин, после чего «убитая» машина появится в GUI Proxmox VE автоматически. Вы сможете запустить ее обычным образом.

    Для размонтирования точки восстановления не следует это делать вручную, а нужно нажать клавишу U в утилите veeam.

    На этом все.

    May the Force be with you!

    Предыдущие статьи на тему гипервизора Proxmox VE:

    Selectel
    ИТ-инфраструктура для бизнеса

    Similar posts

    Comments 20

      0
      Может сначала стоит сказать что бэкапить запущенные виртуальные машины необходимо средствами гипервизорами (snapshot и потом копирование снимка например), думаю не зря тот же платные Veeam Backup стоит немало денег т.к. просто копировать запущенные виртуальные машины — это все равно что выстрелить себе в ногу. Бэкап работающей не особо нагруженной простым копированием — сразу вызовет сбой при попытке запуска.
      Поэтому в данном случае ни в коем случае не используйте это решение для бэкапа, который по сути работает как «cp -r /backup/...».
      VM можно бэкапить используя veeam agent, но это из самой виртуалки, но не гипервизора.
      Селектел — ведь хорошие инженеры работают, исправьте статью и сообщите о проблемах, которые могут возникнуть используя данные решения.
        0
        Возможно это не совсем очевидно, но veeamsnap вначале делает снапшот состояния тех файлов и директорий, которые указаны в задании. Именно поэтому нужен обязательно весь этот подготовительный этап с pve-headers. Вот если вы поставите галочку Backup directly from live filesystem, то вот тогда задание сработает как вы указали и там действительно возможен сбой.
          0
          В начале статьи было написано, что это не для продакшен, поэтому прошу простить мою навязчивость.
          forums.veeam.com/veeam-agent-for-linux-f41/proxmox-incremental-backups-with-veeam-t66702.html
          Но как он будет копировать данные, которые находятся в оперативной памяти VM, явно для виртуалок с базами данных — это не то решение. Потенциальных глюков может стать больше чем предполагается.
            0
            Идеального инструмента не бывает. Всегда есть частные случаи. Если у вас небольшая компания с маленьким парком оборудования, гипервизором и виртуальными машинами, которые работают исключительно по будним дням — такой способ подстраховаться от потери данных вполне применим. Для критичных сервисов, которые не требуют работы 24/7 это можно организовать как внутри виртуальной машины (все верно, механизм тот же, но возможность сбоя меньше), так и с запланированным выключением ВМ по шедулеру. В таком случае будет обеспечиваться полная консистентность.
        0
        Чем не устраивает штатная работа backup + github.com/ayufan/pve-patches?
          0
          Да собственно всем устраивает, просто если в компании уже есть работающий бэкап-сервер Veeam, то им проще будет это делать прямо из него и не плодить лишних сущностей.
          0
          raw диски виртуалок он сможет бэкапить?
          что такое каталог «data»?
            0
            У меня в /data как раз лежали образы виртуальных машин (в формате qcow2).
            RAW-диски он бекапить может.
            0
            Не в тему, но о Proxmox — может ктото подскажет решение, чтоб сделать так, как это сделано в Windows Server с Hyper-V — при перезагрузке хоста все виртуалки/контейнеры сохраняли своё состояние и после загрузки его восстанавливали? Т.е. чтобы перезагрузка хоста для гостей всегда была прозрачна.
              0

              Что это за магия такая расскажите подробнее?

                0
                Что это за магия такая расскажите подробнее?

                Всмысле? Какая магия?? Вы о чём?
                  0
                  при перезагрузке хоста все виртуалки/контейнеры сохраняли своё состояние и после загрузки его восстанавливали? Т.е. чтобы перезагрузка хоста для гостей всегда была прозрачна.

                  Я такого ни на одном гипервизоре не видел, кроме VMware с Fault tolerance с кучей ограничений.
                    0
                    Hyper-V так делает что на Windows Server, что на Windows 8.x/10 — все запущенное даже не будет подозревать что хост перегрузился.
                      0
                      Ну это явно какая-то пропиетарщина только для windows on windows.
                        0
                        Ну это явно какая-то пропиетарщина только для windows on windows.

                        это то здесь при чём? разговор не о том, проприетарщина или нет, разговор о том как сделать такое же поведение.
                        qemu может делать suspend виртуалкам/контейнерам. потом перегрузиться и сделать resume. осталось только понять как это всё объяснить делать proxmox'у
                          0
                          Так при том. Чтобы такое сделать надо уметь из гипервизора лазить глубоко в ядра гостевых ОС, работать с процессами в гостевых ОС. Очевидно, что сторонним разработчикам это так просто не сделать.
                            0
                            что за бред я сейчас прочитал? я выше уже сказал — qemu умеет сохранять/восстанавливать состояние виртуалки. осталось это запихнуть в startup/shutdown скрипты.
              +2
                0
                А-я-я-й, ещё и в корпоративном блоге… как не красиво
                  +3
                  Вы правы, это моя ошибка. Обозначил в начале статьи.

                Only users with full accounts can post comments. Log in, please.