File level Restore для Linux в Veeam BR v11

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

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

Начать стоит с того, что возможность использования Helper Appliance у нас никто не отнял и с ним все также можно восстанавливать файлы. Однако, использование этой легковесной виртуальной машины накладывает ряд неудобств, например, нужно указывать хост, где машина будет запущена, указывать сети, адреса (в случае, если в выбранной сети отсутствует поддержка DHCP):

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

Как уже было сказано ранее, теперь мы можем не использовать Helper Appliance, а использовать один из существующих Linux хостов, на котором доступен SSH и который поддерживает файловую систему, с которой требуется восстановить файлы.

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

Выбираем требуемую точку восстановления:

Следующий шаг это, ради чего затевалась вся статья:

Выбрав пункт «Specify a different host», мы активируем появление диалогового окна, в котором необходимо указать адрес сервера, а также данные для доступа к серверу по SSH:

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

После ввода данных, указанный сервер появится в списке Helper Hosts:

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

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

Попробуем восстановить файл с сохранением оригинальной копии с помощью меню Restore – Keep:

Далее указываем логин-пароль от сервера, на который файл будет восстановлен и наблюдаем за процессом:

На виртуальной машине можно увидеть новый файл с соответствующим суффиксом, который добавил Veeam:

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

Если мы подключимся к серверу, который был указан в качестве Helper Host и посмотрим список доступных блочных устройств, мы увидим новые loop устройства с говорящими названиями:

Veeam заботливо смонтировал все файловые системы из резервной копии в /tmp и аналогичным образом, но уже без использования консоли FLR мы можем выполнять поиск и восстановление, но уже с помощью привычных инструментов Linux.

Например, посмотрим, чем отличается содержимое каталога /var/named из резервной копии и /var/named из рабочей системы:

Как можно заметить, один файл отличается – тот, что был нами ранее восстановлен с помощью FLR.

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

Восстановить файл также просто. Достаточно использовать cp:

Восстановить этот же файл на другой сервер – легко? scp, rsync.

А что же происходит в этот момент в системе, к которой подмонтирована резервная копия?

В /tmp копируются файлы Veeam Agent:

Агент запускается и присутствует в процессах в течение всего времени выполнения процедуры FLR:

Также, в моем случае, на сервере были открыты порты 2500/tcp и 2501/tcp:

После закрытия менеджера FLR в консоли VBR, сессия восстановления автоматически останавливается и агентские процессы в ОС более не запущены:

Veeam также заботливо закрывает ранее открытые порты:

И подчищает за собой файлы в /tmp:

Естественно, при этом все смонтированные ранее loop устройства будут отмонтированы.


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

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

В качестве заключения:

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

Я думаю, что в этом направлении еще есть куда развиваться, например:

  1. Включить поддержку one-time password, чтобы логин и пароль не сохранялись в инфраструктуре VBR и учетные данные использовались однократно (особенно, учитывая, что в дальнейшем этот хост не сохраняется в инфраструктуре);
  2. Рассмотреть возможность подключения бэкапов непосредственно к хосту, как это реализовано сейчас, но без необходимости в открытом окне FLR.

Leave a Reply

Your email address will not be published. Required fields are marked *