company_banner

Про бэкапы в Proxmox VE


    В статье «Магия виртуализации: вводный курс в 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. В этих файлах содержится следующее:

    • raw — образ диска;
    • conf — конфигурация VM;
    • 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).
    Selectel
    ИТ-инфраструктура для бизнеса

    Комментарии 23

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

      А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.

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

      3. С 6ой ветки есть возможность не мучаться с настройкой бэкапа для каждой виртуальной машины в отдельности, а делать бэкапы на основе пулов виртуальных машин, это намного удобней.
        0
        А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.
        С точки зрения безопасности правильнее чтобы не резервируемый закачивал бэкапы на сервер, а сам сервер забирал бэкапы с резервируемого. В первом варианте в случае взлома (или банального rm -rf /, если речь про примонтированное в файловую систему хранилище) можно потерять всё сразу.
          0
          В общем то да, но все зависит от разных ситуаций.
          0
          А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.

          Это оправдано, если удаленное хранилище быстрое. Или не слишком важно время простоя. Ведь в режиме snapshop производительность падает, а в suspend и stop вм вообще простаивает.

          +1
          И в статье ни одного слова про qemu-guest-agent, который хотя бы попытается предупредить гостевую ОС и сервисы в ней о том, что вот прям сейчас нужно сохранить все данные из памяти на диск, иначе в конечном бэкапе может получиться немного каши с супом…
            +1
            Начнем с того, что Proxmox имеет неплохой штатный инструментарий для создания резервных копий виртуальных машин.

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

            А теперь возьмите узел с десятком нагруженных VM по 300-400 гиг в каждой, на обычых (не SSD) дисках, попробуйте делать ежедневные бэкапы и начинайте плакать глядя как всё тормозит.
              +1

              Боюсь предположить, что в предложенном Вами сценарии иные гипервизоры тоже звёзд с неба хватать не будут.
              Думаю логичным выходом при наличии таких вводных будет использование внешних хранилищ данных или чего-нибудь другого. Кстати proxmox очень неплохо дружит с ceph. (https://pve.proxmox.com/wiki/Ceph_Server)
              Сабж очень хорош контейнерами lxc, а их нарастить до нескольких Тб надо постараться, а, в свою очередь, маленькие контейнеры резервировать описанными автором средствами одно удовольствие

                +1
                Если использовать алтернативные методы бэкапа (не встроенные в гипервизоры) то можно значительно снизить затраты. К примеру те же restic/borg, работающие изнутри контейнеров/VM, существенно сокращают время за счёт локального кэша метаданных и отсутствия необходимости сравнивать всё со всем при каждом проходе.

                Для Windows VM можно использовать средства которые отслеживают изменения в блоках устройств (Acronis/Macrium/etc), соответственно не пытаясь копировать всё каждый раз.

                Проблема с vzdump именно в том что он «тупой» — копирует либо весь блочный файл (если это не Linux), либо сравнивает старый tar с текущим состоянием перед созданием инкрементального бэкапа.
                  0
                  Зачем автору поста переписывать всю wiki с официального сайта proxmox? Cуть поста в знакомстве пользователя с софтом, краткий обзор, его не стоит воспринимать как пошаговую инструкцию + как must have и никак иначе.

                  Когда речь заходит об windows — это совсем другая «парафия», где софт от MS и средства его бекапа заточены специально под них и в большинстве случаев за деньги. Потому человеку стоит всегда составить список "+" и "-" за тот или иной инструмент, а потом еще почитать опыт использования, что бы сложилось впечатление и сделать верный выбор.
                    0
                    Я просто отметил слабые места, не более того. Как показывает практика, люди часто даже не думают об альтернативах если есть «стандартные» средства, хотя далеко не всегда они самые эффективные.
                0
                Полностью согласен, оно еще и бэкапы в режиме снапшота делает со скоростью обычного копирования.
                +1

                Самая большая проблема это отсутствие энкриментальных и отсутствие нормальной возможности достать один файл.
                А раз в год бекап превращающийся в зомби с la 60- святое дело.....

                  0

                  На самом деле это выглядит как инструкция по установке MS Office (например): тысяча параметров, но всем интуитивно понятна.
                  Лучше б описали тонкости работы, это все же хабр. Например, развертывание ВМ с имеющегося образа, восстановление ВМ из бэкапа другого Proxmox, простейший кластер

                    0
                    восстановление не возможно при большой разнице в версиях, в первую очередь если попытаемся развернуться на старом кластере
                    Тонкостей нет, т/к прилично багов и нужно тупо разбираться, в конце года у меня группа серверов перегружалась переодически бессимптомно, аля ресет, на форуме кроме обновлений нашли подобное поведение изза ha, lacp и т/д и т/п
                    Ну и стоит ли говорить что даже без ha если не собрался кворум (короче вылетели 3 ноды) у вас виртуалки не подымутся
                    Ну и кучу ошибок у проксмокса закрывается фразой решено в следующих релизах, за 5 лет таких багов штук 20 было
                    0

                    Увы, но бекапить таким образом сервера баз данных не получится — данные из памяти будут записаны не полностью на диск.
                    Такие виртуалки приходится специальным образом приостанавливать.
                    Для mysql — переводить сервер в режим read-only.
                    Остальных — просто останавливать.
                    Плюс тупой бекап в текстовый SQL-файл.


                    Сам бекап делать в 2 прохода: первый rsync, приостановить БД, ВМ в suspend, второй rsync, ВМ в resume, отпустить БД.


                    Такое прокатывает с небольшими виртуалками на OpenVZ / LXC.
                    Как безопасно для данных сворачивать виртуалки в KVM, и тем более с Windows — пока не придумал.

                      0

                      https://github.com/ayufan/pve-patches
                      Неужели вы обошли стороной эти чудесные патчи?

                        +1
                        А кто-нибудь знает, можно ли в штатном бэкапе Proxmox исключить какой-то диск из бэкапа виртуальной машины? Я, к примеру, почти никогда не делаю полные бэкапы виртуальных машин, потому что это неудобно. Обычно бэкаплю системные диски с настройками, а сами данные забираю другим способом (rsync, mysqldump и т.д. в зависимости от данных). В proxmox не понимаю, как применить этот подход, потому что он всегда пытается забэкапить всю виртуальную машину целиком.
                          +1
                          В свойствах диска опция no backup.
                          +1
                          Автор статьи забыл рассказать как ограничить количество резервных копий. Или это было в предыдущих статьях.

                          «Датацентр» ➜ «Хранилище»

                          image
                              0
                              А нельзя делать бекап первым способом (снимок), но так, что бы перед началом бекапа виртуальная машина скинула все кеши на диск и бекап был консистентным?

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

                            Самое читаемое