Отказ от ответственности практически При написании данного текста автор руководствовался следующими ключевыми моментами: 0. Большому числу уважаемых, многоопытных коллег всё это покажется мелочным и не достойным внимания.
Facil omnes, cum valemus, recta consilia aegrotis damus. 1. Некоторому, пусть и небольшому, числу уважаемых, менее опытных коллег это покажется полезным/нужным/интересным.
2. Намеки на устройство для поддержки веса тела пациента при стоянии и ходьбе имеют право на существование, поскольку обходной путь, следовательно, обходной путь.
3. Гугл не знает или я плохо искал.
Но я честно старался.
4. Это мой первый опыт написания подобного, отсюда и комочки в текстуре.
Приветствую, уважаемое сообщество.
Преамбула В инфраструктуре нашей компании есть три параллельных филиала серверов Veeam B&R. Ветви, как мы любим объяснять практически любой инцидент, «исторически сформированы».
Один обслуживает резервное копирование медленно исчезающей фермы виртуализации, оставшейся после слияния компаний.
Вторым было пилотное внедрение Veeam B&R, которое постепенно стало промышленным решением и в настоящее время обслуживает задания резервного копирования и репликации ферм виртуализации vSphere 4.1 (да, все еще работают, извините) и задания резервного копирования ферм виртуализации vSphere 5.5. Третий обслуживает исключительно задания репликации и планы аварийного переключения фермы виртуализации vSphere 5.5. Все это находится в процессе проживания и постоянной миграции.
Честь и счастье администрировать все это богатство на протяжении последних ~5 лет выпало мне как главному администратору виртуализации серверов VMware vSphere, Veeam B&R и Wintel. + Есть коллега в роли администратора резерва.
Во время недавней подготовки к тестированию решения для аварийного восстановления на основе репликации виртуальных серверов с помощью Veeam B&R мы обнаружили непонятное несоответствие между количеством виртуальных серверов, включенных в задания резервного копирования и репликации, и информацией о количестве точек восстановления для этих серверов.
Информацию о количестве точек удалось получить через powershell с помощью оснастки Veeam Backup & Replication Powershell. Случайная проверка количества точек с помощью запроса через веб-интерфейс Veeam Backup Enterprise Manager показала аналогичное несоответствие действительности.
Не то чтобы это сильно мешало жизни или имело существенное влияние.
Но в некоторых случаях это могло привести к неверным выводам — например, при использовании Powershell-скриптов для сбора статистических данных мы газифицировали бы небольшой водоем и могли бы не замечать этого довольно долгое время.
Да и беспокоит, чешется – ну не аккуратно.
Нам нужно это починить.
Администратор резервного копирования в настоящее время проходит обучение вместе со службой технической поддержки Veeam по открытому делу, изучая проблему в рамках заданий репликации.
Я решил покопаться в заданиях резервного копирования на другой ветке Veeam B&R, чтобы не искажать картину, изучаемую ТП вендора.
Момент возникновения расхождений и их причины нам до сих пор неясен.
Если будет точный ответ от Veeam TP, я обновлю текст. Пока я принял для себя рабочую гипотезу: повторные обновления Veeam B&R на месте начиная с версии 7 до актуальной версии 9 update 1, неоднократное изменение настроек существующих заданий и т.д. процессы не прошли даром и предположительно, в базе данных Veeam B&R накопился «мусор», повторяющиеся записи в таблицах.
В качестве СУБД используется MS SQL, теоретически можно покопаться в структуре базы данных, но, перефразируя Арамиса, «…но, правда, я не администратор базы данных…».
Выборочная проверка серверов, включенных в задания резервного копирования, показала, что с данными на точках восстановления все так же плохо.
Позволь мне привести пример: Какой-то виртуальный сервер имяимя включено в задание Veeam Backup & Replication. По информации, предоставленной Veeam Backup Enterprise Manager, у него 36 точек восстановления.
При этом свойства задания резервного копирования по количеству сохраняемых точек никогда не менялись – т.е.
с момента создания задания еще в версии Veeam B&R 7 – и для описываемого задания оно всегда было равно 7. Расширенный список из 36 точек восстановления выглядит вполне «рабочим» — здесь нет сбоев, недоступных частей или чего-то еще, что предполагает повреждение или проблемы с точками:
 |
 |
В основном из-за отсутствия времени на эксперименты.
Нехватка времени вообще была решающим фактором при поиске выхода из ситуации - сразу после невозможности остановить выполнение заданий резервного копирования на неопределенный срок для экспериментов.
КМК при попытке восстановления провалился бы, так как физически репозиторий содержит 1 полную резервную копию, 6 инкрементальных резервных копий и файл метаданных - то есть точек на самом деле 7, считая с текущего дня.
Для 10 мая самая ранняя сохраненная точка была бы создана 3 мая.
А все, что было создано ранее по дате, на самом деле не существует и живет только в базе данных Veeam B&R.
Вот содержимое репозитория для рассматриваемого задания резервного копирования: 
Повторное сканирование репозитория, содержащего файлы резервных копий, не дало результатов, метаданные не обновились.
Большинство заданий имеют файлы резервных копий такого размера, что их просто некуда перенести + N ТБ архивов будут копироваться долго, задание на это время необходимо остановить, а простаивающие резервные копии недопустимы.
Поэтому вариант переноса файлов резервных копий в другое хранилище с последующим выполнением в настройках задачи повторного сканирования хранилища и резервной копии карты не был принят как лучший выход. По этой же причине нельзя удалить все и установить заново, восстановив настройки Veeam B&R из регулярно создаваемой резервной копии.
Пришлось искать выход, который позволил бы решить проблему в, так сказать, достаточно узких рамках.
И, хоть и не слишком элегантно, но нащупывалось.
Алгоритм примерно следующий: 1. В хранилище, содержащем файлы резервных копий, измените расширение имени файла.
— полное резервное копирование - файл метаданных цепочки резервных копий Примечание.
Переименование/перенос одного файла метаданных цепочки резервного копирования в другой репозиторий с последующим повторным сканированием репозитория не помогает. 
2. Выполните повторное сканирование репозитория, содержащего файлы резервных копий.
Мы видим, что одна резервная копия была удалена из базы данных.
3. Верните расширение в имени файлов полной резервной копии и метаданных в хранилище в исходное положение.
4. Выполните второе повторное сканирование репозитория, содержащего файлы резервных копий.
Видим, что в базу данных добавлена одна резервная копия.
5. Проверка виртуального сервера имяимя еще раз и увидеть количество точек восстановления, соответствующее настройкам задачи, и количество файлов в хранилище.
6. В свойствах задания выполните резервное копирование карты в цепочку, импортированную на шаге 4.
Повторяю, решение далеко не элегантное.
При количестве заданий, значительно превышающем примерно 70, в моем случае пришлось бы искать другой путь — от скриптов до переустановки сервера Veeam B&R. Совать свой нос в ненайденные решения, базу данных, мнения, предложения и т. д. приветствуется - fas est et ab hoste doceri. Теги: #Виртуализация #veeam резервное копирование и репликация #vmware vsphere
-
Обзор Surveylot — Стоит Ли Оно Того?
19 Oct, 24 -
«Сначала Количество, Потом Качество»
19 Oct, 24 -
Вустер, Джозеф Эмерсон
19 Oct, 24 -
Ищу Адекватного Работодателя
19 Oct, 24 -
Редактирование Безнадежного Письма Поддержки
19 Oct, 24 -
С Ног На Голову
19 Oct, 24
