Category: Новости

Много лет назад VMware решили, что неплохо было бы сделать свой бэкап-софт для виртуальной среды. Так и появился VMware Data Recovery.

Софт был несколько глючный, поэтому через несколько версий/лет (и объединение с EMC) VMware похоронило свою разработку и сделало vDP на базе EMC Avamar.

На этом глюки поуменьшились, но VMware и этого было мало, вследствие чего поддержка vDP была окончательно похоронена (в 2019 или 2020 году)…

1. Как-то сдох у меня основной сторадж, на котором лежало все: виртуалки, контроллер домена, vcenter 6.0. Остался жить только vdp и еще один виндовый сервер, лежащие на локальных дисках ESXi. Стоит отметить, что места на локальных дисках ESXi под все виртуальные сервера из бэкапа не было. Но это не стало основной проблемой 😉
2. Я зашел на веб-интерфейс vDP и запустил Emergency Restore трех продуктивных виртуальных машин (топ по критичности). Это была главная ошибка: надо было сначала восстанавливать DC/VC.
3. Три критичных виртуалки восстановились, после чего веб-интерфейс vDP отмер – по таймауту. В течение суток и пары ребутов vDP восстановить его не удалось, пошли в саппорт.
4. Ахмед сказал, что vDP окончательно слетел с саппорта и добавил: “я не гинеколог, но посмотреть могу”. Посмотрел на мое горе, посоветовал развернуть максимально свежую версию vDP и вставить диски туда/либо развернуть vDP 6.1.2 и подоткнуть диски туда.
5. В штатном режиме vDP развертывается (ovf deploy) только через vCenter. 😉 (Ох щит) (это знак, что стоило сесть за чтение документации по развертыванию vDP)
6. Я отредактировал вручную .OVF и успешно импортировал виртуальную машину;
7. Затем я научился менять ip-настройки SLES11 из командной строки;
8. После этого запустился инсталлятор vDP из веб-интерфейса и… напоролся на проблемы с отсутствием записей DNS.
9. Ну вы помните, что у меня рабочих систем нет и я работаю в выжженом поле 😉 Ладно, побороли и DNS.
10. На следующем шаге vDP сказал, что ему нужна для развертывания регистрация в vCenter. АААааааа 😊
11. В силу ограниченных ресурсов я попытался развернуть vCSA 6.0. Ожидаемо встал на грабли плагина интеграции с браузером, который не захотел устанавливаться.
12. Мыши плакали, кололись, но продолжали есть кактус.
13. Я решил рискнуть костями и поставить vCSA 6.5. Да, по матрице он не совместим с vDP 6.1.2, но мало ли что. Впрочем, vCenter развернулся штатно (хоть что-то).
14. Ожидаемо, регистрация vDP 6.1.2 на vCSA 6.5 не проходит. (непереводимая игра слов)
15. Развернул через vCenter vDP 6.1.11 – он нормально прошел регистрацию на vCSA 6.5. С замиранием духа втыкаю в него VMDK от старого vDP и прожимаю импорт. Через полчаса…
16. Через полчаса vDP 6.1.11 говорит, что пароль рута к дискам не подходит. Кстати говоря, эта же проблема имела место год назад. Тогда vDP 6.1.2 не стартовал, импорт дисков не помогал. Тогда vDP мне починил инженер из саппорта (фактически, специалист по Авамару и линуксу, судя по тому трешу, что он творил в консоли)
17. Остается обратно лохматить старый и неподдерживаемый vDP.
18. Обратно включаем с дисками старый vDP 6.1.2.
19. Веб-интерфейс старого vDP открывается, но говорит “ждите до 25 минут, запускаемся”;
20. В консоли старого vDP вижу, что не запускается служба MCS из-за проблем с чекпоинтами. К счастью есть статья в КБ (https://kb.vmware.com/s/article/2053986), служба запускается и…
21. Еще минут через 5-10 запускается веб-интерфейс. И я могу продолжать emergency restore!!!11111

Выводы:

1. Никогда. Не. Используйте. VMware Data Recovery!
2. В DR-план восстановления инфраструктуры заложите восстановление самого сервера резервного копирования в случае какого-либо сбоя. Ну и тестируйте это (DR – Disaster Recovery, восстановление после катастрофы)!
3. Я крайне не рекомендую использование в продуктиве софта, для DR-переустановки которого требуется куча “левых” компонент типа vCenter.

P.S. Впрочем, это одна из причин, по которой VMware “мигрировали” vDP на Avamar. До Avamar vDP метаданные держал в базе vCenter. Нет vCenter – ну вы поняли 😉