Бэкап для Linux не пишет писем
Сегодня хочу поведать о том, как управлять Veeam Agent for Linux с помощью командной строки, и о том, какие возможности она открывает в умелых руках программиста.
На написание статьи меня подтолкнул комментарий к предыдущей статье. Перефразирую удивление пользователя: «Ну как же так? Cервер не пишет писем о том, что он забэкапился!». Причём, со слов аналитиков, он не один такой, иначе бы не появился тред на форуме. А раз люди пишут — значит, это кому нибудь нужно!
В статье я поясню, почему этой функции в продукте нет. Но на этом мы не остановимся, мы эту функцию добавим! Мы ж программисты, так что напишем письмо и сгенерируем отчёт в виде html страницы.
Кроме того, покажу наиболее полезные, на мой взгляд, команды, которые смогут облегчить труд администратора.
Приготовьтесь: много кода, картинок нет.
Для начала ответим на вопрос: «Почему Veeam Agent for Linux не пишет писем?»
Ответы вам могут не понравиться, не обессудьте. А дело в том, что более-менее крупным enterprise пользователям это не нужно, и вот почему:
- Во-первых, для работы с почтой нужно либо поставить smpt-сервер на локальную машину, либо пользоваться каким-то внутри сети. При самой простой реализации (команда mail ) потребуется ставить пакет mailutils. А многие системные администраторы не захотят создавать на своём продакшн сервере потенуциальную уязвимость в виде сервиса, который может слать куда бы то ни было письма. Да и возможности может не быть по причине закрытости портов, независимости подсетей и прочее.
- Во-вторых, так как пакета mailutils очень может не быть на системе (по первой причине), нет смысла и пытаться его использовать. Иначе можем получить функцию, которая вроде есть, но «из коробки» не работает, а значит, будет тред на форуме на тему типа: «Как настроить сервер так, чтобы письма-таки отсылались.»
- Ну и в-третьих, вообще никакая дополнительная нотификация не нужна, так как более-менее крупные enterprise-заказчики используют Veeam Backup & Replication. Его консоль собирает информацию о всех бэкапах, которые были произведены на известные репозитории. Убедитесь сами.
В версии Veeam Backup & Replication 9.5 Update 4 есть возможность пользоваться этим продуктом бесплатно, но с ограничением по обслуживаемым виртуальным/физическим машинам.
Если у вас до 3-х (включительно) физических серверов — бесплатных функций VBR вам будет более чем достаточно.
Если же у вас машин больше 3-х, платить за ПО нет возможности, а централизованно производить мониторинг своих серверов всё же хочется, то предлагаю дописать немного скриптов самостоятельно. Люблю потешить себя на python после рабочего для на С/С++.
Скриптами мы будем оборачивать вызов команды veeamconfig . Команда veeamconfig обеспечивает доступ ко всему функционалу продукта. Бесспорно, псевдографический интерфейс, созданный с помощью библиотеки ncurses, намного приятнее для глаз, однако если нужно связать программы во что-то новое, то CLI — наше всё.
Описание команд Veeam Agent for Linux справедливо для версии 3.0. На предыдущих версиях не проверял, так что могут быть отличия.
CLI-интерфейс в Veeam Agent for Linux довольно удобный и неплохо документирован. Достаточно ввести veeamconfig —help , и вы получите список доступных команд:
Для того, чтобы посмотреть, что каждая команда позволяет сделать, достаточно вызвать veeamconfig config —help . Получим:
Тут, кстати, мы можем увидеть команду сбора логов grabLogs . Она позволит быстро собрать все необходимые логи для саппорта. Это на случай, если что-то пойдёт не так.
Есть ещё интересная команда, которая появилась в версии 3.0:
Дело в том, что начиная с версии 3.0 от пользователя требуется явно дать согласие с лицензионными соглашениями. Выглядит это примерно так:
Соответственно, работа ваших скриптов может быть нарушена. Чтобы не заходить на каждую машину и не выполнять эту процедуру вручную, были предусмотрены команды:
Они позволяют принять лицензионные соглашения без лишних вопросов.
Но мы отклонились от темы написания письма.
Для задачи мониторинга состояния сервера нам потребуется команда veeamconfig session list . Выводит она что-то типа:
Отлично, тут есть информация, когда сервер бэкапился и каков был успех. В принципе, уже можно собирать «выхлоп» в файл и слать письмом. Однако уже за год письмо может подрасти примерно на 365 строк. А выискивать в тексте State с ошибками может показаться утомительным. Поэтому распарсим этот «выхлоп» и получим нормальный список, с которым можно уже что-то делать.
Целиком код смотреть тут
Ну а теперь сделаем письмо и отправим его себе.
В результате после установки mailutils можем получить письмо вида:
В письме выводятся только последние 10 сессий. При этом в самом начале письма выводится информация о числе успешных и не очень сессий. Достаточно глянуть на циферки в письме в начале рабочего дня, проверяя почту и потягивая кофеёк, чтобы понять, что ночные бэкапы прошли успешно.
Если же вам нужно что-то понагляднее — можно запросить информацию о сессиях в xml-формате и передать её на свой сервер. Там объединить полученные данные в единую сводную таблицу, которая отобразит всю необходимую информацию в удобном или посильном для вас формате.
XML-ку получаем парой строк:
Сохраняем полученное в файлик
Далее полученную XML-ку отправляем на сервер. Возможен и альтернативный вариант — сервер собирает XML-ки с машин, которые бэкапятся. Кто инициатор — нам пока не важно. Важно, что на сервере собираются XML-ки со списками сессий со всех машин. Я выбрал певый вариант:
Теперь на стороне сервера осталось обработать принятые данные и сделать красивую html-страничку.
В результате отчёт готов:
У меня не было задачи сделать красивый продукт. Задача была показать, что вопрос сбора статистики можно решить на скриптах за один-два дня.
В принципе, если развить изложенные здесь идеи, то можно сделать «Open Backup Monitor for Veeam Agent for Linux». На мой взгляд, хорошая тема для курсовой по Python, или, может, даже для диплома, или просто повод потренироваться в программировании над opensource-проектом. Согласитесь, лучше потренироваться в программировании, чем становиться эльфом 80-го уровня.
Весь код можно найти на http://www.github.com/CodeImp/veeampy/. Качайте, пользуйтесь, дополняйте и форкайте на здоровье.
Учтите, код распространяется по GPL-2 лицензии, может содержать ошибки и прочее. Всё как обычно в мире opensource. Так что прежде чем применять в продакшн — не забудьте погонять на тестовой лабе.
Источник
Step 2. Select Job Mode
At the Job Mode step of the wizard, specify protection settings for the backup job:
The job mode defines the type of the created Veeam Agent backup job: the backup job (backup job managed by the backup server) or backup policy (backup job managed by Veeam Agent).
At the Job Mode step of the wizard, in the Type field, select the type of protected computers whose data you want to back up with Veeam Agents. The selected type defines what modes will be available for the configured backup job and what job settings will be available at subsequent steps of the wizard. You can select one of the following computer types:
- Workstation — select this option if you want to back up data pertaining to workstations or laptops. This option is suitable for computers that reside in a remote location and may have limited connection to the backup server.
For backup jobs that process workstations, Veeam Backup & Replication offers settings similar to the settings of the backup job available in the Workstation edition of Veeam Agent for Microsoft Windows . To learn more, see Veeam Agent for Microsoft Windows User Guide .
With this option selected, the backup job will be managed by Veeam Agent installed on the protected computer — you do not need to select the job mode.
- Server — select this option if you want to back up data pertaining to standalone servers. This option is suitable for computers that have permanent connection to the backup server.
For backup jobs that process servers, Veeam Backup & Replication offers settings similar to the settings of the backup job available in the Server edition of Veeam Agent for Microsoft Windows . To learn more, see Veeam Agent for Microsoft Windows User Guide .
With this option selected, you can also select the job mode. To learn more, see Selecting Job Mode .
- Failover cluster — select this option if you want to back up data pertaining to a failover cluster.
For backup jobs that process failover clusters, Veeam Backup & Replication offers practically the same backup job settings as for servers.
With this option selected, the backup job will be managed by the Veeam backup server — you do not need to select the job mode.
If you selected the Server computer type in the Type field, in the Mode field, select the job mode. You can select one of the following modes:
- Managed by backup server — select this option if you want to configure the Veeam Agent backup job. With this option selected, you will be able to add one or more individual computers and/or protection groups to the job and instruct Veeam Backup & Replication to create Veeam Agent backups in a Veeam backup repository or Veeam Cloud Connect repository. The Veeam Agent backup job will run on the backup server in the similar way as a regular job for VM data backup. To learn more, see Backup Job .
- Managed by agent — select this option if you want to configure the backup policy. The backup policy describes configuration of individual Veeam Agent backup jobs that run on protected computers, and acts as a saved template. With this option selected, you will be able to add one or more individual computers and/or protection groups to the backup policy, and instruct Veeam Agent to create backups on a local disk of a protected computer, in a network shared folder, Veeam backup repository or Veeam Cloud Connect repository. To learn more, see Backup Policy .
Источник
Применение Veeam Backup для виртуальных машин под управлением Linux: аутентификация на основе сертификата
Индексация гостевой файловой системы требуется для того, чтобы обеспечить пользователю удобный поиск и быстрое восстановление нужных файлов. В частности, Veeam Backup & Replication 8.0 поддерживает эту функциональность и для виртуальных машин под управлением Linux, предоставляя удобный веб-интерфейс Veeam Backup Enterprise Manager:
Соответствующие операции Veeam выполняет с помощью runtime-компонента, который запускается на гостевой ОС виртуальной машины с началом выполнения задания резервного копирования. Этот компонент координирует процессы при индексации (о них чуть позже), а по завершении задания прекращает работу. Для работы runtime-компонента на гостевой ОС и требуется аутентификация, для которой Veeam Backup & Replication 8 поддерживает теперь также использование сертификата (Linux public key).
Подробнее о индексации гостевой файловой системы см.здесь и здесь (на англ.яз.).
Почему мы решили поддержать Linux Public Key-аутентификацию
Те, кто работал с Linux-инфраструктурами, наверняка в курсе – редко кто логинится на Linux сервера, вводя имя пользователя и пароль. Причин тому несколько, среди них, в частности – отсутствие централизованного управления учетными записями. Да, кто-то использует Microsoft Active Directory через Kerberos, кто-то иные способы, но это отнюдь не массовое явление, и настройка и управление большим количеством учеток в немаленькой инфраструктуре может стать головной болью для того, кто за это отвечает.
Взять хотя бы пароли: все знают, что в целях безопасности следует использовать пароли достаточной сложности и регулярно их менять. Да на это же можно полжизни потратить! Кое-кто решает упростить задачу и использовать, скажем, никогда не меняющиеся пароли, или простые короткие пароли. Понятно, что жить становится легче, но безопасность при этом снижается. Помним еще, что кроме коммуникации «человек-компьютер» есть еще коммуникация «компьютер-компьютер», и чтобы обеспечить коммуникацию между серверами, следует хранить пароли там, где к ним был бы доступ у приложений и скриптов – при этом очень желательно в каком-то защищенном виде, а не в текстовом формате.
Из-за всего этого администраторы Linux-систем часто используют метод аутентификации с использованием сертификата, полностью отключая возможность логиниться с вводом имени и пароля. Идея состоит в том, чтобы пользователь (или сервер) использовал для доступа через SSH к удаленной машине сертификат, зарегистрированный на этой удаленной машине – что и позволяет получить авторизацию без необходимости ввода имени\пароля.
Этот сертификат нужно зарегистрировать всего один раз, после чего доступ будет предоставляться автоматически. Выдачу сертификатов также можно автоматизировать.
Если на Linux-сервере разрешена аутентификация с использованием сертификата, то при попытке залогиниться с вводом имени и пароля пользователь увидит сообщение об ошибке. Единственный возможный вариант логина при таких настройках – если локальный сертификат SSH (публичный ключ) загружен в список разрешенных ключей (authorized_keys) на сервере, куда требуется залогиниться.При настройке в Veeam Backup & Replication 8.0 задания резервного копирования, в которое входит такой Linux-сервер, нужно будет указать соответствующий приватный ключ.
Как это работает в Veeam Backup & Replication v8
Итак, сперва создается пара RSA-ключей, и у вас получается два файла:
- id_rsa – приватный ключ, его сохраняем на сервере резервного копирования. Путь к этому ключу нужно будет указать при конфигурации задания резервного копирования.
- id_rsa.pub — публичный ключ, его нужно сохранить в файл authorized_keys того SSH-сервера (Linux ВМ), чью гостевую ОС вы планируете индексировать.
Кстати, в установочном каталоге Veeam присутствует PuTTYGen – его можно использовать для генерации приватных ключей PuTTY Private Key (PPK) для сервера резервного копирования Veeam Backup & Replication. Поддерживаются следующие форматы SSH-ключей: OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS#8 и SSH.com.
Более детальную информацию, а также описание работы с Credentials Manager – инструментом для централизованного управления настройками доступа в Veeam Backup & Replication можно найти здесь (на англ.яз.).
Настройки пользовательского доступа можно ввести и в ходе создания задачи резервного копирования или репликации. В мастере настройки задания резервного копирования для Linux ВМ доходим до шага Guest Processing, включаем опцию индексирования гостевой ОС; затем в секции задания настроек доступа нажимаем Add и из трёх представленных в списке способов выбираем Linux public key:
В открывшемся диалоге нужно указать, какому имени пользователя будет ставиться в соответствие наш ключ (например, root), и указать путь к приватному ключу, который вы до этого создали. Если при создании ключа использовалась кодовая фраза (passphrase), вводим её тоже.
После того, как вы указали ключ, можно проверить, сработает ли он при аутентификации – для этого после возвращения к шагу Guest Processing нажимаем Test Now и наблюдаем за процессом:
Эта кнопка реально полезна, т.к. при проверке ключа проверяется заодно и наличие всех компонентов, необходимых для индексирования гостевой ОС. Так, в примере выше использовалась CentOS в минимальной конфигурации, куда по умолчанию не входит mlocate, о чьем отсутствии и сообщила ошибка в сессии. Есть еще две необходимых утилиты – это gzip и tar.
Собственно, основную работу выполняет mlocate, которая ведет эффективный поиск файлов, используя не файловую систему, а индексную БД, а Veeam использует SSH-соединение для «выдачи указаний» этой утилите (стартовать, обновить базу с помощью updatedb, и т.д.). (В данном сценарии использовать соединение через VMware VIX не удастся – данная функциональность запланирована к реализации на будущее, а в текущей версии серверу резервного копирования необходим доступ к Linux ВМ по сети через SSH.)
Заметим, что поскольку обычным пользователям может не хватать прав для доступка к файлам и выполнения команд (в частности, индексная база закрыта для чтения обычными пользователями), то рекомендуется либо указывать в диалоге Credentials пользователя root, либо включать опцию Elevate account to root.
Таким образом, mlocate выдаст файлы, найденные по индексной БД, и метаданные (включая пути, время последнего обновления индекса, и др.), а tar и gzip соответственно сложат все это в один файл и аккуратно упакуют.
После того, как все необходимые компоненты установлены и тест на аутентификацию успешно пройден, можно перейти к завершающим шагам мастера настройки. И помним, разумеется, что указанные настройки будут применяться ко всем машинкам, включенным в задание – если только не указать иное для выбранной машины (так, индивидуальные настройки доступа к гостевой ОС можно ввести, нажав кнопку Credentials на соответствующем шаге мастера).
Во время выполнения задания резервного копирования в окне статистики будет выводиться подробная информация о ходе индексирования Linux ОС с использованием приватного ключа:
На скриншоте показаны этапы процесса (отмечены стрелками, сверху вниз):
- Veeam коннектится к Linux ВМ через SSH, используя для логина приватный ключ.
- Затем с помощью mlocate индексируется гостевая файловая система.
- После этого с помощью tar и gzip создается компактный файл индекса GuestIndexData.tar.gz.
- В конце работы индексный файл публикуется в каталог VBRCatalog – для того, чтобы пользователи могли выполнять поиск файлов для восстановления. (Подробнее о каталоге можно почитать здесь.)
Надеюсь, новые опции работы с виртуальными машинами под управлением Linux пригодятся вам или вашим коллегам. Однако это лишь первый из 8 рассказов, продолжение следует.
Источник
