Сегодня я снова с удовольствием представляю вам полезные советы от моего коллеги Евгения Иванова, тим-лида команды технической поддержки Veeam. На этот раз Женя поделился рекомендациями для работы с бэкапами и репликами. Надеюсь, они помогут вам избежать типичных ошибок, и ваши реплики и бэкапы никогда не будут «слабым звеном» в процессе восстановления, если таковое потребуется.

Итак, добро пожаловать под кат.

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

Бэкап без рестора — деньги на ветер

К нам регулярно обращаются пользователи, которые оказались в схожих затруднительных ситуациях: необходимо выполнить восстановление из бэкапа, но при попытке это сделать люди натыкаются на неразрешимую для них проблему. И эта проблема – вовсе не отсутствие резервной копии, деятельность CryptoLocker или что-либо подобное. Это «всего лишь» недостаточное внимание к проверке резервных копий и реплик на возможность восстановления. Многие часто фокусируются исключительно на процессе создания бэкапа, забывая о том, что просто наличие резервной копии – не панацея от возможных бед. Нужно понимать, что восстановление – это совершенно иной процесс, у которого есть свои особенности, и который обязательно нужно контролировать и тестировать до запуска в продакшене. Вот вам несколько показательных примеров:

1. У пользователя произошел отказ в работе критичной виртуальной машины размером 20 ТБ. Простои, само собой, недопустимы, и админ запускает процесс мгновенного восстановления (VM instant recovery) – через 5 минут машина поднята. Но мы помним, что такое состояние машины может быть задействовано лишь временно – ее обязательно нужно мигрировать на продакшн датастору (datastore). А в этом примере, как выяснилось, возможности инфраструктуры не позволяли скопировать 20 ТБ данных за разумное время. В настройках же процесса instant recovery было выбрано сохранять изменения на диск С: сервера Veeam Backup & Replication (в отличие от снапшота vSphere) – в результате, конечно же, свободное место на диске быстро заполнилось. К тому моменту, как пользователь обратился в поддержку, у ВМ появились изменения, которые нельзя было игнорировать. То есть имеем ситуацию, когда невозможно быстро финализировать процесс мгновенного восстановления критичной машины – как тут спасти данные?

   Признаться, за давностью лет я уже не упомню всех подробностей финала, но помню, что в итоге мы так и не придумали ничего гениального. Клиенты на своей стороне худо-бедно решили эту проблему, расширив диск С: из резервов, скопировали самые важные файлы и уж потом выключили ВМ и так мигрировали. В общем, чуда не случилось.

2. В инфраструктуре у пользователя работал один контроллер домена, и все компоненты Veeam Backup & Replication были настроены с использованием DNS. Да-да, именно так, вы не ослышались. Вариантов развития событий была сотня, не меньше, а реальности все пошло вот как: люди запланировали ТО и решили переключиться на реплику своего домен-контроллера. Они задействовали плановое переключение, что, в общем-то, и рекомендуется делать в подобных ситуациях. На первом этапе все шло нормально, а на втором исходную ВМ ненадолго выключили, чтобы перенести остатки данных. Разумеется, задание переключения тут же завершилось с ошибкой, поскольку DNS перестал работать.

   К счастью, здесь нам удалось справиться с ситуацией, включив реплику вручную из vSphere (вообще-то эту операцию самостоятельно выполнять не рекомендуется, как вы увидите из следующего примера). Но, как вы понимаете, процесс техобслуживания был прерван и отложен. Вдобавок нам пришлось вручную вносить имена хостов в файл C:WindowsSystem32driversetchosts на сервере Veeam Backup & Replication, чтобы обеспечить корректность при обратном переключении.

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

Думаю, что во всех трех примерах пользователи, так сказать, находились в плену иллюзий – они предположили, что если бэкап прошел успешно, то и с восстановлением проблем не будет. Но это, как вы понимаете, отнюдь не всегда так, и поэтому к восстановлению надо готовиться столь же тщательно, как и к бэкапу. Для начала стоит изучить руководство пользователя, где содержится довольно подробная информация о разных видах восстановления. В начале каждого параграфа перечислены требования, подготовительные действия и возможные ограничения. Описание восстановления с магнитных лент или из аппаратных снимков СХД можно найти в разделах документации и в наших статьях на Хабре. Кроме того, действия по подготовке восстановления объектов приложений с помощью инструментов Veeam Explorers описаны в разделе «Planning and preparation» (планирование и подготовка) руководства для каждого из инструментов. Рекомендую с ними внимательно ознакомиться — это поможет вам правильно подготовить систему к восстановлению в случае необходимости. На русском языке инструкции для восстановления SQL Server database приведены здесь.

Почему не надо работать с репликами из консоли vSphere?

По идее, реплики Veeam представляют собой обычные виртуальные машины, с которыми, казалось бы, логично работать, применяя инструментарий vSphere, в частности, vSphere client. Однако мы не рекомендуем этого делать, и вот почему: переключение на реплику в Veeam Backup & Replication – процесс достаточно непростой, требующий строго последовательного выполнения шагов (чтобы в случае чего можно было откатиться на шаг назад) и корректных завершающих действий – вы только посмотрите на картинку, иллюстрирующую процесс:

Если же вы вздумаете включить реплику из vSphere client, то в дальнейшем вас с большой вероятностью ожидает ряд проблем:

1. Механизм переключения на реплику из Veeam Backup & replication (показанный на схеме) для этой машины работать уже не будет.
2. Данные в базе Veeam Backup не будут соответствовать реальному состоянию ВМ. В наихудшем случае для починки придется редактировать базу.
3. Возможна даже потеря данных, как вот в таком примере: пользователь вручную включил реплику в vSphere client и решил продолжить работу с ней. Через некоторое время он заметил, что реплика все еще отображается в консоли Veeam Backup & Replication, и решил убрать ее за ненадобностью. Кликнул по ней правой кнопкой и дал команду «Delete from disk». Veeam Backup & Replication незамедлительно удалил с диска реплику, которая, на минуточку, уже вовсю использовалась как обычная ВМ и содержала нужные и полезные данные.

Безусловно, бывают ситуации, когда приходится всё же включать реплику из vSphere client – как правило, это случаи, когда сервер Veeam выключен, а реплику нужно включить с задержкой. Но если с сервером Veeam все в порядке, то работать с репликами нужно именно из его консоли.

Также не следует и удалять реплики, пользуясь vSphere client. Veeam Backup & Replication останется в неведении относительно такого изменения, а это чревато ошибками и устаревшими данными. Если реплика вам более не нужна, удаляйте ее с помощью консоли Veeam, а не как ВМ из vSphere client. Так вы всегда будете иметь актуальный список реплик.

«О» — осторожно, обновления!

Тут мы имеем в виду, конечно, обновления для гипервизоров и разнообразных приложений, которые бэкапятся с помощью Veeam. Если смотреть на них с точки зрения работы с Veeam Backup & Replication, то обновления можно условно разделить на 2 категории: большие, серьезные, привносящие массу изменений – и небольшие.

Рассмотрим сначала первую категорию.

Самые важные обновления – те, которые предназначены для гипервизора. Перед тем, как установить такое обновление, обязательно нужно убедиться, что оно поддерживается Veeam Backup & Replication. Такие обновления привносят множество изменений в библиотеки и интерфейсы APIs, которые задействует Veeam Backup & Replication, поэтому для того, чтобы официально заявить об их поддержке, необходимо обновить код Veeam Backup & Replication и провести тщательное тестирование.

Надо еще иметь в виду, что, к примеру, VMware не предоставляет предварительного доступа к новейшим версиям vSphere для производителей ПО, так что разработчики и тестировщики Veeam получают новую версию одновременно со всем остальным прогрессивным человечеством – поэтому между релизом VMware и официально объявляемой поддержкой обычно проходит определенное время. Количество и разнообразие необходимых к внесению изменений таково, что в простой hotfix уместить их шансов мало – и официальная поддержка, как правило, заявляется вместе с выходом релизной версии Veeam Backup & Replication.

В итоге имеет место тот неловкий момент, когда после выхода новой версии vSphere количество заявок в техподдержку резко возрастает, ибо пользователи сломя голову несутся устанавливать новую версию, и их бэкапы, конечно, тут же немедленно перестают работать. Нам – техподдержке Veeam – приходится разъяснять пользователям, что же именно они сделали не так, просить их откатиться назад (если возможно) или придумывать замысловатые пути для выхода из тупика. Поэтому до установки серьезного обновления обязательно проверяйте его совместимость с работающим у вас софтом, очень вас прошу!

Всё вышесказанное относится и к приложениям, которые вы бэкапите и рассчитываете восстанавливать с помощью Veeam. У линейки инструментов Veeam Explorers тоже имеется список поддерживаемых версий соответствующих приложений, который пополняется с каждым релизом Veeam Backup & Replication. Поэтому до установки новой версии вашего приложения – будь то Exchange, Oracle или SharePoint — непременно перечитайте соответствующий раздел документации Veeam Explorers.

Ко второй категории, т.е. к небольшим обновлениям я отношу, например, новые версии VMware Tools, кумулятивные обновления Exchange, обновления безопасности vSphere, и т.д. Как правило, они не несут с собой каких-то серьезных модификаций, и в большинстве случаев Veeam Backup & Replication не испытывает с ними проблем. (Поэтому для них и не бывает публичных объявлений об официальной поддержке в продукте.) Однако в нашей практике встречались случаи, когда и такие обновления столь значительно меняли привычный ход вещей, что приводили к ошибкам в работе Veeam Backup & Replication. В таких ситуациях после подтверждения проблемы инженеры Veeam стараются оперативно выпустить hotfix.

Тем, кто владеет техническим английскимЕсли вы хотите быть в курсе того, над чем трудятся инженеры и с чем сталкиваются системные архитекторы и специалисты техподдержки, рекомендую подписаться на наши форумы. Каждую неделю для его подписчиков выходит рассылка «Word from Gostev» за авторством TheRealGostev. В ней Антон Гостев, возглавляющий департамент product management-а, рассказывает о найденных недавно проблемах (и не только на стороне Veeam), планах на новые версии и новостях из мира IT. Если вам нужно больше информации, можно проштудировать топики форума – если у кого-то из клиентов обнаруживается проблема с работой продукта после какого-либо обновления, он, скорее всего, уже написал об этом на форум.

Как вы понимаете, патчи и обновления могут привести к проблемам не только с бэкапами, но и с приложениями, для которых эти бэкапы делаются. И тут вам помогут виртуальные лаборатории — Veeam DataLabs. Вы наверняка слышали о функциональности SureBackup, предназначенной для верификации резервных копий. Она базируется как раз-таки на использовании DataLabs, с созданием изолированной среды, в которой можно, в частности, тестировать обновления до установки их в продакшене. Очень советую так и делать – сбережете себе множество нервных клеток. А если кто-то еще не знает о SureBackup, рекомендую почитать документацию.

Пожалуй, на сегодня у меня всё, спасибо за внимание!

Что еще почитать

Статьи на Хабре:

• Случай в Pixar или еще раз о важности тестирования резервных копий
• Особенности долгосрочного хранения резервных копий
• Практические рекомендации по политике резервного копирования
• Рекомендации по политике резервного копирования и восстановления после «Конца Света»

Руководство пользователя (на русском языке)

Источник: habr.com