Днес отново с радост представям полезни съвети от моя колега Евгений Иванов, тим лидер на екипа за техническа поддръжка на Veeam. Този път Женя сподели насоки за работа с бекъпи и реплики. Надявам се те да ви помогнат да избегнете типичните грешки и вашите реплики и бекъпи никога да не бъдат "слабото звено" в процеса на възстановяване, ако се наложи.

И така, добре дошли под кат.

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

Бекъп без тестове – пари на вятъра

Регулярно получаваме запитвания от потребители, които се намират в подобни затруднителни ситуации: необходимо е да извършат възстановяване от бекъп, но при опит за това хората се сблъскват с неразрешима за тях проблема. И тази проблема не е отсъствието на резервна копия, активността на CryptoLocker или нещо подобно. Това е "само" недостатъчно внимание при проверката на резервните копия и реплики за възможност за възстановяване. Много често хората се фокусират изцяло върху процеса на създаване на бекъп, забравяйки, че просто наличието на резервна копия не е панацея от възможни нещастия. Трябва да разберем, че възстановяването е съвсем различен процес, който има свои особености и който задължително трябва да се контролира и тества преди стартиране в продукция. Ето няколко показателни примера:

На потребителя му отказа да работи критична виртуална машина с размер 20 ТБ. Спирането на работа е недопустимо и администраторът стартира процеса на мигновено възстановяване (VM instant recovery) – след 5 минути машината е възстановена. Но помним, че такова състояние на машината може да бъде използвано само временно – тя задължително трябва да бъде мигрирана на продукционен datastore. А в този случай, както се оказа, възможностите на инфраструктурата не позволяваха копирането на 20 ТБ данни в разумно време. В настройките на процеса на мигновено възстановяване е било избрано да се запазват промените на диска. От: Сървърите Veeam Backup & Replication (в контекста на температурния снимка на vSphere) – следователно, естествено, свободното място на диска бързо се запълни. Когато потребителят се обърна към поддръжката, ВМ имаше промени, които не можеха да се игнорират. Тоест, имаме ситуация, при която не е възможно бързо да се финализира процесът на мигновено възстановяване на критична машина – как да спасим данните?
Признавам, че заради времето не мога да си спомня всички детайли на финала, но помня, че в крайна сметка не измислихме нищо гениално. Клиентите на своя страна нахубаво решиха този проблем, разширявайки диск С: от резервите, копираха най-важните файлове и чак тогава изключиха ВМ и така мигрираха. Общото е, чудото не се случи.
В инфраструктурата на потребителя работеше един домейн контролер и всички компоненти на Veeam Backup & Replication бяха настроени с използване на DNS. Да, точно така, не сте се объркали. Имаше стотици сценарии за развитие, но реалността беше такава: хората планираха ТО и решиха да се прехвърлят на реплика на своя домейн контролер. Те задействат планираното прехвърляне, което всъщност е препоръчително да се прави в подобни ситуации. На първия етап всичко вървеше нормално, а на втория оригиналната ВМ временно беше изключена, за да се прехвърлят остатъците от данни. Естествено, задачата за прехвърляне се провали веднага, тъй като DNS спря да работи.
За щастие, успяхме да се справим с ситуацията, като включихме репликата ръчно от vSphere (всъщност тази операция не се препоръчва да се извършва самостоятелно, както ще видите в следващия пример). Но, както разбирате, процесът на техническа поддръжка беше прекъснат и отложен. Освен това, трябваше ръчно да внесем имената на хостовете в файла C:WindowsSystem32driversetchosts на сървъра Veeam Backup & Replication, за да осигурим коректността при обратното пренасочване.
При един клиент, цялата инфраструктура за резервно копиране беше изградена около магнитни ленти, а на дисковете се съхраняваха само кратки линии с файлове. Когато обаче се наложи да възстановят поредица от файлове от голям файлов сървър, стана ясно, че нито една машина не може да се използва като помощен репозиториум при възстановяване от лента, тъй като на нито една няма достатъчно свободно място. (За директно възстановяване от магнитна лента и с помощта на репозиториум може да се прочете тук. (засега на английски).

Мисля, че в трите примера, потребителите по един или друг начин бяха в плен на илюзии - смятаха, че ако бекъпът е преминал успешно, няма да имат проблеми с възстановяването. Но, както знаете, това не винаги е така, и затова подготвянето за възстановяване трябва да бъде също толкова внимателно, колкото и за бекъп. Първо е важно да се проучи ръководство за потребителя, където има доста подробна информация за различните видове възстановяване. В началото на всеки параграф са изброени изискванията, подготвителните действия и възможните ограничения. Описание на възстановяването от магнитни ленти или от хардуерни снимки на СХД може да се намери в секциите на документацията и в нашите статии на Хабра. Освен това, действията по подготовка за възстановяване на обекти на приложения с помощта на инструментите Veeam Explorers са описани в секцията «Планиране и подготовка» руководства за всеки от инструментите. Препоръчвам ви внимателно да се запознаете с тях — това ще ви помогне да подготвите системата правилно за възстановяване при необходимост. На руски език инструкциите за възстановяване на SQL Server база данни са представени тук..

Защо не трябва да работите с реплики от конзолата vSphere?

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

Ако решите да включите реплика от vSphere client, в бъдеще вероятно ще се сблъскате с редица проблем:

Механизмът за превключване на репликата от Veeam Backup & replication (показан на схемата) вече няма да работи за тази машина.
Данните в базата на Veeam Backup няма да отговарят на реалното състояние на ВМ. В най-лошия случай ще се наложи да редактирате базата.
Може дори да се стигне до загуба на данни, както в този пример: потребителят ръчно включва реплика в vSphere client и решава да продължи работа с нея. След известно време забелязва, че репликата все още се показва в консолата на Veeam Backup & Replication и решава да я премахне поради ненужност. Кликва с десния бутон и дава команда «Изтриване от диска». 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. В него Антон Гостев, ръководител на отдела за управление на продукти, разказва за наскоро открити проблеми (и не само от страната на Veeam), плановете за нови версии и новини от света на ИТ. Ако ви е нужна повече информация, можете да прегледате темите на форума – ако някой от клиентите срещне проблем с работата на продукта след актуализация, най-вероятно той вече е написал за това на форума.

Както разбирате, пачовете и актуализациите могат да доведат до проблеми не само с резервните копия, но и с приложенията, за които тези резервни копия се правят. И тук ще ви помогнат виртуалните лаборатории — Veeam DataLabs. Сигурен съм, че сте чували за функционалността SureBackup, предназначена за верифициране на резервните копия. Тя се основава точно на използването на DataLabs, с изграждането на изолирана среда, в която можете, конкретно, да тествате актуализациите преди да ги инсталирате в продукция. Препоръчвам ви да го правите – ще спестите много нерви. А ако някой не знае за SureBackup, бих препоръчал да прочете документацията.

Мисля, че това е всичко за днес, благодаря за вниманието!