Что-то давненько мы не писали про наш флагманский продукт. Исправляемся, тем более что подоспела еще одна порция полезных советов от ребят из Veeam Support Team. Сегодня с вами снова мой коллега Евгений Иванов, теперь уже из Бухареста, куда он был призван в качестве наставника для румынской команды технической поддержки.
В ходе своей работы Евгений со товарищи собрали приличную коллекцию «граблей», на которые чаще всего наступают начинающие пользователи при развертывании и настройке Veeam Backup & Replication. А чтобы вы не повторяли их ошибок, Женя разъясняет, как всё сделать правильно.
Итак, добро пожаловать под кат.
Обычно рекомендуются «прямой инкрементный» или «бесконечно инкрементный», поскольку они самые быстрые. Бесконечно-инкрементная цепочка (без периодических полных резервных копий) занимает меньше места и довольно быстро обрабатывается. Обычая инкрементная цепочка места занимает больше, но она и более «жизнестойкая», если можно так выразиться, так как содержит не только инкрементальные бэкапы, но и периодически создаваемые полные.
Реверсивный (обратный) инкрементный метод – самый старинный и, естественно, самый медленный. В зависимости от СХД, он может быть в 3 и даже более раз медленнее других. Тем не менее, в его использовании есть и свои плюсы: последним в цепочке всегда является полный бэкап, и поэтому восстановиться можно быстрее, чем из цепочек других типов. Заметим, однако, что разница с обычной инкрементальной цепочкой не очень значительна (разве что вы держите такую цепочку неоправданно длинной, то есть более чем 30 дней).
Подробнее про методы рассказывается здесь.
Операция создания синтетической полной резервной копии использует точки восстановления, которые хранятся в репозитории. Но нужно иметь в виду, что не всякая СХД в состоянии обеспечить достаточную для этой операции производительность. Поэтому мы советуем в качестве альтернативы создание активных полных резервных копий.
Когда вы задаете настройки создания синтетического полного бэкапа, обратите внимание на опцию “Transform previous backup chains into rollbacks” (преобразовывать предыдущие цепочки в точки отката). Ее использование приведет к тому, что будет запускаться задание преобразования инкрементального бэкапа (.VIB) в точки отката (.VRB) (которое будет, однако, потреблять значительную часть ресурсов СХД репозитория). Например, с помощью этой опции вы сможете преобразовать текущую цепочку в обратно- инкрементальную, в частности, для архивного хранения.
Но если использовать данную опцию как метод резервного копирования, то в итоге создастся очень своеобразная цепочка из файла полной резервной копии и файлов инкрементальных и обратно-инкрементальных резервных копий.
Обработка гостевой ОС позволяет создавать консистентные бэкапы виртуальных машин. А если на ВМ работают такие приложения, как Microsoft Exchange, Active Directory, SharePoint, SQL Server или Oracle, то вы сможете задействовать для их гранулярного восстановления возможности инструментов Veeam Explorers. Работа с гостевой ОC базируется на функциональности VSS (поддерживается Windows), которая должна быть корректно настроена, иначе задания резервного копирования не смогут успешно завершиться.
Для активации настроек обработки гостевой ОС:
Если активировать опцию VM Guest File System Indexing (индексирование файлов гостевой ОС) в настройках бэкапа, то Veeam Backup & Replication будет создавать каталоги файлов ВМ. Это позволит выполнять поиск по файлам и восстановление в 1 клик через веб-интерфейс Veeam Backup Enterprise Manager.
Если же вы не работаете с Enterprise Manager, то мы советуем не включать данную опцию – так вы сократите окно резервного копирования (порой весьма существенно) и сэкономите место на диске C: сервера Veeam backup. На восстановление файлов ВМ через консоль Veeam Backup & Replication это никак не повлияет.
Ни один производитель СХД не гарантирует абсолютной целостности данных. Конечно, Veeam проверяет файл резервной копии при записи на диск, но при том, что на СХД выполняются миллионы операций, случайная перестановка бит все же возможна, а в результате получается «невидимое» повреждение. Для выявления таких повреждений на ранних этапах Veeam Backup & Replication предлагает воспользоваться функциями SureBackup и health checks. Но и это не панацея, поэтому мы советуем взять на вооружение правило 3-2-1, которое предписывает использовать для бэкапа разные типы носителей и хранить их как минимум на 2 площадках.
Для этого рекомендуется после создания основного задания резервного копирования настроить задание переноса резервных копий. Такое задание может использовать в качестве целевого места хранения резервную СХД или облачное хранилище. Также можно архивировать бэкапы на магнитную ленту.
Функция мгновенного восстановления ВМ Instant VM Recovery позволяет запустить машину в кратчайший срок непосредственно из бэкапа. Тем не менее, нужно помнить, что эта машина размещается у вас в репозитории и потребляет его ресурсы, пока вы не перенесете ее в продакшен. Не забывайте про этот важный финальный шаг – поверьте, за годы работы в техподдержке Veeam мы повидали немало случаев с ВМ, которые неделями функционировали в режиме «из бэкапа» без того, чтобы быть перенесенными в продакшен. Итог был обычно довольно плачевен: переполнение СХД и потеря данных.
Подробно про то, как правильно выполнять мгновенное восстановление, читаем здесь.
Veeam поддерживает самые разные хранилища в качестве репозиториев. Многие наши пользователи из года в год предпочитают использовать для этой цели физический сервер Windows или Linux, поскольку в большинстве случаев это дает максимальную производительность. Об этом можно почитать на нашем форуме.
Репозитории на CIFS share также довольно популярны, несмотря на то, что их производительность по сравнению с другими самая низкая.
Многие современные устройства NAS поддерживают iSCSI, так что лучше все-таки сконфигурировать диск iSCSI и сделать его доступным для сервера Veeam backup (или для прокси). Следует иметь в виду, что в таком сценарии (с использованием репозитория на NAS) не рекомендуется применять метод обратно-инкрементального бэкапа, т.к. он дает большую нагрузку на СХД из-за интенсивности чтения\записи.
Если вы собираетесь выполнять репликацию через WAN, то рекомендуем вам настроить прокси-сервер резервного копирования на удаленной площадке и указать его в настройках задания репликации. Таким образом вы получите надежный канал между двумя площадками. Советуем включить данный прокси в работу в режиме Network (NBD), так как работа в режиме Virtual Appliance (hot-add) при репликации может привести к возникновению «затерянных» снапшотов.
Прокси на удаленной площадке мы рекомендуем использовать и в случае работы через WAN-акселератор. Можно развернуть WAN-акселератор и прокси на разных машинах или даже на одной (разумеется, если у нее в достатке ресурсов).
Для передачи данных на ленточное устройство Veeam задействует вспомогательный сервер (tape server). Он ставится на физический сервер, к которому подключается это ленточное устройство.
Важно! Подключение к ВМ с “пробрасыванием” через хост ESXi не поддерживается!
Veeam Backup & Replication получает информацию о ленточной библиотеке от операционной системы, поэтому обязательно убедитесь, что у вас установлены последние версии драйверов, а ленточное устройство корректно отображается в консоли Управления устройствами (device manager).
Больше полезных советов о работе с магнитной лентой можно прочитать в этой статье.
Тут уж ничего не поделаешь, придется завести заявку на портале техподдержки. Настоятельно просим сделать пару простых вещей:
Надеюсь, наши рекомендации помогут кому-то избежать типичных ошибок при развертывании и настройке Veeam Backup & Replication. На сегодня у меня всё. С пожеланиями успехов, Veeam Support Team.
В ходе своей работы Евгений со товарищи собрали приличную коллекцию «граблей», на которые чаще всего наступают начинающие пользователи при развертывании и настройке Veeam Backup & Replication. А чтобы вы не повторяли их ошибок, Женя разъясняет, как всё сделать правильно.
Итак, добро пожаловать под кат.
#1: Выберите оптимальный метод резервного копирования
Обычно рекомендуются «прямой инкрементный» или «бесконечно инкрементный», поскольку они самые быстрые. Бесконечно-инкрементная цепочка (без периодических полных резервных копий) занимает меньше места и довольно быстро обрабатывается. Обычая инкрементная цепочка места занимает больше, но она и более «жизнестойкая», если можно так выразиться, так как содержит не только инкрементальные бэкапы, но и периодически создаваемые полные.
Реверсивный (обратный) инкрементный метод – самый старинный и, естественно, самый медленный. В зависимости от СХД, он может быть в 3 и даже более раз медленнее других. Тем не менее, в его использовании есть и свои плюсы: последним в цепочке всегда является полный бэкап, и поэтому восстановиться можно быстрее, чем из цепочек других типов. Заметим, однако, что разница с обычной инкрементальной цепочкой не очень значительна (разве что вы держите такую цепочку неоправданно длинной, то есть более чем 30 дней).
Подробнее про методы рассказывается здесь.
#2: Подумайте о настройках синтетических полных бэкапов
Операция создания синтетической полной резервной копии использует точки восстановления, которые хранятся в репозитории. Но нужно иметь в виду, что не всякая СХД в состоянии обеспечить достаточную для этой операции производительность. Поэтому мы советуем в качестве альтернативы создание активных полных резервных копий.
Когда вы задаете настройки создания синтетического полного бэкапа, обратите внимание на опцию “Transform previous backup chains into rollbacks” (преобразовывать предыдущие цепочки в точки отката). Ее использование приведет к тому, что будет запускаться задание преобразования инкрементального бэкапа (.VIB) в точки отката (.VRB) (которое будет, однако, потреблять значительную часть ресурсов СХД репозитория). Например, с помощью этой опции вы сможете преобразовать текущую цепочку в обратно- инкрементальную, в частности, для архивного хранения.
Но если использовать данную опцию как метод резервного копирования, то в итоге создастся очень своеобразная цепочка из файла полной резервной копии и файлов инкрементальных и обратно-инкрементальных резервных копий.
#3: Настройте обработку гостевой ОС
Обработка гостевой ОС позволяет создавать консистентные бэкапы виртуальных машин. А если на ВМ работают такие приложения, как Microsoft Exchange, Active Directory, SharePoint, SQL Server или Oracle, то вы сможете задействовать для их гранулярного восстановления возможности инструментов Veeam Explorers. Работа с гостевой ОC базируется на функциональности VSS (поддерживается Windows), которая должна быть корректно настроена, иначе задания резервного копирования не смогут успешно завершиться.
Для активации настроек обработки гостевой ОС:
- В свойствах задания резервного копирования перейдите к шагу Guest Processing.
- Включите опцию Application-aware processing (обработка с учетом состояния приложений).
- В секции Guest OS credentials укажите учетную запись с правами администратора для доступа к гостевой ОС.
- Если для какой-либо ВМ в составе задания резервного копирования нужна отдельная учетная запись, то нажимаем кнопку Credentials. Далее надо кликнуть на Set User… и указать нужные данные.
- Настройки для обработки конкретных приложений задаем в отдельном диалоге, который открывается после нажатия Applications…. При необходимости также можно отключить обработку гостевой ОС для отдельно взятых машин.
#4: Не индексируйте файлы без необходимости
Если активировать опцию VM Guest File System Indexing (индексирование файлов гостевой ОС) в настройках бэкапа, то Veeam Backup & Replication будет создавать каталоги файлов ВМ. Это позволит выполнять поиск по файлам и восстановление в 1 клик через веб-интерфейс Veeam Backup Enterprise Manager.
Если же вы не работаете с Enterprise Manager, то мы советуем не включать данную опцию – так вы сократите окно резервного копирования (порой весьма существенно) и сэкономите место на диске C: сервера Veeam backup. На восстановление файлов ВМ через консоль Veeam Backup & Replication это никак не повлияет.
#5: Делайте дополнительные резервные копии
Ни один производитель СХД не гарантирует абсолютной целостности данных. Конечно, Veeam проверяет файл резервной копии при записи на диск, но при том, что на СХД выполняются миллионы операций, случайная перестановка бит все же возможна, а в результате получается «невидимое» повреждение. Для выявления таких повреждений на ранних этапах Veeam Backup & Replication предлагает воспользоваться функциями SureBackup и health checks. Но и это не панацея, поэтому мы советуем взять на вооружение правило 3-2-1, которое предписывает использовать для бэкапа разные типы носителей и хранить их как минимум на 2 площадках.
Для этого рекомендуется после создания основного задания резервного копирования настроить задание переноса резервных копий. Такое задание может использовать в качестве целевого места хранения резервную СХД или облачное хранилище. Также можно архивировать бэкапы на магнитную ленту.
#6: Финализируйте Мгновенное восстановление
Функция мгновенного восстановления ВМ Instant VM Recovery позволяет запустить машину в кратчайший срок непосредственно из бэкапа. Тем не менее, нужно помнить, что эта машина размещается у вас в репозитории и потребляет его ресурсы, пока вы не перенесете ее в продакшен. Не забывайте про этот важный финальный шаг – поверьте, за годы работы в техподдержке Veeam мы повидали немало случаев с ВМ, которые неделями функционировали в режиме «из бэкапа» без того, чтобы быть перенесенными в продакшен. Итог был обычно довольно плачевен: переполнение СХД и потеря данных.
Подробно про то, как правильно выполнять мгновенное восстановление, читаем здесь.
#7: Подумайте, где размещать репозиторий
Veeam поддерживает самые разные хранилища в качестве репозиториев. Многие наши пользователи из года в год предпочитают использовать для этой цели физический сервер Windows или Linux, поскольку в большинстве случаев это дает максимальную производительность. Об этом можно почитать на нашем форуме.
Репозитории на CIFS share также довольно популярны, несмотря на то, что их производительность по сравнению с другими самая низкая.
Многие современные устройства NAS поддерживают iSCSI, так что лучше все-таки сконфигурировать диск iSCSI и сделать его доступным для сервера Veeam backup (или для прокси). Следует иметь в виду, что в таком сценарии (с использованием репозитория на NAS) не рекомендуется применять метод обратно-инкрементального бэкапа, т.к. он дает большую нагрузку на СХД из-за интенсивности чтения\записи.
#8: Используйте прокси при репликации
Если вы собираетесь выполнять репликацию через WAN, то рекомендуем вам настроить прокси-сервер резервного копирования на удаленной площадке и указать его в настройках задания репликации. Таким образом вы получите надежный канал между двумя площадками. Советуем включить данный прокси в работу в режиме Network (NBD), так как работа в режиме Virtual Appliance (hot-add) при репликации может привести к возникновению «затерянных» снапшотов.
Прокси на удаленной площадке мы рекомендуем использовать и в случае работы через WAN-акселератор. Можно развернуть WAN-акселератор и прокси на разных машинах или даже на одной (разумеется, если у нее в достатке ресурсов).
#9: Учтите важные нюансы при архивировании на ленту
Для передачи данных на ленточное устройство Veeam задействует вспомогательный сервер (tape server). Он ставится на физический сервер, к которому подключается это ленточное устройство.
Важно! Подключение к ВМ с “пробрасыванием” через хост ESXi не поддерживается!
Veeam Backup & Replication получает информацию о ленточной библиотеке от операционной системы, поэтому обязательно убедитесь, что у вас установлены последние версии драйверов, а ленточное устройство корректно отображается в консоли Управления устройствами (device manager).
Больше полезных советов о работе с магнитной лентой можно прочитать в этой статье.
#10: Если все равно что-то пошло не так
Тут уж ничего не поделаешь, придется завести заявку на портале техподдержки. Настоятельно просим сделать пару простых вещей:
- Проверьте, какой уровень серьезности (Severity) вы выставляете для вашей заявки – для этого соотнесите ее с соответствующими критериями. Мы понимаем, что все проблемы являются серьезными для наших пользователей (иначе они бы к нам не обратились), и наша обязанность – рассматривать заявки в кратчайшие сроки. Но если вы поставили уровень Severity 1, а заявка не удовлетворяет критериям этого уровня, вы рискуете потерять драгоценное время, которое уйдет на то, чтобы вашу заявку переквалифицировать и перенаправить в соответствующую очередь.
- Чтобы было проще и быстрее найти причину проблемы, обязательно подготовьте логи для отправки нам. О том, как это правильно сделать, написано тут. В некоторых случаях наши инженеры могут попросить логи других компонентов вашей инфраструктуры, так что следует быть готовым.
Надеюсь, наши рекомендации помогут кому-то избежать типичных ошибок при развертывании и настройке Veeam Backup & Replication. На сегодня у меня всё. С пожеланиями успехов, Veeam Support Team.
