Одним из, пусть и не самых значительных, но крайне полезных на мой взгляд нововведений в 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 хост, позволяет не только в некоторых случаях упростить запуск процедуры восстановления выбранных файлов, но и предоставляет на первый взгляд не самые очевидные, но крайне удобные возможности, как это восстановление можно произвести.
Я думаю, что в этом направлении еще есть куда развиваться, например:
- Включить поддержку one-time password, чтобы логин и пароль не сохранялись в инфраструктуре VBR и учетные данные использовались однократно (особенно, учитывая, что в дальнейшем этот хост не сохраняется в инфраструктуре);
- Рассмотреть возможность подключения бэкапов непосредственно к хосту, как это реализовано сейчас, но без необходимости в открытом окне FLR.
