Сьогодні я знову із задоволенням представляю вам корисні поради від мого колеги Євгена Іванова, тимліда команди технічної підтримки Veeam. На цей раз Женя поділився рекомендаціями для роботи з бекапами та репліками. Сподіваюся, вони допоможуть вам уникнути типових помилок, і ваші репліки та бекапи ніколи не будуть «слабкою ланкою» у процесі відновлення, якщо це буде потрібно.

Отже, ласкаво просимо під кат.

У попередній моїй статті ми розуміли, як оптимізувати навантаження на компоненти інфраструктури резервного копіювання, і розглядали типові помилки конфігурації. Переходимо до іншої важливої теми - грамотної підготовки та виконання відновлення. Її ми теж розберемо на реальних прикладах, із якими довелося працювати команді техпідтримки.

Бекап без рестора - гроші на вітер

До нас регулярно звертаються користувачі, які опинилися в схожих скрутних ситуаціях: необхідно виконати відновлення з бекапу, але при спробі це зробити люди наштовхуються на нерозв'язну для них проблему. І ця проблема - зовсім не відсутність резервної копії, діяльність CryptoLocker або щось подібне. Це «лише» недостатня увага до перевірки резервних копій та реплік на можливість відновлення. Багато хто часто фокусується виключно на процесі створення бекапу, забуваючи про те, що наявність резервної копії – не панацея від можливих бід. Потрібно розуміти, що відновлення - це зовсім інший процес, який має свої особливості, і який обов'язково потрібно контролювати і тестувати до запуску в продакшені. Ось вам кілька показових прикладів:

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

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

Чому не потрібно працювати з репліками консолі vSphere?

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

Якщо ж ви надумаєте включити репліку з vSphere client, то надалі вас з великою ймовірністю чекає низка проблем:

Механізм перемикання на репліку з Veeam Backup & replication (показаний на схемі) для цієї машини вже не працюватиме.
Дані у базі Veeam Backup не відповідатимуть реальному стану ВМ. У найгіршому випадку для ремонту доведеться редагувати базу.
Можлива навіть втрата даних, як у такому прикладі: користувач вручну включив репліку в 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, рекомендую почитати документацію.

Мабуть, на сьогодні у мене все, дякую за увагу!